https://bugs.documentfoundation.org/show_bug.cgi?id=167750
Justin L <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|medium |low Summary|FILEOPEN round-tripped |FILEOPEN round-tripped |DOCX: footnote characters |DOCX: footnote characters |are large, not |are large, not superscript |superscript-y |(limited time-frame for | |round-trip) Severity|normal |minor --- Comment #2 from Justin L <[email protected]> --- In the three provided examples in comment 0, none contains the special MSWord "footnote reference" style - so no special handling is envoked to ensure LO's magical ProgName"Footnote Symbol" English-UIName"Footnote Characters" style is set to superscript on import. So for simple import, these examples are somewhat irrelevant. P.S. master is creating the "footnote reference" style again, so this particular aspect of the problem shouldn't be occurring any more. However, multiple round-trips in master still show erratic results. The problem comes when sConvertedStyleName = "Footnote Characters (user)". FillUIName drops the (user), and then xStyles->hasByName returns true - it matches ProgName"Footnote Symbol". So here we have the big problem. "Footnote Characters" doesn't map to "Footnote Symbol", but "Footnote Characters (user)" does. Yikes. (I expect the same concept in true in other languages.) So if I got this right, then I would expect the properties of <builtin-in> and <build-in (user)> to flipflop on each round-trip. (But footnote/endnote are not good testcases for this, because of special code that copies Symbol -> anchor). This whole area seems to still be a complete disaster, but I'm downgrading this to low priority because I can't create something from scratch that clearly shows a problem, and even these documents tend to work themselves out after 3 round-trips. -- You are receiving this mail because: You are the assignee for the bug.
