The frist shape uses style *`FrameStyleAuto'* from *`content.xml'*. /*This is rotatable*/. The second shape uses style *`FrameStyleCustom'* from *`styles.xml'*. /*This is NOT rotatable*/. The `XML' definitions of *`FrameStyleCustom'* and *`FrameStyleAuto'* are identical, and looks as below (save for the `style:style-name') ,---- | <style:style style:name="FrameStyleAuto" | style:family="graphic"> | <style:graphic-properties draw:wrap-influence-on-position="once-concurrent" | style:horizontal-pos="center" | style:horizontal-rel="paragraph-content" | style:vertical-pos="top" | style:vertical-rel="paragraph" | style:wrap="none" | text:anchor-type="char" /> | </style:style> `---- My Question is Above example suggests that LibreOffice chooses between a *`textbox'* and *`a shape'* based *NOT ON /the XML definition/ of the style*, but *on /the type/ ---/custom/ or /automatic/---of the style* ... This observed behaviour is very quriky and suspicious ... Other issues: Fill color of the style is blue Where does it come from? - The *`style:default-style'* for /graphics/ does not specify a fill color. - While examining *`Tools -> Options -> LibreOffice -> Application Colors'*, none of the colors come closer to the fill color. ,---- | <style:default-style style:family="graphic"> | <style:graphic-properties draw:end-line-spacing-horizontal="0.283cm" | draw:end-line-spacing-vertical="0.283cm" | draw:shadow-offset-x="0.3cm" | draw:shadow-offset-y="0.3cm" | draw:start-line-spacing-horizontal="0.283cm" | draw:start-line-spacing-vertical="0.283cm" | style:flow-with-text="false" /> | <!-- style:paragraph-properties and style:text-properties are snipped --> | </style:default-style> `---- ,---- | <style:style style:name="FrameStyleAuto" | style:family="graphic"> | <style:graphic-properties draw:wrap-influence-on-position="once-concurrent" | style:horizontal-pos="center" | style:horizontal-rel="paragraph-content" | style:vertical-pos="top" | style:vertical-rel="paragraph" | style:wrap="none" | text:anchor-type="char" /> | </style:style> `---- ,---- | <style:style style:name="FrameStyleCustom" | style:family="graphic"> | <style:graphic-properties draw:wrap-influence-on-position="once-concurrent" | style:horizontal-pos="center" | style:horizontal-rel="paragraph-content" | style:vertical-pos="top" | style:vertical-rel="paragraph" | style:wrap="none" | text:anchor-type="char" /> | </style:style> `----
Created attachment 180968 [details] bug149734.odt: Problematic ODT document
Created attachment 180969 [details] bug149734.png: Screenshot with annotation bug149734.png: Screenshot with annotation. See the annotation for what I mean.
Version: 7.3.4.1 / LibreOffice Community Build ID: 30(Build:1) CPU threads: 4; OS: Linux 5.17; UI render: default; VCL: x11 Locale: en-IN (en_IN); UI: en-US Debian package version: 1:7.3.4~rc1-1 Calc: threaded
Created attachment 180971 [details] Minimized test case
That was a decision long ago, see comment https://opengrok.libreoffice.org/xref/core/xmloff/source/text/XMLTextFrameContext.hxx?r=aef40e73#48 This decision blocks custom styles on text boxes in Writer. From an ODF point of view, there is no difference between a (Draw) text box and a (Writer) frame. My take is, that we should get rid of this kind of separating. Ideally there should be only one text engine. Nevertheless I see the need for an indicator, whether to use Writer engine or Draw engine, until there is only one engine. I can imagine to have a shape attribute "has complex text". If it is 'true', we use the Writer text engine, if it is 'false' we use the Draw text engine.
(In reply to Regina Henschel from comment #5) > My take is, that we should get rid of this kind of separating. Ideally there > should be only one text engine. That would be great; I assume, the one engine would likely be the Writer's one (as more feature-rich)? Still, to make that happen, we need to improve the chosen engine to match missing features available in the other. One would be related to this issue's mentioned rotation. Then, the Draw engine allows to fit text by stretching it and by scaling the font size, and more. We might need a meta that would focus e.g. on making frame feature set on par with textbox (and other Draw engine-based texts), with per-feature dependent bugs.
Based on what's written, I set as Enhancement.