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.
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.
Created attachment 121690 [details] screenshot
(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.
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."
(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.
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.
(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.
Stuart: should this be closed?
> 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.
(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.
*** This bug has been marked as a duplicate of bug 95812 ***
Back to NEW with WONTFIX of bug 95812 (Armin's aw080 efforts).
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)
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.