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 Postscript) as well as a written description of the diagram that can be provided for accessibility reasons.
The big take-away I got out of this process was that I could write human-readable documents that were also machine-readable while also providing a higher level of accessibility for this documentation than would be possible using traditional WYSIWYG tools.
I highly recommend this style of documentation workflow.
In my case, I was actually stuck with creating a template for Invoice/Order PDFs based on a CRM that was written in PHP, so I made a PHP script that output LaTeX, then rendered that in a folder. The trick was to use a temporary folder for each document render, and to manage the process hands-free using latex-mk: http://tex.stackexchange.com/questions/210500/why-is-somethi...
The resulting PDFs then didn't break lines in the wrong places, had the correct margins on the first page vs other pages, were very graphically rich with vector graphics, and could be produced quickly on demand through their web-based CRM, all thanks to LaTeX and a few days' time debugging.
I'd love to both study the .hs (to further my learning), but I also have a need to make some documents.
We've also had success in working with publishers to simplify the submission process for research articles, with direct one-click submission links where we pass the files plus meta data.
See e.g. https://www.overleaf.com/blog/269 for a recent example.
[Sustainable Authorship in Plain Text using Pandoc and Markdown](http://programminghistorian.org/lessons/sustainable-authorsh...)
I had spent a good deal of effort building a very simple and pleasing resume using LaTeX, and I ended up having a professional career counselor look at it, and she said "Did you use a template? It looks too much like a template." So what? Templates are templates because they look good. If it didn't look like a template, it wouldn't look professional. And something that should've elicited a complement was instead peddled as disappointment.
Instead, I'll just figure that I wouldn't want to work for anybody that trusts people who are too petty or too clueless to make good hiring decisions.
Sure, but it's also kind of like asking - Given the fact that all these songs are number one, could we extract some common features?
Maybe you'll find out that songs have to be shorter than 3 minutes or nobody plays them on the radio, or that they have to be dynamically compressed within a certain frequency range because most people listen to music on hardware that does not reproduce certain frequencies very well, or that having a weird time signature makes a song unpopular, etc.
>I wouldn't want to work for anybody that trusts people who are too petty or too clueless to make good hiring decisions.
Hah, that would exclude a large portion of the professional software industry !
>Hah, that would exclude a large portion of the professional software industry !
It probably does, but I don't actually want to work for a large portion of the professional software industry. I want to work for people that value me and share my vision. And in turn, I want companies that make those kinds of hiring decisions to not have access to people like me.
Your example doesn't carry your point. Beethoven, like Mozart actually is popular simply because both are part of mass culture. Classical music however is not part of popular culture and is restricted to certain niches.
Also, there is a legimitate view out there that pop music hasn't changed for the past few decades, and has certain recurring themes - love, loss, sex, etc. But anyway, that is not a very interesting conversation.
I don't agree with your view on resumes. In my opinion, resume writing comes down to knowing the mind of the person who is going to read the resume and convincing them that you're the right candidate. Since mind reading is usually a difficult task, all one can do is increase the probability of success by adopting tips and tricks that others have used.
> It's better to have more valuable content on your resume than to apply statistics to its paint job.
By writing a resume the "common" way, it does not diminish your own value and self-worth. It seems like you want companies to appreciate you only if they hire someone in HR who also appreciates your style of writing resumes. Thats pretty bizzare TBH, but hey whatever works for you.
You can't read a person's mind, but you can change it. That's what your resume is for. You don't have to read any minds, you have to get others to read yours.
>It seems like you want companies to appreciate you only if they hire someone in HR who also appreciates your style of writing resumes.
If a company hires HR people who think "simple and professional" is not good enough for a resume, then they almost certainly won't appreciate me. Simple and professional is what I'm offering. I'm not going to jump through flaming hoops and read resume acceptance statistics to get noticed. I'm going to solve actual problems.
Anyone familiar with command line tools and a corresponding aversion for bloated WYSIWYG apps will second the underlying idea that MS Word (and the likes) “should die” in favor of plain text workflows.
Yet, with the help of Pandoc (which does the heavy lifting in these boilerplates), nothing prevents you to keep using Word as a front-end and plug it in this exact same workflow. Word may not be the best-of-bread typesetting engine or layouting tool, but to many it still is useful as a quite decent word processor.
For those interested, I did a (long-read) write-up on how one could go from Word over Markdown to even InDesign (as an alternative templating/typesetting engine, instead of LaTeX/XeTeX): http://rhythmus.be/md2indd/
Make sure to check out this article where I talk in depth about a typical workflow and the rationale behind this project:
Also, separation of form from content makes life amazingly simple.
As I said before, preferring Markdown and YAML solely on account of syntax seems fair to me.
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.
(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.
Gummi is also nice for instant feedback, and you don't need to get the whole toolchain working by hand.
Might help you to see their process. You can do the whole thing with CLI but easy in their IDE.
They did some good coding for Pandoc is my main point.
Any tips to make a latex pandoc workflow viable for advanced math documents with custom commands and such. I.e. using the mathtools package and various advanced latex math commands?
I'm genuinely curious about this statement. I thought you must be using Windows, but the latter part of your comment contradicts that.