Bug 97630 - LibreOffice uses wrong attribute for feature "shrink-to-fit"
Summary: LibreOffice uses wrong attribute for feature "shrink-to-fit"
Status: NEW
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: Not Assigned
QA Contact:
URL:
Whiteboard: odf
Keywords:
: 85062 101519 106147 (view as bug list)
Depends on:
Blocks: ODF-spec
  Show dependency treegraph
 
Reported: 2016-02-07 22:35 UTC by Regina Henschel
Modified: 2017-04-07 05:48 UTC (History)
12 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.