Bug 97630 - LibreOffice uses wrong attribute for feature "shrink-to-fit"
Summary: LibreOffice uses wrong attribute for feature "shrink-to-fit"
Status: ASSIGNED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
5.2.0.0.alpha0+
Hardware: All All
: high major
Assignee: Michael Stahl
QA Contact:
URL:
Whiteboard: odf odf_validation target:6.0.0 targe...
Keywords:
: 85062 101519 106147 (view as bug list)
Depends on:
Blocks: ODF-import ODF-export-invalid
  Show dependency treegraph
 
Reported: 2016-02-07 22:35 UTC by Regina Henschel
Modified: 2017-10-20 14:05 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot before saving to ODF 1.2 (36.76 KB, image/png)
2017-03-29 11:05 UTC, Jos van den Oever
Details
screenshot after saving to ODF 1.2 and opening again (47.11 KB, image/png)
2017-03-29 11:06 UTC, Jos van den Oever
Details
Bash script to fix files that are affected by this bug. (357 bytes, application/x-shellscript)
2017-03-29 11:08 UTC, Jos van den Oever
Details
XSLT to fix files affected by this bug. (912 bytes, text/xml)
2017-03-29 11:09 UTC, Jos van den Oever
Details
text distorted to fit frame (121.99 KB, application/vnd.oasis.opendocument.presentation)
2017-04-07 04:07 UTC, Elmar
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2016-02-07 22:35:00 UTC
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.
Comment 1 Buovjaga 2016-02-11 09:26:39 UTC
Setting to NEW.
Comment 2 tommy27 2016-11-19 08:37:39 UTC
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?
Comment 3 Regina Henschel 2016-11-20 19:09:30 UTC
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
Comment 4 Aron Budea 2017-02-23 00:03:06 UTC
*** Bug 101519 has been marked as a duplicate of this bug. ***
Comment 5 Aron Budea 2017-02-23 00:08:48 UTC
*** Bug 85062 has been marked as a duplicate of this bug. ***
Comment 6 Aron Budea 2017-02-23 00:12:55 UTC
*** Bug 106147 has been marked as a duplicate of this bug. ***
Comment 7 Michael Meeks 2017-02-23 09:30:16 UTC
This really bit me when I had (accidentally) left my setting to non-extended for a long period ... =)
Comment 8 Jos van den Oever 2017-03-29 10:49:11 UTC
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)
Comment 9 Michael Meeks 2017-03-29 10:51:30 UTC
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.
Comment 10 Jos van den Oever 2017-03-29 11:05:29 UTC
Created attachment 132250 [details]
screenshot before saving to ODF 1.2

Text is normal size and not fitted to box.
Comment 11 Jos van den Oever 2017-03-29 11:06:48 UTC
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.
Comment 12 Jos van den Oever 2017-03-29 11:08:21 UTC
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.
Comment 13 Jos van den Oever 2017-03-29 11:09:05 UTC
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.
Comment 14 Jos van den Oever 2017-03-29 11:29:37 UTC
Since this bug gives information loss and is very annoying, it should be marked with importance 'major'.
Comment 15 Thorsten Behrens (CIB) 2017-03-30 08:14:19 UTC
(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). ;)
Comment 16 Elmar 2017-04-07 04:05:34 UTC
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.
Comment 17 Elmar 2017-04-07 04:07:35 UTC
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.
Comment 18 Michael Stahl 2017-10-17 20:18:10 UTC
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"?
Comment 19 Regina Henschel 2017-10-18 02:17:50 UTC
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?
Comment 20 Michael Stahl 2017-10-18 12:57:56 UTC
(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.
Comment 21 Regina Henschel 2017-10-18 13:41:44 UTC
(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.
Comment 22 Michael Stahl 2017-10-18 14:43:09 UTC
(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...
Comment 23 Regina Henschel 2017-10-18 17:41:10 UTC
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.
Comment 24 Michael Stahl 2017-10-18 21:23:52 UTC
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...)
Comment 25 Michael Stahl 2017-10-19 11:27:20 UTC
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.
Comment 26 Regina Henschel 2017-10-19 12:53:19 UTC
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.
Comment 27 Regina Henschel 2017-10-19 13:33:25 UTC
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.
Comment 28 Michael Stahl 2017-10-19 21:36:05 UTC
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 :)
Comment 29 Michael Meeks 2017-10-20 08:50:10 UTC
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.
Comment 30 Commit Notification 2017-10-20 09:00:46 UTC
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.
Comment 31 Commit Notification 2017-10-20 09:19:46 UTC
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.
Comment 32 Regina Henschel 2017-10-20 11:22:42 UTC
(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.
Comment 33 Armin Le Grand (CIB) 2017-10-20 12:05:02 UTC
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.
Comment 34 Commit Notification 2017-10-20 14:05:04 UTC
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.
Comment 35 Commit Notification 2017-10-20 14:05:34 UTC
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.