Bug 40469

[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.