Please, no. I've written thousands of pages in LaTeX, and it's far more usable than most tools IF you can resist trying to overcomplicate things. For example, want a diagram? If you do it in xfig/inkscape/omnigraffle, you'll have little pain. If you decide to get clever and try to programmatically do it via tikz or some other package, you've opened up a world of pain.

The level of pain experienced by LaTeX users in my experience is more often poor choices made by the users who create unnecessary complexity. Avoid that, and it's a pretty reasonable model to work in.

I love LaTeX for writing math-heavy documents, but as soon as it involves figures, images or pseudo-code it is quite horrible compared to Word.

For me, the ideal solution would be something WordPerfect but with ability to type LaTeX equations.

I want to be able to manipulate the "code" of the document but with a nice UI with real-time preview that helps me placing and formatting figures, text boxes for pseudo-code etc.

Sure! But the same is true of Word, or CSS for that matter. Any layout system is going to run into this issue: since the space of possible layouts is so big, it's almost inevitable that users will decide they want something that isn't well supported by the system. If the system is sufficiently powerful, they will be able to achieve their desired layout, at the cost of wrecking usability / maintainability.

MS word is also perfectly usable, as long as you don't try to do anything weird (as the example in the article illustrates!).

Sure, but it's probably possible to design something better too, that would let users do more complex things without dying. Maybe you don't need it for your usage, but this seems a bit like a Blub problem[1].

Keep the same core design of compiled source code files, but there are many things that don't make any sense. As just one example having to use the `\makeatletter` / `\makeatother` hack to change the visibility of macros seems completely insane to me when we have had languages with fine-grained visibility control for decades. This is one of the many things that make using many packages together needlessly hard.

[1] http://www.paulgraham.com/avg.html

That's a big if. One has to learn how to not over-complicate. Exactly the reason why latex has usability issues in many cases.

Seems like a step backwards. One of the great things about Latex (or raw tex) is that you can simply type it into a buffer. No need to mouse around to select text or anything like that. Hard to find anything really more usable than that.

Back in 1984 I wrote a small WYSIWYG editor at PARC that outputted primitive LaTex. Fortunately LaTeX was quite early stage and that little project went nowhere. But one of the lessons was that semantic markup was much easier to do by just typing rather than trying to infer it context, while -driven changes meant people usually just changed font and size and erased the semantic anyway. This has been borne out by Word.

Edit: added bit starting “But one of...” to explain my comment

.title My concerns with the point made by Hacker News user gumby

If you were to write something like HTML, how would you do so in a manner that didn't involve raw text? Sure it might be [emph shown] in a marked up way, but then doesn't your LaTeX editor do this?

And if your editor does this, how can you be sure that the new markup language for documents are not, in fact, superior in readability and expressiveness to LaTeX?

I mean, the made up formatting I tried to show in this comment is more readable and extendable than LaTeX (in my eyes, anyway), but it is still raw text.

The article was Word vs a markup language like latex. I find the latter simpler to use.

Html wasn’t mentioned in the article but it is ok. I find latex easier and the result more attractive.

My editor doesn’t do any highlighting or anything like that. It does have syntax-dependent motion commands, which work better with LT than html.

> One of the great things about Latex (or raw tex) is that you can simply type it into a buffer. No need to mouse around to select text or anything like that. Hard to find anything really more usable than that.

More usable for you perhaps, but certainly not for me.

I think the grandparent is talking about a better WYGIWYG language, like HTML generally is. You can (and most people, at least on HN, probably do) edit HTML in a buffer.

Edit: changed parent → grandparent

What do you mean? Writing a document in html is not much different than doing it in LaTeX.

Yes, that's exactly what I mean, I was replying to

> One of the great things about Latex (or raw tex) is that you can simply type it into a buffer.

and pointing out it also applies to HTML.

I clarified my comment.

I keep my custom commands and styles in a separate tex file that I `\input` into the document file I am working on. The document file usually looks very clean with this method. It feels very much like HTML and CSS to me.

Lightweight text markup (Asciidoc or Pandoc) seem to be getting there.

Perhaps, although personally I prefer latex, because at its best it is somewhat self describing:

\chapter{Animals}

instead of

== Animals

or should that be:

=== Animals

I think an xml or html like approach is better:

<chapter>Animals</chapter>

One of the big issue is modal states for structure or styling.

I've often found trouble in latex because you are in some state that you didn't expect and somehow have to get out of.

Nested XML would hopefully be more obvious about what your state is.

Docbook probably got this right, but it was too verbose for most.

True, it is more self-describing and that has some real benefits. What I typically found was that I didn't like writing in LaTeX for the same reason I don't like writing in HTML -- the syntax occupies more space and so it gets more attention, which pulls me away from the thoughts I was actually trying to write.

\chapter, or should that be \section, or should that be \subsection, or \subsubsection etc, depending on which layout you are using. \part maybe?

Good point, https://en.wikibooks.org/wiki/LaTeX/Document_Structure#Secti... wikibooks latex guide suggests \chapter is level 0, which gives "=" (1 equals sign),

But then surely the h1 document title should be above that, which would be "=" (1), so a chapter is below at "==" (2)?

\part apparently is -1 in latex, which would be seem to be odd.

But document title isn't part of the latex sectioning hierarchy...

Given that there is a document title, part and chapter, chapter could maybe "===" (3) or maybe "==" (2) if we're not using parts or we don't consider the document title.

I think anyway?

It's unfortunate that the creators of latex did not follow the HTML heading rules better. (despite latex pre-dating html of course)

:-)

HTML is the answer.

- Can be opened on every device

- Content can be embedded in base64, so you only have to share one file

- Dynamic layout, so it looks nice even on phones

- Searchable, standardized XML structure

- Great customizability through CSS and optionally JS

- Can be written in markdown

- Basic support for page breaks, if you really must print the document (IA Writer already has some HTML-Templates meant for printing.)

The only downside I can think of, is that you can't lock the document to prevent edits.

However, conventions are what keeps PDF alive. Until the academic world realizes that they can do better than Latex, we're stuck.

I have seen here similar opinions about HTML vs. PDF in a few other threads.

However, this is a matter of personal opinion and I am certain that nobody knows how many people prefer PDF and how many prefer HTML.

I strongly prefer PDF for any non-ephemeral content that I might need to read twice or more times, so I hate anyone who forces me to read an HTML user manual or scientific paper, instead of providing PDF documents for them.

Even if HTML can be opened on every device, it also looks different on every device and it looks bad on those that are different from the one used by the developer (unless the HTML pages have been carefully designed to look good on various devices, which seldom happens).

Even on a small smartphone screen, I prefer a good PDF viewer with a good user interface that makes it easy to zoom & pan, instead of the feeble attempts of the Web browsers to reformat the text, which make very difficult the navigation through complex technical documents.

"Print" support is horrible for HTML. Modern Web pages, which use a lot of JS, are almost always mutilated when you use the "Print" command in both Chrome and Firefox, even if they display the pages correctly outside the "Print" mode.

To make some counterpoints:

- On any device as long as it runs a browser

- You can write TeX documents as a single file with ease

- Phones are not designed for reading, so dynamic layout or not, it will still be inferior to finely typeset document

- With care so can be TeX; carelessly written HTML docs will be just as bad as anything else

- CSS is a pretty poor layout tool; typographically speaking, CSS is very subpar to TeX's capabilities, using JS... well how much better is it than just using macros in TeX/LaTeX?

- markdown is fine for simple stuff but for highly complicated documents involving lots of generated tables, lists, and mathematics it is almost like having no tool at all;

- but many people DO like printed documents (I rarely can stand reading anything but basic technical stuff on screen, say language reference is fine but anything that requires thinking, has to be printed);

TeX is not locked to pdf in any way (it is not even it's native format). HTML's support for formulas is primitive (the only decent tools available are ... based on TeX). Academic world is not entirely uniform either but while I do think LaTeX is not ideal (TeX is though), I simply shudder when I think about Word or any MS or Adobe products.

> Phones are not designed for reading, so dynamic layout or not, it will still be inferior to finely typeset document

Personally, I find my phone to be my favorite medium to read prose on, not inferior to anything – including printed paper, which I never use if I can help it. It works for books and most webpages, but PDFs are a disaster.

My second preference is my laptop. Its screen is big enough to make reading PDFs an acceptable experience, but not a great one. When viewing at an optimal zoom level for me, there's almost enough vertical space to fit an entire normally-sized page… but not quite. Which means I have to scroll. In the common case that the paper has two columns, I have to scroll down to read the bottom left of the page, then back up to read the top right, then back down to read the bottom right.

Oh, and it's always great hunting for the figures in a paper, because of course they have to be nicely lined up in a corner of a page, even if that leaves them far from the text that references them. It's a compromise that makes total sense in print, but feels silly on a screen.

So TeX's output is good in print but awkward on a screen. (It may not be limited to PDF, but I'm pretty sure all its output formats assume a fixed page size.) Meanwhile, HTML is good on a screen, but I agree that it's awkward in print.

What we need is a format that's good at both, and that doesn't currently exist.

Try reading pdf's using Tofu.app. Lexcyle's Stanza had the same functionality, but Amazon killed it. I don't know if there are any Unix or Windows programs with the same functionality.

If you are creating pdf's, you are not limited to portrait/a4/letter, you can specify landscape/size of your laptop screen and use newspaper columns.

Counter counter point: I pretty regularly read pdf docs on my phone, and it’s a horrible experience.

I went so far as to write a script that downloads the Tex source of a paper from arxiv, changes up the paper size to match my phone screen, and recompiles the paper. It’s ok for text-heavy documents, but doesn’t work well for most figures. And most of my field does not post preprints (or use LaTeX at all).

For me the ideal solution would be something like org mode -> html output. I think the main gap that isn’t really addressed by any tool I’ve seen is reference management

Well, the entire idea of SGML, on which HTML is based, is to use a custom markup vocabulary adequate for your project (this is distinctively more pronounced in SGML which originally always had to have a DTD than it is in XML with its various additional, optional schema mechanisms targeted at enterprise use). However, HTML is almost the same markup vocabulary for casual academic publishing at CERN it was 30 years ago; with everything around it (CSS, JS) having changed beyond recognition. It is understandable that once JS was out there (plus div and span generic containers), evolving HTML wasn't essential as you could always fallback to using JS. Styling factored out into an ever-growing ad-hoc language with low barriers to changes called CSS further contributed to the fossilization of HTML, yet the fixation towards a 1990s vision of HTML can't entirely be explained by these two factors alone. My guess is that HTML was locked in W3C's long-standing, failed attempt to replace SGML by its subset XML as meta-syntax. With WHATWG's HTML5, parsing was specified in a procedural way, and self-contained in the HTML spec itself rather than in reference to SGML or XML. The way the HTML5 grammar was presented, though, could only lead to further hindrance of its evolution since Ian Hickson captured only the result grammar of HTML4, but not its original construction rules and principles. For example, in [1] I make the point that

> By recovering HTML's original parsing rules from HTML5's specification text, we conclude that HTML5's parsing rules are represented adequately, and more succinctly, since avoiding redundantly specifying p-terminating elements.

> This interpretation is also supported by the fact that for the HTML5.1 specification update (vs. HTML5), the new details, figcaption, figure and menu elements (which are flow-only elements) but not the new picture element (which can also be used in phrasing content) have been added to the set of p-terminating elements.

All in all, HTML doesn't appear to be a rational, recommendable authoring format for any non-trivial writing project. After more than 30 years, it's still SGML that has all the power needed: can handle markdown and other custom Wiki syntax, can deal with and produce any HTML, has stylesheets and type-safe text macro expansion and templating. For the LISP lovers on HN, there's even the OpenJade project (dormant since about 2008 or so) for using Scheme-based DSSSL with SGML.

[1]: http://sgmljs.net/docs/html5.html

I disagree. The answer is not found yet. Even when using semantic HTML elements it's too much of a styling language. We need a system that solves the overlapping markup problem and is fully semantic.

Docbook?

+ XSL-FO.

A blast from the past. Waw, FOP is even still maintained: "Apache™ FOP version 2.5 was released on 13 May 2020." https://xmlgraphics.apache.org/fop/status.html

I'd have said Jadetex. I fondly remember the SGML toolchain; the XML stuff felt horrible in comparison.