It's great to see this here. I meant to try out patoline over a year ago but it wasn't quite ready. This prompts me to take another look. I do remember the devs being very approachable and helpful (which is big plus for me).
I'd encourage the devs to put this in OPAM proper though. Having to add a remote seems like unnecessary friction. Having said that, it's not clear from the site what the current release is.
Hm. The rendered patobook.pdf documentation wouldn't display in the browser; after downloading and opening it in Acrobat Reader, it said some embedded font couldn't be loaded completely, I guess all monospace formatted text was lost: see screenshot at http://i.imgur.com/MhkPqRR.png
I'm very glad to see this project happen but this wasn't a good first impression.
> The new typesetting algorithms of Patoline places your figures at an optimal position decided by the author, not by the system. It can optimize your document in several ways, including reducing its size to fit the standards of a conference paper.
I guess this means you could use this to force a résumé to fit on one page!
I'd recommend adding some more information on the index page.
When I arrived I tried to scroll down hoping to find out what this is about, but instead I had to go to the 'about' page myself.
Then I tried to read the 'about' page but the text is very small and the lines very long, so it's hard to scan for relevant information. The bullet points make a couple of claims about what Patoline excels at, but still no code examples can be seen that could give me a feel for how Patoline actually works.
I had to go to 'documentation' and click a small insignificant looking link to actually get to see an explanation of Patoline and some code examples... in a PDF file.
I understand that it's cool to write the tool's manual using the tool itself, but if I come to the website and want to evaluate quickly whether this is interesting and could replace LaTeX for me, I need a quick overview directly on the index page, together with some examples similar to the one on the wikipedia LaTeX page (http://en.wikipedia.org/wiki/LaTeX#Examples).
I'm very glad people are doing this. The local maximum created by TeX (and its surroundings), while producing impressive output, has kept many people from developing any typesetting software. It was usually easier to learn how to trick TeX into doing what you wanted, or build yet another overlay on top of it.
A similar local maximum exists with Emacs (you might also call it a local energy minimum, as it requires less energy to hack Emacs into doing what you want than to write a whole new system). This has also held back editor development for years (if not decades), but recently we started seeing attempts at breaking out (LightTable is one example).
This is an interesting phenomenon: neither TeX nor Emacs are bad, in fact they are both impressive pieces of software. But we could do better now, and yet we usually don't even start, because it is such a daunting task, and it is easier to extend existing solutions.
Best of luck to authors and contributors to this project!
Your emacs analogy has issues -- vim is another programmable editor alongside emacs. And IDEs, especially ones like Eclipse, have similar complexity behind a graphical interface. Should languages be replaced, or is it better that they just grow and adapt? Look at the scale of the energy minimum around English.
The communities that back vim and emacs would never allow for evolution in the direction of light table or any of the other reinvent IDE projects; heck, they can't break out of their terminal/ASCII mindset for the most part. Technologically they could, but the community has bought into a certain set of principles that work well but don't allow for much deviation. So new projects come along and deviate from entrenched principles, sometimes in successful ways.
English is quite different, it changes with time and even place.
It uses the same archaic syntax as TeX :( I was hoping they would come up with something nice and modern like Markdown.
It seems like a cool project, OCaml is probably a fine choice although I've never used it. But there are a few smells. The first to me was him mentioning the project had 100.000 lines already. Now if this was C I could see why. But this is a modern functional language. There's no 10.000 line rolled out parsers, no hundreds of specialised general libraries.
Why is the project 100k lines? Is it an unmaintainable behemoth already?
a) markdown isn't expressive enough. In fact it's pretty horrendous to edit and separate content and layout IMHO. I'd go as far to say I prefer docbook over markdown. It's fine for github readme's but not typesetting.
b) the problem is complicated. Complicated problems need lots of lines of code. 100kloc isn't much. The thing I'm working on has 5.2Mloc and took 25 people 20 years to write. To the layman it probably looks like it does less than this typesetter meaning it's a bad metric to use.
My MacTeX installation is about 1300Mb if that's any gauge.
> a) markdown isn't expressive enough. In fact it's pretty horrendous to edit and separate content and layout IMHO. I'd go as far to say I prefer docbook over markdown. It's fine for github readme's but not typesetting.
I think they're all pretty poor. Sure they're a reasonable choice for conversion to HTML but they're only a subset of that and HTML is pretty easy to write and separate style and content these days.
The point of these compile-to-html languages (eg. markdown) is that you're abstracting away from the display formatting as much as possible.
It's easy to say that you can just use HTML as content-only and style it using CSS, but the reality is that HTML is primarily a display format; it's pretty much unavoidable having classes, ids & DOM node structure in HTML that govern display behavior.
By abstracting concepts (paragraph, heading, list, etc) out, you can render them as components however you like into the HTML. Which means if you decide to change how they're rendered, you can do it all at once by editing the template.
Markdown & it's kin are certainly not perfect, but I'm pretty sure writing directly into HTML for your content is a generally really terrible idea.
(that said, with web components we will be able to do this directly in HTML by creating custom data-driven tags, so maybe that's the future. ...but it's not quite here yet)
Show me the part of Markdown (and its kin) that allows me to distinguish why the text is appearing in (or, rather, marked up in a manner that normally translates to) italics or bold (hint: you can't assume stress, and simply holding to current conventins is only good for ephemera). Where do the language tags for foreign words and phrases go? Are asides, callouts and infoboxes really the same things as blockquotes? HTML may not quite be SGML, but it is an awful lot richer than Markdown (and its kin) even if no attention is paid to styling. (I haven't used a class or id whose only purpose was styling in a decade. They either have a relationship to the document structure or they don't exist.)
True but I listed two options available which aren't as bad as Markdown. There isn't even one Markdown but several extensions as far as I can see and Markdown looks like a proof of concept sent to production and later extended at various customer sites.
I have been studying AsciiDoc lately. It turns out to be a really hacked-together macro language for creating "ad-hoc lite markup" to "SGML/XML-based semantic markup" conversions. The core idea and the default ad-hoc lite markup are both pretty nice, but the implementation leaves a lot to be desired. AsciiDoctor is an alternative implementation which is used on GitHub and in other places, but I believe it interprets AsciiDoc as more of a "fixed format" like Markdown than the original reconfigurable macro-based approach.
Or, it could be that TeX has been cobbled together over decades with little design guidance or vision, resulting in a mishmash of approaches and inefficient code.
To me almost everything in TeX feels like a hack, even if the fundamental idea is good and the sum of all hacks ends up looking pretty good. The fact that it's a huge hack that takes 1.3GBs to install is not a gauge of quality.
It only takes 1.3 GB if you install every package ever invented. A normal installation of TeX Live takes about 200 MB and includes all the binaries (including tex, pdftex, xetex and luatex), a full LaTeX and ConTeXt and a whole bunch of other libraries.
I usually just install that, and then tlmgr any missing packages instead of downloading a gigabyte of TeX code I'll never need.
The full TeXLive is 1.3GB large, because it ensures that the only thing you need to build any semi-sane TeX document is this installation.
Describing TeX as Code misses the topic by a wide margin, a lot of the things in the distribution are fonts and compiled versions of the documentation.
Bash the idea of treating TeX as code out of your head and you will find it quite a bit saner.
Anecdotally lots of people are using Markdown and Pandoc to get from lightweight files to decent PDF or HTML.
Ok, you're not going to use it if you need actual typesetting, for that just use TeX and be done with it. What we're seeing I think is the same type of backlash that spawned YAML from XML.
Funny thing is, the actual space for .docx or .odt could be shrinking, is it?
Docx and Odt will live forever. 99% of the population will continue to use them. Hell I write hundreds of pages of documentation every year in Word 2010 and use LibreOffice at home because its easy. I use LaTeX for anything that is 'published'.
I hope we don't get another YML, an inferior and minute subset of XML's capabilities with all its problems and none of its advantages and tooling. I've used XML for years and once you understand it properly it's fine.
Call me old school but I find lightweight markup to be a hack job.
> Call me old school but I find lightweight markup to be a hack job.
The best way to think of it is that markdown is a replacement for .txt. It's not a typesetting language, it's just a conventional way to structure text documents.
Most of the elements of markdown are already there in .txt files from the 80s and 90s. All markup does is standardize how to do headers, lists, code blocks and bold/italic so that you can generate documents that actually contain those elements, but could also just treat a markdown file as a normal .txt.
I really like starting documents where I write most text with Markdown, but write out any equations with LaTeX syntax. Pandoc works great for this.
Invariably, if I work on the document for any lengthy period of time, I end up giving up on using Markdown. I'll generate LaTeX output using Pandoc and just start editing it manually.
We don't have to do strict Markdown, but even Markdown is transparently extensible in HTML. It is entirely feasible to write publishing quality documents in HTML/CSS3, and thus, Markdown.
I would love to see something like Markdown, but well-suited for typesetting, but with a transparent backend scripting language for more in-depth tasks. Scribble looks like a good start: http://docs.racket-lang.org/scribble/index.html
Currently, I use org-mode and LaTeX-export for this. It works well enough, but a native integrated environment would open this to a much wider audience.
Reading about macro typesetting systems made me wonder about whether someone had done it in Lisp, and then I saw your post! Scribble looks really interesting, I might have to have a play with it for my book that I'm working on.
Is "line" in this pronounced as in "gasoline" (lin) or "waistline" (laɪn) or "adrenaline" (lɪn)?
edit: Like gasoline. "Its name is to be pronounced like Pa-toe-leen, and it
is the frenchifcation of the translation in portuguese of a joke in english"
I find it ironic that a website for a typesetting tool requires me to zoom in to be able to comfortably read it.
It looks like it could be an improvement over TeX. I like that modularity is a focus, because that's where TeX really suffers. Hopefully the typographical elements will actually be composable and extendable rather than having the loose facade of such functionality found in TeX.
I think if someone was to redo TeX, that it would be really nice to see an incremental type setting system. That means modularity not just at the code level, but also with respect to how the run-time data structures are dependent on each other, and the ability to "reflow" text on a change in a way that required minimal changes to the previous flow of the text. Then we could have something that was Wysiwyg, interactive, and produced output that looked fairly decent.
Ok, at least as good as TeX then, something much better than Word. I mean, we are getting good with doing incremental computation (e.g. FRP, SAC, etc...), why not apply these techs to the problem of typesetting.
The about page gives me no idea of what it is, especially as someone who knows TeX quite well. It starts with the single mistake all of those pages do: "It's like A, but with B!" On top of that, B is already in A. Typesetting with scripting? LuaTex (actually quite easy, if you know the typesetting surroundings). More layout control? ConTeXt.
The biggest hurdle in all those systems is understanding what typesetting actually is (in contrast to content editing or especially programming). It comes with a completely different vocabulary. What's a strut?[1] What's a quad?[2] What are the standard elements of typography and page layout? How are fonts measured?
Finally: how does the system manage forward compatibility (can I still compile my document from 5 years ago?) - scripting and modularity are features that have to be evaluated under all those regards.
Also, I am very surprised that code examples in the reference documentation look horrible. Isn't that what the system is there for?
That said: I love that there is competition in that space. TeX is great and will be around for a few decades, but that doesn't mean there can't be others.
> Can I still compile my document from 5 years ago?
Well on the About page it does have the FAQ:
> Can I use Patoline for a huge, ten years long project that I'm starting now?
> Although one of the authors has written his PhD. thesis (120 pages, in computer science) with it, we don't recommend it now. The reason for this is that small adjustements and bugfixes are being made all the time, and working on such an unstable system can be frustrating. However, for documents that are not meant to last forever in time, we would be happy to help you with it: feel free to contact us for help.
> Stay tuned: we do plan to release a long term supported version of Patoline soon.
The problem is wide, that's why I was asking about _forward compatibility_. Even if I have long term support, what happens if that runs out? How does that work in the presence of scripting and extensions?
TeX has a whole culture around that - even if there are no long term releases, it is _very stable_.
For example, the LPPL even prohibited releasing changed files under the same name for a long time!
It's about time someone gave this a bash - though to some extent this covers the same ground a Pandoc.
However, some of the technological choices seem... unwise if the aim is a lively community project. Version control for instance - whatever technical advantages Darcs may have are heavily outweighed by it's much smaller user base (having to learn a new VCS just to contribute to a project is a massive pain!)
To quote Knuth [1] describing TeX “Think thrice before extending,” because
that may save a lot of work, and it will also keep incompatible extensions of TeX from proliferating.
Personally, I am of the opinion that the original TeX was well 'modularized' in 'Pascal Procedures' [1], being Turing complete, extensions such as the LaTeX format and the countless of packages after that helped it survive and prosper. Think of a macro that you define as an easier way than programming a module in JavaScript and it doesn't need a half a dozen tools to set it up.
\def\#1{\TeX\ is alive says #1.}
Nevertheless, provided the lessons learned are incorporated I applaud any new initiatives in more modern languages. Whatever is produced will however, need to be able to parse TeX, otherwise it will not be easily adopted by the community.
> Whatever is produced will however, need to be able to parse TeX, otherwise it will not be easily adopted by the community.
This is a huge barrier to raise, since parsing TeX is the same as typesetting TeX—the meaning of a macro later on can be affected by a macro now. You can't even just execute the macros in a vacuum, since the meaning of a macro can depend on things like the current page number.
To quote Knuth [1] describing TeX “Think thrice before extending,” because
that may save a lot of work, and it will also keep incompatible extensions of TeX from proliferating.
Personally, I am of the opinion that the original TeX was well 'modularized' in 'Pascal Procedures' [1], being Turing complete, extensions such as the LaTeX format and the countless of packages after that helped it survive and prosper. Think of a macro that you define as an easier way than programming a module in JavaScript and it doesn't need a half a dozen tools to set it up.
\def\#1{\TeX\ is alive says #1.}
Nevertheless, provided the lessons learned are incorporated I applaud any new initiatives in more modern languages. Whatever is produced will however, need to be able to parse TeX, otherwise it will not be easily adopted by the community.
I am still not clear what the output format is - is it a set of html pages that can be hosted on a server? A compiler produces a binary and the binary generates document(s)?
I am looking for an authoring tool where I can create the text of a tutorial but have Bret Victor like sections of interactiveness that illustrate the details of the text. The end format would be a set of web pages. I could code it all up with html+javascript+backend but I am wondering if there is an existing tool to do all this (some sort of task specific editor).
I know it gets said a lot, but have you considered emacs and org-mode. Because, it goes a very long way for this. See this great talk showing its use with python. https://www.youtube.com/watch?v=1-dUkyn_fZA
Quoting Google fonts[0]: 'Alegreya was chosen as one of 53 "Fonts of the Decade" at the ATypI Letter2 competition in September 2011, and one of the top 14 text type systems. It was also selected in the 2nd Bienal Iberoamericana de Diseño, competition held in Madrid in 2010."'
Folks, stop trying to solve problems that have already been solved. Especially if it was Don Knuth who solved it. When that guy solves something, it stays solved.
In this case, you're up against something Don Knuth solved and then Leslie Lamport made more useable. You really want to compete with those two?
It's a mistake to think we can't improve on something because someone smart built it. In my academic community, everyone fights with LaTeX and I can only say with confidence that one person I know has mastered it. Everyone else just hacks at their document until it's close enough.
That could also describe the process by which the majority of computer code is written when you consider everything that involves coding these days. The situation is not likely to change with new tools.
Fair point. I hack LaTeX because I like to, but it's a perishable skill and requires fairly regular use. But that's not really the way (in my opinion) you should be using it. When I designed the layout for my lecture notes, that was a couple of months of on-again off-again tweaking and building a style document and macros. Now, I have a trivial to use template that any of my colleagues could use. After a few years, it's pretty stable, but I still tweak it from time to time and note (pleasantly, given how rare this sort of thing is with code) that my decade old documents still compile just fine with the tweaked version.
When I wrote my thesis, I didn't hack LaTeX - I downloaded the style file and template and just started writing. Someone else maintains those files, and hundreds of Masters' and Doctoral candidates use them without major issues (other than those who've never used anything by Word, but who the hell wants to design for them?)
That person who mastered it? Get them to spend a few dozen hours putting together a bullet proof style. That's how you do it.
Final note: I don't think something built by someone smart can't be improved on. But I do think you need to have a pretty solid understanding of why they did it the way they did before you get to call what you're doing an improvement. And an awful lot of critiques of TeX/LaTeX seem to come from a place of ignorance (frequently the "why isn't it like Word?" ignorance that tend to end the conversation for me).
It's going to take da Vinci like talent and a herculean effort and to build anything 10% as good a TeX. Knuth, the pre-eminent computer scientist, devoted 10 years of his life to type setting to create MetaFont and TeX. Being able to "write scripts" for it ain't enough. Anyway... prove me wrong.
A lot of that time went into the development of not the code per se, but algorithms that newer code could reimplement. Perhaps in simpler forms on newer machines. Conventional TeX has a hard time optimizing placement of page breaks because its data structures hold only one page at a time, and discard its contents before starting the next, due to memory limitations of computers from the 1980s. Those limits no longer apply, which could make it a lot easier to code strategies for eliminating "widows" and "orphans" -- situetions in which only one line of a paragraph is stuck at the top or bottom of a page.
It seems, Patoline's syntax resembles LaTeX syntax a lot, but it lets you embed code more easily. And you can use OCaml or some it's subset instead of TeX's \if, \loop, etc [1], which is probably a good thing.
\begin{genumerate}(AlphaLower, fun s -> [tT (s^". ")])
\item First item
\item Second item
\end{genumerate}
Will it work sanely with Make, handle modular documents better than TeX, etc? The biggest frustration with me and TeX isn't the quality of its output or its extendability, it's simply difficult for me to work it into a reproducible workflow without a lot of effort on my part.
With all of my tools that I use that somehow depend on each other I can always glue together the results of my work with one tool to the input of another tool via Make, minimizing human error in translating results over myself, but LaTeX (combined with tools like BibTeX) somehow always breaks this model, which can be very frustrating since LaTeX is such an important component of mathematics research.
Interesting approach. Even though as for a replacement for TeX, I always expected Lout[1] to gain popularity. I haven't used it in years, but I remember being really easy to learn and way lighter than TeX.
83 comments
[ 2.4 ms ] story [ 142 ms ] threadI'd encourage the devs to put this in OPAM proper though. Having to add a remote seems like unnecessary friction. Having said that, it's not clear from the site what the current release is.
I'm very glad to see this project happen but this wasn't a good first impression.
I guess this means you could use this to force a résumé to fit on one page!
Then I tried to read the 'about' page but the text is very small and the lines very long, so it's hard to scan for relevant information. The bullet points make a couple of claims about what Patoline excels at, but still no code examples can be seen that could give me a feel for how Patoline actually works.
I had to go to 'documentation' and click a small insignificant looking link to actually get to see an explanation of Patoline and some code examples... in a PDF file.
I understand that it's cool to write the tool's manual using the tool itself, but if I come to the website and want to evaluate quickly whether this is interesting and could replace LaTeX for me, I need a quick overview directly on the index page, together with some examples similar to the one on the wikipedia LaTeX page (http://en.wikipedia.org/wiki/LaTeX#Examples).
A similar local maximum exists with Emacs (you might also call it a local energy minimum, as it requires less energy to hack Emacs into doing what you want than to write a whole new system). This has also held back editor development for years (if not decades), but recently we started seeing attempts at breaking out (LightTable is one example).
This is an interesting phenomenon: neither TeX nor Emacs are bad, in fact they are both impressive pieces of software. But we could do better now, and yet we usually don't even start, because it is such a daunting task, and it is easier to extend existing solutions.
Best of luck to authors and contributors to this project!
English is quite different, it changes with time and even place.
It seems like a cool project, OCaml is probably a fine choice although I've never used it. But there are a few smells. The first to me was him mentioning the project had 100.000 lines already. Now if this was C I could see why. But this is a modern functional language. There's no 10.000 line rolled out parsers, no hundreds of specialised general libraries.
Why is the project 100k lines? Is it an unmaintainable behemoth already?
b) the problem is complicated. Complicated problems need lots of lines of code. 100kloc isn't much. The thing I'm working on has 5.2Mloc and took 25 people 20 years to write. To the layman it probably looks like it does less than this typesetter meaning it's a bad metric to use.
My MacTeX installation is about 1300Mb if that's any gauge.
More people should understand this before suggesting Markdown as a solution. For a better experience on github or bitbucket you can use reStructuredText and Org-mode. https://en.wikipedia.org/wiki/Lightweight_markup_language#Co...
The point of these compile-to-html languages (eg. markdown) is that you're abstracting away from the display formatting as much as possible.
It's easy to say that you can just use HTML as content-only and style it using CSS, but the reality is that HTML is primarily a display format; it's pretty much unavoidable having classes, ids & DOM node structure in HTML that govern display behavior.
By abstracting concepts (paragraph, heading, list, etc) out, you can render them as components however you like into the HTML. Which means if you decide to change how they're rendered, you can do it all at once by editing the template.
Markdown & it's kin are certainly not perfect, but I'm pretty sure writing directly into HTML for your content is a generally really terrible idea.
(that said, with web components we will be able to do this directly in HTML by creating custom data-driven tags, so maybe that's the future. ...but it's not quite here yet)
To me almost everything in TeX feels like a hack, even if the fundamental idea is good and the sum of all hacks ends up looking pretty good. The fact that it's a huge hack that takes 1.3GBs to install is not a gauge of quality.
I usually just install that, and then tlmgr any missing packages instead of downloading a gigabyte of TeX code I'll never need.
Describing TeX as Code misses the topic by a wide margin, a lot of the things in the distribution are fonts and compiled versions of the documentation.
Bash the idea of treating TeX as code out of your head and you will find it quite a bit saner.
https://tex.stackexchange.com/questions/22917/a5paper-settin...
(If you thought setting a5paper would result in your output paper size being A5, think again. facepalm)
Ok, you're not going to use it if you need actual typesetting, for that just use TeX and be done with it. What we're seeing I think is the same type of backlash that spawned YAML from XML.
Funny thing is, the actual space for .docx or .odt could be shrinking, is it?
I hope we don't get another YML, an inferior and minute subset of XML's capabilities with all its problems and none of its advantages and tooling. I've used XML for years and once you understand it properly it's fine.
Call me old school but I find lightweight markup to be a hack job.
The best way to think of it is that markdown is a replacement for .txt. It's not a typesetting language, it's just a conventional way to structure text documents.
Most of the elements of markdown are already there in .txt files from the 80s and 90s. All markup does is standardize how to do headers, lists, code blocks and bold/italic so that you can generate documents that actually contain those elements, but could also just treat a markdown file as a normal .txt.
Invariably, if I work on the document for any lengthy period of time, I end up giving up on using Markdown. I'll generate LaTeX output using Pandoc and just start editing it manually.
We don't have to do strict Markdown, but even Markdown is transparently extensible in HTML. It is entirely feasible to write publishing quality documents in HTML/CSS3, and thus, Markdown.
I would love to see something like Markdown, but well-suited for typesetting, but with a transparent backend scripting language for more in-depth tasks. Scribble looks like a good start: http://docs.racket-lang.org/scribble/index.html
Currently, I use org-mode and LaTeX-export for this. It works well enough, but a native integrated environment would open this to a much wider audience.
edit: Like gasoline. "Its name is to be pronounced like Pa-toe-leen, and it is the frenchifcation of the translation in portuguese of a joke in english"
Listen to the first 5 seconds of this video: https://www.youtube.com/watch?v=5AR58I40_Os
That's how you pronounce it.
It looks like it could be an improvement over TeX. I like that modularity is a focus, because that's where TeX really suffers. Hopefully the typographical elements will actually be composable and extendable rather than having the loose facade of such functionality found in TeX.
The biggest hurdle in all those systems is understanding what typesetting actually is (in contrast to content editing or especially programming). It comes with a completely different vocabulary. What's a strut?[1] What's a quad?[2] What are the standard elements of typography and page layout? How are fonts measured?
Finally: how does the system manage forward compatibility (can I still compile my document from 5 years ago?) - scripting and modularity are features that have to be evaluated under all those regards.
Also, I am very surprised that code examples in the reference documentation look horrible. Isn't that what the system is there for?
That said: I love that there is competition in that space. TeX is great and will be around for a few decades, but that doesn't mean there can't be others.
[1] http://en.wikipedia.org/wiki/Strut_%28typesetting%29 [2] http://en.wikipedia.org/wiki/Quad_%28typography%29
Well on the About page it does have the FAQ:
> Can I use Patoline for a huge, ten years long project that I'm starting now?
> Although one of the authors has written his PhD. thesis (120 pages, in computer science) with it, we don't recommend it now. The reason for this is that small adjustements and bugfixes are being made all the time, and working on such an unstable system can be frustrating. However, for documents that are not meant to last forever in time, we would be happy to help you with it: feel free to contact us for help.
> Stay tuned: we do plan to release a long term supported version of Patoline soon.
The problem is wide, that's why I was asking about _forward compatibility_. Even if I have long term support, what happens if that runs out? How does that work in the presence of scripting and extensions?
TeX has a whole culture around that - even if there are no long term releases, it is _very stable_.
For example, the LPPL even prohibited releasing changed files under the same name for a long time!
https://en.wikipedia.org/wiki/LaTeX_Project_Public_License
However, some of the technological choices seem... unwise if the aim is a lively community project. Version control for instance - whatever technical advantages Darcs may have are heavily outweighed by it's much smaller user base (having to learn a new VCS just to contribute to a project is a massive pain!)
Personally, I am of the opinion that the original TeX was well 'modularized' in 'Pascal Procedures' [1], being Turing complete, extensions such as the LaTeX format and the countless of packages after that helped it survive and prosper. Think of a macro that you define as an easier way than programming a module in JavaScript and it doesn't need a half a dozen tools to set it up.
Nevertheless, provided the lessons learned are incorporated I applaud any new initiatives in more modern languages. Whatever is produced will however, need to be able to parse TeX, otherwise it will not be easily adopted by the community.[1] http://www.tug.org/texlive//devsrc/Master/texmf-dist/doc/gen...
last <-- first; { cf. Matthew 19:30 }
https://en.wikipedia.org/wiki/Donald_Knuth#Religious_beliefs...
http://www.webofstories.com/play/donald.knuth/1
This is a huge barrier to raise, since parsing TeX is the same as typesetting TeX—the meaning of a macro later on can be affected by a macro now. You can't even just execute the macros in a vacuum, since the meaning of a macro can depend on things like the current page number.
Personally, I am of the opinion that the original TeX was well 'modularized' in 'Pascal Procedures' [1], being Turing complete, extensions such as the LaTeX format and the countless of packages after that helped it survive and prosper. Think of a macro that you define as an easier way than programming a module in JavaScript and it doesn't need a half a dozen tools to set it up.
Nevertheless, provided the lessons learned are incorporated I applaud any new initiatives in more modern languages. Whatever is produced will however, need to be able to parse TeX, otherwise it will not be easily adopted by the community.[1] http://www.tug.org/texlive//devsrc/Master/texmf-dist/doc/gen...
I am looking for an authoring tool where I can create the text of a tutorial but have Bret Victor like sections of interactiveness that illustrate the details of the text. The end format would be a set of web pages. I could code it all up with html+javascript+backend but I am wondering if there is an existing tool to do all this (some sort of task specific editor).
(Found about this today because someone requested R Markdown support in [vim-pandoc](https://github.com/vim-pandoc/vim-pandoc/), which I manage. The result was [vim-rmarkdown](https://github.com/vim-pandoc/vim-rmarkdown/))
Quoting Google fonts[0]: 'Alegreya was chosen as one of 53 "Fonts of the Decade" at the ATypI Letter2 competition in September 2011, and one of the top 14 text type systems. It was also selected in the 2nd Bienal Iberoamericana de Diseño, competition held in Madrid in 2010."'
Maybe your font rendering is broken somehow?
[0]: http://www.google.com/fonts/specimen/Alegreya
> ...powerful tools that have been developped to process languages...
I assume the author is French from the mistakes, just run it through an english spellcheck platform.
In this case, you're up against something Don Knuth solved and then Leslie Lamport made more useable. You really want to compete with those two?
When I wrote my thesis, I didn't hack LaTeX - I downloaded the style file and template and just started writing. Someone else maintains those files, and hundreds of Masters' and Doctoral candidates use them without major issues (other than those who've never used anything by Word, but who the hell wants to design for them?)
That person who mastered it? Get them to spend a few dozen hours putting together a bullet proof style. That's how you do it.
Final note: I don't think something built by someone smart can't be improved on. But I do think you need to have a pretty solid understanding of why they did it the way they did before you get to call what you're doing an improvement. And an awful lot of critiques of TeX/LaTeX seem to come from a place of ignorance (frequently the "why isn't it like Word?" ignorance that tend to end the conversation for me).
With all of my tools that I use that somehow depend on each other I can always glue together the results of my work with one tool to the input of another tool via Make, minimizing human error in translating results over myself, but LaTeX (combined with tools like BibTeX) somehow always breaks this model, which can be very frustrating since LaTeX is such an important component of mathematics research.
[1]: http://en.wikipedia.org/wiki/Lout_%28software%29