Age | Commit message (Collapse) | Author |
|
Change-Id: Icd08628848cce74407552f57660d75b1ac9816bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143009
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I8846c89d51cc33022f90c3a9c03bc1560497e651
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139701
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@aliftype.com>
|
|
Change-Id: Ida81135280ff61c3a8e96e8f5ed977959e169f61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139716
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I3b1beb5e976a255ef8ecdf8670b1e59547ec5ea4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139700
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@aliftype.com>
|
|
Change-Id: I2140b7b48ee4cc46a4a6e8e4719f3ce78a600829
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139624
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@aliftype.com>
|
|
Implement PhysicalFontFace::GetFontCharMap() on top
hb_face_collect_unicodes() so that it is the same charmap as what
shaping code will actually use.
Change-Id: I486e9d296cec5bd897e4f628d14a2f19e63b70b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139623
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@aliftype.com>
|
|
Change-Id: Icf687d09c2d25a3d578faf7ae574b3e655b8540f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139600
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@aliftype.com>
|
|
Change-Id: I0bad93927248e5d8d19a69661a1b243e55791fd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117889
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
This reverts commit 59887868da3499c68d5f259cfa48178354397448.
Change-Id: I0f3f6a7680c78103a559a0f881badc8211b97ace
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90544
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
improve the script, but it still generates some false positives
Change-Id: If8ee1cba8c04ac0be11f73220149e6de15f24f44
Reviewed-on: https://gerrit.libreoffice.org/81929
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1072642be4fdfa720e61f2d7bad3c2701eb81610
Reviewed-on: https://gerrit.libreoffice.org/60430
Tested-by: Jenkins
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
|
|
of include/vcl/window.hxx and include/vcl/vclevent.hxx
Change-Id: Iacb3cc942693a732de5899af26e08e0977a83102
Reviewed-on: https://gerrit.libreoffice.org/37338
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
|
|
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
|
|
Change-Id: I4c913dc62efe3f3747e78670f4efb0216d95c4ad
Reviewed-on: https://gerrit.libreoffice.org/28585
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I4258bcc97273d8bb7a8c4879fac02a427f76e18c
Reviewed-on: https://gerrit.libreoffice.org/27317
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I8d401e95b69feb710d450768e3b9ac9d22b896ca
|
|
Change-Id: I6173cd191cd771b1f030fa737617b1067278ee10
Reviewed-on: https://gerrit.libreoffice.org/21338
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
|