Use #pragma once instead of header guards
Change-Id: Iba43f2103628ed184933cf2611991e7aef9f0173
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173369
Reviewed-by: Tomaž Vajngerl <quikee@gmail.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
which indicating unit test fails.
Change-Id: I2689b0dda888e15e52ca60cc18e1705a1aefe968
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173143
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Tested-by: Jenkins
These will never compare with tolerance (the zero is a special case
in rtl_math_approxEqual used internally), so the calls like those
don't do what they appear to do in these cases.
Change-Id: I495ac92b7f45637e118e4fdc04bb6fad6fff31ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171391
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
you can find more about the sad story behind this color
in the internet
Change-Id: I0aa201bdc62aebe96f0ae764a359f1f6286027d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169544
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>
This is the way it's done everywhere.
Partially revert 4b6e0f2c88
"tdf#160726, tdf#48062: Simplify how BitmapExs are created"
Change-Id: I15fea0b6855a65da7cb48b24fc00ba303e33dcf8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166456
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
This is needed after 4b6e0f2c88
"tdf#160726, tdf#48062: Simplify how BitmapExs are created"
Otherwise, only the common area is displayed
Change-Id: I40c798380049e62df8729c4acdb5db50d988d8e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166426
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
In my initial approach, I tranformed the primitive2DContainers
before converting them to BitmapEx. This caused circles like
https://bugs.documentfoundation.org/attachment.cgi?id=193790
not to be displayed.
Simplify how BitmapExs are created by just using the range both
primitive2DContainers have in common. This way, DrawBitmapInRect
can be dropped now
Change-Id: I2401dc87b98e04b9cf9f5ebade2b5622d884fc3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166391
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
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>
Same as in commit e275726861
(tdf#160593: make sure to use current element's font size for em unit,
2024-04-18) for em.
Change-Id: Id9003c0426a6b373456da1aa1550f7ff07f766a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166235
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This fixes the error of identical treatment of em and ex in font-size,
which violated https://drafts.csswg.org/css-values-4/#font-relative-length.
The fix uses the fallback of 0.5em for ex, similar to the code used in
SvgNumber::solveNonPercentage. A follow-up should implement the correct
use of "x-height of the first available font".
Change-Id: Id9d581994e158d629d9752299ad93ac7e9fe4cad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166234
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
According to https://drafts.csswg.org/css-values-4/#font-relative-length
em is "equal to the computed value of the font-size property of the element
on which it is used". This means, that for an element that defines its own
font-size, attributes like 'dy' using em refer to the new font-size, not to
inherited font-size.
Change-Id: Ie5a013df99a68edddf466e4c0ee5311f6219fcb2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166233
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
