Learnlatex.org: A place to learn LaTeX online
learnlatex.org
learnlatex.org
Since then LaTeX has basically kept on stagnating in the name of backwards compatibility, while ConTeXt keeps on progressing; it already broke backwards compatibility several times (it's latest implementation is called LMTX).
But the inertia is so powerful that nobody except TeX geeks even knows what ConTeXt is. How does that happen?
Sidenote: it's not just about ConTeXt, even LuaTeX, the latest (but not new anymore) implementation of TeX in general, is being ignored by scientific publishers.
Meanwhile, ConTeXt is mostly used for demanding typesetting of books.
And, BTW, using ConTeXt (or LuaTeX) doesn't even necessarily mean writing TeX anymore, it's possible to drive the engines through the Lua C API, or with XML, etc.
ConTeXt links:
https://wiki.contextgarden.net/Main_Page
https://en.wikipedia.org/wiki/ConTeXt
Mailing list: https://mailman.ntg.nl/mailman/listinfo/ntg-context
> care about the technical level of its implementation
It's not about the implementation, it's about the interface.
Arxiv does of course, most notably. But it’s not a journal.
Each journal I've checked on their site (admittedly, only 4 or 5) seems to mandate TeX.
E.g. https://www.siam.org/publications/journals/siam-journal-on-a...
> Authors of accepted papers must submit TeX files to SIAM for typesetting. Authors are highly encouraged to prepare their papers using SIAM's multimedia LaTeX 2e macros. Note that the SIAM office will format Plain TeX and AMSTeX files to LaTeX 2e. The LaTeX 2e macro package and documentation are available here or by email request.
What? I have papers there and they insisted on latex.
https://www.siam.org/publications/journals/siam-journal-on-m...
> Authors of accepted papers must submit TeX files to SIAM for typesetting. Authors are highly encouraged to prepare their papers using SIAM's standard LaTeX 2e macros. Note that the SIAM office will format Plain TeX and AMSTeX files to LaTeX 2e. The LaTeX 2e macro package and documentation are available here or by email request.
TeX is still pretty darn good though.
Is it easy to convert LaTeX to ConTeXt?
(Well, technically, the same language, but imagine all the std. library functions are different).
They're also very different philosophies.
LaTeX tries to do do everything semantically, and hide the details.
CoNTeXt otoh admits that concreteness matters, so you generally say what you want. Think "empahasis" vs "bold, underlined, 15pt text".
This isn't like going from gif to png.
It's more like going from bmp to svg.
Regarding Lua, I think it is a strange idea from the point of view of the typical LaTeX package writer. Not only you need to learn Lua, but you also have to write packages that are accepted only by this implementation of LaTeX. This is a clear disadvantage if you want to have a widely used package.
Absolutely true.
I would posit that most people writing LaTeX aren't writing up papers in it either (Most journals prefer or require Word these days).
ConText isn't just for books though..it's great for any sort of thing with formatting...like, say, a resume.
https://www.nature.com/srep/author-instructions/submission-g...
"Whilst Microsoft Word is preferred we also accept LaTeX, or PDF format."
In general Word has eaten up everything that isn't hard core math.
(PS: All the IEEE journals accept Word.
it’s probably true that most papers aren’t written in LaTeX but I’m confident most people writing in LaTeX are writing scientific papers.
what exactly do you think they're writing in it then? business cards?
as the other commenter said: publishing across math/physics/cs i have never seen a journal not prefer latex to word. and while ieee accepts word it most certainly prefers latex:
I know that for some journals (osapublishing.org, which is optics so engineering/physics) this came at a time when they moved all their content to be accessible as html. I remember reading somewhere (maybe in their style guides) that they said that word allows them to extract the relevant information more easily, so I suspect that MS made some sort of publishing toolchain for this usecase and the publishers lapped it up.
I know that a significant portion of colleagues still prefer to write their documents in latex, and the journals still accept them.
There's an analogous situation (or a continuation of this same situation, given the overlap in user base) for those who've invested decades in building a personal set of Emacs configuration files. Again, I've got thousands of lines of *.el files (many of them devoted to my idiosyncratic use of LaTeX) in my Emacs configuration. Of projects looking to replace the aged Elisp engine and create a modern implementation aren't going to get much consideration if it would mean replacing that (literally decades of) work in a different language. That's why I continue to be interested in Guile Emacs---less because of Guile (although I have no issues replacing Elisp with a modern Scheme), but because they've always made it clear that an ability to re-use Elisp configuration files was a primary design goal.
Good thing you didn't bother, because it's absolutely not worth it. I chose LuaTeX initially precisely because it seemed more convenient to write commands in Lua than in plain LaTeX, but it turned into a total nightmare. Issues crop up as soon as you try to do something with text that embeds LaTeX macros, and the errors you get are even more byzantine than the ones you'd get by writing "normal" LaTeX code.
IMHO the very idea of embedding an external language into LaTeX is pointless, for the simple reason that LaTeX isn't markup, but code, and that it's pretty much impossible to parse it into a representation that makes sense and could be manipulated like, say, the HTML DOM. The only sane way to automate things is to write your documents in some language or markup that can be compiled to LaTeX, or to use a template engine.
The biggest thing LuaTeX gives you is variou hooks and access to various data structures used internally by the typesetting engine, so that you can work with them directly instead of having to do everything in a roundabout way through macro expansion. If all you need is text expansion then sure, just use TeX/LaTeX macros. (You mentioned "try to do something with text that embeds LaTeX macros"; I think working at the text level like that is a sign that your problem, or at least your solution, may not be a good fit for what LuaTeX gives.)
Here are a couple of my answers where LuaTeX was valuable; you can find hundreds more (IMO) by others:
- https://tex.stackexchange.com/a/379802 Avoid getting short words at line edges: Note that the macro-level solution runs into issues with \ref etc (just as you said about text that embed LaTeX macros), but the LuaTeX solution works perfectly in all cases
- https://tex.stackexchange.com/a/401315 Letter-spacing
- https://tex.stackexchange.com/a/403353 Typesetting on a poster with some image cut out
- https://tex.stackexchange.com/a/416772 Doing text replacements based on TeX macro state (maybe this could be done without LuaTeX?)
- https://tex.stackexchange.com/a/414013 Inserting random kerning
I do completely agree with your recommendation of generating TeX/LaTeX if possible (and keeping the macros/LaTeX to a minimum).
Having said that, org-mode/org-babel is useful when writing for both HTML and LaTeX export.
I think that we desperately need some modern language for document preparation, which will replace TeX and its derivatives, but I also don't see anything like that on the horizon. The biggest drawbacks of TeX are lack of proper Unicode support; lack of support of modern font formats; and outdated programming practices. Tools like XeTeX, LuaTeX and ConTeXt tackle these problems with some success, but they are still not perfect. Also, they are too similar to TeX to bring drastic changes to programmers. We need something that is designed from zero specifically as a TeX replacement (including compiler, package manager, popular packages, bibliography manager, converters, etc...). I can only hope for better future...
BTW, fun fact: TeX is still actively developed. Knuth fixed some bugs in the kernel last month (after few years of pause).
When I want to change something nontrivial about the formatting or style, it's a nightmare. For example, there are zero mature fonts besides the default computer modern that also have math rendering that's aesthetically acceptable to me. And I forget the details, but typesetting is handled in such a way that the kerning around things like hyphens is broken. I've fixed it manually before in places where it was particularly egregious.
Also on this point: an ungodly number of hours are wasted every year by academics figuring out how to contort LaTeX so the resulting document complies with NSF grant specifications, which you must meet or be auto-rejected. In particular, NSF requires one-inch margins, but there's no way to force the typesetting engine to strictly respect the margins you set. So at the end you're left to turn the visual margin guides on and check there are no margin overruns, or you risk getting your proposal set to the trash (theoretically, at least).
I've also heard that LaTeX editors are development disasters with a bus factor of one. The NSF really ought to fund them, because if we wake up one day after the maintainers of all the popular editors die and Apple/Microsoft force an operating system update that breaks compatibility, paper writing in the physical sciences will grind to a halt.
Can you give more details about this? I’ve never heard this complaint before, nor noticed this myself.
Also, I’m not sure I understand what you are saying about “LaTeX editors”; I use Vim, and it works quite well.
But after a while I remembered the more fundamental point that bothered me:
> one might add that it's not just microtype that doesn't offer optical kerning -- it's structural limitations in TeX's typesetting that prevent it. To TeX, each glyph is contained inside a (I guess: black) box. TeX knows the outer dimensions of those boxes, but has no clue (and doesn't care) about what the glyph looks like that's inside it.
https://tex.stackexchange.com/questions/139926/optical-kerni...
And this led to bad spacing for hyphens, which led to me experimenting with manual kerning, which led to the issue that I recalled first.
Also, I am not really convinced of the merits of Vim for LaTeX. Most of my time writing is spent revising, which requires a lot of "random access edits," and I'm at least twice as fast at jumping to arbitrary locations on screen using a mouse as I am with vim (even with the usual tricks).
(I tend to think of vim as something that was purpose-built for programming in C and with usefulness inversely proportional to how far a given task is from that purpose. While I realize that's not entirely accurate, I've found it a good heuristic. Programming: vim works decently for me. General purpose writing: not so much.)
Further, the ability to control-click .pdfs and skip to the corresponding place in the .tex file, and vice versa, is an amazing convenience. I understand that there are technically ways to do this in vim, but then at that point I'm using the mouse a ton anyway and I don't really see the point of vim (which is usually proposed to be "hands don't go off keyboard = write faster" in my experience).
So, yes, I could survive if forced to use vim. I just wouldn't like it.
Given this, and given I feel I'm much more willing to experiment with these things than the average person writing papers in the physical sciences. I can't even imagine how the conversation would go if I tried to tell my 72-year-old advisor that TeXShop's not going to work anymore because he updated his computer and it's time to get friendly with the command line. These people want to do science, they don't want to learn vim shortcuts.
Boring details: TeX, as it comes from Knuth, reads TFM ("TeX Font Metric") files to supply this per-font information. Knuth's Computer Modern fonts do not contain any kerning pairs that contain dash characters, which one may be pleased or displeased about. Various enhanced-TeXs get font info from the OS or perhaps directly from, say, OpenType font files. If the ligature and kern info isn't passed into TeX from there properly, or doesn't exist in the font itself, then of course you won't get the results you're looking for.
That said, Adobe does have a proprietary optical kerning scheme that they use in their applications. But it's turned off by default (hint, hint), and their documentation is a bit defensive about it: "Optical kerning adjusts the spacing between adjacent characters based on their shapes, and is optimized for use with Roman glyphs. Some fonts include robust kern-pair specifications. However, when a font includes only minimal built-in kerning or none at all, or if you use two different typefaces or sizes in one or more words on a line, you may want to use the optical kerning option for the Roman text in your document." Loosely translated: Fonts from real type foundries have kerning pairs carefully created by their designers; if you have slap-dash one where they didn't bother, we'll do the best we can if you want. YMMV.
> (I tend to think of vim as something that was purpose-built for programming in C and with usefulness inversely proportional to how far a given task is from that purpose. While I realize that's not entirely accurate, I've found it a good heuristic. Programming: vim works decently for me. General purpose writing: not so much.)
I don't want to comment on the kerning stuff (I don't really know much about it). However, I found your comment about the merits of vim when revising interesting. Like you, I spend most of my time writing revising/correcting (often other peoples work), however my take on vim is just the other way around.
If I write a large text myself, it doesn't really matter what editor I use, it's when I revise/correct things that I love using vim. While you might be correct that you would be quicker to move to the appropriate spot using a mouse, I pretty much guarantee that all the gain is gone when you have to switch back to the keyboard to do your change. That's why I love vim for these kind of tasks, the moving and changing of specific text is such a seemless experience without even having to change the hand position on the keyboard. My productivity absolutely plummets every time I have to use word or some other editor for these sort of tasks.
I see! What I didn't say is that I'm working on a laptop, so the trackpad to keyboard distance is negligible – it's essentially just another big key. All I have to do is pivot my hand.
TeX should always give you warnings like "Overfull \hbox (0.43386pt too wide) in paragraph at lines 42--45" and the text of theaffected line when it "disrespects your margins", so I don't see why you have to check for them visually?
So this complaint of "I can't enforce that there are no margin overruns" is (to use the same word) actually something like "If I don't take any steps to avoid overruns, and moreover ignore the warnings that are specifically about overruns, then there are overruns". This complaint is not specific to you and is surprisingly common actually, which brings me to my main point, which is that the majority of people seem to use TeX/LaTeX without ever having read the manual. Some of them even joke about "incomprehensible" messages like "overfull hbox". But the whole point of TeX, what TeX is at its core, is this breaking-paragraphs-into-lines (in my view, the rest of TeX is just a large wrapper around this basic function of setting boxes).
The preface of the TeXbook describes it as "TeX, a new typesetting system intended for the creation of beautiful books", and for its initial design goals, it does make sense that it chooses by default to declare defeat in impossible situations and overflow margins with a warning to the user so that they can take appropriate action, instead of silently producing an "ugly" paragraph with lines subtly looser than whatever tolerance settings the user has specified. What is remarkable here is that a lot of people are using TeX who do not care about meticulous typesetting of "beautiful books" at all, and will blithely ignore warnings related to such matters.
The lesson may be that such a state of affairs is inevitable, so perhaps a better default for similar software today would be to produce loose lines to fit in the margin, so that results are good even for the users who don't read the manual, or even the warnings, or even proofread the final result.
Is this really remarkable? It's the standard tool for writing papers in physics. Get result, put into LaTeX, put on arxiv, repeat. The fact that these people have to constantly Google for obscure LaTeX incantations (faster than TeXbook) is not ideal for them. Indeed, it would be better if it were easier to use without reading a 500 page book.
Anyway, thanks for tip. When I googled for this I found only \sloppy, which did not produce reasonable results.
The only one I like is URW Garamond but it's a breeze to install and use and I think it stands head and shoulders above everything else. It also matches the math pretty well imho. I feel you though: Computer Modern is pretty ugly and most other fonts really clash with the math rendering by default.
In case anyone else is wondering about this:
> The bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members, derived from the phrase "in case they get hit by a bus."
Do we? Sadly, appreciation for excellent typesetting has declined now that most people are consuming writing through a screen. And even for printed material there is pressure to cost costs: venerable and respected publishers with long traditions of obsessively good typesetting, realized they could outsource their typesetting to developing-world shops using Word or similar software, and few readers would care. (Similarly, and to the dismay of bibliophiles, even prestige titles these days are likely to get a glued building instead of a sewn one, and fairly low-resolution digital printing).
See my comment below https://news.ycombinator.com/item?id=26498409 :-)
Thank you for bringing it up :)
That said, I've started working on such a project as you propose. The document preparation language will be almost identical to LaTeX, but no macro language and no category codes, UTF-8 as the standard input coding, first-class support for multiple back ends (e.g., use the same source to produce PDF, HTML or ePub), command definition through an embedded scripting language (I'm still debating between Python, Lua or something else entirely), formatting done declaratively, most likely through a YAML file, etc. My musings along the way are at http://finl.xyz
Any reason for that? The rest of your description looks very attractive, but why would I prefer a language without macros? I need conditional compilation, setting variables, parametrized notations, etc. This is extremely useful when preparing a scientific document. If anything, I don't really care about the document preparation language itself, but it must have macros to be useful!
Is that really true? I had no trouble writing UTF8 documents using regular TrueType-fonts in LaTeX almost two decades ago and with no problems with output quality.
The only thing was you couldn't go through the dvi backend so any tools which manipulated dvi was not possible to use. But I believe all this is default now.
Oh yes. For instance, LuaTeX doesn't print combining diacritics correctly unless you painstakingly swap the underlying codepoints around in some unspecified order (to be determined through trial and error) that doesn't match _any_ of the Unicode normalization forms.
[1] https://tectonic-typesetting.github.io/en-US/
[2] https://github.com/crlf0710/tectonic/tree/oxidize [3] https://github.com/tectonic-typesetting/tectonic/issues/459
I use the latter extensively and am quite happy with it. The listed advantages of Tectonic are somewhat debatable:
> Tectonic automatically downloads support files
I use a full TeXLive distribution in a Docker image. But this is a clear advantage on regular desktop setups, although I'd argue most people don't notice that texlive is 4GB+. MiKTeX does downloading on-the-fly, too.
> Tectonic has sophisticated logic and automatically loops TeX and BibTeX as needed
Latexmk does this too. BibTeX is outdated (use biblatex+biber), I hope Tectonic is not hardwired to it.
> doesn’t write TeX’s intermediate files
Sounds terrible! For a long document I maintain, a cold run takes 8 minutes. A "cached" run (all auxiliary files present and somewhat up to date), it's below 3 minutes. It only says this is the default setting, but it would be a devastating default in my case.
> The tectonic command-line program is quiet and never stops to ask for input.
Okay that sounds nice, but I've used the interactive "can't write to file X.pdf" many times before, when the PDF to write to was locked for writing (open in PDF viewer). It saves aborting the entire run and starting fresh.
> Thanks to the power of XeTeX, Tectonic can use modern OpenType fonts and is fully Unicode-enabled.
Nice, but is this Tectonic-specific? I use latexmk with lualatex. The latter is better than xelatex (microtype, contour, memeory management, lua integration, ...). If Tectonic is hard-wired to xetex and doesn't allow lualatex, this is a big downside.
The remaining points are nice, especially the GitHub actions stuff. Though I just use the same Docker image there that I use for local development.
Take for example the element <h2> indicating a new section in an HTML document. LaTeX also has a command for this; here one would use the \section command.
——
I feel like that’s making a very broad assumption about people writing semantic markup in HTML. H{1-6} is for a header. It has nothing to do with a section (<section> or otherwise).
I’m not saying they are wrong just that a ton of HTML is abused.
What that means is that eg. a <h2> element automatically ends an open <p> element when not closed explicitly. WHATWG's HTML spec clumsily expresses these SGML tag inference rules by enumerating explicitly all elements that end <p> elements (and of course, WHATWG's HTML specification process, as would be expected, then "forgets" to update the enumeration when new elements are introduced in later specs):
> A p element's end tag may be omitted if the p element is immediately followed by an address, article, aside, blockquote, details, div, dl, fieldset, figcaption, figure, footer, form, h1, h2, h3, h4, h5, h6, header, hr, main, nav, ol, p, pre, section, table, or ul, element, or if there is no more content in the parent element and the parent element is an HTML element that is not an a, audio, del, ins, map, noscript, or video element
Source: SGML DTD for W3C HTML 5.2 [1], prepared from W3C's HTML 5.2 spec, which in turn is derived from (an older version of) WHATWG's HTML spec.
[1] http://sgmljs.net/docs/w3c-html52-dtd.html#element-categorie...
I didn't get into a lot of advanced stuff - just defined a few "newcolumntype"/"newcommand" and used them everywhere but that freed me from formatting worries and let me focus on the content.
For me the worst is tikz. I know it’s not exactly latex. But I wished it was easier to use. The output is so good, but it’s so damn hard to learn.
But yes, I know what you mean. I use the cargo cult method for writing TikZ code myself. Look for examples of people doing something similar, then poke at the code until it does what I want. I am slowly developing some glimmer of understanding, though. I figure in another 100 years' time, I'll be a TikZ wizard at this rate.
https://github.com/fhackenberger/ktikz
However, it is not quite as helpful as latexdraw was for pstricks.
That said, I am not sure how much of that difficulty is due to tools lacking and how much is due to "describe vector graphics as code" being a hard problem.
More in detail (I refer to [1] for a complete discussion):
1) It makes structured editing possible (and that is its main mode of operation). So if you want to mark your text with "semantic" markup you can do that, and in fact that is what using the software leads you to do.
2) It is controllable via programs
3) It has advanced typography (including mathematical formulae at the necessary level for professional mathematicians, as far as I can see), and it is pleasant and easy to work with: you can concentrate on writing, letting the program take care of the visual appearance and you do not need to interpret the sources while you are editing, to figure out where is the text that you want to edit
4) It has user-definable keyboard shortcuts that further help entering structured text
... and I feel it is enough for a short list of the features.
Back to Scheme. The development team is debating on which Scheme to use for the future of TeXmacs, and the debate is taking time. Here are some experiments [2],[3]. The current software (with Guile 1.8) works smoothly, with full functionality. For Linux installation, I chose the static binary they provide ... because on Ubuntu I don't have Guile 1.8 ;-)
[1] http://cahiers.gutenberg.eu.org/cg-bin/article/CG_2001___39-...
I hope that will help to bring the development forward.
It’s one of those things that is not so funny near a deadline :-)
Of course, it was some sort of user error.
But he. Good thing is no one reads thesis in full anyway
PS: Do you have JS enabled?