Bug 96850 - FORMATTING: send-to-back does not work for embedded images over text
Summary: FORMATTING: send-to-back does not work for embedded images over text
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0.2.2 release
Hardware: All Windows (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: OLE-Objects
  Show dependency treegraph
 
Reported: 2016-01-01 17:45 UTC by Erik Sohns
Modified: 2023-06-30 15:53 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot (44.31 KB, image/png)
2016-01-03 09:57 UTC, Erik Sohns
Details
sample of various Text and Image objects in Writer (288.82 KB, application/vnd.oasis.opendocument.text)
2016-01-04 16:53 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Erik Sohns 2016-01-01 17:45:27 UTC
Embedding an image into the text flow obscures any overlapped areas (using the "wrap through" overlay option). The layering functions "back one" and "send to back" do not work in this case.

Note that I haven't tried how transparent pixels, as supported by different image formats, behave in this case.
Comment 1 V Stuart Foote 2016-01-01 23:39:02 UTC
PNG, JPG, TIFF, EMF, SVG... going to need details. Better would be Steps to Reproduce.  And of course screen clips and attached test case document would help the process.
Comment 2 Erik Sohns 2016-01-03 09:57:28 UTC
Created attachment 121690 [details]
screenshot
Comment 3 Erik Sohns 2016-01-03 09:59:40 UTC
(In reply to V Stuart Foote from comment #1)
> PNG, JPG, TIFF, EMF, SVG... going to need details. Better would be Steps to
> Reproduce.  And of course screen clips and attached test case document would
> help the process.

I just attached a screenshot with the details. The image format I used was TIFF, but the JPG I tried seems to have the same issue.
Comment 4 Buovjaga 2016-01-04 13:27:21 UTC
It is behaving like intended. You have to use In background, if you want it to go below the text.
https://help.libreoffice.org/Writer/Wrap#Through
"Places the object in front of the text."
Comment 5 Erik Sohns 2016-01-04 16:01:37 UTC
(In reply to Beluga from comment #4)
> It is behaving like intended. You have to use In background, if you want it
> to go below the text.
> https://help.libreoffice.org/Writer/Wrap#Through
> "Places the object in front of the text."

Thank you, I hadn't RTFM.

I still believe this feature is somewhat obscure. I think it would be more intuitive if the text flow behaved as an image layer, then the image layering/stacking feature could be applied as usual.

I am therefore changing this issue to a feature request until further notice.
Comment 6 V Stuart Foote 2016-01-04 16:53:47 UTC
Created attachment 121714 [details]
sample of various Text and Image objects in Writer

Nope--different object types.

Also with Writer have issue of normal Paragraph text, text in Frames, and text in Text boxes. Have to handle images differently with each type of text. Or with Fontwork text. 

Frames and "normal" Paragraph objects observe wrap.

Text box, are more limited (both in relation ship to other objects, but also formatting of the paragraphs they contain)--they can however be organized as layers relative to other images and shapes. And Fontwork like Text Box are considered Shape objects rather than images.

See the Navigator <F5> or on the Sidebar deck for the attached sample document.
Comment 7 Erik Sohns 2016-01-04 17:16:00 UTC
(In reply to V Stuart Foote from comment #6)
> Created attachment 121714 [details]
> sample of various Text and Image objects in Writer
> 
> Nope--different object types.
> 
> Also with Writer have issue of normal Paragraph text, text in Frames, and
> text in Text boxes. Have to handle images differently with each type of
> text. Or with Fontwork text. 
> 
> Frames and "normal" Paragraph objects observe wrap.
> 
> Text box, are more limited (both in relation ship to other objects, but also
> formatting of the paragraphs they contain)--they can however be organized as
> layers relative to other images and shapes. And Fontwork like Text Box are
> considered Shape objects rather than images.
> 
> See the Navigator <F5> or on the Sidebar deck for the attached sample
> document.

I see. So, in theory, images are just specific objects that could/should be layered, just like any other object; or "text" component (i.e. paragraphs, frames/boxes, fontwork, ...).

I understand that, in certain situations, it may make sense to group some objects, to layer them relative to other objects and/or groups.
Comment 8 Buovjaga 2016-01-04 18:26:23 UTC
Stuart: should this be closed?
Comment 9 V Stuart Foote 2016-01-04 18:29:28 UTC
> I see. So, in theory, images are just specific objects that could/should be
> layered, just like any other object; or "text" component (i.e. paragraphs,
> frames/boxes, fontwork, ...).
> 
> I understand that, in certain situations, it may make sense to group some
> objects, to layer them relative to other objects and/or groups.

Correct, and unfortunately there is no mechanism for handling layers in LibreOffice (or AOO or OOo, or StarOffice before).  And the real rub with current implementation comes with needing to maintain internal structure of each document and its mix of objects with its rendering into ODF. As I understand things the handling is somewhat fragile and the export/import filtering could be more robust. A current cause of issues with loss of background colors, fills, and transparency among others.

We also lack a GUI for efficiently controlling groupings and individual objects as layers. Draw alone has a rudimentary capability in a tabbed UI. Across the modules Navigator shows labeled/described objects, but does not directly manipulate them for grouping or reordering as layers.

Believe that as work proceeds on restructuring the internal SdrObject/SdrPage  corresponding work on the GUI will then support efficient grouping and ordering of objects (not just as layers on a canvas)--think document structure and flow, for screen readers and other automation. 

So with that said, this specific issue is out of context. Could dupe to one of many issues or even to bug 95812, but probably best to just close as notabug given the current summary write up.
Comment 10 Erik Sohns 2016-01-04 19:48:37 UTC
(In reply to V Stuart Foote from comment #6)
> Also with Writer have issue of normal Paragraph text, text in Frames, and
> text in Text boxes. Have to handle images differently with each type of
> text. Or with Fontwork text. 
> 
> Frames and "normal" Paragraph objects observe wrap.
> 
I understand that images, just like other objects, may "interact" (i.e. wrap, columnize, ...) with "text" objects. This certainly ties into the rendering process (i.e. object placement, scaling, ...), but may be complementary to the layering aspect. Interestingly, the wrap (i.e. paragraph/page layout) functionality could be implemented in terms of laying out objects residing on the same layer.
<snip>

(In reply to V Stuart Foote from comment #9)
> > I see. So, in theory, images are just specific objects that could/should be
> > layered, just like any other object; or "text" component (i.e. paragraphs,
> > frames/boxes, fontwork, ...).
> > 
> > I understand that, in certain situations, it may make sense to group some
> > objects, to layer them relative to other objects and/or groups.
> 
> Correct, and unfortunately there is no mechanism for handling layers in
> LibreOffice (or AOO or OOo, or StarOffice before).
<snip>
>
> We also lack a GUI for efficiently controlling groupings and individual
> objects as layers. Draw alone has a rudimentary capability in a tabbed UI.
> Across the modules Navigator shows labeled/described objects, but does not
> directly manipulate them for grouping or reordering as layers.
>
> Believe that as work proceeds on restructuring the internal
> SdrObject/SdrPage  corresponding work on the GUI will then support efficient
> grouping and ordering of objects (not just as layers on a canvas)--think
> document structure and flow, for screen readers and other automation. 
>
I think the "layers on a canvas" paradigm is fundamental to the document rendering procedure. However, document layout (i.e. the "text processor") may involve both pre- (in order to accommodate text-object interactions and similar features), as well as post-processing steps (as far as the "text processor" requires information about the overall layering configuration).

> So with that said, this specific issue is out of context. Could dupe to one
> of many issues or even to bug 95812, but probably best to just close as
> notabug given the current summary write up.
Yes, this may decay to a dupe of bug 95812, I will mark it accordingly.
Comment 11 Erik Sohns 2016-01-04 19:52:20 UTC

*** This bug has been marked as a duplicate of bug 95812 ***
Comment 12 V Stuart Foote 2017-10-18 13:22:49 UTC
Back to NEW with WONTFIX of bug 95812 (Armin's aw080 efforts).
Comment 13 Stéphane Guillou (stragu) 2023-06-30 14:37:06 UTC
Stuart / Erik, can one of you clarify and summarise what this ticket wants fixed and update the summary?

Is it that the "image anchored to page" in the sample document can't be moved in front of the text box, nor can it be moved "to background / foreground"?
(which is still the case in a recent 24.2 build)
Comment 14 V Stuart Foote 2023-06-30 15:53:35 UTC
Going to close out. The sample document attachment 121714 [details] shows the mix of ways text can interact for 'wrap' and 'layering' with images and drawing objects, but that the frames images and drawing objects don't share layer attributes.

Z-order layering attribute(s) is not consistent across object types--Armin continues to poke, and Jim's work on the Navigator has improved visibility to the UI. But there is no grand unifying effort.

Issue of OP was resolved invalid, and this can be closed as just noise at this point.