Question about tender proposal 'Unify Writer and Draw image'

Hi Thorsten,

you are the contact person for tender proposal
https://wiki.documentfoundation.org/Development/Budget2022#Unify_Writer_and_Draw_Images
The topic of this tender proposal is not very clear to me. Writer-images and Draw-images have many differences. I have collected them in the document
https://wiki.documentfoundation.org/File:Comparison_WriterDraw_image.odt

When working on 'Unify' it is necessary to know the final goal. It could be
A) Elimination of Writer-images. Writer uses only Draw-images same as all other modules.
B) Use only Writer-images in Writer and convert Draw-images for use in Writer.
In both cases a strategy is needed for the time having both types and for loading old documents.

I understand it so, that the item 'extract Writer border rendering & frame special code' would be a step for goal A, whereas items in regard to 'rotated images support' would be a step for goal B.

Could you please explain the proposal a little bit more and outline the final goal?

Kind regards,
Regina

Hi Regina,

copying Armin, who did quite a bit of work in that area -

Regina Henschel wrote:

you are the contact person for tender proposal
https://wiki.documentfoundation.org/Development/Budget2022#Unify_Writer_and_Draw_Images
The topic of this tender proposal is not very clear to me. Writer-images and
Draw-images have many differences. I have collected them in the document
https://wiki.documentfoundation.org/File:Comparison_WriterDraw_image.odt

Thanks, that's an excellent overview, and should IMO be a part of the
requirements for a potential tender.

When working on 'Unify' it is necessary to know the final goal. It could be
A) Elimination of Writer-images. Writer uses only Draw-images same as all
other modules.

Yes, that's the intended final goal.

I understand it so, that the item 'extract Writer border rendering & frame
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? But indeed there's slightly more work needed
besides just the border support (e.g. contour polygons and other
smallish bits and pieces from your comparison doc), to make Draw
images powerful enough to support all Writer features.

HTH,

-- Thorsten

Hi Thorsten,

I understand it so, that the item 'extract Writer border rendering & frame
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"
and,
"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 Writer-images?

Kind regards,
Regina

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 anyways
- 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 different models).

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!

Regards,

Armin

Hi all, Armin,

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,

with several errors, see bug 147763.
  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.

I see it different. From ODF point of view there exists nothing like a "Writer-image", but it is always a <draw:frame> element with <draw:image> child element. So foreign applications will treat our "Writer-image" the same as they treat our "Draw-image".

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 anyways
- 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...)

Shouldn't we just gradually extend Draw-images with the features they lack compared to Writer-images until Writer-images are no longer needed? This would then also benefit Draw/Impress.

[skip some implementation detail]

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..?

PowerPoint has compound (frame border like) line styles for all objects, including presentation objects and images. They are lost on import. PowerPoint even allows to combine them with dash-styles. So we need this kind of border/line anyway.

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.

I don't know drawinglayer. So to be sure to get your idea correctly: Implement compound lines and dash styles in drawinglayer so, that both are usable from all object kinds. And adapt Writer-image and Draw-image to use it. That would mean to extend the features of Writer-images too?

What about shadow? We have nice shadow with blur and arbitrary direction on Draw-images, but only the frame shadow on Writer-images. Would you adapt Writer-images to the shadow features of Draw-images?

And what do you want to do about the different 'size' behavior of Write-images and Draw-images? Writer-images size has border and shadow inclusive and Draw-images exclusive.

Kind regards,
Regina