Open marcban opened 7 years ago
see also the issue of extending custom styles to ODT/ICML: #2106...
The code changes would indeed be simple. It's a matter of deciding on bigger architectural issues. Do we assume that role
attributes should be treated as style names in docx and odt output? What problems might that cause? How should they be handled in other output formats? What attribute keyword should be used? (role
, data-role
, custom-style
?)
Another option would be treat role
as a class. This wouldn't have an automatic interpretation in docx or odt, but at least it would be possible for a filter to do something with it.
Some answers :
It seems in docbook the role attribute is specifically designed for custom styles.
At http://www.sagehill.net/docbookxsl/CustomInlines.html we can read "A phrase with role
attribute is an easy way to add specialized elements to your content, without having to customize the DTD".
Pandoc already reads the role
docbook attribute on the emphasis
element in order to distinguish between bold and italic.
the internal Pandoc AST currently manage a custom-style
attribute on Span
element (used in the docx writer, as stated at http://pandoc.org/MANUAL.html#custom-styles-in-docx-output). In JSON format, the output is in this form: {"t":"Span","c":[["",[],[["custom-style","mystyle"]]]....
Ideally, the parser would also add a custom-style on specific docbook elements like guibutton
, filename
so that it would be easy to style them in the output...
a precision : my docbook files are generated from asciidoc python tool, which already generate phases with role for quoted text, see http://www.methods.co.nz/asciidoc/userguide.html#X51.
Docbook has a way of specifying custom styles with the
role
attribute in thephrase
element, but Pandoc does'nt parse them.So Pandoc is able to generates custom styles in docx, odt, html... formats, but only from markdown or html
<span>
elementfrom the code of the docbook parser, I can imagine that it would take just one line or two to generate a
Span
element withcustom-style
attribute, but I'm not an Haskell developer...I think this would also solve #1235.