Hi all, Regina,
So the issue seems to be that the original proposal is quite a few years
old, and that meanwhile the Writer implementation has already been
extended. - the Writer implementation already supports rotation, and
double-precision bounding box calculations is prepared (so can be used
but is of course not adapted) - has the bounding box updates done when
properties change - support for drawinglayer fill attributes - and
(that's the strongest argument) has all the interactions plugged into
Writer's view code It doesn't make too much sense to use an SdrObject
then instead. We could 'artificially' do so, reference it from SW frames
& render it.
The problems are manifold:
- The Items involved are just in different places in the models
- The Item hierarchy in SW for frames is different (there is some
'parent' fame, additionally)
- The adaption of the frame's dimensions to the rotation, it's reaction
to that and e.g. text floating around *has* to be done at he SW frame
- A potential SdrGrafObj would have to be rendered by Frame's Paint
(artificially) and not by SW's DrawingLayer paint (has own Z-Order,
heaven/hell does not fit to frames, etc...)
So I would not propose to use a SdrGrafObj/SdrObject directly. What
makes sense indeed is to use the same render pipeline. This is already
mainly done, the rendering of an SdrGrafObj/GraphicObject in SW is
already using common code in SW and elsewhere - by using primitives. In
SW currently by making a small 'excursion' to Primitives and
PrimitiveRenderer when a GraphicObject has to be painted, as part of the
regular 'Paint' (due to SW repaint still not being adapted to Primitive
rendering). That guarantees also same output to e.g. PDF export when
recording the Primitive paint as metafile actions.
That means the access to the attribution, creation of Primitives is
slightly different (there are helper classes AFAIR e.g. for crop stuff),
but the Primitives used are the same and get rendered uniformly.
What is missing is directly adding e.g. FrameBorder attributes to
Primitives to create for that what is needed. This can be done,
FrameBorder stuff is implemented as Primitives and decompositions
already (and used for all three Table-Implementations we have, despite
It should *not* be done in general for SdrGrafObj - that brings us in
the situation that you might have a FrameStyle AND a dashed line at the
same time - that might be technically solvable, but would combine the
already tricky FrameStyle decompositions with doing it additionally
dashed - nothing we should try to achieve from my POV. Does that
combination even have a used case in reality..?
It is better and technically no problem to stick the needed Primitives
together like Lego - that's what they are designed for.
Still, the actual rendering code in drawinglayer should be expanded to
support Writer borders, and then be used from the Writer image
implementation, too. What is then technically desirable I guess, is to
continue with nominally two image *core* implementations for Writer and
the rest (due to gui interactions), but consolidate the attributes (so
we're supporting the same features everywhere - dashes for Writer
borders, double/multi-line borders for draw/impress), use the same
rendering code for fills and borders, and keep the Writer frame /
SdrGrafObj as gutted façade. Which would be essentially a modified option A.
Just my 2ct, HTH!
On 5/8/22 14:19, Regina Henschel wrote:
Thorsten Behrens schrieb am 07.05.2022 um 22:46:
I understand it so, that the item 'extract Writer border rendering &
special code' would be a step for goal A, whereas items in regard to
'rotated images support' would be a step for goal B.
Don't quite understand the second part - since obviously draw images
can be easily rotated?
The tender proposal contains,
"several attempts, current status (90-degree rotations) is a
half-house. Rotation issue properly fixed by Armin in 6.0"
"Relevant meta bug: Regressions from rotated images support in 6.0
(has 8 open bugs, having 12 duplicates total --Kelemeng (talk)
2022-03-07T16:58:16 (UTC) )"
which is https://bugs.documentfoundation.org/show_bug.cgi?id=147763
If we agree on goal A - and I support that - it would be wasted money
to include fixes for these Writer-image rotation bugs in the tender.
What should happen with the current implementation of rotating
Armin Le Grand
Senior Software Engineer FLOSS
allotropia software GmbH
Registered office: Hamburg, Germany
Registration court Hamburg, HRB 165405
Managing director: Thorsten Behrens
VAT-ID: DE 335606919
To unsubscribe e-mail to: firstname.lastname@example.org
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.documentfoundation.org/www/board-discuss/
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy