Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

mos6581.org

Post reply on HN
Print view View original

81–90 of 104 posts

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

#81

Post by gjm11 »

GuiA wrote: post #49
gjm11 wrote: post #14

So, the situations in which I would use LaTeX rather than something cruder but friendlier are these: (1) I am typesetting something with nontrivial mathematical formulae in it. (2) I want the excellent typographical quality that comes from, e.g., the very nice Knuth-Plass dynamic-programming algorithm for line breaks. (3) I want to use some clever thing someone has implemented in LaTeX (say, to add Feynman diagrams t…

What are the "cruder but friendlier" alternatives that you use?

Microsoft Word (alas) or one of its generally even worse competitors. For business documents that need sharing with other people who have to use Microsoft Word so they can share them with other people who, etc.

TeXmacs, a more-or-less-WYSIWYG document editor with approximately TeX-compatible formulae and suchlike. I actually use this much more often than TeX or LaTeX.

Plain text :-).

HTML (either edited by hand -- horrible but in some contexts less horrible than (La)TeX -- or using a WYSIWYGish tool like BlueGriffon).

Someone mentioned Markdown. I've somehow managed to avoid ever using Markdown (not counting things like Stack Overflow and occasional blog comments) but it certainly belongs in the list.

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

#82

Post by brechtm »

p4bl0 wrote: post #25
gjm11 wrote: post #14

So, the situations in which I would use LaTeX rather than something cruder but friendlier are these: (1) I am typesetting something with nontrivial mathematical formulae in it. (2) I want the excellent typographical quality that comes from, e.g., the very nice Knuth-Plass dynamic-programming algorithm for line breaks. (3) I want to use some clever thing someone has implemented in LaTeX (say, to add Feynman diagrams t…

I would add that the original title "Introducing RinohType the Python document processor", is way better than the one of the HN submission. It is not a "modern LaTeX", let alone a "LaTeX rewrite" (which is implied by the "in 6500 lines of Python").

Yes, I plead guilty to tweaking the title a little for marketing purposes. I'm sorry if that got some people overexcited.

RinohType should eventually be able to replace LaTeX though, so it is not that far-fetched either. Also, the first paragraph of the article should help temper that excitement.

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

#83

Post by brechtm »

sanskritabelt wrote: post #28

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

Note that this is a WIP version; you should not judge RinohType on the basis of the example documents for now. I hope you'll understand that at this point I'm focusing on functionality, not on style.

The table rendering got messed up when I rewrote the line spacing code. Fixing the table rendering would just require an adjustment of the table style definition.

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

#84

Post by mrottenkolber »

siscia wrote: post #48
mrottenkolber wrote: post #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 ver…

Do you have a github repo for your project ? Or somewhere where I can take a look at the code ? I was hoping to find the time to write something similar in Clojure (a lisp dialect), and the idea should be to take hiccup[1] as starting point. Why hiccup ? Because it is death easy to use, because I think it to be extensible, and because I hate write html while I love to write hiccup-code... The real problem (other than…

I am doing it in Common Lisp, I haven't released it yet but if you drop me an email to max on mr.gy I can let you know when I progress and also tell you about how I designed my system if you like. To summarize: Come up with a model for documents (e.g. datastructure, what is it made up of, how is it represented). Then think about how to input a document (makes a big difference, I made a markdown like language) and how you can render documents (html, paper, audiobook, video...). I concentrated on the idea that my documents should represent structure of content while the type of content (mixed?) is irrelevant. I then started writing backends that support rendering of sets of content types. E.g. HTML can do a lot, including video. But on paper it's hard to play back audo or video data so we fall back to a simple url (which sucks on paper too, but we could render QR codes on paper for instance). So there is a lot of room for specialization, I am trying to keep the core concepts as generic as possible so I can extend the system later on, and maybe use my document format to write a song after I implement musical content types in some backend some day maybe... You get the idea I guess.

Regarding hiccup: I wrote an HTML DSL myself, which I also use in my document pipeline, it is released and can be found here: http://mr.gy/software/macro-html/

By the way, I work prefessionally with Clojure at the moment, and I'd rather advise against using it. Ihmo it is not ready, I like some ideas, some I like less, but its still a mess and the (only!) implementation is not on par with a real lisp yet.

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

#85

Post by chrismorgan »

sanskritabelt wrote: post #28

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

For me, using PDF.js in Firefox for Android, it looks even worse; most of the text is garbled junk characters (only code blocks appear correctly). It's substituting characters and using a different font which PDF.js could not load. (Another renderer is displaying it correctly.) Using character substitution as a standard technique is a really bad idea, and is the only thing that is preventing me from taking a deeper look at it with a view to using it as a backend for a play script/musical/opera libretti format that I wrote; it makes the document inaccessible to things like screen readers and prevents ready copying of text and search. Is there a good reason why substitution is used? If you're willing/compliant to the notion of removing it, I'd probably be pleased to help out with the project.

(This script format tool I wrote is also written in Python, and at present I'm writing to HTML and using wkhtmltopdf to produce a PDF, but that tool is making a mess of the text kerning so that the final result isn't as much of a pleasure to read from as it should be; your tool, however, is producing what are in my eyes quite nice-looking documents---I can easily overlook minor spacing issues at this comparatively early stage.)

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

#86

Post by brechtm »

fusiongyro wrote: post #22

The rendering of the test document is very strange in FF on RHEL 6 on Linux. Acrobat also gave me garbage for a few seconds and then somehow spontaneously figured it out. I'm skeptical of these sorts of enterprises, but I'm glad the author took the challenge and I look forward to seeing where it goes.

I've noticed these problems on Linux too... On Windows, The PDFs render correctly on SumatraPDF, Adobe Reader, PDF-XChange Reader and IIRC also Foxit PDF Reader.

But I'm sure there's still a bug in my PDF font handing code :)

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

#88

Post by viraptor »

brechtm wrote: post #86
fusiongyro wrote: post #22

The rendering of the test document is very strange in FF on RHEL 6 on Linux. Acrobat also gave me garbage for a few seconds and then somehow spontaneously figured it out. I'm skeptical of these sorts of enterprises, but I'm glad the author took the challenge and I look forward to seeing where it goes.

I've noticed these problems on Linux too... On Windows, The PDFs render correctly on SumatraPDF, Adobe Reader, PDF-XChange Reader and IIRC also Foxit PDF Reader. But I'm sure there's still a bug in my PDF font handing code :)

It's also almost completely broken in pdf.js (firefox's new default viewer) - I guess that one should be the same between linux and windows at least.

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

#89

Post by zem »

brechtm wrote: post #87
zem wrote: post #68

i would have been more interested in seeing why he felt lout was not an acceptable alternative

See the linked ML post: http://www.ntg.nl/pipermail/ntg-context/2008/037150.html (search for Lout)

ah, fair enough. i used lout briefly and had a pretty good experience (went back to latex due to better equation support); from what i recall one of its design goals was being easy to machine-generate, so it was at least plausible that "compiling to lout" would be a better option than doing it from scratch. you're right about the lack of momentum and community for the project, though.

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

#90

Post by chrismorgan »

1_player wrote: post #27
fusiongyro wrote: post #22

The rendering of the test document is very strange in FF on RHEL 6 on Linux. Acrobat also gave me garbage for a few seconds and then somehow spontaneously figured it out. I'm skeptical of these sorts of enterprises, but I'm glad the author took the challenge and I look forward to seeing where it goes.

Yes, it's all wrong on Evince too. Chrome PDF reader displays it correctly, though.

I'm finding in evince the parts using character substitution and a custom font are not rendering at all.
Post reply on HN