This bug has been inside OpenOffice/LibreOffice for 6.5 years now, it's discussed here for example: http://openoffice.org/bugzilla/show_bug.cgi?id=45499 Summary: In the "type (size & position)" tab of "frame styles" definition, at least the following strange behaviors can be observed: * keep aspect ratio is always greyed out * the "automatic size" option does not work properly * the values in "width" and "height" get reset to "0.04cm" (or some other stupid number) every second or third time you use the dialog This buggy behavior of all "frame styles" basically makes the use of those "frame styles" mostly pointless. Frame Styles might not be the feature most LO users do use, but it is a very useful feature (and a feature that Word does not have to my knowledge), so why don't me make it work as it's ment to work? Please to cope with this bug, I'd love to use the frame styles for styling all images consistently in a big document.
[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
Sorry for the delay. I've tested for this bug in LO 3.5.5.3. But unfortunatelly it still DOES exists there without any improvements. Please try to eleminate these funny behaviours that make the cool "frame styles" feature of LibreOffice mostly useless at the moment.
I can confirm 1 & 3 * keep aspect ratio is always greyed out * the values in "width" and "height" get reset to "0.04cm" (for me it's 0.02") (or some other stupid number) every second or third time you use the dialog #2 * the "automatic size" option does not work properly Needs to have additional information. What does "does not work properly" mean? I'm still going to mark as confirmed, we try not to bundle bugs like this but I think that if a developer takes on one, they can easily take on all three (if the third can be verified) Editing title a bit Priority: Minor -- Forces users to not user specific features in order to have high quality work Medium - Not a lot of users use frame styles but for those who do this would be very problematic. Might be a bit difficult but I think ProposedEasyHack is valid. Preserving options shouldn't be too difficult, keep aspect ratio code is already available, just need to link it up to these settings and allow user to select it.
Confirmed on LibO 3.6.1.2 Bodhi Linux
i can't reproduce the resetting of with/height here. the "keep ratio" is grayed out though. it seems a good start to investigate this would be SwDocShell::Edit in sw/source/ui/app/docst.cxx
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility. see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
New link to AOOo: https://issues.apache.org/ooo/show_bug.cgi?id=45499
Just noticed but when commenting line 885 of sw/source/ui/frmdlg/frmpage.cxx makes the keepratio checkbox enabled: 881 if (bFormat) 882 { 883 // at formats no anchor editing 884 m_pAnchorFrame->Enable(false); 885 //m_pFixedRatioCB->Enable(sal_False); 886 } More investigation is needed of course. See http://opengrok.libreoffice.org/xref/core/sw/source/ui/frmdlg/frmpage.cxx#881
I tried 2 leads: 1) is it normal bFormat = sal_True and gdb session gave me this: #0 SwFrmPage::SetFormatUsed (this=0x1cb36f0, bFmt=1 '\001') at /home/julien/compile-libreoffice/libo/sw/source/ui/frmdlg/frmpage.cxx:2319 #1 0x00002aaad88ac24a in SwTemplateDlg::PageCreated (this=0x1fa0c30, nId=2, rPage=...) at /home/julien/compile-libreoffice/libo/sw/source/ui/fmtui/tmpdlg.cxx:437 #2 0x00002aaaad9a192c in SfxTabDialog::ActivatePageHdl (this=0x1fa0c30, pTabCtrl=0x1c97100) at /home/julien/compile-libreoffice/libo/sfx2/source/dialog/tabdlg.cxx:1324 #3 0x00002aaaad99fbfb in SfxTabDialog::Start_Impl (this=0x1fa0c30) at /home/julien/compile-libreoffice/libo/sfx2/source/dialog/tabdlg.cxx:747 #4 0x00002aaaad99f7d0 in SfxTabDialog::Execute (this=0x1fa0c30) at /home/julien/compile-libreoffice/libo/sfx2/source/dialog/tabdlg.cxx:678 #5 0x00002aaad8824cad in AbstractTabDialog_Impl::Execute (this=0x18a8cb0) at /home/julien/compile-libreoffice/libo/sw/source/ui/dialog/swdlgfact.cxx:103 #6 0x00002aaac947834c in SwDocShell::Edit (this=0x15f39f0, rName="Frame", rParent="", nFamily=4, nMask=0, bNew=0 '\000', sPage="", pActShell=0x0, bBasic=0 '\000') at /home/julien/compile-libreoffice/libo/sw/source/ui/app/docst.cxx:749 2) if it's normal that ratio is disabled if bFormat = true git history shows it's been like this since the initial import (in 2000) I don't know what to conclude with all this however.
Comfirmed in LO 4.2.4. The frame styles do not have thwe same behavior and some options do not have effect on graphics. You cannot apply frame styles to a bunch of inserted pictures, because formatting optios inside frame style do not work well. []s
Cannot identify described bug in version 4.3 dev, "keep ration" option is available and working properly. Gilvan Vilarim, can you describe more detailed the bug situation you got?
1 - Create or open a text document 2 - Go to Insert > Image > From File 3 - Choose an image and clik Open (note: this dialog box always chooses a default frame style for graphics, which is "Graphics") The image is inserted and you can use the Stylist to see that the frame style "graphics" was applied automatically. 4 - Try to apply another frame style to image (e.g.: Formula). Select image and double-click on a different frame style. Expected behavior: the image should follow the attributes of the Formula style Actual behavior: the new style is applied, but some attributes become grayed inside the style (right-click on Formula frame style > Type); the image also gets stretched/shrinked, and position parameteres (To... combobox) do not show the same options as in other frame styles. It looks like an erratic behavior. I guess frame styles should have the same behavior. The decision to use Graphics, Formula, OLE (etc) styles should only be a matter of categorization. What I (and many others) really need is: apply the same frame style to all images inside a text document, then realign and anchor them to paragraphs, not anchor to pages. I could not do that with styles. Best regards, Gilvan.
This bus seems to have something to do with bug #79160
CONFIRMED: The inability to preserve inserted images' aspect ratio in frame styles in LibreOffice Writer 4.3.5.2 on Windows 7 x64. The "Keep ratio" checkbox is grayed-out. This is actually a *major* problem for users who must insert a large number of disparately dimensioned images into a document and set them at either a uniform width or uniform height, without stretching or squishing them. The time required to format (or re-format) hundreds of inserted images individually is hundreds of time higher than the time required to modify a single style. A potential distant-second-best workaround might be to write a macro to apply initial or subsequently modified frame properties to inserted images individually. While still very tedious and time-consuming, this would cut down on the time required by a factor of, say, 10 to 20, and would reduce the potential for isolated typing mistakes even more. Unfortunately for ordinary (non-coder) users, setting frame properties doesn't seem to be amenable to recording: when I tried it, non-default settings in only one tab were recorded -- and I'm not sure all of *them* were -- and after a second or third attempt, the record macro feature stopped working. (Clicking the "Stop recording" button closed the box without offering the user a chance to name the macro.) I haven't searched for this bug yet or fully explored it myself, but I mention it as it's relevant here. Ideally, in the Frame Style dialog box's Type tab, the user should be able to specify *either* width *or* height, click the "Keep ratio" checkbox, and have the unspecified dimension left blank and free to be calculated on the fly for each inserted image the frame style is applied to.
Andrei, are you actually working on this any more? Keeping the bug in the "assigned" state if you are not working on it is counter-productive, as it likely prevents others interested in an EasyHack from working on it.
Migrating Whiteboard tags to Keywords: (easyHack, difficultyBeginner, skillCpp) [NinjaEdit]
Andrei@ A polite ping are you still working on this ?
Sorry community, I didn't figure it out. And I'm not working more at this bug. I'm changing the status. (In reply to jan iversen from comment #17) > Andrei@ A polite ping are you still working on this ?
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC) [NinjaEdit]
*** Bug 49323 has been marked as a duplicate of this bug. ***
I want to work on this.But i am not very clear about what to implement
(In reply to charan from comment #21) > I want to work on this.But i am not very clear about what to implement If you are not sure what to implement, maybe choosing another easyhack would be simpler. The easyhack are supposed to be easy and explained in the comments.
Does it mean that "Keep ratio" option of type tap of Frame... of Frame of Insert does not properly work? I can't see the problem in this section
If you create a new frame style (image, formula, ...), you can't select to keep the ratio. The only thing that works for me is to import an image first, then set the image how you want the frame style to be and then create a new style from the selected image.
*** Bug 116847 has been marked as a duplicate of this bug. ***
On Win10 with LO 6.3.0.4, "keep ratio" isn't disabled, I can enable it. Then if I change width, it changes the height if I change height, it changes the width so as expected. I don't know anything about frame style so can't test really. Could someone give it a new try with a recent LO version or provide to me a step by step process to reproduce the faulty behaviour?
I have retested this with LO 6.2.5.2. And I still DO see this wrong behavior. For example the procedure outlined in comment #12 behaves still the same. With regards to comment #26: * Yes, when you directly insert an image into a text document, you CAN than set the property "keep ratio". * But if you first insert an image, then change its frame style to something else than it default frame style ("image"), then you canNOT check the "keep ratio" property any more. You can find a detailed step by step instruction to reproduce this behavior in comment #12. I have set the status to "unconfirmed", because a note told me so. But this feels akward because this behavior HAS been confirmed for more than 15 years now...
(In reply to hardy from comment #27) > I have retested this with LO 6.2.5.2. And I still DO see this wrong behavior. > > For example the procedure outlined in comment #12 behaves still the same. > > With regards to comment #26: > * Yes, when you directly insert an image into a text document, you CAN than > set the property "keep ratio". > * But if you first insert an image, then change its frame style to something > else than it default frame style ("image"), then you canNOT check the "keep > ratio" property any more. > ... On pc Debian x86-64 with LO Debian package 6.3.3, I don't reproduce this. Here are the steps: - Launch Writer to have a brand new file - Menu Insert/Image (Frame style is indeed "Graphics" by default) - Choose an image (I use a bmp image) and click Open => image is on the document - select the image with just one left click - in sidebar, select "styles" icons (the fourth one after "Page" icon) - double click "Formula" style - right click on image to make contextual menu appear - Select Properties... - "Keep ratio" isn't disabled, is unchecked by default but I can check/uncheck it. Could you give a try with 6.3.3? Indeed 6.2 will be EOL tomorrow (see https://wiki.documentfoundation.org/ReleasePlan/6.2)
I removed the wrong url (even if there was a redirection) of tdf#79160 so we can see this bug has been put at RESOLVED. See https://bugs.documentfoundation.org/show_bug.cgi?id=79160#c26 and https://bugs.documentfoundation.org/show_bug.cgi?id=79160#c27
Sorry for not responding ealier. (The notify email does not always work for me...) I have retested what Julien did in comment #28 (with LO 6.3) an what I did in comment #27 (with LO 6.2). And now I can also NOT reproduce the buggy behavior, as outlined in comment #12 (or Julien's comment #28). I have no clue what I did different the time before. But when I go back to the very first description of this bug (from the year 2005), then I CAN STILL reproduce the buggy behavior described there. I could reproduce this with LO 6.2. I will quote the original bug report to describe what I did: ----- Simple problem, no solution: I just want to define a Frame style that positions images and assigns them a fixed width, but with the height calculated automatically from the image's proportions (aspect ratio). That's not possible, since for images the "AutoSize" function is not available and the "Keep aspect" is obviously ignored when applying frame styles. To reproduce - Create new writer doc. - Insert a small image (e.g. bigapple.gif from the gallary) - Check image's "Keep aspect ratio" to ON. - Create or edit a frame style to place the object somewhere (e.g. right page border) and set: Width: 4 cm Height (at least): 1 cm AutoSize: ON (P.S. Why is "Keep aspect ratio always grey?) - Apply style Result: Image is rescaled to 4cm width (OK for me) and 1 cm height (wrong!). So obviously a) the frame style's AutoSize does not work for images b) the "Keep aspect ratio" is ignored as well when applying a frame style to an image. Fazit: It's not possible to assign a frame style to an image without having to manually correct the aspect ratio afterwards. I consider this an important issue if images are to be placed as marginalia (with a fixed width) beside the text, but the aspect ratio needs of course to be correct. -----
I've got the same issue on OpenSUSE Tumbleweed. But I could swear it worked years ago when I wrote my Master's thesis on OpenOffice Writer. My thesis had a huge photo catalogue and I'm 95% positive that I used graphic styles for all of it in a way that doesn't work anymore. If it helps, I can dig up my thesis and check which version it was written with.
(In reply to hardy from comment #30) I gave a new try on master sources updated today + kf5 rendering. >... > To reproduce > - Create new writer doc. OK > - Insert a small image (e.g. bigapple.gif from the gallary) OK > - Check image's "Keep aspect ratio" to ON. OK > - Create or edit a frame style to place the object somewhere (e.g. right page > border) and set:... I created a frame style just below my image and I see Keep aspect ratio enabled. A little rectangle appears inside the top of my image (was it expected). Frame menu has 3 entries: - Frame interactively - Frame (the one I chose, was it the right one?) - Floating Frame > - Apply style Where's the option? Right click on image or on frame, no "Apply". => uncc myself cause I can't help here.
Created attachment 169344 [details] keep ratio greyed out This bug is NOT in the image properties. It is the "style" "frame" "graphics" "keep ratio" greyed out. Still present in version 7.0.4.2. It's a basic function, should be fixed for a long time.
@Heiko Papercut?
The root of the problem is that you can't set a frame size in a style, but at the same time the "synced" bool of a height or width is in SwFormatFrameSize. I attempted to improve this a little in this commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=4895a92e67ffbbee87ec5ee1e2394cdc5b833fcb With this, at least the per-view boolean is no longer false all the time you start up Writer, but we write this boolean to documents and restore it on load. You can now alter this setting from the frame style UI. (Not updating the bug status, there might be still unresolved parts of this.)
https://cgit.freedesktop.org/libreoffice/core/commit/?id=02c435082058ecf7f9d4d73cb47d31d0218dc10d is the ODF filter bit, the above was just the UI.