Live data from Hacker News

Show HN: LaTeX Boilerplates – Plain-Text Document Production System

mrzool.cc

41–44 of 44 posts

Re: Show HN: LaTeX Boilerplates – Plain-Text Document Production System

#41
post #38

Earlier quoted context omitted.

LaTeX is complicated and verbose. Markdown and YAML are terse and readable. Also, separation of form from content makes life amazingly simple.

I agree that separation of form from content makes life amazingly simple, that's one the main virtues of LaTeX. :) As I said before, preferring Markdown and YAML solely on account of syntax seems fair to me.

If both content and form live in the same file, like in the standard LaTeX approach, they're not separated.

My approach is to abstract all style-related concerns in a template and keep the content in dedicated files: YAML for structured content (CVs and invoices) and markdown for prose-like content (letters).

Beside making life easier by using formats more suited, syntax-wise, for the particular type of content I'm dealing with, this opens up new possibilities for automation (e.g. I can iterate on repetitive data structures, for example for building an invoice table) and ultimately results in DRYer LaTeX code in the template.

Re: Show HN: LaTeX Boilerplates – Plain-Text Document Production System

#42
post #41

Earlier quoted context omitted.

I agree that separation of form from content makes life amazingly simple, that's one the main virtues of LaTeX. :) As I said before, preferring Markdown and YAML solely on account of syntax seems fair to me.

If both content and form live in the same file, like in the standard LaTeX approach, they're not separated. My approach is to abstract all style-related concerns in a template and keep the content in dedicated files: YAML for structured content (CVs and invoices) and markdown for prose-like content (letters). Beside making life easier by using formats more suited, syntax-wise, for the particular type of content I'm d…

I thought "the standard LaTeX approach" is that you put all of the style information into a document class (or, if you have only minor modifications of a standard document class, into a package) and then all of the content in a separate file with extension .tex. I not only thought that was the standard LaTeX approach but also that that was the point of LaTeX: your document markup is semantic and all formatting issues are decided elsewhere so you can change them independently of the content.

(And whether or not that is the standard LaTeX approach it is certainly a possible and recommended approach in LaTeX.)

In your approach you don't just separate style from content, but additionally distinguish two types of content (the type you'd write in YAML files from the type you'd write in Markdown). That is different from LaTeX, where both the YAMLly and prose-like things are put in LaTeX source files (for the YAMLly stuff you define macros, like \author, \title, \signature, etc.).

At any rate, as I said before: preferring YAML and Markdown to LaTeX syntax seems to me a valid reason for doing things your way. I just wanted to point out that LaTeX makes it easy to separate form and content, too.

Re: Show HN: LaTeX Boilerplates – Plain-Text Document Production System

#43

Been collecting a few links on this topic: https://www.rpi.edu/dept/arc/training/latex/resumes/ https://github.com/mrzool/cv-boilerplate https://github.com/posquit0/Awesome-CV

Also:

http://jsonresume.org https://github.com/jsonresume/resume-cli https://github.com/fluentdesk/fluentcv

Re: Show HN: LaTeX Boilerplates – Plain-Text Document Production System

#44

I use a similar workflow using Pandoc at work. I painstakingly re-created our corporate Word documentation templates using LaTeX and then set up Pandoc to generate documents from Markdown using these templates. In addition to this, I used Haskell and Diagrams to produce DSLs for rendering various UML documents from text based descriptions. These can be rendered in both vector graphics formats (SVG and Encapsulated Po…

Is your Haskell -> tex -> SVG/EPS open source by any chance? I'd love to both study the .hs (to further my learning), but I also have a need to make some documents.

It is my goal to open source the tool at some point in the near future. I have a few IP related things to work out with my employer first, as a courtesy.
Post reply on HN