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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.