GNU troff is looking for a maintainer. If you’re interested, please take a look at this general information about GNU packages and being a GNU maintainer, and then email maintainers@gnu.org with a bit about your background and particular interest in this package. Thanks.
Please note that maintaining this package requires assigning copyright to the FSF, and ensuring that any future contributors also execute papers, since that is what past authors and contributors have done.
As a typesetting aficionado, I have tried most of the suggestions here (Prince, Troff, Lout, Docbook XML, Asciidoc, LaTeX, ConTeXt, .. except GUI typesetting tools.)
TeX appears bad from a distance, mostly from hearsay, until you have to write an actual technical book of certain expected high production standards and you realize TeX gives you the best shot at doing so.
There is a learning curve. It is an investment of your time, but it pays off.
Also, it is not like LaTeX et al are standing still in time. There are companies and teams working on improving the ecosystem everyday. I personally like ConTeXt unless I'm doing a predefined template exists (for conferences etc.,) where it makes sense to just use their LaTeX guidelines.
Of recent attempts at dethroning LaTeX, there's also SILE, which actually reuses some LaTeX internals. For some examples of the output (hard to find, the author seems not great at marketing), see e.g.:
For a deeper dive, see the author's presentation at FOSDEM 2015 - I found it really amusing - from the starting line of: "I wrote a typesetting system - by mistake."
In the video linked above, he mentions several things that ConTeXt can't do, or can't do as easily. On the other hand, the SILE ecosystem isn't as complete as TeX's yet.
yep, that's a significant and notable TODO. Though I have an idea that maybe trying automatic translation of MathJax from JS to Lua using one of the available tools could have a chance of being a win as a relatively quick hack. But I couldn't find time yet to compile SILE itself first, as I don't have a Linux box handy, unfortunately :(
Care to comment on the reasons for using ConTeXt versus LaTeX? I've been curious about ConTeXt for a while, but I fall back on LaTeX out of familiarity (and the need to use provided document classes.)
LaTeX's selling point is, it allows someone(publisher, conference committee, school, professor) to set what is acceptable typesetting and rest of us can focus on the content.
ConTeXt is excellent if you care about design -- visual, layout, use of non-traditional typeface families, non-traditional print medium, create magazines, glossies, etc.,.
Writing a new style, class etc., for LaTeX feels like it's for "experts only". On the other hand, extending and creating new styles etc., for ConTeXt is much more natural part of creating the document.
ConTeXt is also highly programmable and extensible using Lua, XML(think machine generated catalogue).
With Metapost (graphics language), you can create highly sophistical vector diagrams. I have found pgf/tikz to be highly opinionated and it take much more upfront learning compared to metapost.
Sadly I have to work in Windows at times. Context seems to not be the most supported Windows platform. (The link to the Windows simplified package is 404) There is a New Installer http://wiki.contextgarden.net/Windows_Installation_new which does not contain a working binary. The only way to find anything for windows leads to a tar file.
I still think there is a better way to do typesetting in 2016 but all I have seen are a bunch of smaller projects without much support.
Personally I would love a markup language redefined with built in PDF-X support and a simple infrastructure. Context is Ruby, Tex, and ConText. I find LaTex to work well (for the most part) but it is not very flexible but I found the MikText Package Manager as a big step forward.
Well the BIG issue is you can't create new files on Window files only save as. I use virtual machines but my Window computers at work are long in the tooth machines.
I liked TeX for typesetting my thesis, but I feel like, looking back, it would be nearly impossible to convert my document to a reflowable format. Not sure what can be done about that if you want nice typesetting in a fixed size environment, though. I'm curious to what extent the dual-format problem has been addressed.
Thanks for the kind words on the typography. The core formatting
is just troff (groff, really) with the -ms macro package. We
tried Latex briefly but neither Alan or I care for its output, and
I personally find it impossible to control. Troff is the devil I
know -- it's ugly and irregular in many ways but it will put
characters where you want them.
The input was in XML, with a tag set of about 25 items for
headings, paragraphs, index terms, program insertion, simple
tables, and the like. A Go program converted this either into
HTML for rapid viewing on the screen and potentially for an e-book
version, or into troff for printing. Using XML was a mild
nuisance when writing but the error checking was very helpful.
We wrote a variety of small Go programs and scripts to fix things
up, including one that rewrites troff output to do vertical
justification so all pages are the same height. There is also
some fiddling with the generated postscript to put on printer's
marks.
The fonts are Alan's choice, the result of a lot of work on his
part to find them and get the right sizes and appearances. The
handful of Asian characters were tough to get right; troff doesn't
do wide Unicode characters properly, and there are a few places
where we rewrote text to hide that fact.
The drawings are all Alan's work, using Google's drawing program.
We toyed briefly with using pic but it wasn't really up to the
job, and it would not have worked with HTML without a lot of work.
We avoided mathematics beyond superscripts, and the tables are
pretty limited; eqn and tbl would have been ok but again would not
have dealt with HTML.
We should probably write a more organized description of what we
did and make the tools available, though I think most readers are
less interested in the process than you (and I) are. The other
thing is that although one starts with grand ideas of being clean
and orderly, by the end the process is somewhat of a mess, with
a complicated makefile to keep it running.
Recently I've been playing with Prince [1] and I've found it to be very powerful with excellent support for paged media. Given that HTML, CSS, Javascript, SVG is used to build the document, it's also familiar to most people already. There doesn't seem to be any open source competitor to Prince though.
I want to echo the support for Prince here, even though it's not open-source it is a very useful piece of software. I create web-based art books at a museum[1], and Prince has allowed us to generate high-quality PDFs[2] and even print-on-demand editions of the same book for very little additional effort. Full-bleed images, roman numeral page numbers, footnotes, multi-column text pages, all are possible through CSS.
In a past life I was a print designer relying on Adobe software for everything, and it is tremendously liberating to be able to leave that world of vendor-lock-in behind (InDesign has a nasty habit of making each new version's files incompatible with previous ones). So compared to where I'm coming from, Prince (even as proprietary software) is a big step forward because it allows me to work in open formats.
PrinceXML is excellent, we used it for many years for typesetting programs for conferences, etc. After a while, though, I picked up enough LaTeX to be competent at generating LaTeX from our applications (just as we would generate HTML or any other markup) and that's what I use for report generation now. While there are more templates to maintain, the quality of the results is absolutely worth the effort.
On a tangent, a very nice "win" with the (pdf)LaTeX approach is that it's fairly easy to collate other PDF documents into a larger one, with a custom table of contents, consistent running headers and footers, index of authors, etc., and intersperse them with other content from our database. (This was done by splitting the child documents into pages with pdftk, then inserting them as "PDF graphics" into the generated LaTeX document -- and as long as the original PDFs were searchable, they remained searchable in the final output.) In one of our paper-intensive processes (a proposal approval workflow), this approach cut down tremendously on manual labour that was being done to prepare proposal dossiers, and the resulting collation was much easier for the reviewers to work with (e.g., everyone could turn to page "K-34" in the dossier, and be certain they were looking at the same page of the same document).
>There doesn't seem to be any open source competitor to Prince though.
This would be my issue with using it. This is partly why I stay with LaTeX for our book as I can convert it to other formats if I really need to. I find LaTeX gives me more control over presentation & type-setting than web-based stuff as well.
It also means your documents are locked to a proprietary standard that isn't that widely used (compared to say MS Word) and as such, may not be totally recoverable 10,20 or 30 years from now. You want to keep that in mind when you choose which typesetting system to use - for the record, I keep a digital diary that I intend should still exist 50 years from now. I use only markdown, and the occasional entry that mention really private stuff is ascii encrypted with GPG.
I assume there is some additional special sauce that enables you to do things that are not possible in a browser, which means you still won't get the exact formatting, index, etc correct.
To extent of my knowledge, Prince only implements web standards set by w3. The reason browsers can't do what Prince does is because they lack support for those standards.
Wikipedia lists some of what Prince does that others don't:
The other thing is that although one starts with grand ideas of being clean and orderly, by the end the process is somewhat of a mess, with a complicated makefile to keep it running.
It's sad that a complete structure writing/publishing workflow is still so hard. XSL-FO is awkward and limited, and will probably remain so. TeX is not design-friendly. On the other side, InDesign is mostly visual only. Framemaker seems to be only serious tool but it's very expensive.
I was a devoted FrameMaker user until Adobe killed the Mac product. I used to have to do fairly complicated legal documents, and it was worth every penny. Plus, it was a very good word processor--you never had to leave the program to edit text. So I used it for everything I had to write.
A book like this could have been handled fairly easily in FrameMaker, but sadly Adobe has decided to position in it to be only for large enterprise shops running Windows. They're probably (rightfully) afraid it would cannabalize InDesign sales if they made it more accessible.
Yeah, just out of curiosity I looked at what the current deal was, and that might almost be reasonable if a) I were still going to be using it every day and b) there were still a Mac/Linux version. I wouldn't do a subscription deal it just for personal use, but that's a different issue. But 'positioning' is partly a marketing thing. Not having a Mac version clearly separates the product from Indesign for a lot of users.
What about Apple Pages? I find that very good and easy to deal with typesetting. But I am no expert in the field so it might have sever weaknesses I am not aware of. Anyway I like that it seems to have been designed with layout in mind from the start unlike MS Word e.g. where doing layout has never felt natural.
Typesetting isn't the same as word processing, you need a lot more power than something like Pages gives you.
For example, our book is 308,000 words and 32 chapters. By the time it's done it'll probably be ~310-325k plus index. LaTeX means I can change one line in the header and have the build completely re-typeset the book according to those parameters programmatically, and it does a _very_ good job.
Re: index - how do you generate an index with Apple Pages? And I don't mean concordance, I mean a proper index. With LaTeX it's...programmatic. We provide the metadata in the form of `\index{blah}`, it generates the index for us.
It's extremely hard to find anything that's competitive on all these fronts and which is also open source. LaTeX is pretty much it, everything else is focused only on basic formatting & presentation and hasn't even gotten to a proper typesetting algorithm.
You don't have to write the XML tags while you type. The hardest part about writing long-form technical prose is writing long-form technical prose. You can concentrate on getting that right, in the editor of your choosing, using placeholders for diagrams and layout elements. Then, in a second pass, mark the text up.
Sure, a single small example looks almost (but not quite) as bad, but in larger texts LaTeX is basically the text-you're-writing, plus some control stuff, whereas XML interferes with everything.
For an actual typing-on-the-keyboard format, it seems like almost anything would have been better, particularly given the number of markup languages that can translate trivially into XML.
I may have misunderstood -- he was actually typing in XML tags as he wrote the book, right?
Yes, they did. I saw the XML and it didn't look much different from well-written HTML. The amount of markup you need for a book is fairly minimal: h1, h2, p, b, i, c (code font), ix (index entry). Think of it as a customizable HTML.
For anyone missing the lede here: the book is typeset in troff. This is astonishing because troff is 40+ years old and AFAIK hasn't gotten significant development in ~10 years. If it ain't broke don't fix it. http://www.troff.org/history.html
Kernighan has always used troff, so it is not a surprise that he is still using it. He can do things with troff that most people would have a hard time to do with LaTeX. On the other hand, this doesn't mean that troff is better, in fact as you said it has not been updated for a long time. For someone starting now, it is so much easier to learn and be productive with LaTeX instead of troff.
I wrote to Kernighan a few years ago, when "D is for Digital" came out, to ask him, in effect, if troff had been made obsolete by TeX. At the time I had begun using it, and wondered if it was worth investing my time to learn.
He answered that he still preferred to use groff, having tried alternatives. Since then I have used groff exclusively for writing documentation and papers. It never runs out of gas, and always produces attractive output. It offers a complete suite -- math, tables, pictures, graphs -- all in one package. It's fast, adaptable, and easy to learn. It has the highest ratio of text to markup of any typesetting system, including TeX and Markdown. It is the single most overlooked and under appreciated project on the planet.
Whether it's had "significant" development in the past 10 years depends on what that means. Current groff produces PDF format directly, without a Postscript intermediary. The PDF macros support links and TOC generation. I think that all took place in the last few years.
What platform do you write on? Linux? Mac? I'm genuinely curious.
I have been looking for substitutes to Latex ever since writing my dissertation in Latex and having to debug/tweak an already horrendous Latex .sty file. I basically decided that I would either write technical documents in Tex or not at all after that. For me, Latex is great, until it isn't, and then it's Jinga-on-a-unicycle frustration.
The problem with LaTeX is that you are given an already unstable jinga (ie., style file etc.,).
You can always go back to the basics and use simple TeX for your documents if you think groff/troff is simpler.
However, I'd encourage you to give ConteXt http://wiki.contextgarden.net/ a try because it is the spiritual successor to TeX (one tool for all the typesetting) instead of having to depend on "third party" stuff like LaTeX, most of which very few of us (outside the original sty author) understand.
> We wrote a variety of small Go programs and scripts to fix things up, including one that rewrites troff output to do vertical justification so all pages are the same height.
That sounds weird, why would they want that, wouldn't that make the pages pretty irregular internally? Like varying line heights..?
HTML with CSS with lend itself to generate PDFs. Are there open alternatives to Prince XML? Browsers don't support all page-layout related CSS2/3 attributes, like a page break.
wkhtmltopdf has some extensions for forcing a page break etc.
I used it for generating some documents from a groundup rebuild of bootstrap meant purely for printing (meant we could just use a lot of the web templates with minor changes) and it worked pretty well for our uses.
PrinceXML however is in a class of its own (as you'd expect for $3.8k per server)
GNU troff is looking for a maintainer. If you’re interested, please take a look at this general information about GNU packages and being a GNU maintainer, and then email maintainers@gnu.org with a bit about your background and particular interest in this package. Thanks.
Please note that maintaining this package requires assigning copyright to the FSF, and ensuring that any future contributors also execute papers, since that is what past authors and contributors have done.