Building the new hypermedia systems
dz4k.com
dz4k.com
And the results have been fantastic when compared with the asciidoc version we created initially. The repo is here if you want to see how he uses it:
https://github.com/bigskysoftware/hypermedia-systems-book
You can fork it and build either a pdf or epub using the just commands: `just build-pdf` and `just build-epub`. I also uploaded the epub to libgen.
We also had a pixel artist do a new cover for the paper back version:
https://pbs.twimg.com/media/GSsMjBra4AAOQZ_?format=jpg&name=...
Someday, I hope scientific journals can all agree on a standard for mobile display of articles. Maybe something like a Typst template for it. But it probably wouldn’t be a PDF file.
p+p {text-indent:5em} seems pretty simple? I just did a quick test and it seemed to work when I broke up a few paragraphs with an h1, a ul, and a div. This isn't anything esoteric, it's CSS2 stuff that's been working for twenty years. Though "typst breaks lines 500% better than most browsers" is a compelling argument on its own.
p + p { text-indent } absolutely works and has been my go-to method of implementing proper paragraph indentation for as long as I can remember. Impressive drop caps, hanging punctuation, etc. are possible with some effort.
However, balancing lines, hyphenation, eliminating rivers is something that browsers don’t do or do not as well, and custom kerning is painful.
If there is something that handles typesetting on par with InDesign but without the bloat and in a friendlier format, that’d be neat, but I wonder how long would it remain bloat-free considering features that would be needed.
I've been waiting for Typst to get HTML output. It's been under development for quite a while but seems to suffer from some bikeshedding [1].
Glad to see there's Pandoc support for Typst HTML (and LaTeX) export as a workaround. Gotta try it for my next paper!
That said, our plans for HTML export have definitely become more substantiated and concrete over the past year and once the current work on layout finishes, it is the next big thing on our list.
My bikeshedding fear came from the Github issue (forgot the link in the comment), where there is IMHO definite bikeshedding about e.g. tag names. But indeed, there seems to be important architectural concerns.
Following with interest how Typist develops.
Typst is a better 70s answer for a 70s-level ambition, which is a fine level of ambition when you're just out of punch-card programming.
Emacs supports variable-width fonts just fine and in theory you could use variable width for the "content" and reserve fixed width for the code. Not sure how well it works in practice, though. Of course, that doesn't go as far as TeXmacs.
TeXmacs is an interactive typesetter. It typesets as you go. You can mark chunks of content up (semantically or visually or both) the way you do with any other batch-based typesetter, but you don't need to suffer the markup when you look up at the matrix, integral or set-theory equation you wrote on the paragraph above.
Most of the comments just misunderstand TeXmacs. I wholeheartedly recommend to watch the quick tour video (3m40s): https://www.texmacs.org/tmweb/home/videos.en.html
I don't want to edit a rendered document. I already have MS Word if I wanted to do that.
I must be missing context here but I thought we were past side snarks out of mere generational antagonism. If not, please enlighten me ;)
Anyway, comparing XML against a compact syntax a la markdown or typst (AIU!) is besides the point: XML is just meant as canonical SGML syntax for delivery to browsers while full SGML has all the additional features for editing, such as short references (custom Wiki syntax token mappings for eg markdown support), tag inference, and LPDs (restricted element and attribute transformations), that together deliver quite powerful authoring and content app capabilities without turning into a full-featured programming language. HTML, without doubt the most important markup language, is based on it after all though the vast customization features of SGML really favors building your own project-specific Wiki syntax that's then mapped to a rendering vocabulary such as HTML).
The context is right there in the rest of the comment: editing XML by hand is a hideous experience.
It also has its problems as a format for data exchange, but those are much less acute.
Never had a worse experience with TeX.
>instead of a fixed width font, and abstruse markup everywhere.
What?
You could say: the rendered output (interactively or as PDF export) looks as good if not better than if it was done with (La)TeX, and the editor can be customized to a degree similar (perhaps a little less?) than Emacs. Hence the name.
Incidentally, being able to customize Emacs with a Lisp other than emacs-lisp, is something the Emacs community would probably like, and there were in fact (now stalled) efforts to do so with Scheme.
The best part of TeX always was that you only had to deal with text. Trying to write something like TeX, but being forced into a Word like graphical environment felt easily to be the worst of both worlds.
At the same time I understand your sentiment. After all, TeXmacs hasbeen for a long time a one-man effort. Joris was doing everything: programming, documentation, website, community support... How many people work/have worked on Word?
The only reason to learn Latex is the same reason to learn C++: Everyone else uses it
And honestly, I think that is the better way to go. You don't have to chase down weird commands (how do you set LaTeX to use Lato as the main font again?) and you get instant feedback on how things look.
I haven't found a way to mark text up as "this is a blockquote" and then have that mapped to the correct style, and it seems to lack a few of the more esoteric font features LaTeX does support. The fact that you get instant feedback and can tweak the relevant knobs as much as you like? That means you get a much nicer layout.
If you have a Windows machine with the Office package, you get Microsoft Publisher, which I believe can import Word documents and extract the style from that.
Scribus can map styles from imported files, but last time I checked I couldn't get it to auto update the view when you changed the font.
Doesn't even have real math support. Can it even be scripted?
Ridiculous alternative to Typst or LaTeX, they don't even compete in the same category.
I do strongly disagree that they are not in the same category - they both solve the problem of "taking this text and turn it into a nice PDF". If you assume that this must happen through scripting, then that is exactly the point I was questioning.