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.
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.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
The bug is still present in 3.5 beta 2.
*** Bug 47821 has been marked as a duplicate of this bug. ***
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
*** Bug 47915 has been marked as a duplicate of this bug. ***
"Major" due 2 duplicates
It may help to note that unchecking the 'Fit to frame' box does work as expected. This was a bug in Go-oo
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.
So maybe this is related to Bug 49618?
Yes, in 3.6.1 this bug still remains! When I press Shift+CTRL+F8 everything is okay... so please... check this nasty bug!
@Andreas Hyballa: <http://wiki.documentfoundation.org/BugReport_Details#Version>
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.
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
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 :(
Adding Impress expert (believe that means drawing expert as well). Thorsten - you have a bit of time to investigate this long standing issue?
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
(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.
(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.
(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.
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.
(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!
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.
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.
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.
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.
(This is an automated message.) Setting priority to highest as this is a 4.0 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
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
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.
(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.
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
4.1.x reached end of life. moving this still reproducible bug to mab4.2 list.
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
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.
(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.
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
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.
@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]
*** Bug 92109 has been marked as a duplicate of this bug. ***
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)
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)
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.
(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.
(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
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.
(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.
(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.
(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:)
(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.
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.
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
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
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)
>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?
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.
(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).
(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
Proposed fix: https://gerrit.libreoffice.org/#/c/30727/
(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
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.
retested under Win8.1 x64 using LibO 5.2.3.3 and 5.3.0.0.alpha1+ (*) I see no change of behaviour... as described in comment 31 if you use the minimal test-case enlargement has no effect at all (either horizontally or vertically) while shrinking has effect only vertically and horizontally if you shrink it very much (*) Build ID: 84f644eee78106f01486098d446d9163b62927eb 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-15_23:52:44 Locale: it-IT (it_IT); Calc: group
@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?
(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
got it!!! now it works perfectly!!! thanks for explanations and for fixing this very old and annoying bug.
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.
so good that you backported to 5.2.x too. thanks!!!
*** Bug 58348 has been marked as a duplicate of this bug. ***