HTML Export #721
Comments
I fail to see why that is
Documentation says "It may also be useful to redact content because its arguments are not included in the output.", so simply using opacity is not an option
It should at least be possible to get separate pages for chapters/sections, with a menu for navigation. |
|
I'll always vote in favor of semantic tags. That means There are some more tags that may be used with this in mind, like |
|
Re this:
There are CSS Providing for something like |
|
Thanks for the comments, updated the comparison above! ❤️ On the note of pages, we could have some form of metadata in the HTML document noting down, where we want to do a page-break, though it might miss the point as exporting to a printable document should go through the PDF export directly instead of exporting it to html and then printing that. But yes, we can look into supporting that too. |
|
Math should use MathML! |
That would be ideal in principle, but maybe not great in practice... Quoting MDN:
Maybe MathML Core, but I don't know how that would work out.
|
|
We can definitely focus on using MathML Core, my current translation should also only contain MathML Core elements as far as I'm aware. |
|
Hey! Thanks for this issue. I wanted to chip in with a few thoughts here:
In general, you carry over quite a bit of styling! We should ask ourselves what the goal of HTML output will be: Is it to strive for a pixel-perfect reproduction of the PDF or to produce a document that feels "web native" and can easily be styled with downstream CSS or be used as an artifact in i.e. a static site generator. Or do we want something in-between (eBooks)? The answer to these questions should inform the design with respect to the more invasive layout functions like I, personally, think that Typst's HTML output should be more semantic than a pixel-perfect reproduction of the PDF. However, I do not have an opinion yet to the extend we should "bake in" styles as CSS and apply functions like |
|
Updated On the note of I'm definitely on par with keeping the outputed HTML file as semantic as possible so I propose the following balance between Semantics and Styling.
Let me know if that aligns with your thoughts on an HTML export or if I should think this through furhter. |
That's correct. There are some things in your list which are already resolved by the time HTML export will start, including |
Personally, I would prefer this to be something to do outside of the document, and I would avoid making the document "know" about existing environment options. What I mean is that the document would only describe what it would like to do and something else would provide the how. (Not a proposal, but picture something like CSS custom properties that can only be set outside of their usage.) |
|
Note that there are multiple HTML tags that have the same style by default but different semantic connotations: |
The semantic distinction is important for accessibility is not? |
|
I think his would be very useful. The typst language looks perfect for a static site builder, by being both a templating language and a markup language all in one |
|
Im currently investigating forking and adding HTML support myself now that I've learned how typst works internally. It would require making non-fixed-position version of the Im wondering, since I've never contributed to a large project like this, how much I can modify the library? Typst seems to make almost everything public so Im hesitant to rename or modify builtin function signatures so some feedback on what's acceptable would be appreciated. |
|
I wouldn't care too much about breaking changes and HTML export should indeed be 1-step instead of 2-step. However, we have planned to split up the current layout phase into two, where the first results in a fully styled, semantic document model. This would then serve as the source for HTML export and layouting. |
|
Understood. I'll hold off in my efforts for now.
I disagree. For example if using for a static site builder it might be useful to paginate things, like with a list of articles. |
|
Afaik KaTeX uses MathML under the hood where possible but is more fully featured and might be less hassle than MathML itself. |
That would require converting typst math to LaTeX math instead, and KaTeX supports an even smaller subset of that than MathJax. MathML Core is the way to go. |
|
I see. Out of curiosity, how big of an undertaking is HTML export? Doable in weeks/few months/many months? |
|
what if we convert the typst to markdown, then let markdown ecosystem take care of the rest? am I not thinking correct? |
That conversion would be very lossy. |
We first need to rework some internals. I'd say a few months. |
|
This would be more an architectural thought (that I'm naiively suggesting without fully understanding typst internals), but I wonder if it would make sense to create an intermediate representation. Something akin to LLVM-IR but for documents. For example rustc (clang and many other compilers) will first compile to llvm-ir and then use llvm tooling to convert the IR to some sort of machine code. This sort of a pipeline would look something like;
This would be nice for a couple of reasons.
|
|
I wanted to contribute some references since I have thought about targeting html with maths for some time: Tools which try to convert LaTeX to htmlThese tend to be a bit brittle, because they never support the entirety of LaTeX, so when you for example use the package Starting from a new language and targeting both LaTeX and htmlThis is the category typst falls into, so I am suprised that nobody mentioned PreTeXt so far. It is a very interesting approach, which essentially uses XML Templates to convert xml to both html and latex.
The bad:
The existing content in PreTeXt consists mostly of textbooks, i.e. people who wanted their textbooks to be more interactive than pdf pages, but still wanted to be able to publish the book in print. Articles on the other hand are rare (bad citation functionality might either be a cause or effect of this). Starting from html or markdownInteresting projects in this space are
Neither of them are perfect for presenting maths and neither of them have bibilography support and it is typically difficult to target LaTeX so you do not want to write in them even though the end result might be perfect for interactivity. Personal musings about
|
|
@FelixBenning The PDF engine meets 70% of my needs, and a static HTML engine could cover another 20%. I don't plan to use Typst for interactive plots soon, as I use many tools for this and don't think Typst will have advanced features. I believe Typst will rely on extensions for these tasks. Just like I don't expect the Python core team to build plotting or machine learning into interpreter. |
|
@vsheg I mean that is completely valid. And if you want to be like vim to vscode, you can just have better usability without cool features and be a niche product. But if you want to capture larger userbases you need a unique selling point and I explained why interactivity would be that selling point for me. I also don't meant implementing interactive plots yourself but rather integrating with D3.js or other javascript libraries |
|
@FelixBenning I am not so sure about your argument. For me it is the other way around, typst is a bliss to use compared to latex. Talking about vscode, typst already has lsp support that alone is a very good selling point for usabilty and adoption. If anything interactive plots seem more like a niche use case. Also typst has no direct concept of a plot, there are plugins for that, so your request seems more like a plugin feature than a typst feature. |
|
@FelixBenning I think text pre-processing and post-processing, an 'include' directive, and a well-designed extensions API are enough for interoperability with HTML/JS/WASM, etc., or other languages. I prefer not to use Typst for data science workflows that involve plotting and interactivity, as Python is more appropriate for these tasks. Consequently, your suggestions are unclear to me |
That is exactly what people would say about vim: "It is so much easier to use, I don't have to move my fingers away from the keyboard, the combinations makes sense, I am so much more productive". But they are a niche audience who care about text editors and are willing to spend the time to learn the vim language. I don't know what you use typst for, but you can not credibly tell me, that you can write journal articles in it. Because journals want LaTeX. And it matters to the average user, whether you can use it everywhere (including journals). They need a very good reason to choose another tool over a "good enough" tool which they can use everywhere. Trying to get academics to use git for collaboration on And I never suggested using typst for data science workflows, but for interactive textbooks and articles (like the ones produced by PreTeXt), the technologies to make interactive textbooks simply intersect with blogging and dashboard frameworks. And I care 0% whether that is an (easy to install!) extension, or whether that is typst native. That is an implementation detail. The average user views the python programming extension for vscode as part of the vscode experience in python (which is why many of the larger extensions are maintained by microsoft themselves). I have no idea how the typst ecosystem looks like, because I am not going to get into another language right now. I do not have the capacity if there isn't greater payback than "it is marginally nicer to use than latex, but has the same output". I simply wanted to tell you what it would take for me to change my mind on this. What you do with that is your choice And I will try to stop having this argument now. |
|
@FelixBenning Anyone using vim and who is halfway honest about the amount of effort required to get it configured the way vscode works would tell you that it is not easy and that there are tradeoffs. To make my point clear: Typst already has killer features (in my opinion) that make a good argument to switching to it. Interactive plots are not the feature that will make everybody switch (in my opinion). Arguing about opinions is not really productive and not the point. Journals requiring latex will not make people use typst. But typst has more use cases than journals. I use it for presentations, notes, cvs. Things that I do for myself/work and where not having to deal with latex and having great editor support (via lsp) makes it friction less for me. Typst having great text editor support and having native html export (in the future) might make journals provide typst as an option in the future, but that is pure speculation. Again I think those are better reasons to use typst than having Anyway nothing of this has anything to do with the issue at the top, I just wanted to share my view on things because I think you are misunderstanding my reasoning. Maybe one last comment, for the maintainers: Thanks for creating |
|
Interactivity seems orthogonal to HTML generation. Once you've generated static HTML, you could make a JS library that you can load and have it traverse your HTML, parse the static stuff and make it interactive with event listeners and such (kind of what MathJax does). Typst could make it easier to write such libraries if it makes the statically generated HTML predictable and nice for parsing, but that's something for distant future; we can safely ignore it until all of static stuff is done and works well. One problem at a time. |
|
I think the suggestion mentioning the possibility of some type of IR format would be the way to go here: #721 (comment). To me it seems best to view Typst as two separate parts, one that processes the template (simple example being substituting For Typst to have good support in other tools (things like pandoc) having an intermediate format that has none of the programming/templating stuff, and is purely a markup language, seems like a huge help. We cannot expect other tools to implement a full parser/compiler for the Typst language just to output a different format. I have little clue about Typst internals or how difficult this would be to implement, so take my opinion here with a huge grain of salt. It just seems like something that would make sense to add as part of this undertaking. |
AFAIK Typst does have a concept of elements, but since it supports contextual expressions that use functions such as |
|
Honestly it wouldn't even need to be a whole separate intermediate language, just subset of Typst as-is but "expanded" out from functions and whatnot.
…________________________________
From: bluebear94 ***@***.***>
Sent: Friday, March 15, 2024 1:11:53 PM
To: typst/typst ***@***.***>
Cc: Amelia-Mowers ***@***.***>; Manual ***@***.***>
Subject: Re: [typst/typst] HTML Export (Issue #721)
For Typst to have good support in other tools (things like pandoc) having an intermediate format that has none of the programming/templating stuff, and is purely a markup language, seems like a huge help. We cannot expect other tools to implement a full parser/compiler for the Typst language just to output a different format.
I have little clue about Typst internals or how difficult this would be to implement, so take my opinion here with a huge grain of salt. It just seems like something that would make sense to add as part of this undertaking.
AFAIK Typst does have a concept of elements, but since it supports contextual expressions that use functions such as locate, I believe that third-party tools will still need to evaluate Typst code (albeit in bytecode form after #3307<#3307>).
—
Reply to this email directly, view it on GitHub<#721 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AZFNGKRRQBSE52SKOHTFCI3YYNIYTAVCNFSM6AAAAAAWZQT2NGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBQGM3TOMZRGA>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
|
I believe there should exist some primitive structural elements that are expressive enough, like for example tables with headers and col/rowspans. HTML may provide good guidance in this regard. This is not only related to the procedural/declarative distinction, because even if third parties could declare structural elements, it's unrealistic to assume that tools like pandoc will understand any structure out there. Of course, it would be useful to keep this extended structure, but at the same time it should reduce to something primitive albeit not excessively low level / presentational. If tables were always reduced to bare grids, there won't be much structure remaining at the end. To put an example, the merging of tablex into the core introduces more meaningful building blocks which pandoc could take advantage of, but I still think that concepts like the header of a table are being overlooked, they can be inferred from some parameters but they are there because of different concerns like being able to replicate the header in multiple pages, not because of an explicit intention to preserve some basic structure/semantics. |
|
This feature request is called "HTML export". While all that talk about IRs and making typst code suitable for external engines is interesting and maybe worth its own issue/discussion thread, it's really orthogonal to the idea of having typst natively produce HTML output. |
When I originally started the discussion on IRs it was meant more as a discussion on how to implement HTML export in a way that was modular and future proof for other similar formats. So I'd argue that discussion around IR's are "HTML export" adjacent rather than "orthogonal". Discussions on IR's are still potentially relevant in the discussion around how HTML export is implemented depending on the design direction that the core typst team chooses to go in. That being said, I agree that the conversation around other how an IR may enable usage of XYZ external tools has drifted beyond what I would considered relevant in this issue. |
|
Deleted my comment as previous experiences for the problem of typesetting, including HTML support, was not seen as welcome. |
According to architecture.md, typst seems already built that way, just with a internal IR (consisting of " To go further, the Export section of the document mentions there is already other exporters: an SVG one and an internal one (raster). |
It's a bit more subtle than that, currently the Frames hold precise positioning information, which is not compatible with semantic export to HTML. Interactive contentI also think typst can be a great fit for this, albeit not directly. To be "interactive friendly", Typst's output need to be externally stylable. When you use We should ensure it's possible to do with other custom functions or use Let's assume we're using Fictional case : transitions between slides of polyluxIn polylux, every page represents a slide and if you want to animations between them:
With this you could create a manim like (python library for generating interactive animations) What about SVGThat's all well but maybe you don't want to be working with HTML, then the metadata information could also be present in the SVG exports so that we could work with this instead. I think metadata is a good fit for being externally styled and with this addition, you could use typst to generate websites with animations etc. If you want to have REST API for your website I would suggest generating a typst file including the functions used to tag your elements to use these API calls. This generation process should use a description of your API (one source of truth, no bullet in the foot :) ) |
|
The problem is likely about fix-position. |
|
You can get precise positioning in html by modifying the x and y props of a wrapping span component.
…________________________________
From: CaveNightingale ***@***.***>
Sent: Friday, April 26, 2024 11:22:35 PM
To: typst/typst ***@***.***>
Cc: Amelia-Mowers ***@***.***>; Manual ***@***.***>
Subject: Re: [typst/typst] HTML Export (Issue #721)
The problem is likely about fix-position.
A Module generated by eval::eval meets the requirement of being both semantic and without precise positioning.
But a problem is that Func is quite block-boxed and tricky.
I think it will be a good idea to have a IR with all #Set applied to elements and removed from document and all Func evaluated.
As for interactive content, it's easy to add things like #svg(...), #html(...) , #pdf(...) which generate an element handled with specified backend and ignored by other backends.
—
Reply to this email directly, view it on GitHub<#721 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AZFNGKVWOXAGV2ZCGX7V7E3Y7M72XAVCNFSM6AAAAAAWZQT2NGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBQGM4DINBTGE>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Disagree. |
|
Since there was some discussion about use cases for HTML export in context
of extra interactivity, I thought it might be encouraging to present a use
case that expects no extras for the HTML export other than visual
equivalence with PDF.
Had typst implemented HTML export I would start experimenting with it as an
alternative to HTML templates for things like invoices and ToS documents.
My company currently offers with our products a pipeline that goes from an
HTML template to a PDF document using headless Chromium. Maintaining HTML
templates comes with some problems that could be at least partially solved
by having a language that allows writing proper functions, defining
packages, etc. Some people would maybe even find a cleanly written typst
document easier to edit than HTML. Also, having the possibility to import
from other formats built into the language makes decoupling the whole thing
from our code much more straightforward. PDF is our primary target but many
people expect their documents to be also available in HTML.
I probably haven't thought through it fully but this is my current reason
for following typst development after I have finished my diploma project.
…On Sat, 27 Apr 2024, 08:48 CaveNightingale, ***@***.***> wrote:
You can get precise positioning in html by modifying the x and y props of
a wrapping span component.
------------------------------
From: CaveNightingale *@*.
*> Sent: Friday, April 26, 2024 11:22:35 PM To: typst/typst @.*>
Cc: Amelia-Mowers *@*.*>; Manual @.*>
Subject: Re: [typst/typst] HTML Export (Issue #721
<#721>)
The problem is likely about fix-position.
A Module generated by eval::eval meets the requirement of being both
semantic and without precise positioning.
But a problem is that Func is quite block-boxed and tricky.
I think it will be a good idea to have a IR with all #Set applied to
elements and removed from document and all Func evaluated.
As for interactive content, it's easy to add things like #svg(...),
#html(...) , #pdf(...) which generate an element handled with specified
backend and ignored by other backends.
—
Reply to this email directly, view it on GitHub#721 (comment)
<#721 (comment)>, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AZFNGKVWOXAGV2ZCGX7V7E3Y7M72XAVCNFSM6AAAAAAWZQT2NGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBQGM4DINBTGE
.
You are receiving this because you are subscribed to this thread.Message
ID: *@*.***>
Disagree.
When deciding the precise location (i.e. line breaking), typst need to
know the width of the page, but this cannot be known before user actually
load the page in html output. Of course you can compile it to JavaScript,
but it may be tricky and inefficent.
—
Reply to this email directly, view it on GitHub
<#721 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMP4ZP2EFBT3R6B5ENRDXX3Y7NC47AVCNFSM6AAAAAAWZQT2NGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBQGM4DSOJWGY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Great idea to share some use cases @Adhalianna! I've another one. In my use case, I have teaching materials for students which I currently distribute as Pdf's. I'd love to use the same Typst source to generate a website containing the same information. The styling of the website would be completely different from the styling of the Pdf. I.e. I'd like to have sidebars similar to the current Typst documentation website and I'd like to add an option to search through the materials. I see two possibilities to achieve this:
|
|
I've extended the Pandoc reader and writer to support Now <div class="warning">
<p>This is a warning</p>
</div>is equivalent to #block(class: "warning")[This is a warning]in both directions (Typst ⇒ Html and Html ⇒ Typst). This also works for other formats than Html. This is not officially supported by Typst currently. It will give you an error on "an unexpected attribute: class". Try it out, let me know if it's useful. The code is here. |
|
I think we’ll eventually want to have support for We would also need a way to specify the |
and others
This is all very much my draft notes currently but will be worked upon in the comming days, so take everything with a grain of salt.
tl;dr This is looking really promising already in terms of translatability, the main callenge here will likely be the rewrite of the Layout process into separate steps as discussed.
Comparison Typst => HTML
How easy we could convert most functions into a
HTML/CSScounterpart.Text
#lorem()->#text#emph-><em>#linebreak-><br>#lower-><span class="lower">or similar withtext-transform: lowercase#overline-><span class="overline">withtext-decoration: overline#raw-><code>with syntax highlighting done over a<div>instead (possibly highlight.js)#smallcaps-><span class="smallcaps">#smartquote->#text#strike-><s>#strong-><strong>#sub-><sub>#super-><sup>#text-><span>#underline-><span class="underline">withtext-decoration: underline#upper-><span class="upper">or similar withtext-transform: uppercaseMath
Good sauce: https://fred-wang.github.io/TeXZilla/
accent-><mover>attach-><munderover>/<msubsup>scripts-><msubsup>limits-><munderover>binom-><mrow><mo>(</mo><mfrac linethickness="0px"><mi>n</mi><mi>k</mi></mfrac><mo>)</mo></mrow>cases-><mrow><mo>{</mo><mtable columnalign="left left" displaystyle="false"></mtable></mrow>equation-><math>frac-><mfrac>lr-><mrow>with<mo>mat-><mtable>root-><mroot>and<msqrt>round-> Same aslrstyles-> with cssop-><mo>or<mi>under/over-><munderover>variants->#textvec-><mtable>Layout
#align-><span class="center">withtext-align: center#block-><div>#box-><div class="box">withdisplay: inline-block#list-><ul>#colbreak-> maybe possible with cssbreak-before: ...#columns-> possible withcolumn-count: 2#grid-><div class="grid">withdisplay: gridand so on#hide-> either withopacity: 0or using a<div>with a fixed width#measure-> maybe possible with js?#move-> withposition: relative; top: y, left: x#enum-><ol>tbh, the name could maybe be improved#pad-> withpadding: 10pt 2pt ...#page-> Doesn't make sense in context of web media#pagebreak-> Same as#page#par-><p>#parbreak-> beginning of new<p>#place-> withposition: absolute; top: ...#repeat-> Could maybe be possible withwidth: 100%; overflow: hiddenbut very hacky#rotate-> withtransform: rotate(...)#scale-> withtransform: scale(...)#h-> possibly withposition: inline-block; width: ...#v-> same as#hbut with height instead of width#stack-> withdisplay: flex#table-><table>#terms-><dl>Visualize
Easily possible using SVG's
#circle-><circle>#ellipse-><ellipse>#image-><image>#line-><line>#path-><path>#polygon-><polygon>#rect-><rect>#square-><rect>Meta
#bibliography-> Likely with<a href="#el-id">but has to be looked into#cite-> same as#bibliography#counter->#text#document-> should be used to insert meta information into the HTML Document.#figure-><figure>#heading-><h1>/<h2>/ ...#link-><a>#locate-> Doesn't make much sense in the context of web media / possibly with JS#numering->#text#outline->#text#query-> can be ignored#ref-><a>#statemight be ignored#style-> possibly can be ignoredThe text was updated successfully, but these errors were encountered: