...the original code was riddled with errors. It leaked memory, which if it
didn't it would have deleted multiple times.
Change-Id: Ic70b425fac02ef894e35b3dc15039d217f8870f5
The afm dirs are misdetected as having had something in it in the past and
having nothing in it now.
AFAICS it seems that this particular code has always been like this, so keeping
this fix separate for master only.
Change-Id: I8960d0b0d22ee24d5691eecdce262011dc141ea6
...in files generated by gperf; an alternative could be to use -isystem instead
of -I in gb_Library_use_custom_headers.
Change-Id: I316684ab5342977655a5642903b13e127adaf95c
Ealier version of PDF standard allowed for not embedding the so called
standard PostScript fonts in the PDF files and all PDF readers had to
include them or a "suitable substitute". This behaviour had many issues
and is deprecated for 10 years now. The current version of PDF spec
says:
Beginning with PDF 1.5, the special treatment given to the standard 14
fonts is deprecated. Conforming writers should represent all fonts
using a complete font descriptor. For backwards capability, conforming
readers shall still provide the special treatment identified for the
standard 14 fonts.
This commits removes support for not embedding these fonts, and the, now
redundant, option to embed them.
This has the side effect of elimanating the cause of fdo#66108 and
fdo#41547.
Change-Id: I4f1fc4137a2de7baeef9e504f2e4f84fbec0a491
Reviewed-on: https://gerrit.libreoffice.org/4495
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Stupid me, I totally messed this up! God only knows how many non-bugs
people had to fix because of this typo.
Has the side effect of fixing fdo#64972 (among many others of course,
but this is the only one still open).
Change-Id: I9d8fdb6d37d4af9b0ac973902e469e0bd3a2408a
...which has become necessary since bd60d41176da540b01d7583cfe00637431967f39
"Handle oveflow in O(U)String::toInt() functions" reduces values in the range
(SAL_MAX_INT32 .. SAL_MAX_UINT32] to zero, but some calls of toInt32(16) relied
on getting a correct (unsigned) value for the whole input range ["0" ..
"FFFFFFFF"] (see libreoffice-4-1 commit 9bf6c83367cedb7be81bf67f30d2147d26c7a8c3
"Revert overflow checks in O[U]String::toInt{32,64} again").
Audited all uses of toInt32/64 with non-decimal radix. (There is still a TODO
comment in oox/source/helper/attributelist.cxx, and
stoc/source/typeconv/convert.cxx will still need some love and test code.)
Change-Id: Iadaca1c0e41dab553687d0ce41c20c10cd657a95
We need a way to recognize non spacing marks in fonts lacking GDEF table
(like old Arabic fonts), so I just check for zero advance width and hope
nothing elsewhere will break...
Change-Id: I6fa848e97ba24d71fc9a381ae439e0fb98e50419
I was overloading ApplyDXArray() with a HarfBuzz specific implementation
because the GenericSalLayout one was screwing right to left kerning, but
it seems to have broken left to right full justifications. Since
mnXOffset was introduced a bit earlier to fix a similar issue, it can
now be used here as well to minimize the possible side effects.
Seems to work fine for both left to right and right to left text now,
but at least one of my Arabic tests is regressing, so might need some
tweaking.
Change-Id: I1239b0ec77a4978f981a480400a6d01cda18af79
FcGetLangs() will return a new FCStrSet that needs to be freed after usage.
Change-Id: Ie7fe0dd160fa59077d6a90878e70d0e034680812
Reviewed-on: https://gerrit.libreoffice.org/3967
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
Both were CompareIgnoreCaseToAscii( "starsymbol", 10) which is
startsWithIgnoreCaseAscii.
Fixes 7d1f4cdec307bb1e761bb5dd3d8231bba5833e10
Change-Id: I21e2eb8c578b65d5f0e4181ed64af02ec480463e
We don't actually have any implementations of this service.
This service was introduced by
commit 01cf481111436df2cc3f01d1c57cc4348fc037ef
Author: Kurt Zenker <kz@openoffice.org>
Date: Wed Jun 20 09:07:44 2007 +0000
INTEGRATION: CWS compmetric (1.77.2); FILE MERGED
2007/05/09 16:27:46 pl 1.77.2.2: #146890# algorithm is needed
2007/05/09 12:13:59 pl 1.77.2.1: #146890# backwards compatibility service for metrics
Michael Stahl seems to think it was a Sun-internal hack introduced
for a specific customer.
Change-Id: I1b27778f827504c2adb0e27e8d7c0f0dedcaf940
Reviewed-on: https://gerrit.libreoffice.org/3824
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
...so move it from osl/mutex.hxx to its own comphelper/solarmutex.hxx. It looks
like a newbie mistake that 59e7685d8d812ee8773f57475cbe3aa2a0bdfc81 "Create an
abstract interface to be used to implement a SolarMutex" put it here in the
first place.
I do not consider this an incompatible change really, as no external URE client
code should have used SolarMutex anyway.
(Also included some clean up, like removing unused
{Clearable,Resettable}SolarGuard, and spelling out SolarGuard in the few places
it is used.)
Change-Id: I121ffb5b7cefbc19e88b5405e5a85ffc895be852
Which in itself was effectively a revert of
3364fefe1e2dec522211040f2f9ea37bf5cd7466
Keeping the old broken line height calculation code is just masking of
the real problem; there are some code elsewhere that have fragile
workarounds to the real bug here (the removed code here shows a good
example of such workarounds). On Mac we use the correct metrics as well,
so we need to find the quirks and fix them, instead of pretending they
do not exist.
This fixes fdo#55469, among others.
Change-Id: I36f13b28eaba022b7c388feae7e0bfd0ed1c3e89
HarfBuzz integration should be functional now, so to give it more wider
testing it is made now a required dependency on non-Windows non-Mac OSs.
By default text layout is now done by HarfBuzz but ICU LayoutEngine is
kept as a fallback and can be enabled with SAL_USE_ICULE env variable.
After 4.1.x is branched, ICU LayoutEngine should be removed completely.
Change-Id: I4fe3beeaf6092f33dd436906c11b83aeafdfbd5d
It turns out storing the width in the layout is not so good idea,
because in some mysterious cases when font fallback is involved we call
GetTextWidth() without calling LayoutText() first, and we return the
width of the previous text run.
It seems all I needed is to pass down the X offset with the glyph item,
and take it into account when calculating the width.
Change-Id: Idbdb6bba00573fb6ca773701757d667e21ac0912
