Live data from Hacker News

Show HN: RinohType – A modern LaTeX in 6500 lines of Python

mos6581.org

31–40 of 104 posts

Re: Show HN: RinohType – A modern LaTeX in 6500 lines of Python

#31

LaTeX does a lot of stuff - it'd take a long time to replicate all that functionality. However, on my todo list is to write some sort of "TeX-down" wrapper for LaTeX - I want to write my dissertation in a modified form of Markdown, with inline LaTeX equations and sectioning of "theorem" and "proof"-type environments, and then run a make to generate the TeX and PDF based off of a type of TeX template. I'm familiar wit…

You might like Pandoc[1].

1: http://johnmacfarlane.net/pandoc/

Re: Show HN: RinohType – A modern LaTeX in 6500 lines of Python

#33

I looked at the sample output ( http://www.mos6581.org/files/intro_template.pdf ) and is it just me or does the vertical spacing seem off? (for example, look at the tables and how the text goes right up to kiss the horizontal bars).

To me the sample output doesn't produce any aesthetic pleasure at the moment, I can't imagine using it even for the simplest material, provided I can choose between LaTeX and it. I hope it will improve.

The title is definitely misleading: "modern LaTeX" it still isn't.

Re: Show HN: RinohType – A modern LaTeX in 6500 lines of Python

#35
post #34

XML format is a non-starter for me. It adds too much cruft to the text; it requires putting everything inside of open and close tags, including paragraphs.

As much as I agree to your dislike of XML as very unwieldy, LaTeX does have \begin and \end directives for environments.

Definitely agree that at a per-paragraph level that's way too much markup.

Re: Show HN: RinohType – A modern LaTeX in 6500 lines of Python

#36
post #34

XML format is a non-starter for me. It adds too much cruft to the text; it requires putting everything inside of open and close tags, including paragraphs.

Thats what I thought too. However, there's a plethora of tools that can generate (and parse!) XML for you, e.g. HAML or Markdown. I write all my TeX docs in Markdown and then convert it to TeX, but stuff like figure placement has to be done in weird comments containing TeX, which'd be easier with RhinoType.

HAML for content: http://chriseppstein.github.io/blog/2010/02/08/haml-sucks-fo... (its not so bad :P)

Re: Show HN: RinohType – A modern LaTeX in 6500 lines of Python

#38
post #31

LaTeX does a lot of stuff - it'd take a long time to replicate all that functionality. However, on my todo list is to write some sort of "TeX-down" wrapper for LaTeX - I want to write my dissertation in a modified form of Markdown, with inline LaTeX equations and sectioning of "theorem" and "proof"-type environments, and then run a make to generate the TeX and PDF based off of a type of TeX template. I'm familiar wit…

You might like Pandoc[1]. 1: http://johnmacfarlane.net/pandoc/

Indeed! Or Org Mode[1].

1: http://orgmode.org/

Re: Show HN: RinohType – A modern LaTeX in 6500 lines of Python

#39
post #35
post #34

XML format is a non-starter for me. It adds too much cruft to the text; it requires putting everything inside of open and close tags, including paragraphs.

As much as I agree to your dislike of XML as very unwieldy, LaTeX does have \begin and \end directives for environments. Definitely agree that at a per-paragraph level that's way too much markup.

That's the thing, though: environments are not the norm.

I'm writing a document. I want the default text entry to be that document. There's already a lot of noise in my Latex sources; I want less, not more. (And I recognize that we actually agree on this.)

Re: Show HN: RinohType – A modern LaTeX in 6500 lines of Python

#40
Very interesting and great effort you put into it! I know exactly what you mean by cleaning up taking time. I am in the same stage (making it look good) of a document processing toolchain I am working on, which supports HTML, (La)TeX and plain text output backends. I thought I could be done this year, but I will probably take longer. I have started working and thinking on this problem about three years ago and am very careful about it's design (it's focus is on developer friendliness and extensibility, while keeping it dead simple and modular). It's not even that I expect others to jump on it, after all people seem to happy with Org mode and Markdown, but I want to solve my own documentation toolchain needs once and for all.

I am looking forward to see how your project turns out, choosing TeX as the print backend wasn't an easy choice and I would definitely consider another print media backend, if there was one. :)

Big ups!

Post reply on HN