Really exited to see typst continue to improve, especially regarding HTML output. Im looking forward to being able to use a single markup language for both web and print, as latex-to-html isnt great, neither is MD/asciidoc-to-pdf.
Besides being obsessed with lightweight markup languages, lately I started writing my own mail client… mostly to write a composition format based on a lightweight markup language.
So I can send out emails with both a readable plaintext version (that my client would wrap, etc.) and a plain HTML semantic version. And I was considering Typst for this!
I actually have a friend that does email automation—ensuring HTML outputs and email presentation are correct across different clients is the worst part of her job she tells me. So many edge cases and lack of support for the standard.
I don’t have a lot of first-hand experience, but I hear that’s mostly layout. HTML fancy email is stuck using tables without CSS, and apparently table layouts that work across different mail clients are priced heirlooms passed from one generation to the next.
The styling I want to do is mostly what most mail clients let you do (bold, italics, etc.), and I think that’s reasonable to get to work.
Fortunately I didn’t have to touch this for years - but the last person to have this horrible task told me that they were writing HTML like “for browsers of 10 years ago” - maybe it’s 15 years now. Very limited set of CSS and still some table layouts. Or something actually improved in the last years.
If you include an HTML version and a plain text version of the contents of the email, then I think all mail clients (terminal clients included) will show you the proper version.
The main problem (IMHO) is that many HTML email composition systems have the plain text version as an afterthought, so it’s often horrible or unusable.
This is why I think a proper mail composition system should take care of making both versions nice. By using something like Markdown or Typst, the mail composition system can create a good-looking text version, reflow it properly (so you don’t have to care about wordwrapping) and a good-looking HTML version.
I guess it’s still a bit wasteful to send both versions of the content of the email when the text version would suffice, but I think it’s also true that the experience on non-terminal clients with plain text emails is also bad. So sending dual emails IMHO is more pragmatic right now.
I am not an expert on plain text email, but traditionally, plain text emails are wrapped to 80-character lines. This has “responsive design” issues; you might typically experience this by browsing mailing lists in a phone.
There is format=flowed, but I have not used it to learn if it works well and is widely supported.
ah I didn’t consider that. a lot of clients wrap to 72 lines by default, but I can see how that would still be enough to dissuade reading on a phone. honestly probably helps the quality of replies.
IIRC, AsciiDoc had conditional target functionality. AsciiDoc has many areas that could be improved, but it’s one of the most featureful systems out there.
yeah asciidoc has a lot going for it, but a lot of the areas that could be improved tend to rub me the wrong way
i remember last time i tried to use it i had a hard time getting it to play nice with other stuff, and also the syntax is…
one thing i really appreciate about both typst and LaTeX is that there’s pretty much no ambiguity about what’s text and what’s a command/macro/function/whatever
asciidoc, meanwhile, feels much more seat of the pants
If i want to add a footnotefootnote[like so!] mid-sentence, i tend to appreciate something actually separating it syntactically from the word it's attached to
Have been waiting long for the HTML support. Now the static site generators can adopt typst and I will be delighted to write blog entries in my favourite typesetting format!
Really exited to see typst continue to improve, especially regarding HTML output. Im looking forward to being able to use a single markup language for both web and print, as latex-to-html isnt great, neither is MD/asciidoc-to-pdf.
An impossibly difficult order, I’d love to see any of these tools support HTML export for use in email.
Are you in my head?
Besides being obsessed with lightweight markup languages, lately I started writing my own mail client… mostly to write a composition format based on a lightweight markup language.
So I can send out emails with both a readable plaintext version (that my client would wrap, etc.) and a plain HTML semantic version. And I was considering Typst for this!
I actually have a friend that does email automation—ensuring HTML outputs and email presentation are correct across different clients is the worst part of her job she tells me. So many edge cases and lack of support for the standard.
I don’t have a lot of first-hand experience, but I hear that’s mostly layout. HTML fancy email is stuck using tables without CSS, and apparently table layouts that work across different mail clients are priced heirlooms passed from one generation to the next.
The styling I want to do is mostly what most mail clients let you do (bold, italics, etc.), and I think that’s reasonable to get to work.
Fortunately I didn’t have to touch this for years - but the last person to have this horrible task told me that they were writing HTML like “for browsers of 10 years ago” - maybe it’s 15 years now. Very limited set of CSS and still some table layouts. Or something actually improved in the last years.
isn’t it kind of a faux pas to put HTML in emails?
If you include an HTML version and a plain text version of the contents of the email, then I think all mail clients (terminal clients included) will show you the proper version.
The main problem (IMHO) is that many HTML email composition systems have the plain text version as an afterthought, so it’s often horrible or unusable.
This is why I think a proper mail composition system should take care of making both versions nice. By using something like Markdown or Typst, the mail composition system can create a good-looking text version, reflow it properly (so you don’t have to care about wordwrapping) and a good-looking HTML version.
I guess it’s still a bit wasteful to send both versions of the content of the email when the text version would suffice, but I think it’s also true that the experience on non-terminal clients with plain text emails is also bad. So sending dual emails IMHO is more pragmatic right now.
why is that?
I worded that poorly.
I am not an expert on plain text email, but traditionally, plain text emails are wrapped to 80-character lines. This has “responsive design” issues; you might typically experience this by browsing mailing lists in a phone.
There is format=flowed, but I have not used it to learn if it works well and is widely supported.
Like many attempts to improve email, it was fucked by Microsoft’s refusal to implement it.
ah I didn’t consider that. a lot of clients wrap to 72 lines by default, but I can see how that would still be enough to dissuade reading on a phone. honestly probably helps the quality of replies.
On mailing lists, yes, but the vast majority of other mails have HTML.
the vast majority of other mails are also spam with tracking pixels etc.; I don’t think that makes it socially acceptable
I would have said that rst/Sphinx is pretty good, except I’m now writing fifth post-transform to massage the LaTeX output
even in the state it’s in, the html export looks like it might be ideal for my use case lmao
especially the conditional target stuff! i’ve been wanting this for… forever, in any language
as a hardcore semantic markup fan i am. just delighted
IIRC, AsciiDoc had conditional target functionality. AsciiDoc has many areas that could be improved, but it’s one of the most featureful systems out there.
yeah asciidoc has a lot going for it, but a lot of the areas that could be improved tend to rub me the wrong way i remember last time i tried to use it i had a hard time getting it to play nice with other stuff, and also the syntax is…
one thing i really appreciate about both typst and LaTeX is that there’s pretty much no ambiguity about what’s text and what’s a command/macro/function/whatever
asciidoc, meanwhile, feels much more seat of the pants
I am impressed that they added so many new features, while still apparently being mindful about minimizing dependencies:
Have been waiting long for the HTML support. Now the static site generators can adopt typst and I will be delighted to write blog entries in my favourite typesetting format!
Based on this post I decided to rebuild my resume in typst, worked great!
Happy to see the beginnings of accessible PDF output!
Hadn’t heard of Thpst, but it looks lovely. I might try to make a zine using this…