Menu
▾
▴
#276 ODT Writer strips classes from inline character markup when more than one class
For the given RST markup:
.. role:: action
:class: action parenthetical
Hello... (beat):action: ...there!
The generated ODT will only assign one style to the inline markup text "(beat)", rst-action. rst-parenthetical is not generated.
The Open Document Format allows multiple, nested text markup and the ODT writer should use this to mark up text when multiple classes are specified. http://ask.libreoffice.org/en/question/21875/writer-clarification-needed-about-character-attributes/
The fix shouldn't be too hard and is localized so I will consider making the change and posting a patch.
Patch to address the problem. I have write-access to the repository so if this looks good I can check it in myself; I know the checkin will be reviewed anyway so if it's okay I can just commit it now. 1 test, it passes. I don't think needs to be documented as the behaviour is intuitive and is a rare-enough use-case that existing code should be fine and any code that may be changed should still work as expected. The only rare case where this would be an issue would be when the user defines an element with class x and class y then generates some text with rst-x and rst-y style and those styles are distinctive then the text should now have elements of both styles not just x as before, but if x and y contradict, x will override (if I understand the OpenOffice specification) because x is the innermost style.
I am not sure, whether I fully understand, but
in the rST specification, the order of class arguments does not matter (just like in HTML/CSS).
in ODT, the innermost style "wins".
The case of contradictory styles is undefined by the pure definition.
If the new code nests multiple styles in a way, so that the "winning" inner style is the one that was the only applied style before the change,
changes to existing documents due to this patch would be minimized.
This is the expected odt file, attached separately because it isn't included in the patch since it's binary (a zip file).
The code is written so that the first class/style listed is the innermost (which is the reason for the call to
reversed). The previous behavior was to just use the first class so this would have the same behavior with existing code that defined two classes with conflicting styling. The only place where this would manifest differently and strictly more correctly with respect to HTML would be when the two classes/styles are orthogonal in so far as maybe one defining strictly a font size and the other strictly how heavy the font ("boldness"). The goal however is to generate the document in a strictly conformant way and blame the renderer (LibreOffice/OpenOffice/Word) for rendering it incorrectly when properly styled.Wait, no, I do have it backwards. I'm removing the reversed as the nesting order is correct with the forward processing of classes. Thanks for catching that.
Oh, carp, I see why I had reversed. Because the class list is reversed relative to their definition in RST. So to achieve the default behavior we should not reverse the order but the default behavior is currently to ignore all but the last style/class specified in the RST. Is this our desired behavior? In a sense, it seems logical as last trumps all prior settings. So I propose keeping it in forward order and following the last-is-innermost paradigm.
I added this content to my test document (thanks for supplying it)::
The ODT writer generated the following in content.xml inside the
resulting ODT file (after pretty printing it with
tidy)::So, it does seem like the ODT writer is generating both styles, and,
like the bug reporter suggests, one style is nested inside the
other.
Can someone suggest how I can reproduce this problem. What is it
that I do not understand here?
Or, did someone fix this before I got here?
Dave K
Last edit: Günter Milde 2017-07-17
The bug was fixed by Jeffrey/timehorse 2015-06-03.