Age | Commit message (Collapse) | Author |
|
which simplifies the code and fixes a problem with using
strdup(), because strdup() allocates with malloc, while
unique_ptr will free it with delete[], and we'll get
a mismatch error from ASAN
(spotted by Mike Kaganski)
Change-Id: I0f21828ef3482898b81aa3f0745b2bd855a2c286
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112980
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I57dcc1a247e01f1a31fcadc7f998833af42a0466
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112932
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iecbbc58b52d393840b9e68764de276594a86aa4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112882
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I330e0ab6c9955939dad313f9d472f93e39dbd313
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109924
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If7fbb25037343e18081a8ee7064840d75e9a45a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104010
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This is basically just some refactoring. Most interestingly the
MacOS used to work with 257 glyphs. I couldn't find any
explaination for the 256 glyph limit. Sadly the PrintFontManager
is out of scope. That needs more inspection.
Change-Id: Ibfa0e905f5efeb7d4a609884d64b4ed2615a9d3d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102688
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Tested-by: Jenkins
|
|
Since removed code in the previous commit is primary used in
CreateFontSubset and GetGlyphWidths, you have a high chance, that
the CMAP was already used for displaying a font, so it's already
decoded and can be forwarded. Also the lookup should be faster in
general this way.
Change-Id: Icf4d8a1a84ff6ccdaccb7e870abe5df3837f9541
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102686
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Tested-by: Jenkins
|
|
This introduces a potential performance regression, because
FindCmap works on the existing font tables and just sets up
a lookup function, while ParseCMAP creates some optimized,
in-memory lookup table, which needs a bit more work, but
is faster in its usage, I think. At least the initial usage
is faster the old way, as the CMAPs aren't decoded at all.
As you can see, the old code is just used on Windows and
MacOS / iOS. Deep in the bowels of the PrintFontManager, the
CMAP is also decoded using ParseCMAP...
So I'm not sure this potential regression really exists. Most
fonts will already have a decoded CMAP, so my guess is this
is actually faster in the end. No idea, how to measure.
Change-Id: I52caac1264cd3ff11a2a3fa6e9c800f67f146a79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102685
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Not sure if this is strictly needed, and obviously it will be
"wrong" for a sub font containing just some of the glyphs, but
since other backends also do this, follow suit.
Change-Id: Ib83542b685b38d800d09b7a19780f9ac619c7ad0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102487
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This abstracts the just refactored vcl::TrueTypeFont class, so the
Qt5 backend can provide it's own QRawFont based font table access.
Change-Id: Ic71bc95bc8fe39bc7a32086d4adc78cfa00d15be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100718
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This hides all members, which are needed to create a new TTF font
by calling vcl::CreateTTFromTTGlyphs, and adds an abstraction
to access individual font tables. This is needed, because Qt5
just allows access to the raw font based on font tables.
Change-Id: I74e34cf1aa2529a06ec5ec53aa2be751e58982ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100717
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
...now that macOS builds are guaranteed to have std::optional since
358146bbbd1b9775c12770fb5e497b6ec5adfc51 "Bump macOS build baseline to
Xcode 11.3 and macOS 10.14.4".
The change is done mostly mechanically with
> for i in $(git grep -Fl optional); do
> sed -i -e 's:<o3tl/optional\.hxx>\|\"o3tl/optional\.hxx\":<optional>:' \
> -e 's/\<o3tl::optional\>/std::optional/g' \
> -e 's/\<o3tl::make_optional\>/std::make_optional/g' "$i"
> done
> for i in $(git grep -Flw o3tl::nullopt); do
> sed -i -e 's/\<o3tl::nullopt\>/std::nullopt/g' "$i"
> done
(though that causes some of the resulting
#include <optional>
to appear at different places relative to other includes than if they had been
added manually), plus a few manual modifications:
* adapt bin/find-unneeded-includes
* adapt desktop/IwyuFilter_desktop.yaml
* remove include/o3tl/optional.hxx
* quote resulting "<"/">" as "<"/">" in officecfg/registry/cppheader.xsl
* and then solenv/clang-format/reformat-formatted-files
Change-Id: I68833d9f7945e57aa2bc703349cbc5a56b342273
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89165
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...with a boost::optional fallback for Xcode < 10 (as std::optional is only
available starting with Xcode 10 according to
<https://en.cppreference.com/w/cpp/compiler_support>, and our baseline for iOS
and macOS is still Xcode 9.3 according to README.md). And mechanically rewrite
all code to use o3tl::optional instead of boost::optional.
One immediate benefit is that disabling -Wmaybe-uninitialized for GCC as per
fed7c3deb3f4ec81f78967c2d7f3c4554398cb9d "Slience bogus
-Werror=maybe-uninitialized" should no longer be necessary (and whose check
happened to no longer trigger for GCC 10 trunk, even though that compiler would
still emit bogus -Wmaybe-uninitialized for uses of boost::optional under
--enable-optimized, which made me ponder whether this switch from
boost::optional to std::optional would be a useful thing to do; I keep that
configure.ac check for now, though, and will only remove it in a follow up
commit).
Another longer-term benefit is that the code is now already in good shape for an
eventual switch to std::optional (a switch we would have done anyway once we no
longer need to support Xcode < 10).
Only desktop/qa/desktop_lib/test_desktop_lib.cxx heavily uses
boost::property_tree::ptree::get_child_optional returning boost::optional, so
let it keep using boost::optional for now.
After a number of preceding commits have paved the way for this change, this
commit is completely mechanical, done with
> git ls-files -z | grep -vz -e '^bin/find-unneeded-includes$' -e '^configure.ac$' -e '^desktop/qa/desktop_lib/test_desktop_lib.cxx$' -e '^dictionaries$' -e '^external/' -e '^helpcontent2$' -e '^include/IwyuFilter_include.yaml$' -e '^sc/IwyuFilter_sc.yaml$' -e '^solenv/gdb/boost/optional.py$' -e '^solenv/vs/LibreOffice.natvis$' -e '^translations$' -e '\.svg$' | xargs -0 sed -i -E -e 's|\<boost(/optional)?/optional\.hpp\>|o3tl/optional.hxx|g' -e 's/\<boost(\s*)::(\s*)(make_)?optional\>/o3tl\1::\2\3optional/g' -e 's/\<boost(\s*)::(\s*)none\>/o3tl\1::\2nullopt/g'
(before committing include/o3tl/optional.hxx, and relying on some GNU features).
It excludes some files where mention of boost::optional et al should apparently
not be changed (and the sub-repo directory stubs). It turned out that all uses
of boost::none across the code base were in combination with boost::optional, so
had all to be rewritten as o3tl::nullopt.
Change-Id: Ibfd9f4b3d5a8aee6e6eed310b988c4e5ffd8b11b
Reviewed-on: https://gerrit.libreoffice.org/84128
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
+ add required vcl namespace prefix to a call
from outside in fontsubset.cxx
Change-Id: Ib8d5c2e5a409957221c81b17dafaf3323760e8e5
Reviewed-on: https://gerrit.libreoffice.org/80857
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Following kern table removal done with e3caecb5a33288dd46a80b2ffcc47a2288305052
Change-Id: Ifb42f5dc85e25faf9f1a94db7179b981abb150df
Reviewed-on: https://gerrit.libreoffice.org/80742
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7ee86442cf822a2e866f379a98dae901f5291b8f
Reviewed-on: https://gerrit.libreoffice.org/80741
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Move const in sft.hxx and replace define by static const
Also, fix some errors with data formats
+ TrueTypeTableNew_post definition
Following https://docs.microsoft.com/en-us/typography/opentype/spec/otff:
Fixed = 32-bit signed fixed-point number (16.16)
FWORD = int16
UFWORD = uint16
Change-Id: I8c460e517b9f25077f5ad81a6da656695c8e6fa1
Reviewed-on: https://gerrit.libreoffice.org/80733
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I35bf0cda789cbbaa5272b78b30a58fa8c4d8c08a
Reviewed-on: https://gerrit.libreoffice.org/80726
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Id9c3f96acb7b93c7ef215ae33d98ad17ef45095c
Reviewed-on: https://gerrit.libreoffice.org/80719
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
Tested-by: Jenkins
|
|
Move getting UPEM and font tables to the functions and use HarfBuzz API
to get them. In the future we might stop reading the tables ourselves
and use HarfBuzz metrics API instead.
Change-Id: I3f4511628fd33200bae94cdcd96479ba3e6d2fba
Reviewed-on: https://gerrit.libreoffice.org/78081
Tested-by: Jenkins
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
|
|
Platform-specific subdirs are left alone:
android, ios, osx, quartz, win
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Icbb906b7fbc960240c73c56d3dae2a78b06a0f53
Reviewed-on: https://gerrit.libreoffice.org/73754
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ib19e907a9b6fcce3a3938c5dee29ff658b12e9c4
Reviewed-on: https://gerrit.libreoffice.org/73735
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If9c7c67f48311ac68ecc9f8e3a07f9bb7c73d962
Reviewed-on: https://gerrit.libreoffice.org/61101
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
and only return the advance, we don't use the other field
Change-Id: I956033dac97763caea2b27404fe9f099da809899
Reviewed-on: https://gerrit.libreoffice.org/60703
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I85e364da59ce70ddd97fdae9bc03a4ea76b007fc
Reviewed-on: https://gerrit.libreoffice.org/55263
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
...which was apparently unused (under its original name SF_TABLEFORMAT) ever
since its introduction in 571f15004533c1e7a5472e033139d5765862fb73 "Unix PS-
Print Environment". (Not sure what its appearance in the comment to AddTable,
also there since that introductory commit, was ever supposed to mean.)
Change-Id: I363e21e2e2d23aaf17c6f10b3936ba700203b9eb
Reviewed-on: https://gerrit.libreoffice.org/55020
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ib2f267397e419e8164bb2d732f7cbcca7acad1a6
Reviewed-on: https://gerrit.libreoffice.org/54996
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I1618280494ff10d884a3285501303c6a74ef3542
Reviewed-on: https://gerrit.libreoffice.org/50951
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
TYPEFLAG_PS_OPENTYPE is set but never used, and dropping it means we no
longer need TYPEFLAG_COPYRIGHT_MASK either.
Change-Id: Iefb45b32f53a806f2477ce54b7062b5846a6a806
Reviewed-on: https://gerrit.libreoffice.org/49427
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
|
|
Change-Id: I66b17dbee0a04e61b99e23933a7fed4be30f3a93
Reviewed-on: https://gerrit.libreoffice.org/49426
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
|
|
Change-Id: I6fd7a9fed3a80c91a3766fceefd43c5db0aa5275
Reviewed-on: https://gerrit.libreoffice.org/46763
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
To pass the "Application error: no fonts and no vcl resource found
on your system" failure from OutputDevice::ImplInitFontList.
Just saw there is a SAL_NO_FONT_LOOKUP, which probably also would
have helped.
Change-Id: I2c818313c4f8b0f1d36242281e5c51973315b642
|
|
Change-Id: I7a3eb2bfda869e9e66db919f929ead60cf8890a4
Reviewed-on: https://gerrit.libreoffice.org/44209
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
lots of little fixes to make the logic less pessimistic
Change-Id: If368822984250b11b98c56f5890177a1402e8660
Reviewed-on: https://gerrit.libreoffice.org/44168
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9952ddf0b1256e768a664f4da70455245cf67f41
Reviewed-on: https://gerrit.libreoffice.org/41934
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I993ab0021d0a0bee8e78975bba180355d2bfb19c
|
|
Change-Id: I36afe2107e07ffb9b73c0b76be600e3e999a0fd4
Reviewed-on: https://gerrit.libreoffice.org/40116
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I5a6319ba1667af6e9b7b92c22f858188c28c4c61
Reviewed-on: https://gerrit.libreoffice.org/38835
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7b2680898dbfc49185fb949349d81f4ac615a470
Reviewed-on: https://gerrit.libreoffice.org/38593
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If99a944f7032180355da291ad283b4cfcea4f448
Reviewed-on: https://gerrit.libreoffice.org/36629
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
since we only use the AsciiCString enumerator.
Consequently simplify the GetConnectionIdentifier method
Change-Id: I9e1a1318d2f12bfd18edeb8479e0e7171b22d0f1
Reviewed-on: https://gerrit.libreoffice.org/34026
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
there is only one method using it, and all of the call sites pass 0
Change-Id: I5d71b36cf890fbcf0be9d795756da0cfd61ae309
Reviewed-on: https://gerrit.libreoffice.org/34024
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Idfc964930c242d752a78cd109d75d809bce4de11
Reviewed-on: https://gerrit.libreoffice.org/31470
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
|
|
Change-Id: I820ed3905d18801513b14f535042801023be5538
Reviewed-on: https://gerrit.libreoffice.org/31387
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
|
|
Change-Id: I0cd6213f58e8b2d3d5950dfbb12e524de2950265
|
|
We current use platform APIs to calculate line spacing, however
different platforms behave differently:
* FreeType and Core Text will prefer hhea table over OS/2, and OS/2 Typo
metrics over Win ones.
* GDI’s TEXTMETRIC only uses OS/2 Win metrics, while NEWTEXTMETRIC seems
to use Typo one, but we use only the old TEXTMETRIC.
So we get inconsistent line spacing and we have no control which of
three competing sets of line spacing metrics we end up using.
The current conventional wisdom is that:
* hhea metrics should be used, since hhea is a mandatory font table and
should always be present.
* But if OS/2 is present, it should be used since it is mandatory in
Windows.
OS/2 has Typo and Win metrics, but the later was meant to control
text clipping not line spacing and can be ridiculously large.
Unfortunately many Windows application incorrectly use the Win metrics
(thanks to GDI’s TEXTMETRIC) and old fonts might be designed with this
in mind, so OpenType introduced a flag for fonts to indicate that they
really want to use Typo metrics. So for best backward compatibility:
* Use Win metrics if available.
* Unless USE_TYPO_METRICS flag is set, in which case use Typo metrics.
This patch does this by reading the hhea and OS/2 tables directly and
implementing the algorithm above.
Quick comparison with Microsoft Office 2016 shows similar line spacing
as the new line spacing here, so I guess we are improving compatibility
as well.
Change-Id: I4541e67e3e14508e3529e73083056a09de02e637
Reviewed-on: https://gerrit.libreoffice.org/31053
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
|
|
Change-Id: Icb074b628ae479dfe05cc1fe10121f96c492806e
|
|
The getTTCoverage either leaves the bitset empty or inits it with 128 bits,
so it's not particularly dynamic.
Change-Id: Iac0aa6a023acc54da86d681e75ca550faf91ef26
Reviewed-on: https://gerrit.libreoffice.org/25456
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I6c0aaac10b2244271f3cdf45f4eceb6d685b213c
|
|
stage 2 of replacing usage of various checks for the windows platform
with the compiler-defined '_WIN32' macro
In this stage we focus on replacing usage of the WIN macro
Change-Id: Ie8a4a63198a6de96bd158ecd707dadafb9c8ea84
Reviewed-on: https://gerrit.libreoffice.org/22393
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|