The first things I want to see when evaluating a new tool are:
1) a toy usage example
2) why I should use this over whatever I already use (La/Xe/Con/Luatex, Markdown, rST, Pandoc)
3) who is developing it and why I should trust them (e.g. "this is a hobby project", or "this is free-as-in-freedom with a grant from the Gates Foundation", or "we are a startup intending to sell your user metadata to Facebook when we are acquired in a few years")
There is also SILE (https://github.com/simoncozens/sile), which has been in development since 2012 and addresses these points in the docs: SILE is similar to TeX—from which it borrows some concepts and even syntax and algorithms—but the similarities end there. Rather than being a derivative of the TeX family SILE is a new typesetting and layout engine written from the ground up using modern technologies and borrowing some ideas from graphical systems such as InDesign.
The documentation includes "SILE versus TeX" section; some of the quotes from it: "one of the things that TeX can’t do particularly well is typesetting on a grid. This is something of a must have feature for anyone typesetting bibles. Typesetting on a grid means that each line of text will line up between the front and back of each piece of paper producing much less visual bleed-through when printed on thin paper. This is virtually impossible to accomplish in TeX. There are various hacks to try to make it happen, but they’re all horrible. In SILE, you can alter the behaviour of the typesetter and write a very short add-on package to enable grid typesetting."
"SILE does not benefit from the large ecosystem and community that has grown up around TeX; in that sense, TeX will remain streets ahead of SILE for some time to come. But in terms of core capabilities, SILE is already certainly equivalent to, if not somewhat more advanced than, TeX."
Agreed. The number of language projects that don't even have a basic example of the language syntax on their home page is embarrassing. It's like those articles about new astronomy pictures that don't include the actual pictures.
Flutter is pretty egregious, lots of links, zero examples. It took me forever to determine it is a native runtime platform for mobile Dart applications. They wouldn't even admit that very easily.
Since that question was asked for us a couple of days ago (as the creator of awless), let me tell you that the authors were and still are researchers in Computer Science in public institutions in France. I vet personally for Tom (cf. http://www.lama.univ-savoie.fr/~hirschowitz/ ).
Patoline works well (PhD thesis were written using it) and the implementation in OCaml is nice and clean whereas the (La)TeX codebase is extremely complex.
edit: Funny coincidence, we were mentioning the Patoline project with the team last week.
One of the author's PhD thesis and the 'Patobook' are on the site, rendered, as examples. Unfortunately though their source doesn't seem to be.
From what I've seen in the Patobook, it seems so similar to Latex (or *TeX perhaps, I'm not familiar with the differences) as to be a re-implementation - so I'm not convinced even what makes it 'modern' as claimed is explained.
With the exception of sections, actually. But you could define `=> <= -> <-` to begin/end (numbered) sections anyway.
They don't "choose tarballs over github". They choose darcs over git. Both are distributed.
The terrorism line (at https://patoline.org/about.html) isn't taking a shot at git, it's taking a shot at GitHub, which is centralized in spite of git's underlying distributed nature.
And this is far from the first project to choose a free/open distributed system over a proprietary centralized one.
I appreciate the defecating duck automaton on the cover. See "The Defecating Duck, or, the Ambiguous Origins of Artificial Life" by Jessica Riskin Critical Inquiry for the importance of that robot.
Like others have said, an audience who understands what a "typesetting system" is, would immediately need to be convinced as to why they should use your tool over existing ones like LaTeX or Markdown + Pandoc. Do you really expect your users to read someone dissertation to get that info?
I agree - but the dissertation was just a "demo" or "showcase" of the typesetting system (I actually found it quite neatly, but I did not see anything that I could not have done without much trouble in TeX; would have loved to see the sources, though).
I really think the choice of using OCaml is not a very smart one (w.r.t. a roadmap / scale). Just looking at, e.g., Facebook's Flow reminds me that it can be a blocker in the long run (performance + not cross platform friendly).
> I really think the choice of using OCaml is not a very smart one (w.r.t. a roadmap / scale). Just looking at, e.g., Facebook's Flow reminds me that it can be a blocker in the long run (performance + not cross platform friendly).
So can be C# or any other language you might prefer. OCaml can have exceptional performance and the reasons why they are using OCaml sound quite good.
I'm a bit sceptical on the reasons. I feel like "We like OCaml" might have been more honest. Let's see the justifications.
> Our choice was constrained by the goal to let the user program inside the document, if they wished to do so. To achieve the long-term goals of modularity, backwards compatibility, and portability, we decided to use a functionnal [sic] programming language, with types checked by the compiler (ensuring modularity and portability), and whose authors would also have backwards compatibility in mind.
So maybe functional languages get you more fine grain modularity, but otherwise I don't buy it. And what has type checking got to do with either? As for OCaml programs not segfaulting or crashing, that doesn't seem unique. E.g. javascript doesn't do this either, if it is pre-processed/"compiled". (I'm not saying JS is a better choice.)
It's the same with darcs vs git. Yes, there maybe "better" systems than git, and easier to learn, but you're still making it harder to contribute.
IDK, but with sentences like "If you do not like the idea of a free decentralized internet, you can also do", it seems like they're going for ideology over usability.
Fwiw, OCaml has pretty exceptional modularity – for some definition of modularity. Check out "functors".
Also, for backwards compatibility, this might be a reference to the pretty unusual legal obligations that OCaml has as one of the reference languages of the French Atomic Energy Agency.
I didn't know that, but that makes sense! I couldn't find any more info on this, even when searching for "Commissariat à l'Énergie Atomique OCaml". Do you have more details?
(I still think it's a bit rich to assume people will learn OCaml or write their own transpiler just to typeset stuff though.)
The code (from the tarball) looks pretty much like somebody converted a C library into Ocaml, though. I only looked at src/Typography and the font handling and typesetting code, because I'm kind of familiar with that.
Edit: Ok, it depends on the modules. Some of them are indeed written in quite nice functional style. Must be the "handwriting" of the different authors that those modules are so different.
It's frustrating to see that my criticism of the homepage was raised three years ago, and still has not been addressed in that time. That does not make me want to start using this tool, let alone contributing to it.
Wouldn't Xetex + fontspec take care of that, including unicode needs?
Though, I'm curious what comes of this.
Currently the "official" install/build method via make fails on my mac (sierra - could be some other issue) and on top of that 'opam init' (?) completely broke the fish path evaluation (not Patoline's fault, I guess). Manual fish fix: https://github.com/ocaml/opam/issues/2255.
Oh no, Chapter 5 (Understanding the
typesetting model) and 6 (Extending Patoline) of the book (https://patoline.org/patobook.pdf) are not yet finished, that's what I wanted to read :-)
Did the author try to reverse engineer TeX? Is there anything that Patoline can do better w.r.t. typesetting, for some definition of "better"?
Well, not "reverse engineering", sorry, but that's the idea: did they use the same algorithms and rewrote them exactly as same in OCaml? did they find anything that could be done better? etc.
What do you mean by "reverse engineering TeX"? Since TeX: The Program [1] is freely available with full source code and complete explanations of the the source code, I don't think one could characterize understanding how TeX works as reverse engineering.
Sorry, "reverse engineering" is clearly a bad choice of words. What I meant was that one aspect (and maybe a goal) of rewriting TeX in OCaml is to reorganize the code from a procedural approach to a functional one, while trying to clean up any accidental complexity. That requires to take some distance with the actual code, and is not easy. That's why there are not many successful TeX rewrites (I can't cite any, but I am interested in knowing if some of them exist).
1) a toy usage example
2) why I should use this over whatever I already use (La/Xe/Con/Luatex, Markdown, rST, Pandoc)
3) who is developing it and why I should trust them (e.g. "this is a hobby project", or "this is free-as-in-freedom with a grant from the Gates Foundation", or "we are a startup intending to sell your user metadata to Facebook when we are acquired in a few years")
I'm not sure this site addresses any of those