https://bugs.documentfoundation.org/show_bug.cgi?id=58194
Justin L <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.documentfounda | |tion.org/show_bug.cgi?id=51 | |168 Summary|FILESAVE Automatic first |FILESAVE ODT->DOC/X: |line indent is not saved in |Automatic first line indent |DOC/DOCX format |is not available (and thus | |lost) in DOC/DOCX formats --- Comment #17 from Justin L <[email protected]> --- repro 26.8. If the first character is LANGUAGE_KOREAN or LANGUAGE_JAPANESE, then the auto-indent is just the underlying paragraph's font height. Otherwise the auto-indent is twice the underlying paragraph's font height. So in both cases it depends on the underlying paragraph autoformat. [Thus auto-indent runs into the same anomaly as bug 51168 when there is a character style or hyperlink in the line. In that case the para-autoformat itself never has its own font size and gets it from the para style - ignoring entire-paragraph direct formatting.] This is effectively impossible to satisfactorily resolve. The problem is that it depends on the font size, and there is not 'one font size', but 'three font sizes', as well as the question of whether to multiply by two or not. This fontsize-dependent dilemma is similar to superscript/subscripts. See bug 99602 which forced "automatic" for superscript size in character styles. And that itself caused issues which were addressed by vmiklos' commit 85f0a5d7bc54dfba75e8d6dd9c905bc1ac31d927 DOCX filter: improve handling of negative <w:position> in paragraph styles So - just saying - that any work done here will inevitably cause other problems... We could pick the relatively simple Latin case and only 'make it right' for that case, but that hardly seems right. In order to do that at the style level, we would need to watch for CharFontSize or FormatFirstLineIndent. If either one of them changes while IsAutoFirst, then a fake FormatFirstLineIndent would need to be called once. For an example of making sure it is only written once, see commit 1d3ea5e7a4ea42390db29ed50bb426a663c86cc5. But probably the very best thing we can do is NOTHING AT ALL. That way the humans can easily see that there is 'a problem', and that they need to fix up the document the way they want it to look. -- You are receiving this mail because: You are the assignee for the bug.
