This system, at least so far, (1) doesn't do formulae, (2) doesn't have Knuth-Plass line breaking, (3) isn't compatible with LaTeX, (4) isn't compatible with LaTeX, and (5) takes almost 1s/page to do its thing.
It may very well be an excellent system, and deserve to take over the world of typesetting -- but at the moment it surely shouldn't be called "a modern LaTeX".
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.
I therefore take it that no-one who actually writes ever uses it.
1. https://github.com/scpike/word-wrapping/blob/master/ruby/lib...
2. https://github.com/scpike/word-wrapping/blob/master/clojure/...
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.
While I understand you generally shouldn’t rewrite
software from scratch, maybe TeX should be one of
the few exceptions to this rule?
And, really, if the software is designed well for maintainability, either of these should be rare, since if its is loosely coupled, you can change either the low-level implementation details that need to change without touching the high-level organization, or change the high-level organization while preserving the low-level implementation details that are staying the same, in an incremental change.
HAML for content: http://chriseppstein.github.io/blog/2010/02/08/haml-sucks-fo... (its not so bad :P)
Is there some program that converts Markdown into TeX? Or are you saying that you do this manually?
LaTeX is much nicer to hand edit, and if you're not hand editing you may as well use Word or something.
Definitely agree that at a per-paragraph level that's way too much markup.
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.)
However, I would also love to see more movement towards more flexible, semantic document formats for for example academic papers... I want to be able to read papers in my preferred style, whether on my iPad, Kindle or Mac. But still good support for citations, highlighting etc. Maybe epub is the way to go, not sure.
Anyway very exciting project, and good luck!
\section[short]{Long Title}
A GUI will eventually slow you down and is impossible to cater for the hundreds of commands including commonly used packages.
The title is definitely misleading: "modern LaTeX" it still isn't.
(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.)
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.
Then please be more honest. It's not "A modern LaTeX in 6500 lines of Python" -- it's 6500 lines of Python implementing a typesetting language with vastly inferior to TeX, or even Microsoft Word. It may have a syntax more comfortable to Python or Ruby programmers. Just say what you've done.
Does this ever happen?
So yeah, it probably happens. If it's half an hour before the submission deadline and there are four lines left on the page you have to cut, you'll do what you have to to get the job done. =)
When my papers get too long, I take it as an opportunity to obsess over superfluous words and sentences.
And isn't separating content from style what a .sty file is supposed to do anyway?
Probably. I applaud efforts to try to rethink typesetting, and this is clearly a substantial accomplishment. Tex is, however, an outstanding design, both in a number of of its aspects and as an overall design, and a lot of later effort has gone into remedying its limitations.
> TeX is not transparent. It is a huge, complex system ... With hundreds of megabytes and seemingly millions of files for a typical TeX installation, I have no idea what is going on when TeX processes a document.
Knuth's contribution is, in fact, quite small in terms of Mb. This covers just the Computer Modern Roman fonts and the eufrak maths fonts, and Plain Tex. Most of a system such as a full Texlive install is made up of fonts. It covers a huge number of specialist journal styles, and support for the needs of specialist fields (linguistic glosses, setting code, chemical notations, Feynman diagrams, etc.). The complexity is that of a library, and kpathsea is its index system.
I have the idea that maybe you think a package whose value you don't see is fluff: there is fluff in Texlive, but probably much less than you think.
> The arcane TeX macro language is not accessible to a broad audience. I believe this is why most LaTeX-generated documents you come across have exactly the same (retro) look; very few people are capable of creating new document styles.
There is a point here, but I think the reason is that most people don't want to fuss about with style. CSS makes it easy to experiment with page styles, and still most web pages either follow a standard formula or look very ugly. Understanding markup conventions is not usually going to be the biggest obstacle to achieving good design.
> TeX is not very modern
There is not a real problem outlined here: you could equally say that the basic layout engine has proven itself by being capable of accommodating all these later technologies. The Office 2007 team even rewrote its formula layout engine so that it would conform to that described in the Tex book, and employed Knuth as a consultant.
I'd put it this way: Knuth's code combines a very deep insight into the nature of the requirements of computer typesetting with outstanding implementation skills. The basic design has not really been surpassed.
> TeX’s warnings/errors are often very cryptic. It can sometimes take a long time to figure out what’s wrong.
Yes, very much so. This is probably the best reason to consider alternative document description languages. But note that Tex is very successful at allowing "code" invocation to be mixed with text - I'd like to see rivals that challenge Tex on this point.
> But why do I even need to mess around with all these extension packages when all I’m doing is writing a simple article? Doesn’t this mean that LaTeX should include at least some of the most commonly used packages by default?
The Latex3 team concede this. Context, a rival Tex-based system, does not have this problem.
> This might largely be a solved problem by now, but I remember often running into input and font encoding issues with LaTeX in the past.
Use Xetex or Luatex, and standardise everything on Unicode; these problems go away.
> There is no strict separation of content and style.
I'd put it this way: the system offers the possibility of such a separation, but does not enforce it. This is bad if you often have to work with other people's Latex, although in practice, you learn how to deal with it.
Addressing some of the problems raised in http://tex.stackexchange.com/questions/128454/are-there-any-... could be helpful for showing off your design and the advantages of a fresh start.
The Tex-based algorithm for formula layout used from Office 2007 on is documented in http://www.ntg.nl/maps/38/03.pdf (some of those links have fallen to linkrot).
I believe that in such project, but in every project, you should post some kind of document online explaining what is the big design of the project, the biggest problem you have encountered and how you fixed, the limitation of your design choice and why you made those choice.
Why that ?
1) Because if I want to code something similar I don't have to read all your code to understand what is going on, I just need to read a simple(r) English document where you explain it.
2) Because if someone else what to get involved in your project will have a way easier/happier time to understand the whole project and won't spend days just hacking around, s/he understand the project in the first couple of hours and at the 3rd hour is ready to start code some useful feature or refactor the code.
At the end, such document will make easier to everybody to be involved.
I originally planned to release RinohType into wild only after I had finished a full review, refactoring and documenting of the code. I also wanted to write some API documentation and a small tutorial, all in the spirit of making a good first impression. Turns out all this takes a huge amount of time! So I’ve decided to dump the code in its current state onto GitHub, write a blog article about it and await some valuable feedback while I resume my refactoring and documenting chore.
If you decide to play around with the code, please bear in mind that this is just a preview; your experience might not be as smooth as I intend it to be eventually.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.
Chrome PDF reader displays it correctly, though.
But I'm sure there's still a bug in my PDF font handing code :)
In the sample pdf, only the regular font gets messed up by affected pdf renderers (pdf.js in FF, …). That font is TeXGyreTermes-Regular, and it’s the only CID (composite) font. In the source, that font was an OpenType font (.otf), which, during pdf-creation, got converted into a CID double-byte font, resulting in messed-up Identity-H encoding. (CID double-byte fonts are really meant for huge Asian charset fonts, only.) Likely, the pdf engine used, wrongly assumes that all Unicode encoded fonts (.otf) contain huge Asian charsets, and thus converts them into CID.
I guess most newer pdf renderers know to handle the issue, while the renderer used in FF e.a. doesn’t. The quick fix, at pdf creation, is to avoid fonts being converted into CID at all.
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 with Pandoc but haven't delved into it far enough to know if it's robust enough to do what I want.
:-) But thanks!
It's a surprisingly pleasant environment, though it won't probably be enough for your needs (i.e. no "theorem" env).
Likely a clean, general public friendly GUI (web app) can leverage RinohType’s back-end power, and thus it’s adoption. Maybe monetize that as a hosted service.
A set of professionally designed stylesheets/document templates would give wider adoption a head start.
From your roadmap, I’d be glad to help you achieve some goals (if you would want me to be of any assistance):
- Provide a number of standard document/page/font styles
- Include font definitions for freely available fonts
Fake small capitals for fonts that do not provide any
- Advanced typesetting features such as Knuth-Plass … and microtypography
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!
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 the lack of time) is that I have no idea how to start, and it bring me to this other comment:
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.
Such a project should have not been started using Python as all current implementations have performance issues, as long you are not gluing C wrapper invocations together.
Really? Python2 is still extremely common, it's too bad I can't this now, if it's not backwards compatible.
So is Python3. They are not mutually exclusive. Python3 is in Debian oldstable (released in 2011), Ubuntu 10.04 LTS, Fedora since version 13 (from 2010), and in openSuse since 11.2 (from 2009).
What, for the curious, is the reason you wish it would die?
First, let me make it clear that I'm a big big fan of Knuth and Lamport and I respect the amazing impact that TeX/LaTeX have had in the Math/Science/Engineering communities. They are clearly a lot smarter than I am, and I owe them a debt for their contributions to CS. I've read Knuth's original papers on Alpha-Beta search, LR-parsing, etc., I own almost all of his books, and I've studied the Art of Computer Programming in depth since the first editions.
TeX is an amazing feat of programming. I had a friend that was in the same fraternity as Knuth as a student. This friend was a great programmer and even he was in awe of Knuth's abilities as a programmer. Look at the history of TeX, the decisions and approaches that Knuth considered and undertook. It's absolutely amazing, and then he essentially gave it away, one of the first and most important Open Source projects!
But, please, can't we come up with a new replacement for LaTeX? By now, it should be obvious that there are only about 7 people in the world that really understand LaTeX/TeX (and I'm not one of them). Hang out on http://tex.stackexchange.com and see what I mean. I've used LaTeX for almost 30 years; it's the first tool I reach for when preparing a document. Thirty years of it is enough.
Now, I write my own styles (.sty files) and complex macros, but the experience isn't pleasant. I think it's here that something needs to be done. I've never been able to convince more than ten percent of the software engineers that have worked for me to use LaTeX. It's not that they don't like markup or programming. It's the mess caused by TeX's macro based extension language. This leads to less than helpful error messages, cryptic behavior, and is a barrier to anyone wishing to take advantage of the underlying power of TeX.
I don't think anyone will try to argue that the TeX macro system is so elegant and powerful or that I simply haven't spent enough time with it, but let me say this, I've programmed for 45 years and I've used macros plenty. I've written packages of macros running on IBM (big machine) assemblers, did assembly language real-time programming for years, implemented macro programming systems like Calvin Mooers Reactive Typewriter [1] and concatenative programming languages like FORTH. Nothing, to me, is more frustrating than trying to write a sophisticated LaTeX package. I've patched boot loaders from the front panel switches of mainframes that wouldn't boot, debugged real time programs containing thousands of lines of assembler, used C++ templates and Haskell types. All of this is easier than writing a fancy new TeX macro. I don't like writing as much as programming, why do the tools have to make it even harder?
Fundamentally, I think that using macros is the wrong way to write extensions and customizations in LaTeX/TeX, the abstractions used to construct anything complex leak too many implementation details. For some of my projects I've found it easier to write custom filters in Python that preprocess input files into plain LaTeX. This observation isn't unique to Latex [2].
LaTeX3 and LuaTeX kept me interested in TeX; I hoped that they would make programming TeX packages and customization easier. Unfortunately, I don't have enough time left to wait for them; they move at a glacial pace and are essentially indistinguishable from abandon-ware. As those 7 guys that understand TeX move on to get real jobs, these projects falter and don't go anywhere. The LuaTeX web-site has been stuck on version 0.6 for thirty months.
Please, can't the community come up with something? Or point me towards a project with a license that I could contribute to.
[1] TRAC (the reactive typewriter system) is a macro based programming system, described in Computer Lib/Dream Machines a 1974 book by Ted Nelson and by its inventor Mooers in the CACM, Volume 9 Issue 3, March 1966 Pages 215-219.
[2] http://scienceblogs.com/goodmath/2007/12/17/macros-why-theyr...