Please attach the actual file (or a snippet from it) so that we can verify the issue on an independent system :)

Marking as NEEDINFO - once you attach the file (or a test sample file that we can see the problem) mark as UNCONFIRMED and we will confirm it.

Thanks!

You mean you want a doc/odt file? LO doesn't do French-style footnotes, I don't know about Word, most that I can do is providing you with a pdf typeset with LaTex. Would that be good for you anyway?

ah my mistake Alessandro! I think this is an enhancement request, thought it was a bug :)

Marking as UNCONFIRMED - will investigate :) Sorry for the noise

@JBF - thoughts about this one? Should footnotes just be defaulted to this if French locale is chosen? Seems like a simple style would do the trick

Created attachment 80580 [details]
French-style footnote numbering

Indeed, it's a bug because the software isn't properly localised. As for the styles, it's indeed possible to indent the first line, and have the number followed by a space, but there's a problem with the position of the said number.

Please, open the newly uploaded image, take a look at the footnotes: you see the position of 9 and 10, that’s different than the LO’s one. In LO the 9 would be on the same line as 1 while French typography wants it to sit on the 0. Do you get my point? I hope so!

I have found a workaround, good enough also for templates, see the attached document. Unfortunately, its creation is very tricky, also it is sensitive for the modifications of footnote settings, so we need a simpler solution to support French typesetting.

Short description:

1. Paragraph style "Footnote" has got zero indentation (Before text, First line), but two special tabulator positions (see Tabs page of the paragraph style settings of Footnote), a decimal tab stop for the right indentation and a left tab stop for the beginning of the remaining text.

2. Put a tabulator (tricky part, see below), and a dot + tabulator into the Before and After input boxes in Tools»Footnotes/Endnotes... window. 

Unfortunately, normal input methods (clipboard or local menu of the input box » Special character) of LibreOffice don't allow tabulator character (or convert to space), only the direct methods work, eg. Ctrl-Shift-u + hexadecimal code under Linux (pressing Ctrl-Shift-u, 9, and space), see http://en.wikipedia.org/wiki/Unicode_input#Hexadecimal_code_input. 

Warning: after modifications of Tools»Footnote/Endnotes... it has to fix the silently converted tabs (spaces) in Before and After input boxes.

Note: this method works for footnote numbering without dots, using „invisible” characters (eg. U+200B, zero width space) in Tools»Footnote and in the input box “Character” of Tabs page, too.

Created attachment 80627 [details]
Workaround example

(In reply to comment #7)
> Created attachment 80627 [details]
> Workaround example

Hello Mr. Németh,

Thanks for your help but it looks so convoluted to me... and what's more is that I can still use LaTeX, which has an excellent support for French Typography through babel. The examples I posted were indeed typeset with LaTeX. But it shall be useful to those who stick to WYSIWYG.

Thanks anyway,

László, thank you for commenting and providing a workaround. I initially tried to come up with a few solutions to this matter in the related forum thread: 

http://en.libreofficeforum.org/node/6105

I was trying to do exactly what you have somehow managed in your comment #7 example. Unfortunately though I found the usual CTRL+SHIFT+u+9 (tab) insertion into the Before and After fields under Tools > Footnotes/Endnotes... to be, as you say, "sensitive for the modifications of footnote settings." Sometimes they seem to work and other times they appear to be replaced with a space (U+0020). Usually I get either a tab before and space after or the reverse, but not a tab before and after. This is under GNU/Linux Crunchbang 11 running TDF/LO v4.0.3.3 (Build ID: 0eaa50a932c8f2199a615e1eb30f7ac74279539). 

I completely forgot about using a decimal tab (I was using right-aligned) but this (naturally) does not affect the inability to easily insert the tab. Thanks again for your interest and the tip about using invisible characters in the Decimal tab alignment field. Adding myself to the CC.

(In reply to comment #8)
Dear Mr. Ceschini, 

Thanks for your feedback. In fact, this is a problem for English, too:

https://issues.apache.org/ooo/show_bug.cgi?id=18326  Footnote number greater than 99 are missing extra space before text

You are right, LaTeX has got better support for these basic features for French (see also this bug about French typography: https://bugs.freedesktop.org/show_bug.cgi?id=65050#c5).

Also it would be fine to use these improvements in the default French, Hungarian, etc. text document templates.

WYSIWYG is not only a user friendly interface for the average users, but it is a better solution for visually complex things, eg. positioning pictures into the right places.

(In reply to comment #9)
Owen, thanks for the posts! Also I have realized, right aligned tab is enough instead of decimal tab. Pressing a simple OK without any modification will convert the Before and After tabs, so you have to add them in the same time in the dialog window. A (default) check box for French will be the optimal solution. Thanks, again! László

I have fixed the unstable and inaccessible tab settings by allowing "\t" (also used in regular expressions in LibreOffice Writer Search/Replace) notation for tab characters in Begin and After fields, and opening the Settings window will show "\t" in Begin/After fields instead of the removing the tab chars, see Bug 65666. So this could be an acceptable workaround until the implementation of a better solution.

It is easy to define a numbering style doing what is expected. The problem is that when you attach this numbering style to the paragraph style footnote, it is not applied. Perhaps is it due to the links between the footnote and its call in the text.

Best regards. JBF

Dear Alessandro Ceschini,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug