add a fonts-as-attributes option supported by the DOCX reader

[danse]

this pull request features a new reader option as discussed in the mailing list. i can improve the description in the manual if it doesn't explain the new option adequately.

i already tested this with a filter that allows me to format monospaced text as code. i developed this as an option but it could be an extension like styles, the criteria to distinguish between the two is not totally clear to me.

[jkr]

Just to let you know that i have reviewing this on my todo list, but it still might take a bit more time (until the end of the semester) until I have the time to fully think it through.

@jgm: do you have any thoughts on this? It's accomodating broken word usage, but also probably pretty common usage. And we already, eg, read hand-indented paragraphs as block quotes, so there's precedent. Aesthetically I'm sort of against it, but practically, I guess if it doesn't affect normal performance I'd be for it.

I imagine an extension would probably be better than an option. I'm almost tempted to fold this into +styles. (This is implying, after all, that fonts are a sort of ad-hoc character style in word.)

[jgm]

I am not sure, I guess I don't have strong opinions.
I can see how this would be useful in certain situations. I'm not sure about folding it into +styles; that would add a lot of clutter for those who use styles. I suppose alternatively one could have a well of telling pandoc "treat this font as if it were a style."

[danse]

in my opinion there is no need to bind this option to the DOCX format, like it's currently the case for styles. --fonts-as-attrs could be understood by more readers in the future

[jgm]

I wonder if --font-attributes would be a better name.
You're telling the reader to create spans with font attributes.

[danse]

i renamed the option --font-attributes and rebased

[danse]

Hi all, i am looking at this again and wondering whether now it's a better time for reviewing.

In order to support similar use cases, the only alternative i can imagine to this approach is to make this more generic, that means having an option that turns all children attributes into div attributes, maybe with a naming convention. This would be extremely ugly to read in a native representation and take a lot of space, but it would save us the complexity of adding new options or extensions for every interesting attribute in this specific format. Well this is kind of a strawman in order to imagine a better approach.

I think that this goes in the direction of folding this into styles as proposed above by @jkr
. Rather than dumping all attributes, we could have a white list, more compact yet easy to extend in the future. We could rename the extension from styles to extra_attributes or something alike. It could even be used by readers from other formats in order to provide similar functionality. Maybe the aesthetic concerns where related to the complexity involved in managing multiple options for a similar use case?

[danse]

maybe the new name of the extension could refer to the non semantic nature of the additional attributes