It is inherited per CSS Fonts, so the children of a group must inherit
it when set on the group.
Change-Id: I3a7f1c58b249e0d647c3b8a15f9e2043b7d6c891
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209212
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
Tested-by: Jenkins
We added a rectangle using PolygonHairlinePrimitive2D to the
HiddenGeometryPrimitive2D, so we can mark the boundary of the
SVG image. The problem with using the hairline primitive for this
is that the hairline size is grown by 0.5 in each direction
(implGrowHairline, which is called in getB2DRange), which also makes
our SVG size 1px bigger than it should be.
Using FilledRectanglePrimitive2D instead fixes this problem as the
rectangle isn't grown in size.
Also needed to change a lot of tests that were using SVG images
and asserted the size of the image in ome way.
Change-Id: Ic2aa98b3df1f0746e4cfbd3474b6a93d0f4072ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200440
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit aa2c07951b565cd5464a36a2b0721f888ab8531c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200433
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
And not truncate it to an integer value.
Add additional overload for attribute that takes an enumerated type, otherwise
the compiler will complain about ambiguous conversion because it cannot
choose between the attribute that takes a integral value and the one that
takes a double value.
Change-Id: I9eae22817ec3b26da7b9468d1c8b5e6f3e900538
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201193
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
This commit fixes the incorrect positioning and scaling of Metafiles
rendered via EMF+ DrawImagePoints.
Key changes:
- Implemented a normalization matrix for Metafiles to properly map
source coordinates (SrcRect) to the destination.
- Updated EMFPImage to parse and store bounds from nested EMF headers,
ensuring correct dimensions (x, y, width, height) are available.
Change-Id: I07b4d99c334611a10e7faff42b76699f04fa1520
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201084
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
because we run this test with set_non_application_font_use=abort so we
don't expect any glyph substitution, and the default setup is without
any bundled Japanese font.
Change-Id: I2e7ead7404fbacb768c06502a52cde629c1a1116
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195407
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
SubpixelPositioning was until now activated when *any* MapMode was set,
but there is another case this is needed: When a TextSimplePortionPrimitive2D is rendered by a SDPR.
In that case a TextLayouterDevice is used (to isolate all Text-related
stuff that should not be at OutputDevice) combined with a 'empty'
OutDev -> no MapMode.
The DXArray for Primitives (see that TextPrimitive) is defined in the
Unit-Text_Coordinate-System, thus in (0..1) ranges. That allows to
have the DXArray transformation-independent and thus re-usable and
is used since the TextPrimitive was created.
If there is a DXArray missing at the text Primitive (as is the case
with SVG imported ones, but allowed in general) one gets automatically
created during the SalLayout creation for rendering. Unfortunately there
(see GenericSalLayout::LayoutText, usages of GetSubpixelPositioning) the
coordinates get std::round'ed, so all up to that point correctly
calculated metric information in that double-precision dependent coordinate space gets *shredded*.
To avoid that, SubpixelPositioning has to be activated. While this
might be done in the future for all cases (SubpixelPositioning ==
true), for now add this case for all usages of TextLayouterDevice to
not break old stuff.
NOTE: Due to higher precision I had to adapt some values for SVGIO
tests: That is expected since higher precision leads to less-wide
results internally. I checked testdocs that deviations are minimal and
have better quality with SubpixelPositioning then before.
Change-Id: Iab5aa6336cdb18224fd06472bf6badc9eb0fce3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189993
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
These are only sent to an external API expecting char*-like strings,
or for comparison. Having every assertXPath having three of _[ou]str
is too much syntactic noise, making the unit tests almost unreadable.
Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Partially revert 56039daae4
"tdf#149673: only check opacity from parent..." to make
getOpacity behave as before and move the new behaviour
of getOpacity inside add_postProcess
Change-Id: If475cddbc4967308fa06adacda621cb3790c6f70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170376
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
it was caused by 98935eef13
"tdf#159661, tdf#160773: svgio: Add unittest"
and 7f64148507
"Fix a thinko in 8a97f1ba8d9ccb65b2c89106de20666311d90c30"
This partially reverts d984836834
"Fix unit test after commit 98935eef13c7d755221d79fe7d3c5869a40a7c37"
Kudos to Mike for keeping Jenkins happy
Change-Id: I034759b2cd95cbaaeb84ec1b528bf5b61487a1e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166591
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Similar to commit cfa9990d47 (Enable
this test on all platforms. 2024-04-20), it seems that 'mask' gets
exported inconsistently. This patch workarouns the problem; a proper
fix would be finding the real cause.
Change-Id: I94c89442aa0385262fba67ec58c9d8d12ffbea27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166573
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Previous code tried to hack some tricks to restore whitespaces after
trimming them according to the xml:space attribute value. But it was
wrong in multiple ways.
1. The collapsed space must stay in the block where its start was.
When a block ended with a space, then trimming the space from it,
and adding to a next block, can change the size of the space.
2. The shift of a line (e.g., specifying x and y values) doesn't end
the logical line. A space before such a shift must be kept by the
same rules, as if there weren't a shift.
3. A block with xml:space="preserve" is treated as if it consists of
all non-whitespace characters, even if its leading or trailing
characters are spaces. I.e., a trailing space in a block before,
or a leading space in a block after, should be collapsed into a
single space, not removed - even when the space-preserving block
itself is made invisible.
Change-Id: Ic778d1e9d6b9d0c342ea74ad78d44bb47bc8d708
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166239
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Opening an SVG with text in different elements (e.g., tspans) in the
same text element performs calculations to position the parts properly
(i.e., the next part will start where the previous part ended, unless
the position in overridden explicitly). These calculations require to
know the text widths. The first problem leas here: the text width was
calculated for a typically small text size (numerically equal to the
pixel size defined in the SVG), but these calculations aren't truly
linear, because font rendering may change depending on font height.
Additionally, the rounding gives much higher error in smaller sizes
than in larger. There was already a workaround for a similar problem
in ViewRedirector::createRedirectedPrimitive2DSequence, where a large
font (with 100 times greater height) was used to increase correctness.
This was also used here, with the same large height (50000) used as a
reference.
Then, at the time of wrawing the text at different zoom levels, the
code in VclProcessor2D::RenderTextSimpleOrDecoratedPortionPrimitive2D
creates a font of a calculated size, and uses it to output the text.
But the font is always created with an integral height, which means,
that for a wanted height of 2.5 (in a zoomed out view), the really
used height will be 3, which is 20% larger; or for wanted height of
2.4, the actual height will be 2 (20% smaller). This resulted in odd
jumps of the text widths, when the text may overlap the following
part, or conversely, create a big gap before the next gap. To try to
mitigate that, the function now takes the difference between the
wanted and the actual font size into account, and adjusts the MapMode
accordingly. This doesn't fix the jumping completely (e.g., because
of the mentioned special handling of small font sizes in the fonts
thenselves, like hinting), but still makes the calculations much more
stable, decreasing the amount of jumping. Similar changes are made in
TextLayouterDevice.
Use of the functions that return text size as a double, not rounded
value, should additionally help improving stability.
Change-Id: I455845d8ca43ee9c06a0fc980947f35d8a25797a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166238
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This avoids premature rounding in TextLayouterDevice::getTextBoundRect.
The box in D2DWriteTextOutRenderer::performRender needs to be expanded
to allow room for the line width (which now will be guaranteed on all
sides; previously, the rounding could happen to give no room on some
side, even prior to commit 8962141a12).
Fixes some lines partially cut off in smaller text (or zoomed out).
Change-Id: I07335136021f894cf045363b4d736bfab06c64d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166236
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
For now, only use language tag, meaning if
there is a file like in the unittest with
<text systemLanguage="en-us">Howdy!</text>
<text systemLanguage="en-gb">Wotcha!</text>
<text systemLanguage="en-au">G'day!</text>
<text systemLanguage="en">Hello!</text>
"Hello!" with be displayed in a en_AU system locale
This patch partially reverts 13a41e7a12
"tdf#150124: do nothing when parent is of unkown type"
making 0dfd8288a8
"ofz#60384 Direct-leak" no longer necessary
Change-Id: Ifc73bc69aa997088dc0a2b11d7d30446303fa3b3
Change-Id: I885ef0f2c44b86196881fe55a963db2e5c7eb1be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165394
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>