Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider moving the source highlighter support #705

Open
gdamore opened this issue Jul 7, 2020 · 3 comments
Open

Consider moving the source highlighter support #705

gdamore opened this issue Jul 7, 2020 · 3 comments

Comments

@gdamore
Copy link
Collaborator

gdamore commented Jul 7, 2020

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.)

@xcoulon
Copy link
Member

xcoulon commented Jul 7, 2020

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.)

@gdamore
Copy link
Collaborator Author

gdamore commented Jul 7, 2020

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.

@xcoulon
Copy link
Member

xcoulon commented Jul 7, 2020

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.

@xcoulon xcoulon added this to the backlog milestone Jul 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants