This is a resubmitting of this bug (1). Here is a descriptions of it: I'd like to use parentheses, for footnote anchors (in the text area), for better separation. For example: Foobar(1), with «(1)» in superscript. However, although we can add characters, before and after the number, in the footnote area (in the footnote settings, the «Before»/«After» fields -the fact it applies only to the footnote area, is not clear enough, by the way), we cannot add characters to the footnote anchor (in the main content). It is good to keep the two locations independent, regarding prefixes/suffixes. For example, in my case, in the footnote area, I use: 1. Lorem ipsum. There should then be a new set of «Before»/«After» fields, in the footnote settings, to set a prefix/suffix, for footnote anchors. A more global solution (I didn't search for an existing report, but I guess it exists), would be to permit to defined prefixes/suffixes, for any element, like in CSS (the «:before» and «:after» selectors, with the «content» property). This is a low priority enhancement, as we can just add the prefix/suffix manually, which is not too problematic, for footnotes. Thanks in advance to everyone who will work on this. (1) http://www.openoffice.org/issues/show_bug.cgi?id=90842
@Fahad Al-Saidi Can you please try to add some info so that someone who never used a footnote in his life can understand the problem? Useful would be - a mockup - how your workaround works (sample document, every key press / mouse click) - how you expect a soulution (not "here should then be a new set of «Before»/«After» fields", but "In .... click ... then .... dialog ..." and so on
Created attachment 53292 [details] A small document explains this bug.
(In reply to comment #1) > @Fahad Al-Saidi > Can you please try to add some info so that someone who never used a footnote > in his life can understand the problem? Useful would be > - a mockup > - how your workaround works (sample document, every key press / mouse click) > - how you expect a soulution (not "here should then be a new set of > «Before»/«After» fields", but "In .... click ... then .... dialog ..." and > so on Please see the attachment.
[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
needinfo keyword redundant by needinfo status.
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
This feature is not implemented yet. Please don't close it.
*** Bug 68950 has been marked as a duplicate of this bug. ***
Still isn't resolved in 6.1.
