Independent of the elegant typesetting it produces, TeX contains well-designed notation for mathematics, reflecting the algorithmic bent of its author, Don Knuth.
Mathematics doesn't change as frequently as desktop publishing, so it's a good bet that the TeX (e.g. $\int_0^1 \tau \, d\tau$) is going to be around as long as people talk math online.
That said, I think there are much easier-to-use and less error-prone desktop publishing tools (e.g. Scribus) for less math-heavy domains, like magazine layout.
Anything graphics + text heavy I switch to Scribus. The closer what I am working on can be described as a brochure the more likely I will use Scribus.
TeX, for me, tends to be articles, reports, and documents that I expect to use the same format again and again (or the format is provided, such as from IEEE).
The reason TeX is still used is because it is open source and beautiful, because it is the best at handling mathematical notation, and because of its inertial dominance in math and the hard sciences in Academia. The reason TeX has so, so many fixable problems after 30 years is because there is no financial incentive for anyone to fix it.
The answer is not to find a TeX alternative. This will not be possible in Academia for a very long time. The answer is for someone to plunk down a million dollars to hire some full-time developers to fix it. Honestly, the TeX language is wonderful; it's the editors which are terrible. A TeX editor should...
[] seamlessly hide the compilation process
[] feature a modern debugging environment
[] make 99% of commands (including everything you can do in MS Word) discoverable within the editor, rather than sending the user to the internet or some pdf guide, and
[] robustly handle all modern image types
...without becoming an unstable WYSIWYG hybrid like LyX. The only thing about the language itself that might need to be changed is some standardization of common packages. I shouldn't need to download anything to get appendices and sub-figures to behave sensibly.
The amount of professor, post-doc, and grad student time wasted on TeX is staggering, and easily justifies paying for an overhaul...if only the government or some benefactor would step up.
To add to your fourth point, it should also ideally handle all modern font types and all of their provided features in some relatively simple way. XeTeX/XeLaTeX is great, but that it can’t always do the right thing when any regular TeX document is dropped into it is unfortunate (cf. http://scripts.sil.org/cms/scripts/page.php?item_id=xetex_fa...), and it doesn’t support everything it would in a perfect world.
I would disagree that the base is wonderful and it's the editors that are bad. At least in LaTeX there are a multitude of packages to do any given thing, all with varying levels of completeness, and most with incompatibilities between them. Leaky abstractions abound, and the way the macro language works probably makes this easier.
The features you mention would be needed to put it in front of less geeky users but are far from the core issues. I'd love to see a language with better flow control and abstraction features put on top of the Tex engine that indeed produces beautiful output. Maybe LuaTex will be that.
The core algorithms are pretty creaky as well. Knuth did a brilliant job coming up with efficient algorithms that could do a fairly good job at breaking lines/paragraphs/pages and could handle book-length documents even on 70s-era hardware, but they've had minimal improvement since then. Figure placement in particular is pretty bad, especially for two-column, relatively short conference papers, which is currently a frequent TeX use case. And all of those things are really hard to exercise any control over, with black-magic parameters that often don't have obvious effects ("goddammit, why won't it put the figure at the top of page 5?!").
LuaTeX does seem to be experimenting with some improvements in these areas though.
I don't have any insight at that level of abstraction. Figure placement like a bunch of other things has required me to hack around to get my desired result. Is there any newer research on these algorithms that could make it better given much better hardware?
As for LuaTex I wasn't able to find any examples of actual markup written in it. I would expect that for the actual markup you'd want a language with a bigger and more flexible grammar so you could build DSLs. Ruby seems particularly good at that kind of stuff, but I'm biased there.
LuaTeX has the same macro language as the other TeX engines (pdftex and it's ilk). The true power of LuaTeX comes into play when you use Lua scripting. I am not sure if ConTeXt has more advanced figure placement algorithms due to LuaTeX. LaTeX for sure has the same algorithms as before.
But then is the Lua scripting at the user level? Can it be used in the building of documents? Or is it a scripting language for the underlying engine, invisible to the end-user?
Incidentally I went looking for what pure TeX actually looks like as most people say TeX when they really mean LaTeX. Here's Knuth's TAOCP Volume I errata:
I did a few times. It's actually easier to make something look exactly the way you want it to look in plain TeX than fight with some poorly documented LaTeX package.
I'm sure its possible and useful for specialty cases but would you want to write TAOCP in it?
My experience of using LaTeX compared to WYSIWYG is that it's easier to focus on the text in the editor instead of fighting with the UI interface but it then requires some chasing around package bugs and compile errors. In total it's clearly a net positive for me.
Writing pure TeX would seem to push the tradeoff quite a bit, having so much distracting stuff around the text that requires a totally different mindset than the text being written. It was probably designed for a world where typesetting was done as a final step before publication, potentially by someone else.
The idea is that you put together the few macros that you need and then the book is mostly tag-free.
IDK you can find the source to the TeXbook on CTAN, see if it seems too noisy to you (I don't remember).
You can do Lua scripting a the user level (\directlua{...}). But you have to know the Lua interface. What purpose is having Lua inside your document? Do some calculations? Yes, that's easy. Do complex algorithms for placing floats? Then you need to replace a lot of TeX/LaTeX code anyway and then I wouldn't speak of user level. What you can do easily from inside Lua: shuffle nodes (nodelists) around. Everything you see on a page is represented by a node. So you can reposition anything. That requires a lot of knowledge of the internal representation of nodes and the LuaTeX API, but once you grok it, it is much fun to do these things.
And no, Knuth is definitely not the only one using plain TeX. Yes, it is a niche.
I wrote a LaTeX macro package for my university's PhD thesis format, and like a lot of such packages, the bulk of the work was in TeX rather than LaTeX. It's...well, I'm struggling to find the appropriate word that means "awful, but sort of comfortably awful."
Like a lot of things, if you're handed a finished product, it looks like random noise. If you could watch it being written, it pretty much makes perfect sense. It's a hideous syntax, and sometimes I still wake up in a cold sweat with long strings of '#' signs running taunting me from the corner of my eyes. But I can't say it was all that daunting to write, although I suspect my TeX code was highly non-idiomatic.
All true. Also, the way indexes, table of contents, bibliographies and cross references work in LaTeX are unholy, fragile hacks. Foot- and endnotes could use some TLC. And on 2011-era hardware we really should have some approximation of globally optimal page breaking.
Ugh, and fonts and character sets. Do you still have to put in magic incantations like
to get working hyphenation with wacky characters such as æ, ø, and å?
LuaTeX does seem to be experimenting with some improvements in these areas though.
About when I stopped paying attention to TeX and LaTeX many years ago (2002-ish?), there was some effort under way to rewrite all of TeX in Java. Did that go anywhere?
> About when I stopped paying attention to TeX and LaTeX many years ago (2002-ish?), there was some effort under way to rewrite all of TeX in Java. Did that go anywhere?
>I would disagree that the base is wonderful and it's the editors that are bad
OK. (As I said elsewhere...) When I said the language was fine, I meant that the language as a means for the user expressing an idea was fine, not that there aren't problems at a deeper level with the language. I'm a physicists, not a programmer. Nevertheless, the limitations of the given language could be massively ameliorated with a powerful editor.
>At least in LaTeX...
Sorry, I wasn't clear. I wasn't distinguishing between TeX and LaTeX. Everyone I know in Academia used LaTeX. I was just using TeX as a catch all to distinguish from other typesetting options.
> The features you mention would be needed to put it in front of less geeky users...
There's no reason I should have to go on the internet to find out how to use columns. Or sub figures. Or appendices. It should just work.
I'm not a less-geeky user who needs to be coddled (unless by "less geeky" you mean 99.99% of users). I just want to write up my research, and I don't want to have to think about typesetting theory.
>There's no reason I should have to go on the internet to find out how to use columns. Or sub figures. Or appendices. It should just work.
>I'm not a less-geeky user who needs to be coddled (unless by "less geeky" you mean 99.99% of users). I just want to write up my research, and I don't want to have to think about typesetting theory.
I agree that those things should be easy to find. What I meant is that for the current user base those are nice to have but not essential. I have long since accumulated enough examples of the type of documents I write that I can quickly do the basic things just by copying them from somewhere else. I assume that people that write scientific articles already have working examples of two columns, sub figures and appendices that they just copy when they do a new article.
If you wanted to make LaTeX much more widely use then you'd need all the goodies you mentioned. But to even make those possible the environment under them needs to be much more consistent and robust than it is now. Something like LyX could work well if manual intervention in the typesetting wasn't so needed.
I guess we're disagreeing about what's essential. At this point, I prize robustness more than power. I'd be pretty happy if LaTeX would just work smoothly. Additional capabilities would be gravy.
I'm confused. You're the one that wanted extra features in the environment. All I hoped for would be for the typesetting engine to be more robust and modules to work well together. All I want are bugfixes.
There are several editors for Tex&co that do on-the-fly compilation. Have you seen Kile's two panelled interface, for example?
feature a modern debugging environment
Well, this is a problem with the language: macro expansion is notoriously tricky to debug. I'd like to see work done on a static analyser for Tex.
robustly handle all modern image types
This is not a problem I have ever had. What are you thinking of? The only file types needing special handling in Luatex are Postscript and SVG; both convert painlessly to PDF, and the converter can be run automatically by Luatex.
> There are several editors for Tex&co that do on-the-fly compilation...
Yes, I have two-panelled TeXworks open as we type. It's not seamless because I had to spend an hour fussing with it to set it up with my LaTeX distribution, and another 2 hours dealing with it when I needed to move from pdflatex to regular latex because the journal I was submitting to used some bizarre packages.
It's not that you can't eventually get it working, it's that you ever have to think about it at all.
>Well, this is a problem with the language: macro expansion is notoriously tricky to debug. I'd like to see work done on a static analyser for Tex.
Fine. When I said that the language was fine, I meant that the language as a means for the user expressing an idea was fine, not that there aren't problems at a deeper level with the language. I'm a physicists, not a programmer. Still, I can't imagine the debugging situation can't be greatly improved with the given language if actual people were employed to fix it.
>This is not a problem I have ever had. What are you thinking of? The only file types needing special handling in Luatex are Postscript and SVG; both convert painlessly to PDF, and the converter can be run automatically by Luatex.
I have had many, many headaches with getting images into a document. Last month, I spent 4 hours trying to solve one particular problem. Yes, maybe if I were deeply familiar with all the technical stuff surrounding TeX's relationship with images, I could have figured it out.
It should just work. I should type \includeimage{filename}, and it should just work.
TeXmacs is a true WYSIWYG scientific word processor. It's not a TeX/LaTeX GUI front-end. Rather, it has its own typesetter that produces quality comparable to TeX in real-time as you type.
"... The answer is for someone to plunk down a million dollars to hire some full-time developers to fix it. Honestly, the TeX language is wonderful; it's the editors which are terrible. A TeX editor should... ..."
Would it really take a $1M dollars to achieve a useful enough fix for TeX editing? And a better question, "is there are market for such an editor?"
Yes. Read Yossi Gil's answer: http://tex.stackexchange.com/questions/13370/13435#13435. Here's an excerpt:
I believe most users (maybe not so in this site) just turn a blind eye to the not so elegant features, and produce amazing documents in no time. The very friendly bunch here does not see these not-so-elegant portions as being so annoying. To most, these are just riddles to enjoy, just like cryptic crossword puzzle.
....
The difficult part is in programming something new, something that cannot be found in existing package. There are experts of this dark art: the rest of us just watch them do their wizardry with awe. Luckily, the cases where you really need to do this kind of programming are very rare: chances are that you will find it was done.
In my experience, this is the state of the language. If you could fix this, I believe that even those who currently enjoy the riddles would move over.
That's probably because Linux has more utility for its audience than TeX does. Which is sad, as TeX's original goal was to provide typesetting for the masses, who are unlikely to ever use it for their typesetting purposes.
Nope, TeX's original (and only) goal was to help Knuth typesetting his books (TAOCP specifically) and he didn't think anyone but his secretary will use it.
Replying to someone else's statement with 'nope' and your own different understanding of facts is inane and rude. Either ask for a citation - which I'll gladly provide - or provide a referenced counterpoint of your own.
Assuming you're actually interested in some kind of discussion rather than just trolling, see http://papers.ssrn.com/sol3/papers.cfm?abstract_id=908946, the same reference that's provided on the Wikipedia page for TeX if you'd bothered wondering where I got the information from, rather than just replying 'no' without any research.
The quote is: "TeX was designed with two main goals in mind: to allow anybody to produce high-quality books using a reasonable amount of effort, and to provide a system that would give exactly the same results on all computers, now and in the future."
A simple Google search for the statement above will reveal it's in almost every document ever produced on the topic of TeX, which suggests it may have been written by Donald Knuth himself.
Regardless, TeX failed for the masses because it was too complicated to begin with (the masses are not programmers, nor are they interested in "programming" their documents). WYSIWYG word processors and desktop publishing software do a decent enough job quickly with a learning curve orders of magnitude shallower, and rightly so since it's the learning curve that poses the greatest barrier to entry.
And while many attempts have been made to flatten that curve with various tools, I'm hard pressed to find a compelling competitor to Microsoft Word or OpenOffice in terms of ease-of-use.
People in general are far more interested in the final result than the "beauty" of the steps to produce that result, especially when it comes to the written word.
And still most majority of kernel hacking is done by private people in their free time. No mention of virtually every other software I use everyday. Think of drivers, often made and improved AGAINST a company will, by reverse engineering closed sources.
Money have nothing to do with open source. Sure they help, but if a project is not followed it's not because of money incentives.
That might have been the case 10 years ago but not today. According to G. Kroah-Hartmann, more than 80% of kernel contributors are full-time paid developers, the remaining 20% being spread among free-time contributors and companies who do not want to disclose their names. People contributing to gcc, mozilla or OpenOffice are all full-time paid developers funded by a company to do so.
Money is not everything, but it has a lot to do with everything, including open source. Linux would still have been a hobby operating system if a number of big players (Sun, IBM, etc) didn't get on the Linux bandwagon in the early 2000s.
> LyX is a document processor that encourages an approach to writing based on the structure of your documents (WYSIWYM) and not simply their appearance (WYSIWYG).
Their written description notwithstanding, LyX is a hybrid between WYM and WYG. It bundles up standard blocks of source code and hides it behind graphical objects which resemble the final product.
I believe that description is aimed at former MS Word users who don't even know the WYM/G distinction exists, not as a definitive membership claim by LyX.
I'm glad you like LyX, and I encourage other people who haven't found a TeX editor they like to try it out.
Personally, I don't want my editor to do anything with my source code except color code it, like turning the source code into into manipulable objects (or whatever you call that).
I use scribtex.com. It handles all the packages and compilation process. I can't say, really, about the debugging, and I haven't used different image types, but moving Tex on Latex online fixed a lot of problems for me.
Honest question: What makes you say that? I've never completely understood why TeX is considered the best at handling mathematical notation. Personally, I've been very happy with the equation editor in Word 2010. I'll certainly acknowledge that there's likely better solutions than Word 2010, but before I invest substantial time learning something like TeX I'd like to understand exactly what it is I'm missing out on.
Do you typeset any serious mathematical work in Word 2010?
When people talk about TeX's mathematical typesetting abilities, they are often (from personal experience, as a math major currently in school) referring to having to typeset documents with many pages and upwards of 25% being math. It's much easier for me to type \int_0^\pi \sin (x) dx than it is for me to go click-click-click-click in Word. But besides that, when you're writing proofs, for example, and you have to keep referring to the same symbol, say sigma, over and over again, in LaTeX, you would simply write $\sigma$, but in Word, you would have to do Insert->Symbol or some nonsense. Several more seconds wasted, and that adds up when you have 100 occurrences of the character sigma in your document.
TeX has a learning curve, but it's not even actually that steep. Within 4 days of starting to use it I was already starting to grok it.
LuaTeX can be used as a PDF writing library that has a "perfect" line breaking algorithm inside along with many other nice features. We use it as a base for our database publishing tool. Its absolutely reliable, has modern features (unicode, OTF) and can be programmed in a very decent language (Lua). You need to know TeX if you want to unleash all the power, but you don't need to program in TeX's macro language (which is fun but also a PITA).
I think that a new generation of TeX based applications will show up in the next 10 years.
Agreed. Luatex makes the following division of labour practical: work with data structures and manipulate fonts and the backend in Lua, handle moving about text and setting parameters in the macro language.
One thing I would like to see is proper static analysis tools for Luatex. Lua has tools like https://github.com/fab13n/metalua/tree/master/src/samples/me... but there's nothing of comparable sophistication for Tex, let alone code combining the two, which makes debugging needlessly hard.
The problem is that you can change TeX's syntax during the run time. I am not sure if it is theoretically possible to create such a tool for TeX input. That is one of the reason why I use (except for approx 10 lines of TeX code) only Lua code in my software. These 10 lines will disappear once there is a tex.initialize() in LuaTeX.
I'm quite sure flow-based static analysis can be done for Tex, the question is how expensive it is to perform and how useful the results are.
With respect to catcode-changing code, you can model its possible execution paths: while you can construct example Tex code where you can't infer anything past this point without having complete information from before, in practice with, say a package, you do have example documents which the package is meant to work with, and you can use that in the static analysis.
I've thought about this a fair bit, at least in the context of typical Plain Tex, but not written much code. I should try and enough time for a proof of concept: there's a lot that could be built on it.
I got tired of OpenOffice's IMHO clunky formula editor, so I thought: "Ah ha! Pros use TeX! So should I!" Then I saw how much fingertyping is necessary to reproduce what I was doing in OO, and I went back. Of course, I was trying to kill a field mouse with a nuke, so I should have expected to be disappointed. Any recommendations for a math-friendly TeX-lite for those of us who don't need all that power?
if you want a gui equation editor, check out lyx [http://www.lyx.org/], which uses tex as its backend. texmacs [http://www.texmacs.org/] is another option worth exploring.
Texmacs often get recommended, but I haven't seen any arguments for it that are compelling. I guess there must be a case for it, else no one would work on it. What do you like about it?
it's a decent middle ground between the clunkiness of wysiwyg word processors and the typing-to-reward ratio of pure markup. personally i prefer just writing markup in ascii, but if you want some of the control of tex, but dislike doing that much typing, texmacs or lyx might be just what you are looking for.
kile is more of a lyx competitor (latex frontend versus latex ide). texmacs has its own rendering engine; despite the name it does not in any way depend upon tex.
TeXmacs is a true WYSIWYG scientific word processor. It's not a TeX/LaTeX GUI front-end. Rather, it has its own typesetter that produces quality comparable to TeX in real-time as you type.
I can recommend LyX as well, it makes authoring LaTeX documents much easier. The formula editor is nice, and it makes editing tables a lot more convenient.
Once you're used to it it’s actually quite efficient (at least if you’re just writing mathematics; doing any kind of complex document layout gets a bit more annoying). I know people who can TeX math (including commutative diagrams even) substantially faster than I can write it down on paper full speed. Names for things are mostly pretty intuitive/memorable, quick reference cheatsheets abound, and if you find yourself doing the same thing repeatedly it’s trivial to make your own shorter names for things or encapsulate patterns.
If you're creating a lot of lists and (especially) nested lists, Emacs' Org Mode (now part of the standard GNU Emacs package) is worth learning. You can export it to LaTeX and HTML directly.
There are good alternatives, depending on the type of document being written. For instance, for technical documentation that does not contain to many equations[1], DocBook is often used. Since DocBook uses XML (or SGML previously), it is easy to transform with XSLT. The DocBook project provides excellent stylesheets for xhtml and xsl-fo output, making it easy to target the web and printed media. It is easy to customize output, by overriding templates in the default stylesheets.
Also, DocBook documents can be validated automatically using DTDs or RelaxNG schema. (Yes, XML is full of buzzword bingo :).)
[1] Equations can be typeset with MathML, but since most software only supports presentation MathML this is not ideal.
Before I forget: yes, hand-editing XML is no fun. I did this for years when writing the 'Slackware Basics' book. It is tedious and annoying, even with the excellent nxml-mode for emacs.
For Natural Language Processing for the Working Programmer, we use the <oXygen/> XML editor, which really takes the pain out of writing DocBook documentation. It provides WYSIWYG mode that also renders inline or xincluded XML, such as SVG and MathML. I rarely switch back to the non-WYSIWYG mode, unless I want to reorder some elements quickly.
FYI, asciidoc is great, provides a pipeline to docbook (and thence on to PDF), and is a joy to edit (not quite as concise as, say, markdown, but not ambiguously-defined, either). See my other comment on this thread about it.
asciidoc is nice, but the tag set in DocBook is far broader. Also, DocBook makes it easy to add new elements. But if you need just the basic functionality of DocBook, it is great.
True enough. I've needed some bits of docbook that don't have a direct asciidoc corollary twice, and just used asciidoc passthrough blocks to use them. It's a very practical solution to a leaky abstraction, while allowing me to stay in asciidoc 99.7% of the time.
DocBook is not really a TeX alternative, since it is merely a markup language and does no typesetting of its own. There are actually many DocBook workflows that do the final typesetting in TeX.
Actually, I think this is an asset. DocBook is modular, and consists of DTDs/schemas and stylesheets to translate DocBook content to other XML documents (or plain text). Since TeX is so tightly-coupled to typesetting, it kinda sucks for producing non-typesetted formats.
Using TeX to do the final typesetting in a DocBook workflow is quite old-fashioned. For years, I have used the XSL-FO stylesheet to create XSL-FO output. You can pass this to an XSL-FO typesetter, such as Apache FOP or RenderX.
This workflow has several advantages:
* You can easily tweak output by overriding templates.
* Commonly-used FO renderers render SVG and MathML. You can use one vector graphics format to create XHTML, ePub, and PDF/print output.
* Each step and output, except for the rendering step is XML and can be validated and transformed easily.
Yup, except that XSL-FO output is of shitty quality, especially if you are doing heavy math typesetting, and I know at least one pretty successful open access publisher doing this DocBook->TeX workflow for all their puplications.
I have used LaTeX, TeX and ConTeX for years as my only programming language for writing beautiful docs and I think that nowadays there isn't a good alternative if you write technical documents that have math inside.
Today I use XeTeX together with the swiss-knife memoir class and a huge preamble that I have built over the years. XeTeX is modern and lets you write your docs in UTF8 with ease. I have stopped writing a lot of commands by hand cause there are a lot of modern editors out there (TeXShop on the Mac, TeXworks/TeXnicCenter on Windows, Kile and a bunch of others in Linux.)
When you enter the TeX world you cannot go back cause you start to see typographical errors everywhere: wrong kerning, missing ligatures, wrong align in formulas, wrong page dimensions and others. As Don Knuth says: "I can't go to a restaurant and order food because I keep looking at the fonts on the menu."
For my usage, I came to conclusion that HTML is the solution. When I need formulas, I may use TeX, for graphs I'll use Excel most of the time. For pictures Gimp etc. HTML is the glue I now use:
- You can reuse it everywhere, publish it on the web, print it
- It's easier to generate
- You can combine it with code much more easily
- Semantic tags in HTML5 (<article>, <section>) remove a big feature gap with LaTeX
- You can reuse your HTML skills for much more other topics.
I use LaTeX quite a bit, still use it for special goals (resumes, articles), but outside the scientific crowd, I don't think it is the best solution any more. I know the typography is better there than on most other software, but on that I rather wished browsers and HTML got better.
It is quite small and fast, and mostly aimed at integration with other libraries, unlike Hyphenator.js (which comes with a partial DOM library.) An example integration can be seen in the Treesaver library (https://github.com/bramstein/treesaver/tree/hyphenation) where it is used to hyphenate magazine columns.
Nearly all the most beautifully typeset documents I've ever seen have been typeset in TeX. Also, it's probably the only way I can type in a mathematical formula without going crazy.
That said, I never use TeX. It's too much work. Bean.app is more than I need.
I used to work for a Framemaker competitor, Interleaf, which was better at long documents and customizable in Lisp to boot. The longest document i participated working on was 30,000 pages and was successfully published on schedule. But Interleaf is not available now in any meaningful way.
I hate trying to produce anything longer than a couple of pages in Word and get predictable results. But it is often the required document standard in academia those days.
Fortunately I discovered Scrivener, albeit not available on Linux. But I find it a great writing tool without having to code in TeX, which just isn't something i want to do anymore. :)
I very much agree with the sentiment. LaTeX works well and it produces the best technical documents of anything I've seen, but the world could really use a modernized replacement. The syntax is a pain in the ass, the error messages are horrible, and it takes documentation to figure out how to do anything new. If it could be made more user friendly I think something like Tex would be used much more widely as well. (It works with version control, unlike word docs which are hell to manage in group collaboration.)
I feel that the OP misunderstands TeX's virtues: it is a very powerful typesetting system whose macro system happens to be Turing complete. Typesetting is the hard problem and TeX has solved it so well that most people wanting to build a text-driven typesetting system has built on top of TeX rather than trying to replicate it. This is especially true for typesetting equations.
If you try to use TeX as a programming language, you're going to be disappointed, as the OP seems to have been. The macros work well enough for saving typing by making simple substitutions, which is what most people use them for. But using them for anything more complicated is a bit of a black art. Somewhere I read that Leslie Lamport wrote out LaTeX in pseudo-code first and then translated it into macros. Knuth was impressed by what Lamport was able to do with a system which was not meant to be a general-purpose programming language.
In the end, I think Knuth was correct to make TeX's input focused on document entry and not on programming. I've never used it, but LuaTeX seems interesting because I think it's better to use an external language for programming rather than one embedded in a document layout format.
It's good at what it does. We need useful layers on top of it.
We need a simple, hot-key friendly outliner that persists to something very much like docbook. Then you'd transform to TeX when you need something printed, and to html if you want the same content on the web, and to some sort of braile engine if you want blind people to interact with it.
A major obstacle to better document production is the WYSIWYG is a bad but strong meme.
Why I still use TeX? First of all, it still compiles my documents and samples from 1998. Try that in any other equally sophisticated system.
Second, it is the only system where I can expect a constant error rate. No feature is "done in no time", but can be solved in a rather constant time using Google and some TeX knowledge. In other systems, I am usually lost, because most of the stuff has not been tried or is not intended.
Also, it is actually quite fast in batch usage.
If you want to have a look at what can be done with TeX, have a look at the PGF documentation.
Also, don't mistake TeX with LaTeX, there are other TeX environments around that are better in certain regards.
I think TeX notation for maths is still very good, sometimes you just need that bulk to properly handle equations, though finding symbol keywords can be a pain.
I recently released a web editor for Markdown/LaTeX mix (http://notepag.es/introduction) using Showdown/Mathjax. Have found it very useful for quick technical docs (assignments at university primarily). Though it still needs some smoothing between markdown and tex.
WYSIWYG editors are not an example of intuitiveness either, most people don't get the concept of Style in MS Word like editors.
For that, I find the hierarchy macros of Latex much simpler to apprehend as well as lot of goodies: footnotes, references, hyperref, mathematic mode, bibliography management…
Also, and it's blocker for lot of my use cases, Latex is version control friendly. The WYSIWYG editors are not.
Changing fonts may become a PITA and I recommend to use the koma-script classes for that (btw, the whole system of packages and the build system are a mess), but at least people can't use Comic Sans.
If only people would know how to use styles! This is probably the most important thing to know about word processors. Styles make documents consistent and beautiful. Most word processors these days ship with really beautiful and professional styles (not OOo, though). Maybe not as beautiful as TeX, but easily good enough for most applications.
But people don't know about styles, and their documents are ugly.
I've recently taken to MultiMarkdown + HTML5 + CSS3 + MathJAX.
As CSS3 support gets better and libraries like MathJAX brings beautiful math to HTML, I see less and less reason to stick with TeX.
One of the remaining issues I'm struggling with is margins which browsers unfortunately seem to have real problems with.
However, if you can do with just default margins, MultiMarkdown -> HTML in your browser -> PDF works perfectly.
If you were really determined or needed extra features in regard to the PDF generation (as I did with a similarish workflow) you could use something like PrinceXML rather than a browser.
TeX is great for typesetting but it does very little else. It's a nightmare to parse and analyse. The equation language doesn't convey any information about the equation other than it's appearance (eg syntactic scope, semantics). This makes it really hard to build things like search engines or screen readers (screen readers for LaTeX tend to end up saying things like 'sum-symbol subscript x equals zero superscript infinity x subscript one superscript two plus x subscript two superscript two' rather than 'the sum from x = 0 to infinity of x one squared plus x two squared).
I spent months building an equation search engine for Springer's math/science corpus so I've experienced the pain and horror of parsing LaTeX first hand. HTML + Semantic MathML is so much easier to work with. Its easy to parse, it allows the author to easily convey scope and semantic information and it can handle resizable displays. It just needs better tooling (eg a sane macro language which outputs MathML).
ConTeXt Mk II has had solid MathML support for a long time. It's also there albeit still undergoing construction in Mk IV, which is the newer LuaTeX-based rewrite.
I do a lot of math. That makes LaTeX much faster to write than any alternatives. At this point, in math classes, I can take notes in real time. A properly written LaTeX file is also much faster to modify -- if I'm giving a presentation, and I have an arrow between two equations on different lines, when I rearrange things, that arrow keeps pointing between those two things. I can generate LaTeX programmaticly (e.g. tables of results). I can keep it in version control and have sensible differences between versions.
My major problem is that it does not handle animation and video well. Those are increasingly coming to be critical parts of presentations, and are the major thing pushing me towards OO.Presentation or PowerPoint or similar.
I think Tex is wonderful just as it is. It does have a learning curve, like any powerful system, but so does e.g. html+css or any programming language. Emacs is a great editor and I run it with a simple inotify script to get automatic compilation. The error messages could be better, but that too comes with experience; I can almost always tell exacty what is wrong from the error message. Tex is so well suited to the purpose of producing mathematical documents that I really think asking for a modern replacement is like asking for a modern replacement for HTML. If you are not interested in becoming an expert user, go with a front end (the equivalent of frontpage or dreamweaver or similar). For the heaviest users, learning Latex is not a big deal relative to the other arcane knowledge one must acquire to write something worthwhile with it. As others have said, the investment is paid off in beauty, speed, and control.
FWIW, I and my coauthors are writing "Clojure Programming" for O'Reilly using asciidoc[1]. Our source ends up being converted to a beautiful PDF using a post-commit hook that performs a translation from asciidoc -> docbook -> PDF.
I've enjoyed it so much that I'm now using asciidoc for my github readme's and such, and will likely use it for future documentation-generation requirements (e.g. generating PDF and HTML versions of library developer guides and such). For those that need mathematical notation, it appears that asciidoc just uses passthrough blocks of LaTeX math notation (or direct MathML if you're so inclined)[2].
Do you have an example PDF for that? For the average use, TeX is overkill (sometimes OK), but if you need the finest possible typography, TeX yields its power. And then the XSL-FO formatters are pretty fast disappointing.
Not that I can post publicly. It should be available as an O'Reilly Rough Cut soon; if you snag it (or any PDF ebook version of it), you're looking at an asciidoc-sourced PDF.
AFAIK, the vast majority of O'Reilly books pass through docbook at some point (many authors write in docbook directly, some portion of them use asciidoc like us), so if you look at any O'Reilly PDF ebook, chances are good it was generated from docbook (at least as an intermediate format).
Seconded. AsciiDoc is enough like writing a plain-text e-mail that everything but the writing just falls away.
For a little more control, you can feed the generated DocBook to something like Remko's DocBook kit (https://github.com/remko/docbook-kit), which downloads and runs the various document processors for converting to PDF in stages--with gnarly XML config files available for each stage. This can be helpful for trying to match a specific conference template, for instance.
Agreed. I think the stack exchange sites hould just openly state:
"If you ask a questions that harms the ego of any of our mods, your question will be summarily closed. Be advised that our mods identify with the technology at hand, so any criticism of the underlying technology will almost certianly be taken as a personal attack on our mods."
It's a cancer that affects all of the SE forums (and they _are_ forums).
People that suggest this usually don't have experience using Tex. Tex may be hard to learn, but it is the best solution for the problem it is supposed to solve: high quality technical documents. Of course you can create something easier to use, but to achieve the same fine quality you'll need so much control that the system will end up more complicated than Tex.
If you really want Tex quality without much work, one can just use Lyx, a gui application that uses Tex as the backend.
I was an early member of the TeX user's group (TUG) and have been a serious and happy TeX user for 15 years.
I use TeX itself just as Knuth wrote it and rarely have anything to do with LaTeX or any of the other extensions or preprocessors.
The TeX installation I use is ProTeX 1.2, which now is relatively old. From ProTeX 1.2, beyond TeX itself, I make heavy use of three more programs: (1) The screen preview program YAP (yet another previewer). (2) The program DVIPDFM.EXE for converting TeX output files with extension DVI (device independent file) to PDF. (3) The spell checker Aspell.
I type my input into my favorite, general-purpose, programmable editor KEdit. Nearly all my typing for anything goes into KEdit -- blog posts, e-mail, notes on cooking to car and house maintenance, programming in ASP.NET, Visual Basic .NET, C, PL/I, Fortran, Rexx, etc. And I use Aspell for essentially all my spell checking.
Point: My means of input to TeX is just this general purpose text editor. I do a lot of typing, use this editor heavily and have for 25 years, and, thus, have good facility with it. So, I minimize typing into anything else and am pleased that for TeX I can type just into this same text editor. In particular, for entering TeX I want nothing to do with any other tools for typing. I would consider converting to an editor better than KEdit, but I see no candidates.
I have a Ph.D. in applied math, and for me TeX is one of my most important professional tools. Why? A crucial reason is, for typing math TeX is well designed.
Since TeX has high quality in many respects, I also use it for nearly all my higher quality word processing -- letters, foils, technical documentation, business plans, etc.
II. How to Use TeX.
There is a book, Knuth's 'The TeXBook'. It is polished documentation, very carefully written to make first and easy things easy but still contains a lot of detail. Really you need a copy of the book and to read at least the easier parts cover to cover.
In its internal design as software, TeX makes heavy use of the idea of 'macros'. The main idea of the macros is just string substitution. The main use of the macros is just to replace some frequently used long patterns of typing with short patterns.
The macro language is powerful enough that TeX is really a programming language. Yes, the language supports arithmetic, string manipulations, if-then, loops, and reading and writing files.
The language also has an elegant 'architecture' of scope of names. So there is the nested and static scoping of what is typed in and also the nested and dynamic scoping as the macros execute. For this scoping, there is memory management with a push down stack with some enhancements.
So, a good TeX user will write some macros, and I have over 100 that I have used for years and write new ones occasionally. I have macros for tables of contents, automatic numbering of chapters, sections, tables, and figures, cross referencing, bibliographic entries, simple lists, ordered lists, and lists with bullet points, putting TeX annotation on figures, using some of the special math fonts from the AMS (American Mathematical Society), more in memory management, etc.
TeX has a concept 'verbatim' which means to produce output 'just as entered' and that might contain characters such as '$_%\' usually treated in special ways in TeX. I have several macros for verbatim, and some of these are good for listing source code and TeX macros.
To create a new document with TeX, I make use of the windows in Windows: So, I have one window with KEdit with the document I am creating, one window for the screen preview program YAP, and one window to run the TeX program itself. These three windows work well.
So, I type in my document, run TeX, and look at the output in YAP. The process works well.
If there is some tricky TeX usage in my document, then at th...
No single piece of software is everything, and neither is TeX.
It is possible to look at TeX and wish for more.
So, just what is TeX and what is it good for?
The history is clear: For Knuth's series of books, 'The Art of Computer Programming', the publisher Addison-Wesley told Knuth that for his next edition they were going to use an approach to typesetting that would reduce the 'typesetting quality' of the results. So, Knuth wrote TeX so that he could do the 'typesetting' for his books himself and deliver to the publisher 'camera-ready' copy or perhaps just some files.
So, Knuth wrote TeX to let him write his books.
Knuth presented his work to the American Mathematical Society that quickly took TeX seriously. Why? For typing math, TeX is terrific, was much better than anything else, and mostly still is. Otherwise, the typesetting quality is about as high as typesetting gets.
So, TeX is also good for developing camera ready versions of papers in mathematics.
Quickly TeX became the international standard for word processing of more mathematical material in all of the more mathematical fields in science and engineering.
Since then, TeX has been used for the word processing for many books in mathematical fields.
TeX is good for such word processing: TeX was designed for such work and is heavily used for it.
Note: With TeX, Knuth was essentially looking backwards in time, not forward. So, he was writing software to automate, with high quality, what was old and solid but slow and expensive in manual typesetting for mathematics and to be printed on paper. So, he was not trying to do all of word processing, graphical design, interactive user interface, and software development for the future of information, computing, the Web, and civilization.
Notice the typesetting and 'graphical design' in Knuth's 'The Art of Computing' and 'The TeXBook' and in papers with a lot of mathematics:
(1) There isn't a lot of color; mostly it's just black and white.
(2) There fonts are not 'stylish' like can find in printed advertising.
(3) There are only a few tables and figures, and the figures are mostly simple line drawings, X-Y graphs, or photographs.
(4) The output is to be on paper and not 'interactive' or continually updated. That output can also be converted to PDF and still not be interactive.
(5) Typically the writing is by no more than a few authors so that the techniques for coordinating the work of many people on one large software development project are not relevant.
Net, the emphasis is on the technical content and not the typography, graphical design, GUIs, or large work groups.
So, now we know what TeX is good for.
IV. Warnings.
For the math, be well advised to stay with just Knuth's math fonts standard in TeX and the AMS fonts and symbols. Once you are staying with these math fonts, for the text just stay with Knuth's Computer Modern fonts that are standard in TeX and work well with the math fonts.
For developing your own high quality math fonts for TeX, that'd be a LOT of work. For using fonts for text other than Knuth's standard Computer Modern, it would be a lot of work to get them to work well with Knuth's math fonts.
If you are not doing math, then you can work to use fonts Helvetica, Bookman, Century School Book, etc. for your text, but then there will be some question just why you are using TeX.
If you are developing a Web page, then use HTML and whatever, maybe ASP.NET, that helps writing HTML. TeX and HTML have very different purposes.
If, compared with TeX, you want a lot more or something very different, then you will likely run into problems from limitations from the original intentions of TeX.
If you want something as good as TeX where TeX is good plus a lot more, then don't hold your breath while waiting for it.
If you want to write a better TeX yourself, then start with Knuth's voluminous, exemplary, polished, very finely detailed documentation in volumes A-E of 'Computers and Typesetting'. After reading ...
Actually, I'd argue that HTML had a very similar goal to TeX with a very different philosophy. That goal was purely the sharing of information. Some early browsers even had postscript interpreters so you could link to papers and view them in the browser. The first website at SLAC (first site in the US) was purely meant to be a gateway to the SPIRES database.
I guess what I'm trying to say is that their histories are interwoven, and despite being different technologies, they shared a common goal and worked together. It's possible philosophy of what a web browser is probably led to their divergence more than anything.
I've suspected that Tim Berners-Lee knew TeX before he did HTML. That he was a physicist in computing at CERN means that he had to have seen TeX.
I'd say that the main difference is that TeX was looking backwards and HTML, forwards. Again, TeX was trying to computerize old, stable, slow, expensive, high quality manual typesetting for math, and HTML, at least now, is on the way to being the main way people view nearly all information and interact with computers. The emphasis on the 'typographic quality' of the results is very different: TeX goes for the highest quality, and HTML is to be quick and dirty.
Yes, both had smaller beginnings: For TeX, Knuth wanted to write his books. For HTML, Berners-Lee wanted a physics newsletter.
At this point there is a huge difference: TeX is solidly frozen, and HTML continues with changes as fast as Jeff Jaffe and the rest of computing can implement,
In the future, sure, HTML could replace TeX. For the very high quality paragraph setting, there's no fundamental reason HTML could not specify and implement that. For the math, similarly. There does need to be an 'executing language' (TeX is a programming language, maybe Turing machine equivalent, and not just static text), but JavaScript might suffice.
A big advantage would be that HTML now knows about all the characters in all the languages.
But such high interest in math is likely in conflict with reality!
126 comments
[ 2.7 ms ] story [ 218 ms ] threadMathematics doesn't change as frequently as desktop publishing, so it's a good bet that the TeX (e.g. $\int_0^1 \tau \, d\tau$) is going to be around as long as people talk math online.
That said, I think there are much easier-to-use and less error-prone desktop publishing tools (e.g. Scribus) for less math-heavy domains, like magazine layout.
TeX, for me, tends to be articles, reports, and documents that I expect to use the same format again and again (or the format is provided, such as from IEEE).
The answer is not to find a TeX alternative. This will not be possible in Academia for a very long time. The answer is for someone to plunk down a million dollars to hire some full-time developers to fix it. Honestly, the TeX language is wonderful; it's the editors which are terrible. A TeX editor should...
[] seamlessly hide the compilation process
[] feature a modern debugging environment
[] make 99% of commands (including everything you can do in MS Word) discoverable within the editor, rather than sending the user to the internet or some pdf guide, and
[] robustly handle all modern image types
...without becoming an unstable WYSIWYG hybrid like LyX. The only thing about the language itself that might need to be changed is some standardization of common packages. I shouldn't need to download anything to get appendices and sub-figures to behave sensibly.
The amount of professor, post-doc, and grad student time wasted on TeX is staggering, and easily justifies paying for an overhaul...if only the government or some benefactor would step up.
The features you mention would be needed to put it in front of less geeky users but are far from the core issues. I'd love to see a language with better flow control and abstraction features put on top of the Tex engine that indeed produces beautiful output. Maybe LuaTex will be that.
LuaTeX does seem to be experimenting with some improvements in these areas though.
As for LuaTex I wasn't able to find any examples of actual markup written in it. I would expect that for the actual markup you'd want a language with a bigger and more flexible grammar so you could build DSLs. Ruby seems particularly good at that kind of stuff, but I'm biased there.
Incidentally I went looking for what pure TeX actually looks like as most people say TeX when they really mean LaTeX. Here's Knuth's TAOCP Volume I errata:
http://www-cs-faculty.stanford.edu/~uno/err1.textxt
Talk about Perl being line noise... I wonder if Knuth has ended up being the only person to actually write pure TeX.
My experience of using LaTeX compared to WYSIWYG is that it's easier to focus on the text in the editor instead of fighting with the UI interface but it then requires some chasing around package bugs and compile errors. In total it's clearly a net positive for me.
Writing pure TeX would seem to push the tradeoff quite a bit, having so much distracting stuff around the text that requires a totally different mindset than the text being written. It was probably designed for a world where typesetting was done as a final step before publication, potentially by someone else.
And no, Knuth is definitely not the only one using plain TeX. Yes, it is a niche.
Like a lot of things, if you're handed a finished product, it looks like random noise. If you could watch it being written, it pretty much makes perfect sense. It's a hideous syntax, and sometimes I still wake up in a cold sweat with long strings of '#' signs running taunting me from the corner of my eyes. But I can't say it was all that daunting to write, although I suspect my TeX code was highly non-idiomatic.
Ugh, and fonts and character sets. Do you still have to put in magic incantations like
to get working hyphenation with wacky characters such as æ, ø, and å?LuaTeX does seem to be experimenting with some improvements in these areas though.
About when I stopped paying attention to TeX and LaTeX many years ago (2002-ish?), there was some effort under way to rewrite all of TeX in Java. Did that go anywhere?
I'd say no. See http://extex.org/
OK. (As I said elsewhere...) When I said the language was fine, I meant that the language as a means for the user expressing an idea was fine, not that there aren't problems at a deeper level with the language. I'm a physicists, not a programmer. Nevertheless, the limitations of the given language could be massively ameliorated with a powerful editor.
>At least in LaTeX...
Sorry, I wasn't clear. I wasn't distinguishing between TeX and LaTeX. Everyone I know in Academia used LaTeX. I was just using TeX as a catch all to distinguish from other typesetting options.
> The features you mention would be needed to put it in front of less geeky users...
There's no reason I should have to go on the internet to find out how to use columns. Or sub figures. Or appendices. It should just work.
I'm not a less-geeky user who needs to be coddled (unless by "less geeky" you mean 99.99% of users). I just want to write up my research, and I don't want to have to think about typesetting theory.
I agree that those things should be easy to find. What I meant is that for the current user base those are nice to have but not essential. I have long since accumulated enough examples of the type of documents I write that I can quickly do the basic things just by copying them from somewhere else. I assume that people that write scientific articles already have working examples of two columns, sub figures and appendices that they just copy when they do a new article.
If you wanted to make LaTeX much more widely use then you'd need all the goodies you mentioned. But to even make those possible the environment under them needs to be much more consistent and robust than it is now. Something like LyX could work well if manual intervention in the typesetting wasn't so needed.
There are several editors for Tex&co that do on-the-fly compilation. Have you seen Kile's two panelled interface, for example?
feature a modern debugging environment
Well, this is a problem with the language: macro expansion is notoriously tricky to debug. I'd like to see work done on a static analyser for Tex.
robustly handle all modern image types
This is not a problem I have ever had. What are you thinking of? The only file types needing special handling in Luatex are Postscript and SVG; both convert painlessly to PDF, and the converter can be run automatically by Luatex.
Yes, I have two-panelled TeXworks open as we type. It's not seamless because I had to spend an hour fussing with it to set it up with my LaTeX distribution, and another 2 hours dealing with it when I needed to move from pdflatex to regular latex because the journal I was submitting to used some bizarre packages.
It's not that you can't eventually get it working, it's that you ever have to think about it at all.
>Well, this is a problem with the language: macro expansion is notoriously tricky to debug. I'd like to see work done on a static analyser for Tex.
Fine. When I said that the language was fine, I meant that the language as a means for the user expressing an idea was fine, not that there aren't problems at a deeper level with the language. I'm a physicists, not a programmer. Still, I can't imagine the debugging situation can't be greatly improved with the given language if actual people were employed to fix it.
>This is not a problem I have ever had. What are you thinking of? The only file types needing special handling in Luatex are Postscript and SVG; both convert painlessly to PDF, and the converter can be run automatically by Luatex.
I have had many, many headaches with getting images into a document. Last month, I spent 4 hours trying to solve one particular problem. Yes, maybe if I were deeply familiar with all the technical stuff surrounding TeX's relationship with images, I could have figured it out.
It should just work. I should type \includeimage{filename}, and it should just work.
[http://sydney.edu.au/engineering/it/~jeff/nonpareil/]
TeXmacs is a true WYSIWYG scientific word processor. It's not a TeX/LaTeX GUI front-end. Rather, it has its own typesetter that produces quality comparable to TeX in real-time as you type.
TeX has a huge ecosystem built around it (Latex, Contex, many others). It's going to be very difficult replacing that.
Better build on what exists rather than replace it.
ftp://ftp.texmacs.org/pub/TeXmacs/macosx/qt/TeXmacs.dmg
Would it really take a $1M dollars to achieve a useful enough fix for TeX editing? And a better question, "is there are market for such an editor?"
What? What is the financial incentive of fixing ANY of the classical open source software?
Assuming you're actually interested in some kind of discussion rather than just trolling, see http://papers.ssrn.com/sol3/papers.cfm?abstract_id=908946, the same reference that's provided on the Wikipedia page for TeX if you'd bothered wondering where I got the information from, rather than just replying 'no' without any research.
The quote is: "TeX was designed with two main goals in mind: to allow anybody to produce high-quality books using a reasonable amount of effort, and to provide a system that would give exactly the same results on all computers, now and in the future."
A simple Google search for the statement above will reveal it's in almost every document ever produced on the topic of TeX, which suggests it may have been written by Donald Knuth himself.
And while many attempts have been made to flatten that curve with various tools, I'm hard pressed to find a compelling competitor to Microsoft Word or OpenOffice in terms of ease-of-use.
People in general are far more interested in the final result than the "beauty" of the steps to produce that result, especially when it comes to the written word.
Money have nothing to do with open source. Sure they help, but if a project is not followed it's not because of money incentives.
> LyX is a document processor that encourages an approach to writing based on the structure of your documents (WYSIWYM) and not simply their appearance (WYSIWYG).
I believe that description is aimed at former MS Word users who don't even know the WYM/G distinction exists, not as a definitive membership claim by LyX.
Personally, I don't want my editor to do anything with my source code except color code it, like turning the source code into into manipulable objects (or whatever you call that).
Honest question: What makes you say that? I've never completely understood why TeX is considered the best at handling mathematical notation. Personally, I've been very happy with the equation editor in Word 2010. I'll certainly acknowledge that there's likely better solutions than Word 2010, but before I invest substantial time learning something like TeX I'd like to understand exactly what it is I'm missing out on.
When people talk about TeX's mathematical typesetting abilities, they are often (from personal experience, as a math major currently in school) referring to having to typeset documents with many pages and upwards of 25% being math. It's much easier for me to type \int_0^\pi \sin (x) dx than it is for me to go click-click-click-click in Word. But besides that, when you're writing proofs, for example, and you have to keep referring to the same symbol, say sigma, over and over again, in LaTeX, you would simply write $\sigma$, but in Word, you would have to do Insert->Symbol or some nonsense. Several more seconds wasted, and that adds up when you have 100 occurrences of the character sigma in your document.
TeX has a learning curve, but it's not even actually that steep. Within 4 days of starting to use it I was already starting to grok it.
I think that a new generation of TeX based applications will show up in the next 10 years.
Edit: some links:
http://luatex.org/ - official site
http://en.wikipedia.org/wiki/LuaTeX - wikipedia
http://wiki.contextgarden.net/LuaTeX - LuaTeX is now also the base of ConTeXt, a LaTeX alternative
One thing I would like to see is proper static analysis tools for Luatex. Lua has tools like https://github.com/fab13n/metalua/tree/master/src/samples/me... but there's nothing of comparable sophistication for Tex, let alone code combining the two, which makes debugging needlessly hard.
With respect to catcode-changing code, you can model its possible execution paths: while you can construct example Tex code where you can't infer anything past this point without having complete information from before, in practice with, say a package, you do have example documents which the package is meant to work with, and you can use that in the static analysis.
I've thought about this a fair bit, at least in the context of typical Plain Tex, but not written much code. I should try and enough time for a proof of concept: there's a lot that could be built on it.
Also, DocBook documents can be validated automatically using DTDs or RelaxNG schema. (Yes, XML is full of buzzword bingo :).)
[1] Equations can be typeset with MathML, but since most software only supports presentation MathML this is not ideal.
For Natural Language Processing for the Working Programmer, we use the <oXygen/> XML editor, which really takes the pain out of writing DocBook documentation. It provides WYSIWYG mode that also renders inline or xincluded XML, such as SVG and MathML. I rarely switch back to the non-WYSIWYG mode, unless I want to reorder some elements quickly.
Using TeX to do the final typesetting in a DocBook workflow is quite old-fashioned. For years, I have used the XSL-FO stylesheet to create XSL-FO output. You can pass this to an XSL-FO typesetter, such as Apache FOP or RenderX.
This workflow has several advantages:
* You can easily tweak output by overriding templates.
* Commonly-used FO renderers render SVG and MathML. You can use one vector graphics format to create XHTML, ePub, and PDF/print output.
* Each step and output, except for the rendering step is XML and can be validated and transformed easily.
Today I use XeTeX together with the swiss-knife memoir class and a huge preamble that I have built over the years. XeTeX is modern and lets you write your docs in UTF8 with ease. I have stopped writing a lot of commands by hand cause there are a lot of modern editors out there (TeXShop on the Mac, TeXworks/TeXnicCenter on Windows, Kile and a bunch of others in Linux.)
When you enter the TeX world you cannot go back cause you start to see typographical errors everywhere: wrong kerning, missing ligatures, wrong align in formulas, wrong page dimensions and others. As Don Knuth says: "I can't go to a restaurant and order food because I keep looking at the fonts on the menu."
The beauty of LaTeX (XeLaTeX in this case): http://nitens.org/taraborelli/latex
- You can reuse it everywhere, publish it on the web, print it
- It's easier to generate
- You can combine it with code much more easily
- Semantic tags in HTML5 (<article>, <section>) remove a big feature gap with LaTeX
- You can reuse your HTML skills for much more other topics.
I use LaTeX quite a bit, still use it for special goals (resumes, articles), but outside the scientific crowd, I don't think it is the best solution any more. I know the typography is better there than on most other software, but on that I rather wished browsers and HTML got better.
And example in action http://www.bramstein.com/projects/typeset/flatland/
https://github.com/bramstein/Hypher
It is quite small and fast, and mostly aimed at integration with other libraries, unlike Hyphenator.js (which comes with a partial DOM library.) An example integration can be seen in the Treesaver library (https://github.com/bramstein/treesaver/tree/hyphenation) where it is used to hyphenate magazine columns.
That said, I never use TeX. It's too much work. Bean.app is more than I need.
WYSIWYW >> WYSIWYG
modern alternatives?
nothing i can think of.
I hate trying to produce anything longer than a couple of pages in Word and get predictable results. But it is often the required document standard in academia those days.
Fortunately I discovered Scrivener, albeit not available on Linux. But I find it a great writing tool without having to code in TeX, which just isn't something i want to do anymore. :)
TBH, i've never used framemaker and their site makes me want to give it a try. TODO: give it a try.
If you try to use TeX as a programming language, you're going to be disappointed, as the OP seems to have been. The macros work well enough for saving typing by making simple substitutions, which is what most people use them for. But using them for anything more complicated is a bit of a black art. Somewhere I read that Leslie Lamport wrote out LaTeX in pseudo-code first and then translated it into macros. Knuth was impressed by what Lamport was able to do with a system which was not meant to be a general-purpose programming language.
In the end, I think Knuth was correct to make TeX's input focused on document entry and not on programming. I've never used it, but LuaTeX seems interesting because I think it's better to use an external language for programming rather than one embedded in a document layout format.
We need a simple, hot-key friendly outliner that persists to something very much like docbook. Then you'd transform to TeX when you need something printed, and to html if you want the same content on the web, and to some sort of braile engine if you want blind people to interact with it.
A major obstacle to better document production is the WYSIWYG is a bad but strong meme.
Second, it is the only system where I can expect a constant error rate. No feature is "done in no time", but can be solved in a rather constant time using Google and some TeX knowledge. In other systems, I am usually lost, because most of the stuff has not been tried or is not intended.
Also, it is actually quite fast in batch usage.
If you want to have a look at what can be done with TeX, have a look at the PGF documentation.
Also, don't mistake TeX with LaTeX, there are other TeX environments around that are better in certain regards.
I recently released a web editor for Markdown/LaTeX mix (http://notepag.es/introduction) using Showdown/Mathjax. Have found it very useful for quick technical docs (assignments at university primarily). Though it still needs some smoothing between markdown and tex.
For that, I find the hierarchy macros of Latex much simpler to apprehend as well as lot of goodies: footnotes, references, hyperref, mathematic mode, bibliography management…
Also, and it's blocker for lot of my use cases, Latex is version control friendly. The WYSIWYG editors are not.
Changing fonts may become a PITA and I recommend to use the koma-script classes for that (btw, the whole system of packages and the build system are a mess), but at least people can't use Comic Sans.
But people don't know about styles, and their documents are ugly.
As CSS3 support gets better and libraries like MathJAX brings beautiful math to HTML, I see less and less reason to stick with TeX.
One of the remaining issues I'm struggling with is margins which browsers unfortunately seem to have real problems with. However, if you can do with just default margins, MultiMarkdown -> HTML in your browser -> PDF works perfectly.
I spent months building an equation search engine for Springer's math/science corpus so I've experienced the pain and horror of parsing LaTeX first hand. HTML + Semantic MathML is so much easier to work with. Its easy to parse, it allows the author to easily convey scope and semantic information and it can handle resizable displays. It just needs better tooling (eg a sane macro language which outputs MathML).
My major problem is that it does not handle animation and video well. Those are increasingly coming to be critical parts of presentations, and are the major thing pushing me towards OO.Presentation or PowerPoint or similar.
I've enjoyed it so much that I'm now using asciidoc for my github readme's and such, and will likely use it for future documentation-generation requirements (e.g. generating PDF and HTML versions of library developer guides and such). For those that need mathematical notation, it appears that asciidoc just uses passthrough blocks of LaTeX math notation (or direct MathML if you're so inclined)[2].
[1] http://www.methods.co.nz/asciidoc
[2] http://www.methods.co.nz/asciidoc/userguide.html#X78
AFAIK, the vast majority of O'Reilly books pass through docbook at some point (many authors write in docbook directly, some portion of them use asciidoc like us), so if you look at any O'Reilly PDF ebook, chances are good it was generated from docbook (at least as an intermediate format).
For a little more control, you can feed the generated DocBook to something like Remko's DocBook kit (https://github.com/remko/docbook-kit), which downloads and runs the various document processors for converting to PDF in stages--with gnarly XML config files available for each stage. This can be helpful for trying to match a specific conference template, for instance.
I have written a few books using LaTex: in my experience way nicer than using a word processor.
"If you ask a questions that harms the ego of any of our mods, your question will be summarily closed. Be advised that our mods identify with the technology at hand, so any criticism of the underlying technology will almost certianly be taken as a personal attack on our mods."
It's a cancer that affects all of the SE forums (and they _are_ forums).
If you really want Tex quality without much work, one can just use Lyx, a gui application that uses Tex as the backend.
I can respond here in sections:
I. My Background.
II. How to Use TeX.
III. What TeX is Good for.
IV. Warnings.
below:
I. My Background.
I was an early member of the TeX user's group (TUG) and have been a serious and happy TeX user for 15 years.
I use TeX itself just as Knuth wrote it and rarely have anything to do with LaTeX or any of the other extensions or preprocessors.
The TeX installation I use is ProTeX 1.2, which now is relatively old. From ProTeX 1.2, beyond TeX itself, I make heavy use of three more programs: (1) The screen preview program YAP (yet another previewer). (2) The program DVIPDFM.EXE for converting TeX output files with extension DVI (device independent file) to PDF. (3) The spell checker Aspell.
I type my input into my favorite, general-purpose, programmable editor KEdit. Nearly all my typing for anything goes into KEdit -- blog posts, e-mail, notes on cooking to car and house maintenance, programming in ASP.NET, Visual Basic .NET, C, PL/I, Fortran, Rexx, etc. And I use Aspell for essentially all my spell checking.
Point: My means of input to TeX is just this general purpose text editor. I do a lot of typing, use this editor heavily and have for 25 years, and, thus, have good facility with it. So, I minimize typing into anything else and am pleased that for TeX I can type just into this same text editor. In particular, for entering TeX I want nothing to do with any other tools for typing. I would consider converting to an editor better than KEdit, but I see no candidates.
I have a Ph.D. in applied math, and for me TeX is one of my most important professional tools. Why? A crucial reason is, for typing math TeX is well designed.
Since TeX has high quality in many respects, I also use it for nearly all my higher quality word processing -- letters, foils, technical documentation, business plans, etc.
II. How to Use TeX.
There is a book, Knuth's 'The TeXBook'. It is polished documentation, very carefully written to make first and easy things easy but still contains a lot of detail. Really you need a copy of the book and to read at least the easier parts cover to cover.
In its internal design as software, TeX makes heavy use of the idea of 'macros'. The main idea of the macros is just string substitution. The main use of the macros is just to replace some frequently used long patterns of typing with short patterns.
The macro language is powerful enough that TeX is really a programming language. Yes, the language supports arithmetic, string manipulations, if-then, loops, and reading and writing files.
The language also has an elegant 'architecture' of scope of names. So there is the nested and static scoping of what is typed in and also the nested and dynamic scoping as the macros execute. For this scoping, there is memory management with a push down stack with some enhancements.
So, a good TeX user will write some macros, and I have over 100 that I have used for years and write new ones occasionally. I have macros for tables of contents, automatic numbering of chapters, sections, tables, and figures, cross referencing, bibliographic entries, simple lists, ordered lists, and lists with bullet points, putting TeX annotation on figures, using some of the special math fonts from the AMS (American Mathematical Society), more in memory management, etc.
TeX has a concept 'verbatim' which means to produce output 'just as entered' and that might contain characters such as '$_%\' usually treated in special ways in TeX. I have several macros for verbatim, and some of these are good for listing source code and TeX macros.
To create a new document with TeX, I make use of the windows in Windows: So, I have one window with KEdit with the document I am creating, one window for the screen preview program YAP, and one window to run the TeX program itself. These three windows work well.
So, I type in my document, run TeX, and look at the output in YAP. The process works well.
If there is some tricky TeX usage in my document, then at th...
III. What TeX is Good for.
No single piece of software is everything, and neither is TeX.
It is possible to look at TeX and wish for more.
So, just what is TeX and what is it good for?
The history is clear: For Knuth's series of books, 'The Art of Computer Programming', the publisher Addison-Wesley told Knuth that for his next edition they were going to use an approach to typesetting that would reduce the 'typesetting quality' of the results. So, Knuth wrote TeX so that he could do the 'typesetting' for his books himself and deliver to the publisher 'camera-ready' copy or perhaps just some files.
So, Knuth wrote TeX to let him write his books.
Knuth presented his work to the American Mathematical Society that quickly took TeX seriously. Why? For typing math, TeX is terrific, was much better than anything else, and mostly still is. Otherwise, the typesetting quality is about as high as typesetting gets.
So, TeX is also good for developing camera ready versions of papers in mathematics.
Quickly TeX became the international standard for word processing of more mathematical material in all of the more mathematical fields in science and engineering.
Since then, TeX has been used for the word processing for many books in mathematical fields.
TeX is good for such word processing: TeX was designed for such work and is heavily used for it.
Note: With TeX, Knuth was essentially looking backwards in time, not forward. So, he was writing software to automate, with high quality, what was old and solid but slow and expensive in manual typesetting for mathematics and to be printed on paper. So, he was not trying to do all of word processing, graphical design, interactive user interface, and software development for the future of information, computing, the Web, and civilization.
Notice the typesetting and 'graphical design' in Knuth's 'The Art of Computing' and 'The TeXBook' and in papers with a lot of mathematics:
(1) There isn't a lot of color; mostly it's just black and white.
(2) There fonts are not 'stylish' like can find in printed advertising.
(3) There are only a few tables and figures, and the figures are mostly simple line drawings, X-Y graphs, or photographs.
(4) The output is to be on paper and not 'interactive' or continually updated. That output can also be converted to PDF and still not be interactive.
(5) Typically the writing is by no more than a few authors so that the techniques for coordinating the work of many people on one large software development project are not relevant.
Net, the emphasis is on the technical content and not the typography, graphical design, GUIs, or large work groups.
So, now we know what TeX is good for.
IV. Warnings.
For the math, be well advised to stay with just Knuth's math fonts standard in TeX and the AMS fonts and symbols. Once you are staying with these math fonts, for the text just stay with Knuth's Computer Modern fonts that are standard in TeX and work well with the math fonts.
For developing your own high quality math fonts for TeX, that'd be a LOT of work. For using fonts for text other than Knuth's standard Computer Modern, it would be a lot of work to get them to work well with Knuth's math fonts.
If you are not doing math, then you can work to use fonts Helvetica, Bookman, Century School Book, etc. for your text, but then there will be some question just why you are using TeX.
If you are developing a Web page, then use HTML and whatever, maybe ASP.NET, that helps writing HTML. TeX and HTML have very different purposes.
If, compared with TeX, you want a lot more or something very different, then you will likely run into problems from limitations from the original intentions of TeX.
If you want something as good as TeX where TeX is good plus a lot more, then don't hold your breath while waiting for it.
If you want to write a better TeX yourself, then start with Knuth's voluminous, exemplary, polished, very finely detailed documentation in volumes A-E of 'Computers and Typesetting'. After reading ...
http://en.wikipedia.org/wiki/Stanford_Physics_Information_Re...
I guess what I'm trying to say is that their histories are interwoven, and despite being different technologies, they shared a common goal and worked together. It's possible philosophy of what a web browser is probably led to their divergence more than anything.
I'd say that the main difference is that TeX was looking backwards and HTML, forwards. Again, TeX was trying to computerize old, stable, slow, expensive, high quality manual typesetting for math, and HTML, at least now, is on the way to being the main way people view nearly all information and interact with computers. The emphasis on the 'typographic quality' of the results is very different: TeX goes for the highest quality, and HTML is to be quick and dirty.
Yes, both had smaller beginnings: For TeX, Knuth wanted to write his books. For HTML, Berners-Lee wanted a physics newsletter.
At this point there is a huge difference: TeX is solidly frozen, and HTML continues with changes as fast as Jeff Jaffe and the rest of computing can implement,
In the future, sure, HTML could replace TeX. For the very high quality paragraph setting, there's no fundamental reason HTML could not specify and implement that. For the math, similarly. There does need to be an 'executing language' (TeX is a programming language, maybe Turing machine equivalent, and not just static text), but JavaScript might suffice.
A big advantage would be that HTML now knows about all the characters in all the languages.
But such high interest in math is likely in conflict with reality!