Bug 34467 - FORMATTING: Fit to Frame for text boxes is broken
Summary: FORMATTING: Fit to Frame for text boxes is broken
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.3.0 release
Hardware: All All
: highest major
Assignee: Justin L
URL:
Whiteboard: target:5.0.0 target:5.3.0 target:5.2.4
Keywords: bibisected, bisected, regression
: 47821 47915 92109 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-02-18 18:24 UTC by dr.jose.ameknorb
Modified: 2016-11-29 06:18 UTC (History)
21 users (show)

See Also:
Crash report or crash signature:


Attachments
Fit to frame example (123.95 KB, application/vnd.oasis.opendocument.graphics)
2013-03-05 00:27 UTC, crxssi
Details
new fit to frame example (11.09 KB, application/vnd.oasis.opendocument.graphics)
2014-04-30 23:52 UTC, tommy27
Details

Note You need to log in before you can comment on or make changes to this bug.
Description dr.jose.ameknorb 2011-02-18 18:24:25 UTC
The Fit to Frame option for a text box in the draw application does not work when creating a new text box.

If, prior to creating a text box, the "Fit to Frame" checkbox is selected from the dialog accessed via the Format menu's Text... item, text entered into the box is supposed to fill the frame.  Instead, ordinary small text is entered.
If the same steps are taken in Oracle's OpenOffice.org, the text will fill the frame.
When opening a drawing document created by Oracle's OpenOffice.org that uses "Fit to Frame", LibreOffice will display it correctly and the text will resize with changes to the frame.

This is being reported against LibreOffice 3.3, but has also been present in earlier 3.x go-oo builds of OpenOffice.org.
Comment 1 Javier Rivera 2011-08-26 03:28:23 UTC
I can comfirm this bug in LibreOffice 3.3.3 under Ubuntu 11.04 and LibreOffice 3.4.0 under Windows. There is a workaround, you can select the text frame and hit CTRL+SHIFT+F8, it will work as expected.

The functionality is there, so it looks like a bug in the user interface.
Comment 2 Björn Michaelsen 2011-12-23 11:46:06 UTC Comment hidden (obsolete)
Comment 3 dr.jose.ameknorb 2012-01-07 08:43:25 UTC
The bug is still present in 3.5 beta 2.
Comment 4 Rainer Bielefeld Retired 2012-06-23 04:40:13 UTC
*** Bug 47821 has been marked as a duplicate of this bug. ***
Comment 5 Rainer Bielefeld Retired 2012-06-23 04:48:16 UTC
Reproducible.

Creating text boxes due to 
<http://help.libreoffice.org/Draw/Adding_Text#Fitting_Text_to_Frames>
works for me as expected with OOo 3.1.1 and still with AOOo 3.4, so this one is a LibO specific regression I already observe with "LibreOffice 3.3.3  German UI/Locale [OOO330m19 (Build:301) tag libreoffice-3.3.3.1] on German WIN7 Home Premium (64bit).

@Radek:
Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
Comment 6 Rainer Bielefeld Retired 2012-06-23 04:51:09 UTC
*** Bug 47915 has been marked as a duplicate of this bug. ***
Comment 7 Rainer Bielefeld Retired 2012-06-23 04:58:59 UTC
"Major" due 2 duplicates
Comment 8 Dave Legge 2012-06-26 04:07:56 UTC
It may help to note that unchecking the 'Fit to frame' box does work as expected.
This was a bug in Go-oo
Comment 9 sasha.libreoffice 2012-07-06 08:38:11 UTC
Bug 47915 has attachment.
For producing this effect we should save drawing
document as fodt, open it in text editor and do following:
Change this:
draw:fit-to-size="shrink-to-fit"
To this:
draw:fit-to-size="true"

So, as I can see, Draw and Impress UI not fully corresponds with ODF format.
May be someone changed saving/opening of document, but not updated UI.
Comment 10 Rodolfo 2012-08-04 07:52:31 UTC
So maybe this is related to Bug 49618?
Comment 11 Andreas Hyballa 2012-09-21 21:10:32 UTC
Yes, in 3.6.1 this bug still remains! When I press Shift+CTRL+F8 everything is okay... so please... check this nasty bug!
Comment 12 Rainer Bielefeld Retired 2012-09-22 04:14:14 UTC
@Andreas Hyballa:
<http://wiki.documentfoundation.org/BugReport_Details#Version>
Comment 13 sasha.libreoffice 2012-12-05 13:24:58 UTC
cite from OASIS ODF standard v1.1:
15.16.2 Fit To Size
The attribute draw:fit-to-size specifies whether or not to stretch the text content of a drawing object to fill the entire object. If the value of the attribute is true, the text content is stretched.
-----end citation-----

But when I open attachment from Bug 47915 in Calligra office and msOffice, text in frame is small. They do not understand this option. May be this change in Impress done for compatibility reasons.
Comment 14 Joel Madero 2013-02-08 15:53:21 UTC
3.5 has come to end of life in its cycle so we are confirming the bug still exists in LibreOffice 4 and if it does, confirming that it is indeed a MAB. 

I have confirmed this bug on: Version 4.1.0.0.alpha0+ (Build ID: 027bb41aa16793e88e9fc1b3550c8c893363647) Bodhi Linux

Moving to 3.6 MAB
Comment 15 crxssi 2013-03-04 17:13:46 UTC
This is a *CRITICAL* regression bug.  We just stumbled across it today in the real-world where it ruined many of our existing Draw and other documents that depend on the feature to be working correctly.

The "fit to frame" option is completely broken.  It doesn't fit text at all when the frame is increased in size .  And when reduced in size, it doesn't work properly either, it keeps the text proportional (which it is not supposed to do).  And those are behaviors for NEW objects in a NEW document.  When you open an EXISTING older document that uses fit-to-frame, the behavior is even more bizarre- increasing the vertical size of the frame causes the text to become huge (yet still proportional) and run way outside the frame.

Confirmed as broken in LibreOffice 4.0.0 and confirmed as NOT broken in OpenOffice 3.4.1.  This is the second "show stopper" bug we have found that prevents us from using LibreOffice :(
Comment 16 Joel Madero 2013-03-04 17:37:37 UTC
Adding Impress expert (believe that means drawing expert as well).

Thorsten - you have a bit of time to investigate this long standing issue?
Comment 17 Rainer Bielefeld Retired 2013-03-04 18:02:07 UTC
WORKSFORME with  Attachment 63893 [details] for Bug 47915 and 
"Version 4.1.0.0.alpha0+ (Build ID: 21171e0a7fd3aaa14a45a72bfecbc2b2a4ad767)
TinderBox: Win-x86@6, Branch:master, Pull Time: 2013-03-03 03:36:03

I will do additional check with 4.0.2, soon
Comment 18 Thorsten Behrens (allotropia) 2013-03-04 18:28:14 UTC
(In reply to comment #15)
> When you open an EXISTING older document that uses fit-to-frame, the
> behavior is even more bizarre- increasing the vertical size of the frame
> causes the text to become huge (yet still proportional) and run way outside
> the frame.
> 
I would consider that a bug indeed - can you please attach a simple example showing that behaviour?

Beyond that, the usefulness of the OOo-era fit2Frame anisotrophic scaling behaviour is probably a matter of debate. A possible workaround is to convert such text objects into metafiles, then scale. Or if you need to keep it editable, e.g. create in Draw, then paste-special as "Draw 8" in Impress to get you an embedded OLE object.
Comment 19 crxssi 2013-03-04 23:45:27 UTC
(In reply to comment #17)
> WORKSFORME with  Attachment 63893 [details] for Bug 47915 and 
> "Version 4.1.0.0.alpha0+ (Build ID: 21171e0a7fd3aaa14a45a72bfecbc2b2a4ad767)
> TinderBox: Win-x86@6, Branch:master, Pull Time: 2013-03-03 03:36:03
> 
> I will do additional check with 4.0.2, soon

Interesting.

I did not try the attachment references, above, until just now.  That works for me too.  However, I don't understand how that document object was created.  It is showing options that are not allowed and also not changeable.  (Fit height to Text AND Fit to Frame AND Resize shape to fit text are all selected, which is not valid, plus they are all shaded out and unselectable)/

I will illustrate the broken behavior for you:

* Start a new Draw document in LibreOffice
* Use the text tool and click on the screen
* Type the words "Enlarge it"
* Select the text object
* Right click and select "Text"
* Under the "Text" menu there are several selections checked by default
* In order to use the "Fit to Frame" option, you MUST de-select Fit width to text and Fit height to text, so do that.
* Once those two are deselected, you can now select the "Fit to Frame option"
* Click on OK
* Now select the text object and attempt to enlarge it.
* Note the completely broken behavior in LibreOffice- it will not scale the text at all.
* Repeat under OpenOffice and note the correct behavior.
Comment 20 crxssi 2013-03-04 23:53:49 UTC
(In reply to comment #18)
> (In reply to comment #15)
> > When you open an EXISTING older document that uses fit-to-frame, the
> > behavior is even more bizarre- increasing the vertical size of the frame
> > causes the text to become huge (yet still proportional) and run way outside
> > the frame.
> 
> I would consider that a bug indeed - can you please attach a simple example
> showing that behaviour?

I am not at work now, so I will see what I can come up with later (it will have to be created such as not to contain proprietary info).  
 
> Beyond that, the usefulness of the OOo-era fit2Frame anisotrophic scaling
> behaviour is probably a matter of debate.

It might seem like an old feature that can be ignored, but:

1) The option is there and doesn't work.
2) Previous documents can contain such objects and will break under LO.
3) The option actually is quite useful and powerful.

If the proposed solution is to just de-code the feature entirely, or to ignore the issue, I think that would be bad.

> A possible workaround is to convert such text objects into metafiles, then
> scale. Or if you need to keep it editable, e.g. create in Draw, then paste-
> special as "Draw 8" in Impress to get you an embedded OLE object.

As you pointed out, converting such objects to curves or metafiles does not allow editing.  In my experience, using OLE objects has always been slow, difficult, and unreliable.  It might work in a similar manner, however.
Comment 21 crxssi 2013-03-05 00:27:28 UTC
Created attachment 75932 [details]
Fit to frame example

Looks like I could create this more easily that I thought.  This is a test document that clearly illustrates the broken behavior of "fit to text" in LibreOffice 3.6.5 and 4.0.0.  It is self-documenting and includes screenshots of itself as seen in LibreOffice vs. OpenOffice.
Comment 22 Thorsten Behrens (allotropia) 2013-03-05 00:43:57 UTC
(In reply to comment #20)
> 2) Previous documents can contain such objects and will break under LO.
>
Yes, as I said, I consider that a bug. Thanks for the sample file!
Comment 23 Rainer Bielefeld Retired 2013-03-05 05:52:17 UTC
I see, this one is much more tricky than I thought after my simple test, so there might be some progress, but the problem currently is definitively not fixed yet for 4.1; remove target for now.

@crxssi:
Your sample is great, shows the manifold cases to be considered.
Comment 24 crxssi 2013-07-26 19:13:10 UTC
Tested in LO 4.1.  No change in behavior, it is still a major regression/problem.

Text in a newly created "fit to frame" object will not increase in size when the frame is enlarged, it will only shrink if the frame is made smaller than the text and then it wraps, which it should not do, and it doesn't scale non-proportionally.
Comment 25 tommy27 2013-08-01 04:45:18 UTC
moving it to mab4.0 from mab3.6 because 3.6 has reached EOL so we are in the process of closing the meta bug.
Comment 26 crxssi 2013-10-07 13:59:45 UTC
There is a change in behavior when I tested this under 4.1.2 (might have been in all 4.1.X to date, I am not sure).  It is still broken for creating any new text box with fit to frame selected.  And you can see this still in the last two boxes on the sample document.  They will only shrink the text proportionally and only if you make the box really small.  But it will never enlarge the text, nor scale it disproportionally like it is supposed to do.

But text boxes with fit to frame that were created in OpenOffice 3.4.2 or prior seem to be working properly now.  This can be seen in the correct behavior of the top two text boxes in the sample document.  I can even select and copy one of the older text boxes that is working, and the copied one works too.

Very strange.
Comment 27 Björn Michaelsen 2014-01-17 09:58:24 UTC Comment hidden (obsolete)
Comment 28 tommy27 2014-02-15 16:55:16 UTC
still reproducible with 4.1.4 and 4.2.0 final releases

moving from mab4.0 to mab4.1 since 4.0 reached end of life
Comment 29 tommy27 2014-04-30 19:13:25 UTC
retested test file under Win7x64 using LiBO 4.2.3.3
it seems to me that things work now. situation looks normal unlike the original buggy behaviour in older releases.

I set status to RESOLVED WORKSFORME

please open a new bug report if you still see some residual issues.
Comment 30 crxssi 2014-04-30 23:26:25 UTC
(In reply to comment #29)
> retested test file under Win7x64 using LiBO 4.2.3.3
> it seems to me that things work now. situation looks normal unlike the
> original buggy behaviour in older releases.
> 
> I set status to RESOLVED WORKSFORME
> 
> please open a new bug report if you still see some residual issues.

I am sorry, but it is not fixed at all- I just tested it in LO 4.2.3.3 Linux 64bit.  If you follow the steps in comment 19, the behavior has not changed.  If you create a text object and turn on "fit to frame", it does not enlarge with the frame, ever.  And it does not shrink with the frame except if you resize the frame vertically.  If you resize the frame only horizontally, it keeps the exact same size and just wraps the text.

I see no need for a new bug report- this report is still valid.  Changing to REOPENED.
Comment 31 tommy27 2014-04-30 23:52:00 UTC
Created attachment 98268 [details]
new fit to frame example

Ok. Instructions in comment 19 are helpful to reproduce the bug.
thnak you for pointing this out.

I think the original test file is misleading probably because contains old issues that have been fixed meanwhile.

so I attach here a new minimal test case that shows current behaviour under 4.2.3.3 and 4.3.0.0 alpha (22 april build)

enlargement has no effect at all either horizontally or vertically
shrinking has effect only vertically and horizontally if you shink it very much
Comment 32 tommy27 2014-05-01 08:26:33 UTC
4.1.x reached end of life.
moving this still reproducible bug to mab4.2 list.
Comment 33 tommy27 2014-09-14 19:37:19 UTC
still reproducible with LibO 4.3.1.2 and 4.4.0.0.alpha0+
Build ID: 880c18f23068a1faf34f36a67161e3b85fffdea7
TinderBox: Win-x86@42, Branch:master, Time: 2014-08-30_23:06:34
Comment 34 tommy27 2014-11-19 04:06:01 UTC
still reproducible in LibO 4.4.0.0.alpha2+
Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827
TinderBox: Win-x86@42, Branch:master, Time: 2014-11-12_00:19:18

LibO 4.2.x reached the end of life.
moving this mab4.2 to mab4.3 list.
Comment 35 Timur 2015-01-23 14:44:00 UTC
(In reply to Javier Rivera from comment #1)
> you can select the text frame and hit CTRL+SHIFT+F8, it will work as expected.
> The functionality is there, so it looks like a bug in the user interface.

Sorry, since this is true, is this not some simple bug in GUI?
Keyboard combination CTRL+SHIFT+F8 stands for "Format - Fit to Frame" command.
Comment 36 Julien Nabet 2015-04-11 09:02:32 UTC
ux-team: I gave a try first to  Menu Format/Text (without having selected any object first), is it right that some checkboxes are checked but disabled?
Indeed, we can't uncheck them since they're disabled.

If needed, I can create a separate bug for this.

Code pointer: cui/source/tabpages/textattr.cxx
Comment 37 Commit Notification 2015-04-13 07:33:32 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b2bae9b940fc34d2eecd7839e3cba1f41d111e87

Related tdf#34467: Fit to Frame for text boxes is broken

It will be available in 5.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 38 tommy27 2015-05-22 12:12:15 UTC
@Julien
I just tried LibO 5.0 beta1 but I do not see any difference in behaviour from the 4.4.x branch after your patch. I tested using attachment 98268 [details]
Comment 39 tommy27 2015-06-16 12:26:35 UTC
*** Bug 92109 has been marked as a duplicate of this bug. ***
Comment 40 tommy27 2015-08-15 13:34:08 UTC
no change too with LibO 5.1.0.0.alpha1+
Build ID: 7d3fa6bae9f7a755eb2d0ca24bf1afd5f3646bb7
TinderBox: Win-x86@39, Branch:master, Time: 2015-08-09_08:38:08
Locale: it-IT (it_IT)
Comment 41 tommy27 2015-12-27 21:39:19 UTC
no change with LibO 5.2.0.0.alpha0+
Build ID: 451f359023c681a91dbb232a5ea3fffb12c964bc
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-12-27_07:49:03
Locale: it-IT (it_IT)
Comment 42 Wolfgang Jäger 2016-02-06 22:35:55 UTC
Caused by this forum post http://en.libreofficeforum.org/node/12611#comment-46561 I just tested with V5.1.0.3 under Win 8.1. 
The bug is still "happily living" and has some nice little brothers and sisters. 

By the way: AOO V4.1.2 does not show this bug.

I will not report new details whether there may be some or not. As long as the bug is stll NEW in its sixth year of life despite the many confirming comments and not officially recognised nothing will happen, I am afraid. 

Can someone explain this to me? 

If there is no intention to "reactivate" the option, it might better be removed from the respective settings dialogs.
Comment 43 Joel Madero 2016-02-06 23:26:47 UTC
(In reply to Wolfgang Jäger from comment #42)
> 
> I will not report new details whether there may be some or not. As long as
> the bug is stll NEW in its sixth year of life despite the many confirming
> comments and not officially recognised nothing will happen, I am afraid. 
> 
> Can someone explain this to me? 

The explanation is simple. This is a volunteer project, for a bug to get fixed a volunteer has to find it interesting. The options are always the same:

1) Fix it yourself - code is readily available;
2) Find a friend/family/colleague to fix it;
3) Pay for a fix;
4) Wait for a volunteer to tackle it.

Most of us fall into category 4 (10's of millions of users, a few dozen really active developers). We have a few thousand open issues, plus of course volunteer developers are doing cool things that they find interesting. So yes, sometimes a bug can sit "confirmed" (NEW) for a long time - this is the world of open source.
Comment 44 Wolfgang Jäger 2016-02-07 15:35:57 UTC
(In reply to Joel Madero from comment #43)

Thanks for the explanations. Just a few remarks.
ad 1) I surely would do that. Being 71 the needed preparations might fail.
ad 2) I only can hope to find a qualified friend here.

ad 3) I tried this concerning another (biger?) issue to no avail. If you consider paid contributions (or you know someone who does) visit https://ask.libreoffice.org/en/question/60133/how-to-get-better-scalable-bracket/, there my own "answer", for example. Since I no longer depend heavily on 'Math', this was an "unselfish" offer.

ad 4) No comment. 

AOO does not show THIS bug. It may be leading with others. Quarrel among sisters may endanger the complete heritage. Lack of readiness to accept authority to a certain degree possibly also may.

Regards
Comment 45 Regina Henschel 2016-02-07 23:13:45 UTC
If you use "ODF 1.2" and not "ODF 1.2 extended" for save and load, then the feature "fit to frame" will work as in older versions.
Comment 46 Thomas Krumbein 2016-02-08 08:39:12 UTC
(In reply to Regina Henschel from comment #45)
> If you use "ODF 1.2" and not "ODF 1.2 extended" for save and load, then the
> feature "fit to frame" will work as in older versions.

Sorry Regina - I just checked this on Win 10 with LibO 5.0.3  - this is not right.

"Fit to frame" does still not work. No change to prior versions.
Comment 47 Regina Henschel 2016-02-08 12:03:52 UTC
(In reply to Thomas Krumbein from comment #46)
> (In reply to Regina Henschel from comment #45)
> > If you use "ODF 1.2" and not "ODF 1.2 extended" for save and load, then the
> > feature "fit to frame" will work as in older versions.
> 
> Sorry Regina - I just checked this on Win 10 with LibO 5.0.3  - this is not
> right.
> 
> "Fit to frame" does still not work. No change to prior versions.

It works here for LO 5.2 and for LO4.2. The essential part is, that you have to _save_ it in "ODF 1.2". When you then reload the file, you will see that it fits to frame.

The reason for the trouble is, that "ODF 1.2 extended" writes the attribute value "shrink-to-fit" for the attribute "draw:fit-to-size". Strict ODF 1.2 only allows "true" or "false" as values and "ODF 1.2" indeed writes "true" as value. So if you have ever saved it in "ODF 1.2 extended", it has the wrong value and you first have to repair it.

You can exchange "shrink-to-fit" with "true" directly in the file source if you want. But opening and saving in "ODF 1.2" works as well.

I have written issue #97630 for a suggestion to get both features.
Comment 48 Thomas Krumbein 2016-02-08 13:03:14 UTC
(In reply to Regina Henschel from comment #47)
> (In reply to Thomas Krumbein from comment #46)
> > (In reply to Regina Henschel from comment #45)
[..]
> It works here for LO 5.2 and for LO4.2. The essential part is, that you have
> to _save_ it in "ODF 1.2". When you then reload the file, you will see that
> it fits to frame.
[..]
> 
> You can exchange "shrink-to-fit" with "true" directly in the file source if
> you want. But opening and saving in "ODF 1.2" works as well.
> 
> I have written issue #97630 for a suggestion to get both features.

ok, Regina, your are right. 

To change all the options, create the Frame, put in the text, store Document as 1.2, reopen ist and the text is "fit to frame";))

But I guess, this is not the target of this issue.

As a "normal" user I expect the following behaveor:

- create an new draw -document (i.e.) 
- create a new (text-)frame
- edit some text
- change the property of the textframe (fit to frame) 

--> and now I want to see the expanded text fitting to the frame! On my screen!
    (at this time we do not have any storing-prozess)

Or: if I change first the propertie of the textframe - my input-text should fit to frame during eding:)

So, your discription will create an new issue: a created file will change it viewing after storing and reopening..

Maybe, that there is a different issue in fileformat using - but this does not influence this issue here:)
Comment 49 V Stuart Foote 2016-02-08 14:31:07 UTC
(In reply to Thomas Krumbein from comment #48)
...
> --> and now I want to see the expanded text fitting to the frame! On my
> screen!
>     (at this time we do not have any storing-prozess)
> 
> Or: if I change first the propertie of the textframe - my input-text should
> fit to frame during eding:)
> 

During editing (creating a new Text Box or editing and existing) the Fit to Frame stretching does work correctly, it is just interplay of the commands linked to the Text Box dialog that remain scrambled.

You can directly manipulate the anisotropic stretch to fill the frame (creating an SVG meta) as follows:

1. select Text box Frame--triple click the text in the text box, the text should highlight and the blue text box should show, then click the frame-- status bar will show "Text Frame 'SOMETEXT...' selected"
2. open the context menu -> Text dialog
3. uncheck all boxes in the Text section, and OK out
4. enter a <ctrl><shift>+F8 to toggle the uno:TextFitToSize command
5. the text box may momentarily shrink to fit width of text, if so click outside the text box
6. text will expand anisotrophically to fill the frame
7. a second <ctrl><shift>+F8 will toggle the text back to its unstretched size.

It is the Text dialog that remains incorrect. It is not correctly applying the stretch when the "Fit to frame" box is checked--but it will remove the stretch when unchecked.
Comment 50 tommy27 2016-07-22 06:56:19 UTC
I see this bug is credited as  fixed in LibO 5.1.5 RC1 bugfix list.
https://wiki.documentfoundation.org/Releases/5.1.5/RC1

has anyone checked if it's right?
I don't have this version installed right now to test.
Comment 51 Thomas Krumbein 2016-07-22 07:19:51 UTC
Sorry, cannot confirm a solution.

It is still the same behavior (no effect when selecting the Checkbox "fit to frame" in textbox-properties).

It is still working like in comment #49 mentioned (ctrl + shift + F8) - but no influence when using the dialog.

Linux Mint 18, LibreOffice 5.2.0.2
Comment 52 Robinson Tryon (qubit) 2016-08-25 05:49:30 UTC Comment hidden (obsolete)
Comment 53 Heiko Tietze 2016-09-06 08:43:18 UTC
Using the attachments to test and in particular "Newly created fit to text box (small font)" I can confirm that ctrl+shift+F8 works as expected and resizes the text (however I have to press the shortcut twice the first time) but it doesnt when I use the "Text" dialog.

To me it's an ordinary bug so I remove the needsUXEval.

Version: 5.2.0.3
Build ID: 7dbd85f5a18cfeaf6801c594fc43a5edadc2df0c
CPU Threads: 8; OS Version: Linux 4.7; UI Render: default; 
Locale: de-DE (en_US.UTF-8)
Comment 54 crxssi 2016-09-06 12:04:44 UTC
>Heiko Tietze changed bug 34467
>What 	        Removed 	Added
>Component 	LibreOffice 	Writer 

Did I miss something?  Why would you change this to "Writer", when it is and always has been a Draw bug?
Comment 55 V Stuart Foote 2016-09-06 13:09:44 UTC
Text box draw objects were added to writer along with other Draw objects--slight differences in UI, but function the same (or rather don't function as here).

But issue affects Draw/Impress and Writer --> LibreOffice rather than Draw

Regina's notes regards saving to ODF 1.2, rather than ODF 1.2 extended, comment 46 apply to Writer Text box draw objects as well. Unfortunately the <ctrl><shift>+F8 shortcut toggle from Draw is not likewise implemented for Writer.
Comment 56 Justin L 2016-11-09 10:02:56 UTC
(In reply to Heiko Tietze from comment #53)
> I can confirm that ctrl+shift+F8 works as expected and resizes the text
> (however I have to press the shortcut twice the first time)

This makes sense. ctrl-shift-F8 is not a re-fresh, but a toggle, turning the setting on and off via SdrTextFitToSizeTypeItem->SetBoolValue (which sets SdrFitToSizeType::Proportional [anisotropic - stretch irregularly to fill frame]). If the setting is already on, the first C-S-F8 turns it off, the second turns it on.

> but it doesn't when I use the "Text" dialog.

The tab dialog (cui/source/tabpage/textattr.cxx) uses SdrFitToSizeType::Autofit [isotropic - shrink to fit] when you enable "Fit to frame".  (Fit to frame is "enabled" if SdrFitToSizeType is not ::NONE - so enabled if Proportional, AllLines, or Autofill.)

regression from Thorsten Behrens <tbehrens@novell.com>	2010-09-17 08:11:28 (GMT)
commit b7628798ec1a966c97a64d7cf0aa9f3859b78bef
fit-list-to-size.diff: Shrink font automatically when text overflows.
i#94086.  Scale-font-down if typing text in Impress and the text box becomes too small.
-            case STATE_CHECK: eFTS = SDRTEXTFIT_PROPORTIONAL; break;
+            case STATE_CHECK: eFTS = SDRTEXTFIT_AUTOFIT; break;

Changing this back to the original setting of ::Proportional will not affect previous documents - only the authoring of new documents.  Help indicates that the text will fill the frame (i.e. proportional).
Comment 57 Thorsten Behrens (allotropia) 2016-11-09 11:10:37 UTC
(In reply to Justin L from comment #56)
> regression from Thorsten Behrens <tbehrens@novell.com>	2010-09-17 08:11:28
> (GMT)
> commit b7628798ec1a966c97a64d7cf0aa9f3859b78bef
> fit-list-to-size.diff: Shrink font automatically when text overflows.
> i#94086.  Scale-font-down if typing text in Impress and the text box becomes
> too small.
> -            case STATE_CHECK: eFTS = SDRTEXTFIT_PROPORTIONAL; break;
> +            case STATE_CHECK: eFTS = SDRTEXTFIT_AUTOFIT; break;
> 
> Changing this back to the original setting of ::Proportional will not affect
> previous documents - only the authoring of new documents.
>

Fair enough - and there's still the context menu to toggle this
autofit feature. Perhaps a UX eval question then whether to have an
extra checkbox inside SvxTextAttrPage
Comment 58 Justin L 2016-11-09 18:37:54 UTC
Proposed fix:  https://gerrit.libreoffice.org/#/c/30727/
Comment 59 Justin L 2016-11-09 18:57:37 UTC
(In reply to Thorsten Behrens (CIB) from comment #57)
> Perhaps a UX eval question then whether to have an
> extra checkbox inside SvxTextAttrPage

I think UX's response is in comment 47 and bug 97630
Comment 60 Commit Notification 2016-11-15 10:31:46 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=098f7a4ac2b6f309a45d29f1b68bea18418b9ee7

tdf#34467 - FitToFrame: stretch text to fill drawing obj

It will be available in 5.3.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 61 tommy27 2016-11-16 06:42:48 UTC Comment hidden (no_fix_for_5.2_indicated, obsolete)
Comment 62 tommy27 2016-11-19 07:16:36 UTC
@Justin
as I told you in a private mail I did not expected that the bug was fixed in 5.2.x 

I retested in 5.2.x and 5.3.x just to see if there was any difference in behaviour between a version without the fix (5.2.x) and a version with the fix (5.3.x)

so marking my previous comment as obsolete was not correct.

I just retested with latest build  5.3.0.0.alpha1+
Build ID: 8d613870b2cd2e3e4396b4fa97dbd8080fda8f52
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-11-18_22:58:29
Locale: it-IT (it_IT); Calc: group

I still don't see any difference... maybe I'm doing something wrong, so follow my steps and tell me if are correct or not.

I took the test file from comment 31

again, if I enlarge the frame the text inside it ("Enlarge it") doesn't enlarge at all, an stay the same size it was at the beginning (not what I expect).

instead if I shrink it, the text becomes smaller and adapts to the new smaller frame (this is what I expect).

then if I enlarge the frame the text turn bigger but never bigger than the original size.

so it seems to me that the "fit to frame" works fine when shrinking but not when enlarging over the original text size.

anyone else can take a look at this?
Comment 63 Justin L 2016-11-19 08:25:55 UTC
(In reply to tommy27 from comment #62)
> I took the test file from comment 31

The key part that you are missing is that "fit to frame" is not yet enabled on the test file from comment 31.  (Yes - it was REPORTED as enabled before, but that is because before it regarded "Fit to Frame" as _Autofit, and thus the document is saved with the Autofit setting.  With the fix, _Autofit is now considered to be the opposite of "Fit to Frame".)

After turning on Format - Textbox and Shapes - Text Attributes - Fit to Frame, now you can continue with this test:
> again, if I enlarge the frame the text inside it ("Enlarge it") doesn't
> enlarge at all, an stay the same size it was at the beginning (not what I
Comment 64 tommy27 2016-11-19 08:35:44 UTC
got it!!! now it works perfectly!!!

thanks for explanations and for fixing this very old and annoying bug.
Comment 65 Commit Notification 2016-11-29 06:14:39 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8a0575819ae3526831699767177b333270d6c718&h=libreoffice-5-2

tdf#34467 - FitToFrame: stretch text to fill drawing obj

It will be available in 5.2.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 66 tommy27 2016-11-29 06:18:25 UTC
so good that you backported to 5.2.x too.
thanks!!!