I’m investigating the possibility to bring a new markup language (Typst) to Hugo. Here are some information about it:
- The Typst contents can be converted into HTML via some external tools. So the problem may be mitigated if I can invoke some external program like Pandoc for Hugo to process typst contents.
- It seems that Hugo can import some go modules for Hugo’s content logic, which would be better where I can make typst feel like other markup languages.
Typst produces PDF.
Hugo produces HTML.
That leaves a huge gap.
Please check what I said:
The Typst contents can be converted into HTML via some external tools .
Reference: typst/src/export/svg/mod.rs at 966d7349945e762306d0865a14f9b49c3a7816ca · Myriad-Dreamin/typst · GitHub
Please check the reference, specifically:
I’ve been down this path before; it’s not pretty.
Um… I know that issue, but I do not mean the external tools convert a PDF produced by Typst to HTML. There has already other approach to make Typst directly to a HTML that has responsive layout.
Given that Typst’ first assumed purpose is to produce books like laTex, before going to enormous lengths to support a new language not separating presentation and semantics - a difficulty I found self-evident when reading the reference -
efforts should rather go into supporting epub as an output, as it’s basically a subset of html, hence involving much less work I believe.
So I have not figured out the reason that we could not assume that a well HTML has been produced. I thought the story should start from a dynamic HTML from Typst has already provided by some tool.
So what you envision is hugo asking a tool to produce the html and put the result in a website like it would with a standalone page plus some change of URLs, minification etc ? Ok, that’s a bit simpler than what I said in that case.
Yes the html output has passed all the testcase of typst and can be automatically adjusted for different screen sizes. The work turns to find a way that tool gets integrated into Hugo and benefits from the power of Hugo.
Typst is an interesting project, it’s actively maintained, and growing in popularity.
Conditions under which integration might occur:
- The “Typst to HTML” process must provide substantially the same output as “Typst to PDF”, and
- There is strong demand from a significant percentage of the Hugo user base, and
- The value offsets the cost (reasonable ROI)
And #3 is the most important: design, implementation, testing, documentation, support, and maintenance. If I had to guess, I would say that equates to over $25,000 USD in the first year—perhaps much more. We would also need to consider the opportunity cost (i.e., the delay of other features and fixes).
We currently have 6 content formats:
- Org (Emacs Org mode)
Combined, items 3, 4, 5, and 6 probably represent less than 1% of the content published with Hugo worldwide. To me, these seem like distractions without significant aggregate value. Yes, they are important to some users and organizations, but I’m not sure the value exceeds the cost.
With items 4, 5, and 6, we have to “shell out” to another executable, which means:
- Another dependency
- Another cross-platform matrix / headache
- Another source of risk, both in security and availabilty
- Performance is less than optimal
From what little I have learned so far, the “Typst to HTML” process would be yet another external dependency, similar to items 4, 5, and 6 above.
But, never say never.
I’ve stayed on this topic just now, and I found that you kept in replying status for a long time, so I’m waiting for it, and what you have said has been very helpful to me! If you don’t mind, I would like to respond to some of your points:
- I agree that Typst to HTML should not lack the quality that Typst to PDF has. Therefore, I spent two months researching Typst to HTML and successfully implemented it in Hexo, and the results seem to be quite good. Although Typst to HTML meets the normal use of various terminals where people can read, copy, and paste its text, it still lacks polishing, such as PDF Accessibility.
- I may not have given enough consideration to the concerns that the maintainers have raised, and I appreciate your input.
- This seems to be a similar issue as the second one has pointed out.
Regarding the second part, I could argue that Rust applications have strong platform extensibility, but as you said, they are external dependencies that may cause issues in a large system. This would be not good, at least in a Go application.
Outside of your response: I may not be seeking official support, but rather seeking advice from experienced Hugo developers and implementing it myself. What It might be is the Typst markup support can be imported as a go module by Hugo users like Hugo themes do. It is likely impossible, because I read the docs from Hugo’s GitHub and official sites. So I came here to find a more available solution.
Lastly, thank you for taking a long reply in the view of a maintainer. I learn a lot.