| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
after
commit 664ecbd8916478cdc28a9c793fbdb9359b3cac64
Author: Noel Grandin <noelgrandin@gmail.com>
Date: Wed Nov 20 16:08:14 2024 +0200
remove OutDevSupportType::TransparentRect
Change-Id: I57804ec9e9967c7082a1f657165d967d75b1dedf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176910
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
Change-Id: Ib14a2e6b41165887fcf99c3d155850faa8564822
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176218
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which allows us to eliminate a bunch of rounding at various layers, and
consequently maintain a lot more precision
Change-Id: I911dedd7c041c1d67396c082e5695346ea689acb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175814
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I39388963a7e9b37c91e6b39e0af68a21de114431
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174344
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I2758c5ebacea4917beb3bedd96fa01f8e4ad2917
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174346
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Added general interfaces to be able to render directly
to an RGBA target SDPR:
- processor2d::createPixelProcessor2DFromScratch creates
a target-SDPR with given pixel size and RGB or RGBA,
owning and using a cairo surface internally
- processor2d::extractBitmapExFromBaseProcessor2D extracts
rendered content to BitmapEx, including alpha
All this is currently only implemented for Ciaro, thus
the internal impls are encapsulated by USE_HEADLESS_CODE,
but already created gererally available. The return values
have to be checked to see if an evtl. shortcut is possible.
For convertToBitmapEx this means that it can do conversions
much faster than up to now for cairo when CairoSDPR is
available, else it has to to the older slower way that
also works and is the default: Create RGB content, create
Mask, RemoveBlendedStartColor (see convertToBitmapEx
implementation). This works and has the same quality,
but needs two renderings and one bitmap operation, thus
is clearly slower.
Note that these interfaces can and will be supported for
other SDPR implementations in the future, thus will make
this converter automatically faster on systems where we
will have a SDPR in the future, too.
Also note that this is the gereral converter from
a sequence of Primitives to Bitmap data, already used in
many places, inculding UNO API, thus is expected to have
some impact on conversion efficiency - if Cairo is used,
so e.g. also headless.
Change-Id: Ia638a549a04b19622892d91651317ec6727b6cd0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174266
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
|
|
Unfortunaletly we have 'virtual' OutDevs, that means their
PixelSize is bigger as they claim and they use an internal
offset. This is used to not have to create too many Windows
inside Windows (AFAIR initial reason was that Windows has
a fix number of Windows per process that can be incarnated).
The offset was/is already supported by SDPRs using
ViewInformation2D and adding ot to the ViewTransformation,
but the evtl. existing PixelSize has to be clipped against.
The fallback VclPixelProcessor2D supports that indirectly
by doing that in the OutDev commands that get called, so
it does not need to be done by that renderer.
I have now added code to support that for the
CairoPixelProcessor2D, see code and comments. It uses an
existing method of cairo to do that elegantly inside the
system-dependent code of the SDPR.
Note that the Windows SDPR D2DPixelProcessor2D will
have the same problem that will have to be solved there,
too. Since it's currently in experimental state I made
myself a note about that.
Change-Id: I68915985102bb4a63c84299f8d022ab013633510
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173998
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Use static_cast instead of dynamic_cast when it makes more sense
to do so and use auto to make the code more readable (when we
write the type 2 times).
Change-Id: I433885ab11437b1e086e0b8e255ed9dbe7e43b90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173978
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
|
|
This is to check all builds/tests with activated
CairoSDPR to evtl. make needed additional changes
as preparation to activate this in the future.
adapted for testTdf139000():
Use no AA offset (0.5) for applying mask.
Adapted for testDoublePixelProcessing:
The trick (hack) to create a PixelProcessor and then
attact a metafile to start recording to it does no
longer work/make sense since the VclPixelProcessor2D
is no longer the only PiyelProcessor you might get.
If it is a SDPR one (e.g. CairoSDPR) it *cannot*
record metafiles - and is not intended to do so.
Since this test was already adapted 6 years ago to
the modernized decompose of a double line to just
two lines anyways it is OK to now change to use
a VclMetafileProcessor2D now initially.
Adapted for CppunitTest_svgio:
In SvgFeBlendNode::apply execute the calls for
convertToBitmapEx without AntiAliasing to get better
edges. Input data is SVGToken::FeFlood, so a
rectangular area, so no AA needed.
Taking this back: The reason must be in the renderer,
nothing else changed. Debugged in detail through
both, problem is that VclPixelProcessor2D ends up in
CairoCommon::drawPolyPolygon and draws the polygon
AntiAliased, but just the fill and thus *not* with
the AA-offset of 0.5, that is only done for fill.
I have to re-consider the AA offset decision for filled
polygons. Checked CairoCommon again, indeed AA offset
is ony done for lines, not for fill - that corresponds
with my thoghts from the weekend. Somehow this must
have come in with copy/paste (?). Same is already
in D2DPixelProcessor2D, have to remove there, too.
Adapted for CppunitTest_sd_png_export_tests:
This was a hard one, debugged all the components used
for ConvertToBitmap/MaskCreation. Cumulated to be
some diff in processTransparencePrimitive2D, but
found no error after checking all tranmsformations.
The orig errof ro the failing test (tdf#158743)
seemed to give a hint, but ObjectTransformation
was just handled well. At the end the diff was
that VclProcessor2D uses the same processor, while
CairoPixelProcessor2D creates local instances
(what is cheap). Thus the content rendering for
TransparencePrimitive2D was *not* using the set
BColorModifierStack. Added as needed to be able
to transfer that to the content rendering
instance.
Adapted for CppunitTest_sd_png_export_tests:
Gerrit says PNGExportTests.cxx:1041 asserts,
but I cannot reproduce. Maybe at the build
system a slightly different font is used.
My only idea is to add the mentioned point
at (12,120) to the rectangles, obviously the
bottom one.
Next one is (13,82), again bottom one,
adapting.
Adapted for CppunitTest_sw_ooxmlexport16:
The test 'testTdf136841' uses a WMF that contains
XOR paint parts. This showed that that part in
CairoSDPR did not work yet as needed. Adapted
that, also the test slightly due to the color
result slightly changed with CairoSDPR.
One last change before activating in master: Add
DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER in
case it urgently needs to be switched off or to
be able to simply test if something happening is
related to CairoSDPR
Change-Id: Idb8237a05d7594efe20edfa1707ca0002185645a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173330
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I7ce859d402626da156ff36247d987a3fe3010e47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172837
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I14d477dbeb9a18cc6f9d750b5d1f837117c22eaf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172798
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
- Add new text Glow effect properties for shapes
- Using TextGlowPrimitive for rendering uniform text glow in shapes
- Add/allow new UI Glow Effect for texts in shapes on sidebar
(Only for Impress/Draw and Calc)
- Import/Export ooxml files with Glow effect on texts in shapes
(Only PPTX/XLSX)
- Import/Export odf files with Glow effect on texts in shapes
- Add unit test for glow text attributes in ODF
- Add uni tests for OOXML import/export
Note: Also this patch effects on
tdf#144061 - Effects: Allow GLOW to apply to Text (as we have for shapes)
Change-Id: I16586c01654f197f532129e4e06aa2ef9f214395
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172216
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
Change-Id: If739dd9f28f56874978c7b3a76e1234e5f430c9f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172319
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I7fb1c885e46a23e999ea4c98a73d3d526a2923e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172245
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: Idcb33e0f799b2219a4e737d0421bc21d85b5c7aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171915
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
|
|
and
cid#1616499 COPY_INSTEAD_OF_MOVE
Change-Id: I21b089cab036902a7ba5b725a6eae0f1212f2b31
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171923
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I8c8820066a402653bf0f49bd78a98be692530e42
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171892
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Handling EmphasisMarks for direct text rendering
was a hard task - the EmphasisMark stuff is deeply
buried in vcl (would have needed to move quite some
includes from vcl to public) and thus hard to use.
It is also quite old (tools Polygon, Rectangle).
It was missing in the decomposition of the
TextDecoratedPortionPrimitive2D (for good reason),
but is needed now.
I found a way using a callback lambda function to
create the needed geometry in vcl and hand back the
needed data to the caller, in this case to the
decomposition. Adding it to the decomposition of
TextDecoratedPortionPrimitive2D also guarantees
that other renderers/usages will do the correct
thing and all will look identical.
Interestingly EmphasisMarks were never added to
Metafiles (see OutputDevice::ImplDrawEmphasisMarks)
so they were not 'missing' in Metafile-based
exports. But for SDPRs they have to work. I added
another encapsulating TextHierarchyPrimitive to
encapsulate primitives that do represent
EmphasisMarks and added to ignore these in the
VclMetafileProcessor2D (as needed).
Change-Id: I5b5c1528d86a123df2beb57d8366f05aa71e77cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171826
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I923069582bb7c5022cfbff7e869c1d577a9123ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171691
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
|
|
Cairo can render RGBA gradients directly and the
CairoSDPR supports that. If we have a PolyPolygon
filled with single color combined with a gradient
alpha the renderer could map RGB to that color
and combine with the real alpha gradient steps.
To support that I added another Primitive called
PolyPolygonAlphaGradientPrimitive2D. It decomposes
as needed (TransparencePrimitive2D if needed), so
no other renderers have to be touched.
The Cairo renderer supports it directly, though,
what makes it much faster.
Change-Id: Ie90c8bd84d6458d12443db815ced55bdea93c15c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171628
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
I have added basic support for the text primitives
(TextSimplePortionPrimitive2D) to the SDPR Cairo
renderer. It can now basically render Text using
a fallback to the already existing CairoTextRender.
NOTE: This is not yet complete, but for discussion.
Change-Id: I9b0c7b6bb4892905576593ef4e2b4071c7663c63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171429
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
The EditEngine decomposes it's content mainly to
Prmitives (there is still a direct paint mode used
in rare remaining cases which we not yet got rid
of). For TABs the special case for 'extended' TABs
(see format/paragraph/Tabs, FillCharacter) was
handed through all layers using method DrawingTab,
put into a DrawPortionInfo and held at the text
primitive (TextSimplePortionPrimitive2D). While
for direct paint the expansion was already done in
ImpEditEngine::Paint anyways (and always painted,
independent from bStripOnly what was unneccessary
and I corrected that, too) it had to be done for
text paint in VclProcessor2D for each repaint.
This is not needed, so now the extended text
created in EditEngine decompose gets used.
This makes a lot of stuff simpler, including
EditEngine/Outliner and some involved classes.
If it somehow should show that it might be
necessary to do that for each paint it should
be done in the obvious way then - using an own
primitive that creates the expansin in the
decomposition (and buffers it).
Change-Id: Ieb02219142af8f6bee01dcd658e08b185a4212cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171380
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
FillGradientPrimitive2D/ and PolyPolygonGradientPrimitive2D
now support both alphas, a gradientAlpha and a unified one.
This allows a processor to directly handle a gradient with
a unifiedAlpha if he wants. Adapted other places accordingly.
NOTE: In VclMetafileProcessor2D handling of the primitive
PolyPolygonGradientPrimitive2D has to do a local compromize,
see comment there.
Change-Id: I536f4935dafde0369f768dbd281d547b7bb08eb4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171052
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
|
|
Change-Id: Iec45b32fce6381564f21c79d999a8db9a7757518
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170981
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I582bf693085251725b314b6caab9247650b25c6f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170980
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Up to now these needed to be decomposed to be
rendered and did not support animation. I already
added animation, but that was a compromize.
Done that now in the correct way, so that animation
is possible and can be directly rendered using
a FillGraphicPrimitive2D if wanted, including one
extra layer of alpha, too.
This will also enhance other primitive processors,
but of course most those that do handle that now
directly, so CairoPixelProcessor2D does that.
Note that it does not need to support animation
in any way (that is part of the primitive stack),
but just direct tiled rendering.
Change-Id: I8860098dfb3f2369e361579cf1deea7c67b662b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170937
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
To more directly support an additional alpha channel
for BitmapPrimitive data I have done some deeper
changes to the primitive stack, in a compatible
way. Quite some more graphic types and primitives
now support an additional direct alpha value. All
that is decomposed/created/broken down in a way
that needs no changes for existing renderers, in
already described ways.
The CairoPixelProcessor2D already uses this in the
processFillGraphicPrimitive2D implementation and
thus in the FillGraphicPrimitive2D. This works since
primitive productions now all try to create that
FillGraphicPrimitive2D type including an additional
alpha value - if possible and necessary.
Change-Id: Ib1b16491a2b3aee16f14cc8196e28af30a7cf9be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170900
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
|
|
This provides a BitmapPrimitive2D extended by a unified
transparency component. It will decompose to a
UnifiedTransparencePrimitive2D containing a
BitmapPrimitive2D and the transparence, so no primitive
processor has to support this primitive directly - but
can if feasible. I plan to use that ASAP
Change-Id: I83ec84eaadc8ba2b21f0ba0cb1fdcf43bdc455db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170852
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: Icfce04f91f76119f970073bbcdbe65770f0e31c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170798
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
Tested-by: Jenkins
|
|
Change-Id: Id1480297126bcc422945df7cd47993cc7fe5c22a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170768
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
|
|
I thought about this functionality again and decided
to change doing it in a way that will support more
alpha more directly in existing primitives - that will
be better for also supporting e.g. PolyPolys with alpha,
etc. Will need checking of existing usages of e.g.
FillGradientPrimitive2D, but it's worth it.
Note that when your primitive processor (usually a
renderer) does *not* support alpha in gradients
directly it is now requuired to continue using the
decomposition (what renderers do automatically when
calling 'BaseProcessor2D::process' in the default
case. Checked that for existing processors.
Change-Id: I840c9feb8c98549b790ef16285a309b42c4b1b53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170687
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I702043c566f79a81c6b40b7062cd1a83dcdaf652
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170575
Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
Tested-by: Jenkins
|
|
This step wil now use the new primitive
PolyPolygonRGBAGradientPrimitive2D inside the
CairoSDPR/CairoPixelProcessor2D to directly
render gradients as RGBA, without painting
RGB (content) and A (alpha) separate and mixing
the results.
Note that this is only possible for gradients
which use the same graphical definition, see the
method 'sameDefinitionThanAlpha' and it's usages
in the code.
Change-Id: I6c46a211ea26d3e4b7bb39c7f2aaff09ec38dec5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170584
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
|
|
Improve the hit-test machinery so we don't need to rerender the graphic
when moving the mouse over it
Change-Id: Ide088296aa9c2be1348b8908194f47378454ae40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170587
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
Detect where created when a RGBA gradient could be
used directly and create a primitive representing
that, a PolyPolygonRGBAGradientPrimitive2D.
That primitive decomposes to what was created before,
so no primitive renderer has to be touched, all will
work as before.
NOTE: That helper primitive just holds references to
what would be created anyways, so one depth step
added but not really any additional data.
This is the 1st step for direct support, the 2nd is
to then detect and use that primitive in SDPR
implementations directly.
Change-Id: I4f247636ce58a8a1fd1e0df32dabed0d6cc10d0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170527
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Avoid decomposition of it in AnimatedExtractingProcessor2D
by handling there directly. Goal is to find/extract animation
primitives, so only do something when the contained Graphic
is active
Change-Id: I1d168428ddbaaac2c9d5fde7b26be380ba442c30
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170203
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I0e722e9438e7e21d4fa8ba05a9bd56719db521fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170144
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
|
|
Added and corrected quite some stuff to this basic
construct provided by Caolan (thanks again!). No
detailed descriptions here, but it's getting more
complete and faster.
May contain errors and is primitive-complete in the
sense that all gets rendered, but some basic stuff
that should be directly supported is still missing,
e.g. text rendering.
Adding this to allow people to check it out (speed)
also since it's not yet used as default in master,
so it's safe and also safes the changes publically.
To test it, use TEST_SYSTEM_PRIMITIVE_RENDERER as
set EnvVar in linux systems.
Change-Id: I25f795c9ea4ad4f3b99591304f8803dffa499436
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168911
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
This is the way it's done everywhere.
Partially revert 4b6e0f2c88debaedb514c868e061c21e15215b6e
"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>
|
|
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>
|
|
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>
|
|
create a plugin that finds methods we can mark as final because they are
not override in subclasses.
Which is useful both as documentation (telling you that you don't need
to worry about subclasses changing the implementation under you),
and for performance, letting the compiler elide virtual calls in many
cases.
Apply the results to a subset of stuff in /include
Change-Id: I7b5cc893ec2f343bc356bfc338e4cf531ffba1e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165054
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This was missing in the mechanism to suppress
EditView exclusive content, so it is now also
suppressed in PDF export.
Also changed TextHierarchyEditPrimitive2D to
also decide inside it's local get2DDecomposition
implementation, so it does not need to be#
supported in PrimitiveProcessors (and cannot be
forgotten in future implementations).
Also added support for EditView exclusive
Primitive's name in idToString (missed that).
Change-Id: I61efc9dddb7d6f0190c7b1fb4b0acf98ab5767f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165109
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
We have the case that e.g. a placeholder Graphic/Text
shall only be processed/shown in the EditView of the
application, but not in any other Primitive-based
usages, including exports, SlideSHow, etc.
I already thought about that when initially converting
Draw/Impress to Primitives, but always found other
solutions, mainly because full XShapes/SdrObjects
had to be taken into account, that can be handled in
VC/VOC/OC implementation. But here we have varying
visualisations of one shape.
Thus I implemented a helper Primitive called
ExclusiveEditViewPrimitive2D. Anything you embed
there will only be processed when the switch to
do so is active in the ViewInformation2D. And
that switch is only set in the EditView paint.
Change-Id: I307f4b0fe7f8faf98789787f216cac7be86a0515
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165066
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
The current version suppressed text for Objects
in edit mode for the paint in the view since that
text is painted/visualized by the EditEngine/Overlay
while it is being edited, so that would be displayed
twice - and in different states.
That is correct, but e.g. also suppressed display
for e.g. an opened second Window for the Document or
in a running SlideShow.
The mechanism uses embedding the Text in case it gets
edited to a simple Primitive that then can be
suppressed by the view rendering it. It decomposed
to empty, thus to visualize it a renderer had to
actively identify and process it.
I now turnedd this around - it is a normal
GroupPrimitive2D and decomposes to the text content,
so will be visualized by all renderers that do not
actively suppress it. To actively suppress it I added
a get/setTextEditActive marker to ViewInformation2D
that will be used by the ObjectContactOfPageView
to signal exactly that and to suppress in the pixel
based VCLRenderer in that case.
This is important e.g. for 2nd view window, but also
for PDF export with active TextEdit (yes, happens)
and SlideShow.
There was also support missing for an up-to-now
empty/new object (no text yet) so that text from the
active TextEdit was not provided, corrected that.
Change-Id: I0d8befdb023028d78ce341091331e9a83a0173bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163773
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I102ccab2a423c38b0414c9565fec349aa6ffb5af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163725
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I351a9127fb26369d8f598b6d6519d7e490fa476b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163190
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
.. instead of a Primitive2DContainer.
The container very frequently contains only a single item, since
the decomposition method often sticks only a single top-level node
in there, so it turns out to be a net loss overall, memory
consumption-wise.
Also, if we return a single Primitive2DReference from
a BufferedDecomposition, that maximises the sharing of
data between the BufferedDecomposition objects at the
bottom of the decomposed tree, and objects higher up.
Change-Id: Iaf272e60e2997299cc35a1bd209c51b6b79e9a8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162976
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
by avoiding making multiple copies of the Primitive2D container
that we pass to TransformPrimitive2D.
Instead, make TransformPrimitive2D store its children using a
GroupPrimitive2D, which means we can share the GroupPrimitive2D
among all the TransformPrimitive2D instances we create.
Change-Id: I8a4398f9db6a6ab013ee24ad53836975fba6f3df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162951
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
where it belongs. It appears it was only put into
BufferedDecompositionPrimitive2D so that it can be accessed
by Primitive2DXmlDump, so fix that by creating an extended version
of the dumper for use in svx.
Change-Id: Idb0b849c4fa538bbede882e48c2d090669c2325a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162949
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
