This code is bogus in multiple ways:
* It scales text based on ascent or descent, but this makes no sense
as those control line height and nothing else, if one is to scale two
different fonts to “fit” together, cap or x height would be more
appropriate. This results in some text being ridiculously shrunk.
* Not only that, but it is comparing apples to oranges; original font
ascent/descent with the bounding box of the fallback glyphs, which
results in different scale ratios depending on the shape of the glyphs
at hand, which leads to all sorts of funny and irregular text.
* Even worse, the PDF export is completely broken in this case; it uses
the scaled down glyph widths but the unscaled font size, resulting in
cramped unreadable text.
Change-Id: Iaa6117ecfdad8388887d9a03b538e7327544ad5e
Reviewed-on: https://gerrit.libreoffice.org/4293
Reviewed-by: Bosdonnat Cedric <cedric.bosdonnat@free.fr>
Tested-by: Bosdonnat Cedric <cedric.bosdonnat@free.fr>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Core Text does not fake missing italic and bold (unlike ATSUI), so we
have to do it on our own. This commit handles fake italic, bold is a bit
harder.
Change-Id: I4e705669638f67e3c8ec414f2cadd0c6daea9bcb
Commit e717d1dcce7f8906311c5ccdbb2326b61a702630 interacts badly with
commit 7b2a0e541567be9750dfc7d98374555967da3470:
the newly added "long" variables serialized to SvStream with
operator>>/<< now read/write 8 bytes.
Using "long" for binary serialized integers is an idiotic idea in the
first place.
Change-Id: I9432c1bb2c339e797c064371f2cbdcfec2200994
This is "collateral damage" from the actual bug, and is broken since CVS
initial import (which likely means that in practice no bare MetaActions
exist), but the MetaAction::Read() must not read the type from the
stream since MetaAction::ReadMetaAction() has already done that!
Change-Id: I9ab06ec3112c1eefb86ab70ddfa2f588af257b88
When drawing right aligned text, rounding errors in the position
returned by GetDrawPosition() cause the right margin of the text to
change whenever text width changes causing "jumping letters" effect. So
here we calculate the drawing position relative to the right margin on
our own to avoid the rounding errors. That is basically a hack, and it
should go away if one day we managed to get rid of those rounding
errors.
Continue using GetDrawPosition() for non-right aligned text, to minimize
any unforeseen side effects.
Change-Id: Ia095a17a41f723f5fb7afc99df4250262e9a0051
This patch fixes horizontal scrollbar in Calc when a sheet is RTL and UI is LTR.
When a particular window (horizontal scrollbar in this case) is RTL and a whole
UI is LTR this code used for mirroring and re-mirroring back coordinates. AFAICS
mirroring is correct, but re-mirroring is not.
The used formula comes from commit 69b684b12e42bf1396bdffca88ca880ac3c2e00b, and
the same formula appears in the other variant of overloaded function "mirror":
mirror(sal_uInt32, const SalPoint*, SalPoint*, const OutputDevice*, bool),
but it does not affect the bug.
Change-Id: Iec9c53edce9d33be6b676d1094bed8bf92f2e435
returning false here in getNativeControlRegion results in a fallback to
square buttons in vcl scrollbar code. But there is no problem in gtk+ backend
in this case, let's fix the problem differently.
This reverts commits 898a3e84807bccbb876e3f5583728f6d24e05e9a and
e8e82bd2109b82ddd535cdac30303249c6b62942.
Change-Id: I66fcdd1f27d471321852445e5881cee03baef7b1
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>
Besides, it caused a WaE: format '%d' expects argument of type 'int', but
argument 3 has type 'sal_Int32 {aka long int}'
Change-Id: Ib0360816e7d0a4829aff4267aa922269950d520c
The >>operator of SvStream doesn't initialize a variable if the stream
is faulty. So initialize the variables before usage to prevent accidental
matches. Also explicitly check stream status in while loop to prevent
looping on eof or error.
Change-Id: I21c0acc1c9217b4523c593cbcef5718f4cdc7597
Reviewed-on: https://gerrit.libreoffice.org/4469
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
AquaSalGraphics::drawPolygon() should close the path like other polygon
drawing functions. It have been like that for 5 years since
3ca40fb8a2e8c805517b351ebd97c1385cfc92a3, no idea how it was never
noticed.
Change-Id: Ifba740afa66ad485943c7873d78e007b778cd7b3
Reviewed-on: https://gerrit.libreoffice.org/4448
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
Apparently we need to subtract the trailing white space from the desired
line length or text will sometimes protrude to the margin.
Change-Id: Iee5ef40670c2fefc189afa319387b180c4ed648d
