Hugo: Add alternative rendering format for LaTeX

Created on 26 May 2017  路  7Comments  路  Source: gohugoio/hugo

As discussed on the foums: https://discuss.gohugo.io/t/proposal-for-alternative-rendering-formats-for-content-docbook-latex-etc/6727/2

I've been tinkering with getting Hugo to generate Latex output from markdown files. With a quick hack in the code to switch out the Blackfriday HtmlRenderer used in Hugo with the Blackfriday LatexRender I was able to get some clean Latex output.

However I was thinking it would be useful to generalize this approach. Basically creating a BlackFriday renderer that could take bunch of Go templates. Each template would render a different markdown element.

This would allow a Hugo user to full customize the content generation. For instance spitting out Docbook markup or Latex or whatever other text format they want..

This proposal (combined with Output Formats) would allow the same source .md files to be turned for example into a Latex book and a website (or epub book) with relative ease.

I've started tinkering with a template based renderer. Here is the code: https://github.com/rabidgremlin/blackfridaytemplaterenderer/blob/master/templaterenderer_test.go

I think it could work quite nicely.

Excuse my code I'm not much of a Go developer :)

Enhancement Keep

Most helpful comment

I haven't really been following the discussion but here are my 2 cents:

  • I don't think Markdown is a good starting point to add "language features" that are semantically equivalent to that of the LaTeX language. You'll end up creating a whole different language.

  • My extension has only two non-Markdown+extension features: math blocks and inline math. Math block is mostly backward compatible. Inline math breaks the language though (the rendering, not the parser). I could not come up with anything better, and unless you can, this proves my point: you'll end up creating a whole different language.

  • See Org-mode for an example of an attempt at being "LaTeX-compatible": Org-mode parse comments with special tags so that it can include raw LaTeX in its output. Quite opposite to the "ease-of-use + readability" philosophy of Markdown.

As @bep suggested, if you want to add primitive LaTeX support without hassle, I recommend you switch to Blackfriday v2 and use my extension :)

Last but not least: it's LaTeX with capital X! :p

All 7 comments

I have narrowed the scope of this issue -- the only reason I'm even considering this as a good idea is the built-in support for LaTex in Blackfriday. We have no intention to build any "DocBook renderer etc." here in Hugo. That is way too much work.

There is a good example of Markdown to LaTeX to HTML and PDF here:
https://www.madoko.net/

As you can see in the Madoko reference manual, there would need to be some significant expansion in Markdown syntax to pass different kinds of content to the LaTeX rendering templates.
http://madoko.org/reference.html

Synchronizing the content in an HTML layout with the LaTeX>PDF equivalent does not seem trivial.
It might be good to talk to Daan Leijen at Microsoft who is working on Madoko about this kind of effort.

@bwklein Thanks for those links. This is a slowly moving target and not fixed in one weekend. Black Friday v2 is a starting point. I'm not sure about the "significant expansion" part, at least not to get something very usable. Quickly reading the reference manual I see that some kind of "custom processing tokens" should be added to the Markdown syntax somehow (i.e. rendering instructions, styling, math, whatever).

I notice that @Ambrevar has already starting to think about this in his Blackfriday renderer, maybe he can chime in with his thoughts:

https://github.com/Ambrevar/blackfriday-latex

I haven't really been following the discussion but here are my 2 cents:

  • I don't think Markdown is a good starting point to add "language features" that are semantically equivalent to that of the LaTeX language. You'll end up creating a whole different language.

  • My extension has only two non-Markdown+extension features: math blocks and inline math. Math block is mostly backward compatible. Inline math breaks the language though (the rendering, not the parser). I could not come up with anything better, and unless you can, this proves my point: you'll end up creating a whole different language.

  • See Org-mode for an example of an attempt at being "LaTeX-compatible": Org-mode parse comments with special tags so that it can include raw LaTeX in its output. Quite opposite to the "ease-of-use + readability" philosophy of Markdown.

As @bep suggested, if you want to add primitive LaTeX support without hassle, I recommend you switch to Blackfriday v2 and use my extension :)

Last but not least: it's LaTeX with capital X! :p

I agree with @Ambrevar -- open source is always filled with trade-offs. These LaTeX requests often come from PhD people wanting to write their scientific papers in Markdown. I can understand them, but if the first goal is to make them happy, then likely none will be happy for a very long time.

So book and article publication are not all about science: Fiction, art books ... Genres with, I suspect, simpler requirements in this area. And also genres closer to my heart. When I'm finished with Hugo (yea, right!), I'm going to write a crime novel ... in Markdown.

This would be a nice addition. I've created a theme for myself for the purpose of writing essays and other papers in markdown so I don't have to touch a word processor. It makes use of print CSS styles to make pages that look like they were made in a word processor.

I'm currently using KaTeX to render LaTeX on these documents, but having some built-in LaTeX parsing would be even better, if it would remove the need for a JavaScript library at all for rendering that stuff.

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

Was this page helpful?
0 / 5 - 0 ratings