Created attachment 165242 [details] Writer file to illustrate an issue with note anchors Version: 7.0.0.3 (x64) Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded This issue goes back to LO6 (and beyond perhaps). AFAIR, it was not an issue in OpenOffice a few years ago, so may be a regression. 1. Open the attached Writer file and select the first footnote anchor on the page (for example). 2. In Character styles, double-click the style marked "Footnote Anchor - New". EXPECTED RESULT: The size of the anchor should now be 100% and at normal position (because this is the setting in "Character Style > Position > Position"). ACTUAL RESULT: The size and position of the anchor remain UNCHANGED (i.e. as set in "Footnote Anchor"). 3. Experiment by changing other properties of "Footnote Anchor - New" and see how this affects the footnote anchor. EXPECTED/ACTUAL RESULT: The footnote anchor changes in line with the new properties—apart from "Position > Position". (not checked for all properties) CONCLUSION: It seems that, for some reason, the "Character Style > Position > Position" properties are disabled when overwriting an existing footnote/endnote anchor. (BTW, if you are using BOTH numbers and traditional characters (e.g. *, †, ‡, §, |, ¶) as footnote anchors, you will need to have two different styles for the anchors: so this issue is not just a technicality)
So in sum: You are searching for a way to insert a footnote in a normal position, right? => NEEDINFO I also couldn't find a way. Sounds to me like an enhancement request.
Not totally following here: They paragraph style footnote setting looks the same as Footnote Anchor - New. So not seeing the reason why Footnote Anchor - New should result in a change?
(In reply to Dieter from comment #1) > You are searching for a way to insert a footnote in a normal > position, right? More general than that. In books, for example, you occasionally see a mixture of numbers and traditional typographical symbols (e.g. *, †, ‡, §, |, ¶) used as footnote anchors. (see "New Harts Rules", 2005, section 17.2.3 "Notes and references: Numbering and Placement"). IME, the character style that works for numbers does not necessarily work well for non-numericaL symbols: hence the need for two different character styles for the anchors. One solution is to use the default character style for numbered footnote anchors, then create a second character style for typographical mark note anchors, and apply it over the desired note anchors. This worked in Open Office but not in LibreOffice. In the latter, for some reason you cannot overrule the default "Character Style > Position > Position" properties. (In reply to Dieter from comment #1) > I also couldn't find a way. Sounds to me like an enhancement request. Possibly. But IMV the inconsistent application of the overwriting character style properties looks like a bug.
(In reply to R. Green from comment #3) > More general than that. In books, for example, you occasionally see a > mixture of numbers and traditional typographical symbols (e.g. *, †, ‡, §, > |, ¶) used as footnote anchors. (see "New Harts Rules", 2005, section 17.2.3 > "Notes and references: Numbering and Placement"). Thanks for clarification. It's not a problem to use those symbols as footnote anchors. But you want to use them in normal position?
Still having issues to understand the issue. The footnote paragraph style will affect: they typographical symbols. So change the paragraph style to desired. And apply they Character style for the content of the note itself? Or I'm I totally of track. They current implementation is the same at least since LibreOffice 3.3.0
IMV, it's probably a minor bug, but I'm highlighting it because it seems to be a regression compared to OpenOffice. It boils down to the fact that if you try to apply a different character style from the default to a footnote anchor (i.e. select anchor, then double-click a different character style) the new "Character Style > Position > Position" properties are not applied.
(In reply to R. Green from comment #6) > IMV, it's probably a minor bug, but I'm highlighting it because it seems to > be a regression compared to OpenOffice. It boils down to the fact that if > you try to apply a different character style from the default to a footnote > anchor (i.e. select anchor, then double-click a different character style) > the new "Character Style > Position > Position" properties are not applied. The settings are exactly the same as paragraph style footnote.. so what difference would I expect to see? Still not following; but maybe me. There is clearly something you want to archive, but not working as expected. A solution would be to search for the old OpenOffice version which should the desired behavior.. Adding V Stuart; maybe he knows more/ or is able to grasp the issue better.
(In reply to Telesto from comment #7) > The settings are exactly the same as paragraph style footnote.. so what > difference would I expect to see? Still not following; but maybe me. The issue is with the footnote ANCHOR, the superscript character in the main body of text. This is controlled by the character style "Footnote Anchor"
Tools -> Footnotes & Endnotes & set the desired style for they Text Area?
(In reply to Telesto from comment #9) > Tools -> Footnotes & Endnotes & set the desired style for they Text Area? I don't want to change the default footnote anchor style: that serves well for numbers. But suppose that, as well as numbered footnotes, I also want to occasionally insert a footnote with an asterisk as the anchor (using the "Insert > Footnote and Endnote > Footnote or Endnote" dialogue). I may find that the default anchor style does not quite give the right appearance to the asterisk. I might, for example, wish to embolden the asterisk and lower it a little. So I create another character style with the desired properties and apply it to the existing asterisk anchor (by selecting the existing anchor, then double-clicking the new character style). This will overwrite all the default properties but, for some reason, NOT the "Position" properties. That is the bug. Why are the new Position properties not being applied?
So select a footnote field in text & double click the style to apply (not working) Or select the field anchor & Format -> Character style -> Position.. (it shows normal; while being superscript) Certainly a bug: as this Tools -> Footnotes & Endnotes & set the desired style for they Text Area does work for all So no reason to not work individually, IMHO
@Caolan Slightly opportunistic. As this touched the 'UI' area Select the footnote anchor in text & Format -> Character style -> Position.. (it shows normal; while being superscript) And changing the setting does work either.. Inherited from OoO
(In reply to Telesto from comment #12) > @Caolan Slightly opportunistic. As far as I can see its not a regression and AOO seems to function the same way. I have no particular insight into writer's footnotes to make any useful suggestions but the issue presumably resides in the writer layout and document rendering rather than the general UI. An analysis of what competitors do in this area is probably relevant for anyone who wants to tackle it.
@R. Green Prepare your arguments.. adding UX/Heiko
Confirming: you cannot change position and background color of footnote fields, neither per character style nor direct formatting. Any reason, Mike? (Saving Caolan's expertise for issues around gtk3)
This is not a bug, this is working as designed. This is not a regression, this is working the same way in OOo 1.0 through 3.3, and in AOO 4.1. The reason is that the footnote anchor feature inserts a special field in the text flow, without changing the text style. It *then* adds the character style configured in Tools->Footnotes and Endnotes... *atop* of the formatting that results from all the normal rules at the point of insertion of the footnote anchor. So whatever styles you apply to the text where the anchor field is inserted, it is used as base formatting, and *then* the character style is applied from the Footnotes and Endnotes dialog, overriding everything that is explicitly defined in that style: since "Footnote Anchor" character style only defines "Superscript automatic", all other properties (font, color, ...) would take effect from the text, but the superscript would be applied last. Doing otherwise would be wrong. One may select large parts of text, including anchors, and apply formatting and styles - and if the settings applied to the whole range (and of course to the anchor) would override the anchor-specific settings, that would make the behaviour wrong and unusable. I see only one possibility: to extent the Footnotes and Endnotes functionality (e.g., introducing dedicated style category, with everything that is configurable wrt footnotes and endnotes), so that you could specify the corresponding style at the moment of insertion of a footnote ... but I don't know how much change would it require in ODF.
(In reply to Mike Kaganski from comment #16) > I see only one possibility: to extend the Footnotes and Endnotes > functionality ... so that you could specify the corresponding style > at the moment of insertion of a footnote ... +1.
See enhancement request at Bug 143433.
Working on https://ask.libreoffice.org/t/custom-style-not-showing-in-writer-document/100592, I came to the same conclusion as Mike Kaganski in comment # 16. This is a matter of precedence between the various styles: - paragraph style - user character style - automatic character style (from Tools>Footnotes & Endnotes However I could not determine the precedence of direct formatting. DF will applied last as usual for most attributes, but DF colour seems to be taken into account before automatic CS. This looks like the same misbehaviour as in bug 158835 (addressing bullet/number formatting in lists). This prevents from using DF to show differently a single note anchor among all others. Also, but this could be another bug report, DF can be used in the footnote area to decorate a single note "number" because the "number" can't be selected (since this is Writer generated text).