Tested on 4.3.1 on Linux and master on Windows.
Guess you are saying, they should be smaller or upper case?
Could you describe in more detail what you want to be fixed here.
Otherwise I can confirm your finding: Word displays a small number while LO displays the number, the same size as the footnote text itself.
Yes in Word the footnote numbers look like superscript, while in LibO it seems as if it a regular sized number.
Adding bug 82077 as that one is similar but with RTF.
@VMiklos - same issue as the rtf one just for docx. Code pointers welcome if you think that this can be an easy hack. Thanks in advance.
Seems LO is importing the style correctly but not mapping it within the correct style names. LO is importing MS's "Footnote Reference" into "Default Paragraph Font > footnote reference" rather than into "Footnote Anchor" and "Footnote Characters". Below is the relevant xml code in attachment 133420 [details].
This bug is not (and isn't supposed to be) fixed yet.  So far, the only change is that the "in text" anchor now contains the "footnote reference" style defined in MSWord. I haven't figured out how to duplicate/link the "Footnote Characters" style to the "Footnote anchor" style.
The fix in comment 12 only enabled the existing mapping between styles.
The third patch seems like an obvious correction, except that it causes problems with the unit test for bug 82071. One way to avoid the problem is to avoid setting the stylename if !IsOpenField() - but that is a hack.
Another problem is that this solution is not round-trippable.
I think that ignoring case when mapping style names is a problem, as for example, its possible to have 'Heading 1' and 'heading 1' in the same word document and LO will trip over itself.
> document and LO will trip over itself.
But certainly, if we find an example document where those are a problem, we can revert. The main reason I did a "generic" fix was because I saw so many existing examples, and it didn't seem reasonable to keep adding them one by one as more were discovered.
Yes that is true, but Word outputs 'Heading 1' as 'heading 1' in the xml, so any idea why we were also mapping 'Heading 1' on import? In your investigations, have you found documents which had 'Heading 1' instead of 'heading 1'?
I was able to create a document in word 2010 and 2013 like this (attachment 133825 [details]), but when i reopen it, Word auto renames the user created 'heading 1' to 'Heading 11'.
There would need to be some error checking to see if a style has already been created and another style is trying to overwrite it on import. The w:customStyle attribute would also be helpful in finding out whether a style is a built-in style or user-defined style.
> one as more were discovered.
Where can i find these examples?
> any idea why we were also mapping 'Heading 1' on import?
I only looked at the git history, and saw that these were were present already in 2008. There haven't been any recent changes to the list.
> Where can i find these examples?
I only meant many examples in the code - not in .docx files.
> I think that ignoring case when mapping style names is a problem.
I agree. It appears that many of these mappings had been ineffective since, as you noted, Microsoft tends to export the lowercase form of the stylename, but most of the mapping are in Titlecase.
What I plan to do is leave the commit in place for a couple of months to see if QA notices that it fixes anything (as it should). After that I will revert it.
> > I think that ignoring case when mapping style names is a problem.
> but most of the mapping are in Titlecase.
Actually MS titlecases most of their styles in XML, but only lowercases headings and table of content entries, though titlecases headings and capitalizes TOC in the UI. Here are the lowercase entries from a Word 2010 file.
footnote reference and endnote reference are also lowercase.
Your latest patch got me thinking about how well we handle exporting of footnotes, especially if LO's two footnote styles are different.
> footnote reference and endnote reference are also lowercase.
True. Also footnote text and endnote text and alot more according to attachment 131189 [details].
Revert "revert related tdf#82173 writerfilter: ignore case when mapping styles"
Marking this bug as fixed since the description problem is resolved. Other matters brought up as discussion items should become new bugs since this one has gotten pretty cluttered.