You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The source highlighting code is located in the parser / types, which has an unfortunate side effect in that the resulting output is fixed to HTML. That's probably ok for most cases, but certainly not all output formats. This will be a problem for docbook and PDF in the future (I hope).
Chroma allows the parser and renderer to be separated, and we could conceivably provide the backend with the parsed results (as well as the original content I suppose) in the form of the token stream. It could then either use the Chroma to generate HTML, or perhaps generate it's own output. This would also be an appropriate place to give backends more control over the theme (for example to honor a global black and white option for print or ereader use.)
The text was updated successfully, but these errors were encountered:
The source highlighting code is located in the parser / types, which has an unfortunate side effect in that the resulting output is fixed to HTML. That's probably ok for most cases, but certainly not all output formats. This will be a problem for docbook and PDF in the future (I hope).
I'm not totally following you: as far as I can see, Chroma is used in the pkg/renderer/sgml package. Could you explain how/why it is fixed to HTML?
Chroma allows the parser and renderer to be separated, and we could conceivably provide the backend with the parsed results (as well as the original content I suppose) in the form of the token stream. It could then either use the Chroma to generate HTML, or perhaps generate it's own output. This would also be an appropriate place to give backends more control over the theme (for example to honor a global black and white option for print or ereader use.)
You're right -- I was misreading this -- sorry. It's still unfortunate even there that the output is forced to HTML. But this is a better place to do it I suppose, than in the parser!
I may look at this more closely when it comes time to figure out how to make this all work for docbook. That's not on my immediate radar -- right now I'm focused on epub3.
yes, and to be honest, until now my focus was on the HTML output. I still have no idea how it will work for other backends, so I would not be surprised if some refactoring was needed in the future.
I suggest we leave this issue in the backlog for now if it's ok for you.
The source highlighting code is located in the parser / types, which has an unfortunate side effect in that the resulting output is fixed to HTML. That's probably ok for most cases, but certainly not all output formats. This will be a problem for docbook and PDF in the future (I hope).
Chroma allows the parser and renderer to be separated, and we could conceivably provide the backend with the parsed results (as well as the original content I suppose) in the form of the token stream. It could then either use the Chroma to generate HTML, or perhaps generate it's own output. This would also be an appropriate place to give backends more control over the theme (for example to honor a global black and white option for print or ereader use.)
The text was updated successfully, but these errors were encountered: