In the stylist, the graphics 'Update Style' now only partially works.
Borders will apply. Background colour will apply. However, image anchoring will not apply.
This is exactly how I would change a graphics style in Writer:
1. Insert an image, modify its style (add borders) and presentation (anchor: as character)
2. Select "Update Style" on the graphics style in the stylist pane. Save document. Or save as template.
3. The graphics style immediately will be able to be used. I could immediately insert, or even paste an image into the document and the newly updated graphics style would apply itself (i.e. border applied, anchored to character).
This no longer works as of LibO 3.3.2. and OOo 3.3.0.
These steps also worked with OOo 3.2.1, 3.2.0.
[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:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Reproducible in 3.5.0 on Fedora 64 bit with changing anchoring
(changing borders behaves correctly)
This still occurs in release 22.214.171.124 with changing anchoring - only the changing of picture borders acts as is expected. Anchoring does not carry through. Windows 7, 64-bit.
Thanks for additional testing
Sorry, but "version" means most early version of LO where bug is reproduced. Not current version. Changing back to 3.3.2 and platform to All
Setting keyword "regression" according to initial description
I added this bug to the votelist wiki page :
wrong bug : forget the last comment
I agree. The default anchor type should be configurable. Just try to paste several images without any text in between, and with the default behaviour it acts very strange. I see dissapearing images sometimes. "Anchor as character" works perfectly, however. I almost always select "anchor as character" for images, as it's much more predictable.
Migrating Whiteboard tags to Keywords: (preBibisect)
In LO 5.1 there is no UI to change anchoring in graphics styles. So I am not sure if the problem is really in the malfunctioning of "Update Style" or only that it is not allowed to define anchor in the graphics styles
Are you sure that it was allowed to change anchoring in the graphics style in some previous LO or OOo version?
Best regards. JBF
Possible problem with any UI for "change anchoring" is that when anchoring is to para, which para? (presumably "current" para or "next" para, some algorithm), if e.g. anchored to "current page", then which para would be chosen when changing to "anchor to para"? The first para on the page? The first para that -starts- on this page? What if there is neither e.g.?
I.e., this is not a simple request.
The WYSIWYG View -> Normal view, when the object (frame, graphic etc) is selected, and the anchor is displayed, I think will always be the sane and expedient way to edit anchoring.
Notwithstanding, I say that "current anchor setting" -ought- be visible, e.g. as part of the "advanced properties" or "normal properties" for any selected object that has an anchor property. Advanced users always crave maximum siutational awareness, since it often helps to solve problems.
(In reply to Jean-Baptiste Faure from comment #9)
> In LO 5.1 there is no UI to change anchoring in graphics styles. So I am not
> sure if the problem is really in the malfunctioning of "Update Style" or
> only that it is not allowed to define anchor in the graphics styles
> Are you sure that it was allowed to change anchoring in the graphics style
> in some previous LO or OOo version?
> Best regards. JBF
Yes, it was allowed to change anchoring in both LibreOffice and OpenOffice.
This video shows OpenOffice 3.2.1 working: https://youtu.be/V761IxmmosI
*** Bug 36583 has been marked as a duplicate of this bug. ***
styles cannot contain anchor positions, and due to the implementation of class SwFormatAnchor that means it can't contain the anchor type either.
bug 112574 is related, a crash caused by a style containing anchor position.
presumably a similar crash bug was fixed in OOo 3.3.
but maybe it's possible to clear just the anchor position instead of the whole SwFormatAnchor in styles.
(In reply to Michael Stahl (CIB) from comment #13)
> styles cannot contain anchor positions, and due to the implementation of
> class SwFormatAnchor that means it can't contain the anchor type either.
Our "Formula" style is
<style:style style:name="Formula" style:family="graphic">
<style:graphic-properties text:anchor-type="as-char" svg:y="0mm" fo:margin-left="0mm" fo:margin-right="0mm" style:wrap="parallel" style:number-wrapped-paragraphs="no-limit" style:wrap-contour="false" style:vertical-pos="middle" style:vertical-rel="text"/>
That has anchor type and position.
You can use your own styles. Write the style with all the needed graphic-properties into the styles.xml of an document template. You can then use the styles to change the anchor type and the position by applying the style, or you can select your style in the insert dialog of an image.
Looking in the tab "Organizer" of the style, you see the anchor-type in the "contains" section. The info about position is not complete there. In style "Formula" I see nothing, in my own style or in "Watermark" I see the position but not the "rel"-value. Nevertheless, assigning a frame style to an image will adapt anchor type and position.
It is only running LibreOffice, that does not allow to set the anchor type and position infos of styles. If a style exists, you can use it as expected.
ah right now i remember another related bug 114396 ...
so the problem is that creating the style from the selection shouldn't call ClearItem(RES_ANCHOR) but instead override RES_ANCHOR with an item that is the same except it has its anchor position cleared; then it would be able to retain the anchor type.