The presentation object "Outline" has the feature, that the font-size is reduced, if the content does not fit into the frame area. In "ODF 1.2 extended" this is written to file as 'draw:fit-to-size="shrink-to-fit"'. But the attribute 'draw:fit-to-size' has only the values true and false. And the attribute itself is the wrong one. The correct attribute is "style:shrink-to-fit" Read section 20.350 "The style:shrink-to-fit attribute specifies whether content is reduced in size to fit within a cell or drawing object. Shrinking means that the font size of the content is decreased to fit the content into a cell or drawing object." The attribute "style:shrink-to-fit" is not only usable with <style:table-cell-properties> but also with <style:graphic-properties>. Therefore I do not see any need for extending the kind of the value of attribute 'draw:fit-to-size'. Instead use the correct attribute and retain the old behavior of 'draw:fit-to-size'. Besides being conform to ODF1.2, the correct attribute would make it possible to solve issue #34467, and to bring this feature to UI, so that a user can freely decide, whether he wants to use this feature or not.
Setting to NEW.
Bug 34467 has been fixed in 5.3.0 alpha. would you please retest to see if the current issue had positive side effects from this?
It is not fixed and no positive side effect. The invalid attribute 'draw:fit-to-size="shrink-to-fit"' is still written in case Autofix_Text is on. Tested in Version: 5.3.0.0.alpha1+ Build ID: 92c1128fb80b4e38df219ce60f018cfb1522b20a CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; TinderBox: Win-x86@39, Branch:master, Time: 2016-11-19_23:45:40 Locale: de-DE (de_DE); Calc: group
*** Bug 101519 has been marked as a duplicate of this bug. ***
*** Bug 85062 has been marked as a duplicate of this bug. ***
*** Bug 106147 has been marked as a duplicate of this bug. ***
This really bit me when I had (accidentally) left my setting to non-extended for a long period ... =)
This bug bites me whenever I write a presentation. I tend to set LibreOffice to save ODF 1.2 *without extensions*. This is the recommended setting if one wants to avoid interoperability surprises. When I create a presentation and save it as plain ODF 1.2, the attribute draw:fit-to-size on the style Standaard-outline1 is saved as 'true'. So after I reopen my presentation, most body frames in the presentation will suddenly scale the text to the box. The solution to this is then to manually set all of them to false in LibreOffice or to edit styles.xml and set draw:fit-to-size to 'false' for Standaard-outline1. I suspect that the cause for this bug is that when saving draw:fit-to-size in plain ODF 1.2 mode, the runtime value is draw:fit-to-size="shrink-to-fit" and that is being translated to draw:fit-to-size="true" where it should be translated to style:shrink-to-fit="true". Probably a fairly simple fix. (famous last words)
In general exporting auto-fitting into the file-format itself is a horror - IMHO it should be disabled and/or deprecated. We should write hard font-sizes that are the result of auto-fitting - so that the algorithm can change and so on later; we should also set this UI flag so that when someone edits that box - the thing will re-auto-fit things, but ... =) The current implementation rather worries me TBH.
Created attachment 132250 [details] screenshot before saving to ODF 1.2 Text is normal size and not fitted to box.
Created attachment 132251 [details] screenshot after saving to ODF 1.2 and opening again After opening the file again, the text scales to the box size. In a normal presentation this affects most slides.
Created attachment 132252 [details] Bash script to fix files that are affected by this bug. This script translates draw:fit-to-size='true' to style:shrink-to-size='true'. Also requires fix_shrink_to_fit.xsl.
Created attachment 132253 [details] XSLT to fix files affected by this bug. XSLT used by fix_shrink_to_fit.sh which is also attached to this bug.
Since this bug gives information loss and is very annoying, it should be marked with importance 'major'.
(In reply to Michael Meeks from comment #9) > In general exporting auto-fitting into the file-format itself is a horror - > Why is that? It's actually a fairly normal thing to say 'scale this here into that one' when producing documents - > IMHO it should be disabled and/or deprecated. We should write hard > font-sizes that are the result of auto-fitting - so that the algorithm can > change and so on later; > That is what MSO currently does, but it has a drawback - especially presentations are rather fragile with people cramming text boxes full with text - if you don't have the font, layout breaks horribly, unless you can size-adjust. > we should also set this UI flag so that when someone > edits that box - the thing will re-auto-fit things, but ... =) > That's what currently happens. And therefore you still need to write this flag to odf, which is what this bug is about (and not about the implementation details above). ;)
Version: 5.4.0.0.alpha0+ Build ID: 1a1d1a86e9129ec3885610b641179b30f9bf5e79 CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-04-04_01:25:43 Locale: en-ZA (en_GB.UTF-8); Calc: group Not sure if this is same issue (not actually a bug). It seems as if this changed at some time, or I don't understand how it works. In a presentation one wants to prevent text from running off the slide. Therefore the text size should be reduced to fit the frame. What one does NOT want to happen is for a single word to be stretched to fill the frame. The text can become unreadable and simply makes no sense - the font proportions should be maintained. It also means that when one saves the presentation to a Microsoft format, the slides are messed up. I also feel that there are too many places where such font manipulation takes place and who this is worked out in practice: the same attribute seems to be in format/position and size as well as format/text. I can never figure out which has precedence, and when I have figured it out, next time I try, I have forgotten and have to go through the same process again.
Created attachment 132390 [details] text distorted to fit frame The sample file shows how text is distorted to become almost unreadable, or to dominate a slide - which is not what one wants.
oh, i had no idea that style:shrink-to-fit is a thing. style:shrink-to-fit is only allowed on table cells in ODF 1.1 but is also allowed on graphics-properties in ODF 1.2. unfortunately there's *another* possible value: { XML_FALSE, drawing::TextFitToSizeType_NONE }, { XML_TRUE, drawing::TextFitToSizeType_PROPORTIONAL }, { XML_ALL, drawing::TextFitToSizeType_ALLLINES }, { XML_SHRINK_TO_FIT,drawing::TextFitToSizeType_AUTOFIT }, { XML_TOKEN_INVALID, (drawing::TextFitToSizeType)0 } NONE -> draw:fit-to-size="false" style:shrink-to-fit="false" PROPORTIONAL -> draw:fit-to-size="true" style:shrink-to-fit="false" ALLLINES -> ? AUTOFIT -> draw:fit-to-size="false" style:shrink-to-fit="true" is there some existing attribute that would match this? /** like <code>PROPORTIONAL</code>, but the width of each text row is also scaled proportional. */ ALLLINES, (where in the UI can i set this anyway? ... open the toolbar "Fontwork", click the button to insert one, then click the "Fontwork Alignment" and "Stretch Justify" - wow that is obscure...) ... some grepping indicates that the alias SdrFitToSizeType::AllLines can be created in filter/source/msfilter/msdffimp.cxx (the PPT import filter) ... sooo... if we stay with the ODF 1.2 boolean attribute theme we want a loext:fit-each-line-separately="true" to represent that? and together with draw:fit-to-size="true"?
I've dug a little bit in the history. It seems, that the values drawing::TextFitToSizeType_PROPORTIONAL and drawing::TextFitToSizeType_ALLLINES and drawing::TextFitToSizeType_RESIZEATTR never had been implemented as described in the API reference. Read comments in https://www.mail-archive.com/ooo-dev@incubator.apache.org/msg23388.html If I assign the three constants to rectangles in AOO and compare them, the resulting file format is the same, always only draw:fit-to-size="true". Especially the burn-in character size of RESIZEATTR is not done. So there are actually only a) NONE -> draw:fit-to-size="false" style:shrink-to-fit="false" b) PROPORTIONAL;ALLINES;(RESIZEATTR only AOO) -> draw:fit-to-size="true" style:shrink-to-fit="false" c) AUTOFIT -> draw:fit-to-size="false" style:shrink-to-fit="true" The forth combination {draw:fit-to-size="true" style:shrink-to-fit="true"} would result in the same visual result as b). One of PROPORTIONAL or ALLLINES can be used to reflect that state in the API. Such redefining would not harm, because the description texts in the API needs to be adapted to the actual implementation anyway. (In reply to Michael Stahl from comment #18) > > (where in the UI can i set this anyway? ... open the toolbar "Fontwork", > click the button to insert one, then click the "Fontwork Alignment" and > "Stretch Justify" - wow that is obscure...) > > ... some grepping indicates that the alias SdrFitToSizeType::AllLines > can be created in filter/source/msfilter/msdffimp.cxx > (the PPT import filter) ... > > sooo... if we stay with the ODF 1.2 boolean attribute theme > we want a loext:fit-each-line-separately="true" to represent that? > and together with draw:fit-to-size="true"? LibreOffice writes for stretchy-justify in the fontwork-shapes currently draw:fit-to-size="all" (invalid too). AOO writes simple draw:fit-to-size="true" for the same rendering, but loose it on reloading. I do not get such stretching in PowerPoint 2010, neither with import nor from scratch. Is it possible in newer PowerPoint? I think, for ODF draw:fit-to-size="true" would be sufficient. Or which rendering of text in a custom-shape is not covered?
(In reply to Regina Henschel from comment #19) > If I assign the three constants to rectangles in AOO and compare them, the > resulting file format is the same, always only draw:fit-to-size="true". > Especially the burn-in character size of RESIZEATTR is not done. yes, this is because AOO doesn't implement ODF export of these values, which was added in LO 3.5 commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=e479f47f7d48dbd0d701bf347b6a2d5121ba3d34 > So there are actually only > a) NONE -> draw:fit-to-size="false" style:shrink-to-fit="false" > b) PROPORTIONAL;ALLINES;(RESIZEATTR only AOO) > -> draw:fit-to-size="true" style:shrink-to-fit="false" > c) AUTOFIT -> draw:fit-to-size="false" style:shrink-to-fit="true" > > The forth combination {draw:fit-to-size="true" style:shrink-to-fit="true"} > would result in the same visual result as b). One of PROPORTIONAL or > ALLLINES can be used to reflect that state in the API. it's technically possible to map that to ALLLINES (and true/false to PROPORTIONAL) but i find it very un-intuitive that these 2 attributes with "true" should mean per-line scaling. > Such redefining would > not harm, because the description texts in the API needs to be adapted to > the actual implementation anyway. incidentally see https://cgit.freedesktop.org/libreoffice/core/commit/?id=8304de4701eca8a41f0dd70c84e437707cbb43cf > I do not get such stretching in PowerPoint 2010, neither with import nor from > scratch. Is it possible in newer PowerPoint? it must be possible somehow since we can import it from the binary PPT format.
(In reply to Michael Stahl from comment #20) > incidentally see > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=8304de4701eca8a41f0dd70c84e437707cbb43cf The current behavior of draw:fit-to-size="true" is not changing the font size, but the image of the text is stretched to fit the frame.
(In reply to Regina Henschel from comment #21) > (In reply to Michael Stahl from comment #20) > > > incidentally see > > https://cgit.freedesktop.org/libreoffice/core/commit/ > > ?id=8304de4701eca8a41f0dd70c84e437707cbb43cf > > The current behavior of draw:fit-to-size="true" is not changing the font > size, but the image of the text is stretched to fit the frame. actually i was considering whether to write "the font is scaled" or "the glyphs are scaled" but the widget in the sidebar was adjusting the font size to the scaling so i thought it's the font that is being scaled and we just do it badly somehow; if you say it's the glyphs that are scaled then it's no wonder it looks awful...
New suggestion: Summarized we have from a user point of view for text size adjustments: a) none b) old style "glyph" scaling on the entire text block, which is not available for fontwork-custom-shapes c) font-size reducing d) stretchy-justify = "glyph" scaling with each line independent, which is only available for fontwork-custom-shapes. I suggest to map it to the API a) -> NONE Description: The text size is only defined by the character properties. The text might exceed the shape. b) -> PROPORTIONAL, ALLLINES PROPORTIONAL Description: In fontwork custom shapes each line is stretched to fit the available width independent from other lines; for other shapes the entire text block is stretched to fit the available space. Thereby glyphs might be scaled without keeping ratio. AutoGrow and auto line breaking is disabled. Note: The identifier wording is misleading and only kept to not break existing macros. ALLLINES Description: Same as PROPORTIONAL c) -> AUTOFIT Description: The font size is scaled down in rendering, not in property CharHeight, until the text fits into the available space. Thereby line breaks are newly calculated. The font size cannot be scaled up larger as set in property CharHeight. ------------- The description in API for TextFitToSize is wrong too. There is a conflict between description "true" and datatype com::sun::star::drawing::TextFitToSizeType. -------------- For mapping to file format: a) {draw:fit-to-frame="false" style:shrink-to-fit="false"} b) {draw:fit-to-frame="true" style:shrink-to-fit="false"} c) {draw:fit-to-frame="false" style:shrink-to-fit="true"} LibreOffice does not write the case {draw:fit-to-frame="true" style:shrink-to-fit="true"}. On loading either one or the other can be set, depending on producer and version of the document. The specification has yet no preference set. I suggest preference shrink-to-fit="true" over draw:fit-to-frame="true" for ODF 1.3. For b) an adaption in core is needed for fontwork-custom-shapes, because currently the draw:fit-to-frame="true" is not respected on loading, although it was written in older versions.
https://gerrit.libreoffice.org/43521 (assuming that we need a new attribute to distinguish between ALLLINES and PROPORTIONAL; Regina claims that may not be necessary...)
IRC conversation: <mst_> thorsten pppregin: "old style "glyph" scaling on the entire text block, which is not available for fontwork-custom-shapes" - is it really true that it's not possible? <mst_> if i resize the "fontwork" then the text is scaled automatically - so it looks like the PROPORTIONAL case <pppregin> mst_, what do you mean with "resize the fontwork"? <mst_> pppregin: drag the little blue squares <pppregin> mst_, that is the normal behavior of fontwork custom-shapes. The text is painted along the path onto the shape and will resize with the shape as every other painting in custom shapes. It resizes because the path resizes. If you open the file and look, you will see draw:fit-to-size="false". <mst_> pppregin: ... why does this then use TextFitToSizeType for the ALLLINES when it doesn't use TextFitToSizeType for PROPORTIONAL but instead uses NONE ? does that make any sense at all? <mst_> pppregin: is it possible to set a text-shape (not fontwork) to ALLLINES? <pppregin> mst_, you can set ALLINES only via macro. As far as I remember it does the same as PROPORTIONAL. But I need to test it again. <mst_> presumably Draw can import SVM files as a document? that would be the way to do it.. <mst_> in which case there is a possibility that you can set either PROPORTIONAL or ALLLINES on the same object, so we need some attribute to distinguish them <pppregin> mst_, after some test in LO6: For legacy shapes, normal custom shapes and textbox shapes the behavior is identical for both. For fontwork shape assigning ALLLINES results in the same visual rendering as stretchy-justify, but that is not selected. In file format is the invalid draw:fit-to-frame="all". For PROPORTIONAL is the same visual rendering than NONE and in file format is the draw:fit-to-frame="true". <mst_> pppregin: so for "normal" shapes PROPORTIONAL and ALLLINES are the same, and for fontwork NONE and PROPORTIONAL are the same? <pppregin> mst_, yes, but for fontwork shapes ALLLINES is invalid in file format and although visual it is stretch-justify, that is not reflected in the UI. So it is a buggy state and needs rework anyway. more on the bizarre case of the ALLLINES value: as far as the SdrTextObj is concerned, SdrTextObj::IsFitToSize() checks for either PROPORTIONAL or ALLLINES and there is no further distinction between them; there is also no UI to set ALLLINES here, while there is UI to set PROPORTIONAL. as far as the font-work custom-shape is concerned, GetFontWorkOutline() checks for ALLLINES and there is no code to check for any other value such as PROPORTIONAL; the ALLLINES value can be set by the UI and the PPT import but there's no UI to set PROPORTIONAL. then there is this mysterious function ImpSdrGDIMetaFileImport::ImportText() which imports a SVM GDIMetafile and creates a SdrRectObj and sets ALLLINES on it. i think ideally ALLLINES should not be a value of TextFitToSizeType but of TextHorizontalAdjust, let's say BLOCK_STRETCH, that would make more sense to me. unfortunately it would be an incompatible API change now.
ALLLINES cannot be part of TextHorizontalAdjust because that explicitly defines, that it is not for individual lines, but for the entire text area. It belongs to to the part "Text Anchor" in the "Text..." dialog in the UI. I guess, that ALLLINES and PROPORTIONAL where never different in the beginning (please ask Armin). The line pText->SetItem( SdrTextFitToSizeTypeItem( SDRTEXTFIT_ALLLINES ) ); in svdfmtf.cxx was there already in OOo1.1.5 source 2002. At that time custom-shapes and fontwork-custom-shapes did not exist. The question is, whether any other object then fontwork-shape is already able to render like stretchy-justify. Then you need an additional attribute. I do not know any such object. If such object not exists, then the question is, whether the rendering "stretchy-justify" is going to be implemented for other objects. I see no need for it. If not, then my proposed mapping should work.
In regard to MS Office import and why it is in filter code: MS Office has a VML WordArt with v:textpath element and a style attribute and therein v-text-align:stretch-justify. Such WordArt belongs to Word 97-2003. It can be read, edited and saved by Word 2010, but Word 2010 has no obvious UI to generate it from scratch. LibreOffice imports v-text-align:stretch-justify correctly from a .doc document, but not from .docx document.
i searched the OOXML part 1 for some time and didn't find an equivalent to the VML "v-text-align:stretch-justify". okay, you've convinced me, if OOXML can't do that and we currently don't need it then i don't want to propose it for ODF, given how ugly it looks :)
So - just to throw in my random 2 cents; I am completely convinced - primarily by reading the -horrors- that are the slow, non-converging, and otherwise generally grim code that tries to fit text into slides - that we should treat "shrink to fit" as purely a UX hint - to be used on editing. Otherwise everyone loading and rendering the text should use the result of the last attempt to do this - which should be the font-size on the text =) Of course, that we prolly don't do that now is given, and a big mistake =) I can well imagine that other implementations would really struggle to match our algorithm here - even if it is/was stable ;-) Not sure if that helps but ... anyway; just a queued up annoyance to vent; thanks for listening.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=33eb9fdb61033b3fd35d923900b1f5791f4b71c8 tdf#97630 xmloff: ODF extended draw:fit-to-size mess It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=92fe6fed58d3166740ab00a274e4c69562b20d0e offapi: update TextFitToSizeType documentation for tdf#97630 fix It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Michael Meeks from comment #29) > So - just to throw in my random 2 cents; I am completely convinced - > primarily by reading the -horrors- that are the slow, non-converging, and > otherwise generally grim code that tries to fit text into slides - that we > should treat "shrink to fit" as purely a UX hint - to be used on editing. > Otherwise everyone loading and rendering the text should use the result of > the last attempt to do this - which should be the font-size on the text =) Currently the resulting font-size is not written to file. If writing it as burn-in value to an automatic style, that would override the reference font-size, so that size-up in case of making object larger or reducing text, would not work. If writing it as burn-in value to e.g. "outline1"-style, that would not only effect the one desired slide, but other slides with same master too. So remembering the font-size would likely need a new attribute in ODF with meaning: If consumer is not able (or currently not willing) to recalculate the font-size, it can use the font-size in this attribute for rendering.
It is longer part of the code than I am working on it, so I cannot really say why it is there. I would *guess* that it has to do with the MS import and some BugFix/adoption to something they did differently than we did.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=451fcee7f7c2bdc5a9241662c412027672df3a1c&h=libreoffice-5-4 tdf#97630 xmloff: ODF extended draw:fit-to-size mess It will be available in 5.4.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=244dfe2f3fa874d99dacea191e2265a288457a98&h=libreoffice-5-3 tdf#97630 xmloff: ODF extended draw:fit-to-size mess It will be available in 5.3.8. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-5-3-7": http://cgit.freedesktop.org/libreoffice/core/commit/?id=530bd29aa61279ce5fe55b240a394cb76a791637&h=libreoffice-5-3-7 tdf#97630 xmloff: ODF extended draw:fit-to-size mess It will be available in 5.3.7. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-5-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ae039c48cc611e7498e2b781003287cd939fcd5f&h=libreoffice-5-4-3 tdf#97630 xmloff: ODF extended draw:fit-to-size mess It will be available in 5.4.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Master still writes the faulty draw:fit-to-size="shrink-to-fit", which makes the file invalid.
Dear Michael Stahl, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assigned it back to yourself if you're still working on this.
Dear Regina Henschel, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Created attachment 151783 [details] Presentation with objects failing in ODF 1.2 extended The error still exists for "ODF 1.2 extended" in Version: 6.3.0.0.alpha1+ Build ID: f6e7dbccf063767c2ac87c6460bd1004df742081 CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-05-30_00:13:29 Locale: de-DE (en_US); UI-Language: en-US Calc: threaded Saving in "ODF 1.2 strict" writes it correctly. Open attached file in current master and save it in "ODF 1.2". Then open both files in a current LO vers. 6.2 or 6.1. Compare the two versions, e.g. adding lines or reducing shape height so that "fit" is triggered. You will notice no difference. So what it the reason to still write the wrong attribute values?
(In reply to Regina Henschel from comment #41) > So what it the reason to still write the wrong > attribute values? the reason is that we want to wait until most users have upgraded to a version that includes commit 33eb9fdb61033b3fd35d923900b1f5791f4b71c8 before fixing that.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/bd03dc39f6f02a875590413378355daa4893a988 tdf#97630 xmloff: ODF export: fix draw:fit-to-size mess, step 2 It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
fixed on master
Seen OK in Version: 7.0.0.0.alpha1+ (x64) Build ID: 0a7341c26741f16835c9062c309e7d3a7fca8209 CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Raster; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL