[HN Gopher] Exploring Typst, a new typesetting system similar to...
___________________________________________________________________
Exploring Typst, a new typesetting system similar to LaTeX
Author : judell
Score : 503 points
Date : 2024-10-12 18:41 UTC (1 days ago)
(HTM) web link (blog.jreyesr.com)
(TXT) w3m dump (blog.jreyesr.com)
| alphazard wrote:
| This is neat. I've used Latex before, and it definitely suffers
| from poor ergonomics. Both the language and tooling contribute to
| this.
|
| The selling point seems to be that this is more similar to
| Markdown. That makes sense, Markdown is objectively more common
| and has more users than Latex. I've used both, but Markdown way
| more often.
|
| Here's something I don't understand: it would be trivial to make
| Typst even more similar to Markdown, and yet it exists at some
| strange middle point in the language design space, arbitrarily
| far from Markdown.
| prettymuchnoone wrote:
| Could you give an example of how it could be more similar to
| Markdown? I recently used Typst for my bachelor's project and
| never really thought that it needed to be simpler
| huijzer wrote:
| Well maybe it's good to make it clear that it isn't markdown to
| avoid confusion? Also Typst has less syntactic sugar which also
| has benefits.
|
| More generally, I am really impressed by Typst's abstractions.
| I have typset my whole PhD thesis in it without needing any
| external packages. It was so easy to use the basic building
| blocks and write a few extra functions for the rest.
| raphman wrote:
| Is your template/source available by chance?
| huijzer wrote:
| Yes at https://github.com/rikhuijzer/phd-thesis
| llm_trw wrote:
| Markdown is a very poor language to try and use for anything
| other than single column typewriter like text.
|
| As evidenced by the fact that every project which uses it for
| more than that adds arbitrary extensions.
|
| The minimum viable language for non-mathematical technical
| documentation is reStructuredText.
| mbivert wrote:
| I'm not sure the selling point is similarity with markdown, but
| rather, to improve, or modernize LaTeX/TeX-the-language/s: TeX
| is _really_ archaic: if you 're curious, there's a series of
| articles by overleaf[0] detailing some of TeX's inner-working,
| quite insightful.
|
| I remember reading -- but can't find a source at the moment --
| that TeX originally didn't had counters; people came to rely on
| Church numerals[1] instead, before Knuth finally implemented
| them.
|
| EDIT: found out where I've read about it: [2]
|
| [0]: https://www.overleaf.com/learn/latex/A_six-
| part_series%3A_Ho...
|
| [1]: https://en.wikipedia.org/wiki/Church_encoding
|
| [2]: https://news.ycombinator.com/item?id=29713270
| sshine wrote:
| Places I've switched from LaTeX to Typst: My resume, research
| papers. Markdown was never a serious contender for my resume,
| since I want to control the rendering and the layout.
|
| Places I've switched from Markdown to Typst: Slides. There are
| some okay Markdown-to-HTML solutions, but they have this
| unfortunate side-effect that you move the slides to some other
| computer, and something breaks in your rendering. PDFs ftw.
| josephg wrote:
| I really wish typst had a good way to emit html. Id love to
| use it for blogging & technical writing and documentation.
| laurmaedje wrote:
| (Typst dev here.) That's one of the next big things we plan
| to work on once Typst 0.12 has shipped. :)
| josephg wrote:
| I can't wait! Thankyou for all your work - I really
| appreciate what you're building!
| gumbojuice wrote:
| Are there journals/conferences that accept typst for
| typesetting yet? It is probably my main reason for staying in
| LaTeX.
| ykonstant wrote:
| Perhaps you can use pandoc to turn Typst into Latex and
| then do the little dance of making it compatible with the
| provided headers?
|
| [ The latter is painful no matter what; once, I had a paper
| that I simply could not get to compile with the journal's
| header and had to give it to a wizard for examination. He
| did some manual TeX shenanigans resulting in a big blob of
| raw TeX at the preamble and it all worked. ]
| prettymuchnoone wrote:
| the pandoc typst reader is a bit barebones, it doesn't
| support packages (understandable) and seems to get
| confused with functions for me...though it's been a bit
| since i tried it
| auggierose wrote:
| How do you submit your research papers written in Typst?
| Animats wrote:
| > The selling point seems to be that this is more similar to
| Markdown.
|
| The problem is that extending Markdown syntax gets messy.
| #figure( image("image.jpg", width: 70%),
| caption: [ Observe the image in the picture
| ], ) <figure>
|
| This is kind of a strange blend of Markdown, CSS, JSON, and
| HTML. TeX at least has a consistent syntax.
| airstrike wrote:
| Strange to the untrained eye, perhaps. To me that just looks
| like a function. In a long document I recently wrote, I
| defined a custom function #let
| img(filepath, inset: 0.5em, caption: none) = {
| figure( box(inset: inset, stroke: 0.5pt + gray,
| image(filepath)), caption: caption );
| }
|
| and just used it like:
| #img("images/excel-5.0.png", caption: "Microsoft Excel 5.0
| was released in 1993.")
|
| edit: fixed unused inset param
| padjo wrote:
| Looks like it has a bug, the inset parameter is unused
| airstrike wrote:
| Whoops, thanks. Wrote this one-off and never needed to
| change the inset so didn't catch that. Fixed!
| smartmic wrote:
| These 6 lines actually put me off. Probably I have to read
| more about Typst syntax but, same for me, consistent syntax
| which covers necessary complexity wins over bending a markup
| language for purposes for which it was never intended.
| josephg wrote:
| It's best not to think of it as a markup language. It's a
| programming language designed around the needs of
| outputting pdfs.
|
| Structurally it's like a modern, nice version of php, only
| it's built for academic articles rather than emitting
| websites.
|
| The code snippet there packs in about 8 typst concepts all
| at once. It's like if someone showed off how "simple" c++
| is by showing some template-heavy magic. It's
| straightforward once you've spent time with the language,
| but it's a pretty terrible place to start learning typst.
| (That example shows expression mode, block mode, function
| calling, tags, named arguments, and probably more. Whew!)
| gauge_field wrote:
| That is a great analogy. When I wrote my note/hws in
| latex, I had the urge to go look for a package more
| frequently. When I started converting those docs into
| typst, I was able to hack around more easily, it really
| did feel like a modern programming language that has
| great error messages and that I enjoyed writing in. It
| did not feel complex, especially with the help of
| compiler errors messages
| __mharrison__ wrote:
| It's a little odd at first. I would recommend reading
| through the tutorial (which is quite good) and you might
| start to see some of the method to the madness.
| orangeboats wrote:
| It may be _similar_ to Markdown if you squint your eyes real
| hard, but it 's not Markdown.
|
| Furthermore, quoting a random snippet without any elaboration
| is unhelpful and only serves to confuse people (as it already
| did for the other comment!)
|
| # means "evaluate". figure(...) is the function being
| evaluated.
|
| The syntax inside figure(...) is fairly regular, not too
| different from what you'd see in typical programming
| languages (but with a document-oriented twist like the %).
|
| <figure> may seem to be related syntatically to #figure(...),
| but it's not. It's just a label. Like an HTML div tag with
| id="figure". It can very well be changed to <foo> in your
| example and it'd still work.
| SkiFire13 wrote:
| Was do you find inconsistent here? It seems pretty consistent
| to me, except maybe the <figure>
| chrisweekly wrote:
| and that <figure> tag is kind of moot -- as another
| commenter mentioned, it could have been some other html tag
| like a div
| SkiFire13 wrote:
| It's not a tag, there aren't even HTML/XML tags in Typst.
| The effect of that <figure> is giving the #figure(...)
| element the label `figure` (i.e. the name is what's
| inside the <>). Probably using the label "figure" was not
| the best choice for an example, something like
| <my_figure> would have been a bit less confusing showing
| that it is an arbitrary name/id that you choose.
|
| Edit: and I think you also misinterpreted the other
| comment about the <div>. It wasn't about using <div> in
| place of <figure>, but rather that using <figure> in
| typst does the same thing as id="figure" in HTML.
| SkiFire13 wrote:
| Personally, I don't really care about it being similar to
| Markdown. After all if someone wants Markdown they can just use
| that... For me the selling point is that it provides almost the
| same features as Latex except with a sane scripting language.
| This allows me to actually write my own scripts, as opposed to
| Latex where even understanding how basic stuff worked was a
| huge pain.
| __mharrison__ wrote:
| I write markdown and use Pandoc (plus some filters) to create
| Typst. Happy to never touch LaTeX again.
| necovek wrote:
| As a side note, TeX engine could support Markdown or HTML or
| many other syntaxes too: it's easy to redefine control
| character in TeX to be anything instead or in addition to "\"
| (I've actually done that with Plain TeX a couple decades
| earlier to allow two-byte UTF-8 input by making all first-bytes
| of valid 2-byte UTF-8 sequences into control characters).
|
| So, LaTeX being "unergonomic" is only relative -- it's pretty
| ergonomic compared to things like HTML but especially DocBook
| or TEI SGML/XML schemas, but less ergonomic than Markdown or
| even Plain TeX. However, it inherits the most complex part
| where it is extremely ergonomic from Plain TeX (for the most
| part): editing math formulae.
|
| But it's also much richer in expressing intent than any of
| those, and from what I can see, compared to Typst as well --
| LaTeX is basically semantic markup for excellent printed output
| (where Plain TeX is excellent printed output with no semantics,
| DocBook/TEI are pure semantic markup, and HTML/Markdown/Typst
| are somewhere in the middle too).
| vivekd wrote:
| I've tried typsit and Ive really been enjoying it. It's very easy
| to learn and easy to use. It's a new project so it can't as of
| yet replace the functionality of LaTeX's many packages. However
| it is good for quick and easy texts, it's replaced markdown and
| office for me for writing simple documents on a computer.
| darkteflon wrote:
| Love to hear some informed opinions on typst versus quarto.
| timeon wrote:
| There is overlap, with creating whole documents, but I can
| imagine at some point one could use Typst inside Quatro. (Like
| using Typst inside Obsidian.)
| kgwgk wrote:
| https://quarto.org/docs/output-formats/typst.html#raw-typst
| fourthark wrote:
| Yes, Typst is fully supported as an output language of
| Quarto.
|
| Exceptions: you'll need extensions for slides, some layouts.
| No books support, yet.
|
| [I work on this.]
| ternaryoperator wrote:
| Search in HN for Typst and you'll see this link is routinely
| posted and as little as three months ago got nearly 200
| comments.
| bitexploder wrote:
| Built my resume with typst and know of several other folks using
| it for serious document typesetting. It is a very nice and modern
| typesetting system and language that just feels easy to make it
| do what I want.
|
| It incorporates elements like templates and it is very easy to
| create reusable content "functions". It is everything I want out
| of LaTeX while being super fast and easy to use.
|
| Edit: pandoc can generate typst output if you want to explore :)
| sega_sai wrote:
| I was hoping that the syntax for equations would be borrowed from
| LaTeX but it is not the case unfortunately. I would like to
| switch away from LaTeX, but i think the syntax for equations in
| LaTeX is pretty sensible actually.
| Gualdrapo wrote:
| Have you tried with ConTeXt? As LaTeX, it's built atop TeX -
| though it's not as modular (and popular) it's more powerful.
|
| I'd like to like Typst, but (as mentioned the other day) it
| follows the same model as LaTeX - great for some predefined
| styles, but the moment you want or need something different
| you'd need to get third party plugins, and with that all the
| perks and cons they may have.
| thangalin wrote:
| > Have you tried with ConTeXt?
|
| Have you taken a look at my text editor, KeenWrite?
|
| https://keenwrite.com/screenshots.html
|
| The text processing chain for KeenWrite is:
| Markdown (input) -> XHTML (export) -> ConTeXt (import) -> PDF
| (output)
|
| The look and feel of the final PDF document is controlled by
| a theme, which allows complete customization.
| cbolton wrote:
| Do give typst's syntax a try! I had the same worry as you but I
| now find typst's syntax more pleasant to write, and the
| resulting code is much more readable. Instead of
| \frac{1}{\alpha - 1}\ \mathrm{for}\ n\in\{1, \ldots, N\}
|
| you get to write 1/(alpha - 1) "for" n in {1,
| ..., N}
| elashri wrote:
| Previous discussions about Typst.
|
| https://news.ycombinator.com/item?id=41014941
|
| https://news.ycombinator.com/item?id=38354422
|
| https://news.ycombinator.com/item?id=38047224
|
| https://news.ycombinator.com/item?id=35250210
|
| https://news.ycombinator.com/item?id=34423590
| dang wrote:
| Thanks! Macroexpanded:
|
| _Typst: An easy to learn alternative for LaTex_ -
| https://news.ycombinator.com/item?id=41014941 - July 2024 (187
| comments)
|
| _Building the New Hypermedia Systems using Typst_ -
| https://news.ycombinator.com/item?id=40986352 - July 2024 (1
| comment)
|
| _No-Signup Typst Tools_ -
| https://news.ycombinator.com/item?id=40905678 - July 2024 (1
| comment)
|
| _Typst Symbol Classifier_ -
| https://news.ycombinator.com/item?id=39878069 - March 2024 (1
| comment)
|
| _Show HN: A no-frills CV template using Typst and YAML to
| version control CV data_ -
| https://news.ycombinator.com/item?id=38990197 - Jan 2024 (8
| comments)
|
| _TexText: Re-editable LaTeX / typst graphics for Inkscape_ -
| https://news.ycombinator.com/item?id=38804431 - Dec 2023 (2
| comments)
|
| _Typst - Compose Papers Faster_ -
| https://news.ycombinator.com/item?id=38354422 - Nov 2023 (134
| comments)
|
| _I rewrote my CV in Typst and I 'll never look back_ -
| https://news.ycombinator.com/item?id=38047224 - Oct 2023 (25
| comments)
|
| _typst-conceal.vim: cute UTF-8 conceal for typst_ -
| https://news.ycombinator.com/item?id=37862666 - Oct 2023 (1
| comment)
|
| _Typst 0.7: floating content, improved SVG support and better
| math layout_ - https://news.ycombinator.com/item?id=37038708 -
| Aug 2023 (1 comment)
|
| _Typst: Finally a Solid LaTeX Alternative_ -
| https://news.ycombinator.com/item?id=35835703 - May 2023 (3
| comments)
|
| _Typst starts its public beta test and goes open source_ -
| https://news.ycombinator.com/item?id=35364822 - March 2023 (1
| comment)
|
| _Typst, a new markup-based typesetting system, is now open
| source_ - https://news.ycombinator.com/item?id=35250210 - March
| 2023 (146 comments)
|
| _Typst: A Programmable Markup Language for Typesetting [pdf]_
| - https://news.ycombinator.com/item?id=34423590 - Jan 2023 (53
| comments)
|
| _What If LaTeX Had Instant Preview?_ -
| https://news.ycombinator.com/item?id=33222356 - Oct 2022 (23
| comments)
|
| _Typst: Compose Papers Faster_ -
| https://news.ycombinator.com/item?id=32209794 - July 2022 (30
| comments)
|
| _Typst: Compose Papers Faster_ -
| https://news.ycombinator.com/item?id=32205005 - July 2022 (1
| comment)
| pseingatl wrote:
| Does Typst have epub or html export?
| njkleiner wrote:
| Both are on the roadmap, apparently.
|
| https://github.com/typst/typst/issues/188#issuecomment-14933...
| CJefferson wrote:
| Both have been "on the roadmap" from day 1, with little
| progress.
|
| Many open source projects put "we should make our system
| accessible to disabled vision issues" on the roadmap,
| depressingly few projects then actually do it.
|
| Even latex, which in academic circles is famous for not
| having html output, nowadays produces more accessible output
| than typist.
| Vallaaaris wrote:
| You are right that it's been on the roadmap for a while,
| however, it's definitely very high on their priority list.
| The recent update (v0.12) contained a lot of necessary
| internal refactorings of the layout engine, and they've
| mentioned on the Discord that after v0.12, they will start
| work on HTML output.
| CJefferson wrote:
| I really hope so, and I will start recommending typst
| when there is good accessible output.
|
| However, it's also been a "top priority" since basically
| the first release.
| samatman wrote:
| The issue is a bit more than a year old.
|
| Feel free to step up and close it. Complaining about it
| isn't going to add velocity to a new project.
| vslavkin wrote:
| I've been looking into it. It's `blazingly fast` (aside from the
| rust joke, it really is way faster than latex), the syntax is
| more "modern", consistent, etc.
|
| The main problem is the popularity. It just does not have enough
| packages, at least for my use case.
|
| I mainly do a lot of equations (simple math), and a loooot of
| tikz (forest, circuitikz, pgfplots, etc.)
| [https://gitlab.com/vslavkin/escuela/-/tree/main/5to?ref_type...]
| I'm not a fan of tikz, but it's the only way to mantain the
| graphics homogeneous, clean, easily editable, compiled with the
| document and with links/references. Cetz (the typst alternative)
| is years behind. I've been thinking of contributing, but tikz is
| really complex, and I don't have enough time ATM.
|
| Besides the typst packages, it also lacks the editor packages. I
| am an emacs user _insert joke here_ , and I use AucTeX, which is
| a really great, and gigant package to edit latex (+cdlatex).
| AFAIK there's nothing like it for typst, which makes me way
| slower.
|
| Another thing is that they changed the math syntax. While the
| latex one wasn't perfect it was insanely popular, because of its
| use on markdown and a lot of pages (and this was thanks to
| mathjax iirc).
|
| The good thing is that something like latex or typst will always
| be needed, so there'll always people that want to have something
| like it; latex/tex isn't really great, and it has a really low
| entry bar.
|
| Maybe I'll switch when I have more time to study it and make
| packages. (It could be as soon as next year or a late as...
| never)
| sourcepluck wrote:
| > I use AucTeX, which is a really great, and gigant package to
| edit latex (+cdlatex)
|
| This is tangential, but have you any quick tips for someone
| looking to get started with AucTeX? I'm a comfortable Emacser
| who has started to occasionally think of some document I'd like
| to do in LaTeX (some maths questions for a student, or an
| overview of some topic). I've looked at AucTeX once or twice,
| and ran away thinking, oh, I'll do that some other time.
|
| What is the order of events? Should I make a few really basic
| LaTeX documents first with a terminal, and then try AucTeX?
| fiddlerwoaroof wrote:
| I've found that the best way to learn a new emacs package is
| incrementally: for something like Auctex, I initially just
| enable it for my latex documents and then I configure and
| learn features as I need them, never learning too much at
| once. Even with minimal configuration, it gives you some nice
| things like imenu entries for headings and a menu that
| surfaces some of the basic latex feature
| vslavkin wrote:
| It's pretty easy, actually. First, install the plugin, I use
| this with elpaca: ``` (use-package latex :ensure nil :hook
| (LaTeX-mode . TeX-fold-mode) ;; I don't use a lot the fold,
| but it's useful (LaTeX-mode . turn-on-reftex) ;; For biblatex
| (LaTeX-mode . LaTeX-math-mode) ;; For inserting math symbols,
| altough I think cdlatex is better (LaTeX-mode . outline-
| minor-mode) ;; If you use outline to surf throughout the
| buffer ;; (LaTeX-mode . abbrev-mode) ;; If you use abbrevs
| (LaTeX-mode . visual-line-mode) ;; Either this or auto-fill-
| mode, which will return when you have more than the `fill-
| column` characters (LateX-mode . prettify-symbols-mode) ;;
| Will replace most latex math symbols with unicode :bind (:map
| LaTeX-mode-map ("s-a" . abbrev-mode) ("s-c" . preview-
| clearout-at-point) ("s-q" . LaTeX-fill-buffer) ) :custom
| (TeX-auto-save t) (TeX-parse-self t) (preview-auto-cache-
| preamble nil) ;; Setting this to t should be faster, but for
| me it wouldn't work with lualatex (TeX-command-extra-options
| "-shell-escape") ;; Use pdf-tools to open PDF files (TeX-
| view-program-selection '((output-pdf "PDF Tools"))) ;; I use
| pdf-tools to read the pdf in emacs (TeX-save-query nil) ;;
| Auto save without saving (TeX-show-compilation nil) ;; Hide
| the compilation (TeX-engine 'luatex) (reftex-plug-into-AUCTeX
| t) ;; I think this is redundant (TeX-source-correlate-mode t)
| ;; To enable synctex (click on the pdf to go to source) (TeX-
| source-correlate-start-server t) :config (add-to-list 'TeX-
| command-list '("Make" "make" TeX-run-command nil t)) ;;
| Update PDF buffers after successful LaTeX runs (add-hook
| 'TeX-after-compilation-finished-functions #'TeX-revert-
| document-buffer) ) (use-package auctex
| :ensure (auctex :pre-build (("./autogen.sh")
| ("./configure" "--without-texmf-dir" "--with-lispdir=.")
| ("make"))) :demand :mode (("\\.tex\\'" .
| LaTeX-mode) ("\\.tex\\.erb\\'" . LaTeX-mode)
| ("\\.etx\\'" . LaTeX-mode)) :config
| (with-eval-after-load 'preview (dolist (env
| '("tikzpicture" "circuitikz")) ;; I want to preview
| tikzpictures and icrcuitikz (add-to-list
| 'preview-default-preamble (concat
| "\\PreviewEnvironment{" env "}") t)) (add-to-list
| 'preview-inner-environments "axis") ;; And axis (pgfplots)
| (set-face-attribute 'preview-reference-face nil
| :foreground "black" :background "white")))
| ;; Tikz previews look better with a white background, if you
| don't use it, it's way cooler to preview latex with a
| "trasparent" background
|
| ```
|
| And then the usage:
|
| Just continue using latex as you are, and then try to
| incorporate auctex commands. The most useful being =latex-
| environment= and =latex-section= + the previews. So don't
| write \begin{env}... nor \section{sec}, and instead use C-c
| C-e and C-c C-s (They seem hard, but they aren't) For the
| previews, use C-c C-p ... (there are a lot of options there,
| using which-key you can see them) And for compiling use C-c
| C-c. I recommend reading
| https://karthinks.com/software/latex-input-for-impatient-
| sch... and if you have the time, read bits of the manual
|
| (Sorry, I can't get the code to display right. goto
| https://gitlab.com/vslavkin/emacs-
| config/-/blob/master/emacs... and search for the latex
| heading)
| josephg wrote:
| > Besides the typst packages, it also lacks the editor
| packages. I am an emacs user...
|
| The typst editor plugin for vscode is pretty great. It gives
| you a split view of source & pdf, and you can cmd+click on
| either side to scroll to the corresponding source / rendered
| output. It also does things like give you autocomplete on
| fields from externally referenced json data.
|
| Obviously, that might be no help if you're married to eMacs.
| But if you're a little promiscuous with editors like I am, give
| it a try.
| porridgeraisin wrote:
| Latex workshop gives an identical experience with latex
| josephg wrote:
| Yeah I think its fair to say latex has a much more mature
| ecosystem. And we should expect nothing less from something
| made in 1985. Its almost 40 years old.
|
| But typst is catching up as fast as it can. I find it very
| usable already.
| porridgeraisin wrote:
| Yeah, my guess is that it'll fall on either side of the
| same go/c vs c++/rust "simple rules with more implicit
| rules in your head" vs "complex tool with less in your
| head" divide in people's opinion.
| josephg wrote:
| Can you say more? That's not my experience of it.
|
| I think it's more like latex is like c++ and typst is
| like zig. C++ & latex have been worked on for decades,
| and has all this design baggage it carries around. An
| ugly macro system, weird "compile it 3 times" things. But
| it also has decades of work filling out the 3rd party
| package ecosystem and decades of stackoverflow questions
| and answers.
|
| Zig & typst are rewrites from scratch with new ideas. The
| core is better designed, since they have been able to
| learn from what came before and have a do over. But
| they're missing the decades of incremental work fixing
| bugs and filling out the ecosystem. So, yeah, I'm sure
| the eMacs plugin is worse for typst and latex. It's all
| just ... newer.
| vslavkin wrote:
| I don't know which of the several typists plugins are you
| talking about, but they all seem decent, but years from
| achieving the features auctex has.
|
| Just to say, the most important features:
|
| Well, the feature you mentioned of clicking the PDF and
| redirecting to the source.
|
| Preview in the same buffer (window) as the code
|
| It uses other regexps to recognize the enabled packages, and
| then adds the package's macros and environments to its list,
| so with a command you can open an environment or macro, and
| it recognizes which packages you are using, if you are in a
| math environment, etc. and shows only the ones you can use in
| the context. It's like a super-intelligent set of macros.
|
| AucTex has also great support for bibtex/biblatex, and
| glossary/glossaries, both for using the macros and for
| compiling.
|
| Automatic, intelligent, labeling.
|
| And a lot more (altough this is probably the biggest latex
| package, there are a lot of other smaller packages that are
| also extremely useful) . Maybe it's not the hardest package
| to do, but it needs a lot of people and time to replicate,
| basically what typst is also lacking, for now.
| fncypants wrote:
| The current actively-developed VSCode extension is
| Tinymist. Its workflow is great and addresses all your
| issues (to the extent they are even relevant to Typst):
|
| > Well, the feature you mentioned of clicking the PDF and
| redirecting to the source.
|
| Tinymist does this. Click on text and it redirects the
| document buffer to the corresponding source text.
|
| > Preview in the same buffer (window) as the code
|
| Tinymist previews in a separate tab for side-by-side real-
| time writing with a preview.
|
| > It uses other regexps to recognize the enabled packages,
| and then adds the package's macros and environments to its
| list, so with a command you can open an environment or
| macro, and it recognizes which packages you are using, if
| you are in a math environment, etc. and shows only the ones
| you can use in the context. It's like a super-intelligent
| set of macros.
|
| This sounds like an artifact of Tex. The standard Typst
| library is very thorough. And for everything else, Typst
| has automatic retrieval of community packages. Just add an
| #import and it just works: #import
| "@preview/example:0.1.0": add #add(2, 7)
|
| > AucTex has also great support for bibtex/biblatex, and
| glossary/glossaries, both for using the macros and for
| compiling.
|
| This just works with Typst in-the-box for bibliographies,
| and with the glossarium package for glossaries (just add
| with: #import "@preview/glossarium:0.4.2": *). But one
| thing a Typst IDE like Tinymist or the web service adds to
| the writing environment is an autocomplete for labels and
| citations. Just start typing the reference and get
| autocomplete options.
|
| > Automatic, intelligent, labeling.
|
| Not sure what this means, but you can add a label to
| headings, figures, etc. and quickly reference them with
| @label, and the current IDEs
| vslavkin wrote:
| It seems good, and there's an emacs version, altough
| simpler than auctex.
|
| Not having the preview in the code buffer, isn't a
| dealbreaker, especially when typst is so fast, but it's
| still a useful feature.
|
| The part of the packages I wasn't talking about a tex
| feature but an emacs one. When you import a package,
| it'll usually add environments or macros (in typst i
| believe they are called commands). Emacs would recognize
| thay you imported a package and with a shortcut you are
| able to quickly insert a command without writing it
| manually (because that's too much time... Like a
| template) It also recognizes the document type for
| inserting sections, and whether you are or not inside a
| math environment.
|
| Albeit, looking a bit more in typst I think it's as
| mandatory as in latex. Commands tend to be simpler and
| shorter, especially sections. So maybe it wouldn't impact
| as hard as I had thought.
|
| For references, using bib files, it would be almost as
| good as latex.
|
| The auto labeling is useful for align envs or itemizes.
| AucTeX adds a label to each item or equation
| automatically. Again, not a dealbreaker, but would be
| great.
|
| Reading a bit more, it seems that typst is a bit more
| different that what I had thought. I will not switch till
| cetz is more mature or I find another alternative.
|
| Maybe I'll remake my Cv in typst just to try it out (+ my
| cv is horrible)
| josephg wrote:
| With typst you can get autocomplete for symbols imported
| from packages or defined locally. And your bibliography
| can use the same .bib files as latex if you want to. I'm
| pretty sure the typst editor plugins also know which mode
| you're in and give you different autocomplete suggestions
| depending on the mode. But yeah, it's probably still not
| quite as mature. But it is, in my opinion, much better
| designed.
|
| What features do you want from cetz that you think are
| missing?
|
| (And yeah making something with it is a good idea. You'll
| get much more of a sense of it by playing around with
| it.)
| Vt71fcAqt7 wrote:
| One of the worst things about LaTeX is its reliance on packages
| to do anything useful. In fact, LaTeX is itself essentially
| just a set of packages for Tex. I hope whatever replaces LaTeX
| finds a solution that covers as many usecases as possible
| without needing any packages.
| tolerance wrote:
| Writing Typst in Emacs is pretty easy with this setup.
|
| https://codeberg.org/meow_king/typst-ts-mode/wiki/
|
| https://github.com/Myriad-Dreamin/tinymist/tree/main/editors...
| vslavkin wrote:
| It looks nice, but it doesn't have as many features, altough
| I understand that, as typst is easier to write, a lot of
| things aren't needed. I'll try it out when I have time
| aulin wrote:
| > I am an emacs user insert joke here
|
| In my totally anecdotal experience the intersection between
| proficient LaTeX users and emacs users is pretty large.
|
| So having good emacs support would be a big selling point.
|
| My experience on the other hand is also those people never
| complain about LaTeX, so they're probably not the target for a
| new typesetting system.
| vslavkin wrote:
| Yeah, I've also seen that in the latex forums, Emacs is
| strangely popular. I don't think that there's someone that
| doesn't have at least one complaint about latex. But probably
| there are a lot of people that try to understand its flaws
| and start to love it or something after using it for dozen of
| years, and don't want to spend the time to switch. (Stockholm
| syndrome??)
| cbolton wrote:
| I have a similar "user profile" and find typst a much better
| experience. It's true CeTZ is not as mature, _but_ it 's much
| easier to extend where it's missing functionality (because you
| have a nice, normal scripting language to work with instead of
| a macro mess). But math is the reason I smile every morning
| when I open my .typ files. It's so clean and readable, and a
| pleasure to write, compared to LaTeX. It's also not as mature
| so I can imagine some things can be tricky to do in typst
| depending on your needs. But it does everything I need, and is
| only getting better (I see that several of the annoyances I
| found are getting fixed in the next release).
|
| Can't comment on the AucTeX part, I'm using helix and typst
| support is not great but good enough.
| vslavkin wrote:
| Yeah, that's why I thought of contributing to cetz, the
| language is definitively way better. Although I think that
| for basic usage, I like the tikz way a bit better. The main
| problem I'd say is circuitikz. It's a really big and
| versatile project, and I would need years to make it work.
|
| However, thinking about it, it's not like anyone other than
| me cares about how clean my circuits are. They are high
| school notes, and the rest of my classmates are doing it on
| paper, but I haven't found a good alternative. One that
| probably isn't as clean as circuitikz, but easier, faster and
| easy to integrate to latex/typst
| andrepd wrote:
| Well that's going to remain an issue for a long time: TeX has
| close to half a century head start :)
| larsrc wrote:
| Judging from the releases page on Github, Typst has been in the
| public since May 2023. You can hardly expect it to catch up
| with decades of LaTeX packages in that time.
| vslavkin wrote:
| Typist is a bit older than that, it was born in 2018.
| Regardless, I don't expect it to have feature parity with
| latex, but it still lacks several important and simple
| packages. Besides, I was just making a point on why people in
| a similar situation to mine should/shouldn't use it for big
| documents; what I found good and bad; and what would
| maintainers need to develop for more people to switch
| YmiYugy wrote:
| In the very limited time I used typst it has been pretty amazing,
| but imho there is one missing feature that a LaTeX successor, but
| even more so, templating engine should have. Come up or adapt a
| format, that can defer certain styling decisions to the consumer
| of the document. Stuff like, font, font size, line spacing,
| citation style, double or single column, numeration style, etc.
|
| On a different note, we got to find a better way to exchange data
| than pdf reports. In my totally made up estimation about 10% of
| development time for enterprise software is spend on variations
| of these pdf templating tools and another 20% on extracting data
| from such generated pdfs.
| mixmastamyk wrote:
| That's what html was supposed to be; probably still could. Epub
| uses it as well, though readers are not equivalent.
| justinpombrio wrote:
| You can do that in a couple different ways in Typst. First, if
| the user passes content into the template, then it's the user's
| content that ultimately gets to choose its styling. That is,
| there are three places that a style can be set:
|
| 1. In the content passed that the user passes to the template
|
| 2. In the template itself
|
| 3. By the user, outside the template
|
| They take priority in that order.
|
| OTOH, if the template really wants control, it can take
| optional styling arguments with defaults, and do as it likes
| with them. And if it wants content from the user that the user
| doesn't get to style, it can take that content as a string.
|
| It's a fantastic system, so far as I've seen.
| BoingBoomTschak wrote:
| That was exactly my reaction after stumbling upon
| https://typst.app/universe/package/modern-cv/ I just want a
| replacement for ModernCV, not downloading MBs of fonts I don't
| want to use.
| Klasiaster wrote:
| You can embed attachments in PDFs. This way you could include
| CSV or JSON files into your PDF report. For a quick way doing
| it with CLI see `qpdf --help=add-attachment`
| perlgeek wrote:
| > Come up or adapt a format, that can defer certain styling
| decisions to the consumer of the document. Stuff like, font,
| font size, line spacing, citation style, double or single
| column, numeration style, etc.
|
| We have that, it's called HTML. The use case is quite different
| from PDF though.
| kaba0 wrote:
| There is no universally correct layouting. I for one absolutely
| detest epub versions of scientific books. Even if they are the
| official variant and not a generated one from some other format
| that understandably sucks, diagrams will be all around and I
| have to go back and forth and lose context. PDFs for all their
| shortcomings are a godsend and they do their single job
| perfectly. I much rather zoom in on my phone to a paragraph
| than look at a badly placed diagram taking up half a page in an
| unrelated context.
| viralsink wrote:
| I like Typst, but I've had a couple issues so far:
|
| 1. The line spacing. It's not defined as baseline to baseline,
| but as the space inbetween two lines of text. Very difficult for
| an assignment with a prescribed line height since it usually
| refers to a baseline-baseline measure. 2. While having multiple
| columns is really easy, adding floating elements for the text to
| wrap around seems not possible. There's a reason all these CV
| templates have the info bar on the right instead of the left.
| Aaron2222 wrote:
| You can change how the bounding box Typst uses for layout is
| defined (i.e. set the top and bottom edges both to the
| baseline), then I would imagine the spacing would be baseline
| to baseline. Would need to adjust the space before a paragraph
| to compensate though.
| suvadivian wrote:
| https://github.com/typst/typst/issues/4224
|
| This issue and others like it are dealbreakers for me. There
| are numerous related issues, but the developers are stubbornly
| sticking to their interpretation--using the older definition of
| leading from the days of metal type, rather than the more
| modern concept of line-spacing. No other software or modern
| typesetting system I know of uses this approach anymore. This
| is particularly frustrating since I work with a lot of
| multilingual text, including Arabic, and it's very difficult to
| align the baselines when setting text in more than one column.
| viralsink wrote:
| I gotta say though, Typst is powerful enough to implement a
| custom line spacing. Using the measure command you can get
| the height of the current font and use that to automatically
| convert. It's just cumbersome.
| laurmaedje wrote:
| As one of the core developers, I would say "stubbornly
| sticking to their interpretation" is not entirely fair. I am
| open to changing this, but I don't want to do it hastily ---
| because that means changing things twice. Figuring out all
| the correct behaviours, in particular with equations and
| inline objects, is challenging. I tried to constructively
| present some arguments in favor and against the proposed
| changes in the linked issue, but I simply did not have time
| to push things forward beyond that myself so far.
| moelf wrote:
| the current show-stopper issue is that Typst can't insert PDF as
| figure[1], this makes a lot of scientific publication workflow
| impossible.
|
| [1]: https://github.com/typst/typst/issues/145
| me_jumper wrote:
| I thought about trying it. This just killed it for me...
| xkevio wrote:
| It's a somewhat difficult issue and I understand being hesitant
| because of this. Converting to SVG is one possible path around
| it which isn't too bad but having it natively is of course even
| better.
|
| The thing is, inserting PDF for just the PDF export would be
| quite easy. The issue is the other export targets Typst
| supports (SVG and PNG) as that would require some form of
| rasterization / a full blown PDF engine written in Rust without
| C-bindings because of the web app and that simply does not
| exist yet.
|
| And the developers are hesitant to just add features for one
| specific export target which I get.
| __mharrison__ wrote:
| I've moved all of my LaTeX-based content creation to Typst.
|
| It's:
|
| - Fast--Compiling my books would take around 1 minute (I often
| had to compile twice due to indexing). With Typst, it takes less
| than 5 seconds.
|
| - Easy to write--I actually don't write it, I wrote a bunch of
| Pandoc plugins to tweak the output from Pandoc (I write all my
| books in Jupyter these days, so lots of markdown).
|
| - Easy to read--I've used LaTeX for years (and wrote a bunch of
| tooling around it) and still couldn't tell you when to use a { or
| a [. Typst is very readable.
|
| - Easy to script--Okay, I did write some Typst the other day. I
| migrated my LaTeX-based invoicing system to Typst. I created a
| list of objects with pricing and count and was able to throw it
| into a table easily. It has less code than my LaTeX version,
| which was using a library, and is easier to read. (I did need to
| write a function to properly format $ because that doesn't exist.
| A few rounds with AI made that easy.)
|
| - Has great error messages--If you've used LaTeX, you know what I
| mean.
|
| My needs are different from others, but I'm writing PDFs that
| need to be printed into a real book that looks professional. This
| includes front matter, footnotes, callouts, page numbers, page
| headers and footers, and indexes. I don't do a lot of math-heavy
| stuff, so I can't comment on that. And the widow/orphan support
| is a little weak.
|
| Otherwise, I'm happy to never use LaTeX again!
| akoboldfrying wrote:
| With your experience of both, have you found that Typst has
| fewer issues with conflicting/non-commutative plugins than
| LaTeX does?
|
| Because that's where I lose the most time with LaTeX: packages
| often mess with the (piles of) global state in ways that
| sometimes conflict, and the only "solution" seems to be that,
| if you're very lucky, sometimes conscientious package authors
| will try to "detect" (through various hacks) whether some other
| known-conflicting package has already been loaded and adjust
| accordingly. I didn't see any mention in TFA of any module
| system or even local variables in Typst to contain this
| explosion of complexity, so I suspect it will be just as bad in
| this respect as LaTeX is once there are as many plugins
| available.
| __mharrison__ wrote:
| To be honest, I don't know if I've seen conflicting packages.
|
| Do you have specific examples?
| akoboldfrying wrote:
| It's been a while, but I vaguely remember that the hyperref
| LaTeX package for making URLs didn't play nicely with
| certain other packages -- possibly with one of the citation
| packages.
|
| Sorry I can't be more specific. I definitely have memories
| of reordering \usepackage{} statements until "it worked"...
| susam wrote:
| This is correct. In fact there is a highly upvoted
| question about it on TeX Stack Exchange:
| <https://tex.stackexchange.com/q/1863>.
|
| See also <https://latex.org/forum/viewtopic.php?t=25156>.
| seanhunter wrote:
| There are quite a few examples, but here's two that have
| affected me
|
| 1)pstcol has to be loaded before graphicx (I forget the
| reason but it just does)
|
| 2) if I use pdftricks I have to unset the "clipbox" command
| because it conflicts with the one in adjustbox.
|
| As you say in another comment, given how latex reports
| errors debugging these can be a Fun time.
| justinpombrio wrote:
| I imagine you're projecting how LaTeX works onto Typst,
| though despite years of use and a PhD in PL I never really
| figured out how LaTeX works so I'm not certain.
|
| I don't think Typst _has_ a lot of global state to get
| corrupted. Like, if one package defines a variable `foo` and
| another package defines a variable `foo`, and you use both of
| them (and don 't try to import `foo` from both), it's not
| like those `foo`s are going to conflict with each other. Is
| that the sort of issue that LaTeX packages run into?
|
| Likewise, you don't modify typesetting in Typst by modifying
| global state like you do in Latex. You use `set` and `show`,
| which are locally scoped. You never need to, like, set the
| font size, then write some stuff, then remember to set it
| back. You just put `set font(size)` around precisely the
| stuff you want to be bigger.
| necovek wrote:
| In general, with the TeX "engine", you can locally scope
| most changes by simply wrapping them in braces {}.
|
| However, if you have a need to override something globally
| (eg. a global heading font, or spacing at the paragraph
| level), there is really no way to do it other than doing it
| globally.
|
| How would Typst solve this without having the same problem?
| Eg. how can I have a package that sets every "the" in red
| colour, without it interfering with a package that sets
| every "the" in blue or titlecase?
|
| Perhaps it's structured better (I would hope so, with ~40
| years of learnings since TeX was introduced), but the
| problem seems unavoidable if you allow things like the
| above.
| akoboldfrying wrote:
| >how can I have a package that sets every "the" in red
| colour, without it interfering with a package that sets
| every "the" in blue or titlecase?
|
| Exactly.
|
| Broadly, the things you might want a package/plugin to do
| can be categorised as "local" (e.g., add some new type of
| content in a fixed-size box that the layout engine can
| then treat the same way as it treats any other such box)
| or "global" (e.g., change where floats appear). Making
| local effects play together can be easily handled with
| standard PL ideas like lexical scoping, but doing the
| same for global things is much harder: it strongly
| depends on exactly what knobs (API) the base typesetting
| engine provides. We now have design patterns like
| Observer to help make creating such "global" effects
| simpler, _assuming that their effects are genuinely
| orthogonal_ , but what if they aren't?
|
| A plugin that sets each "the" to red clearly conflicts
| with a plugin that sets each "the" to blue: at most one
| of them can "win", so which is it? Does it depend on
| which plugin was loaded first? If so, that's no better
| than LaTeX, and will become an ever-growing headache as
| the ecosystem grows.
|
| OTOH, a plugin that sets each "the" in italics _can_
| sensibly interoperate with a package that sets each
| "the" in bold -- and can even produce the same results
| regardless of which was loaded first, because these
| effects "commute". These effects could be implemented by
| having the base engine expose an event that can be
| listened to by any interested plugin.
|
| ETA: The main reason LaTeX is a pain is because it makes
| no real attempt (that I can see) to manage any of the
| inevitable complexity of "global" effects. (Admittedly,
| this is a tough design problem.) _I don 't yet see signs
| of anything better from Typst_, thus I assume it will
| become roughly as painful as LaTeX in time.
| cbolton wrote:
| I disagree with the assumption that the red/blue conflict
| should produce an error. In real life most of the time
| you want one style to override the other. So in this
| simplistic example at least, having the result determined
| by the order is the correct behavior (and it's what typst
| does).
|
| More generally, if your system generates errors left and
| right, you end up making it hard for users to find a
| combination of packages that work. It's better to make
| them work error-free as much as possible. And the concept
| of "overriding" is natural and useful.
|
| I think typst does make a nice attempt at managing global
| effects. It's nowhere near perfect but works pretty well
| already. For example it's super easy to implement your
| example with two packages, one applying bold and the
| other applying italic: Template from
| package A: #show regex("\bthe\b"): set text(style:
| "italic") Template from package B: #show
| regex("\bthe\b"): set text(weight: "bold")
|
| You can use both templates in any order, typst will
| correctly render "the" in italic bold.
| SkiFire13 wrote:
| > A plugin that sets each "the" to red clearly conflicts
| with a plugin that sets each "the" to blue: at most one
| of them can "win", so which is it? Does it depend on
| which plugin was loaded first? If so, that's no better
| than LaTeX, and will become an ever-growing headache as
| the ecosystem grows.
|
| Just loading a package in Typst won't perform side-
| effects. Instead what they can do is giving you some
| function that will apply the styling to any content
| passed to it. It will be up to you to choose to wrap your
| whole document in such functions in order have them apply
| globally, which can be done conveniently with something
| like `#show: foo_template`, where `foo_template` is the
| aforementioned function.
|
| This still has a chance of "incompatibility", like in the
| blue/red example, because you might do this with two
| functions from two different plugins. However it is up to
| you to do this, and it will hopefully be clear that
| you're modifying global styles in two different ways with
| a specific order between them.
|
| To be fair though I should mention that some packages
| will expect you to use `#show` with their functions, so
| sometimes it will be difficult to avoid using it multiple
| times.
| mr_mitm wrote:
| Typst uses pure functions, so they cannot mutate globale
| state
| cbolton wrote:
| I think compatibility issues in LaTeX often come from
| packages that redefine the same macros in incompatible ways.
| This kind of things doesn't happen in typst because all user
| code is pure: a package can define 1) values or pure
| functions that can be imported (this makes them available
| only in the scope where they're imported) and 2) content that
| can be included in the document.
|
| There's still potential for conflicts, for example content
| can contain elements that represent a state update such as
| incrementing a counter. Packages can define their own states
| for internal use, and the namespace is global, so they can
| interfere with each other if they don't follow good practice
| (prefixing state names with __package-name for example). And
| show rules can replace an element of content with another
| one, for example one package can replace verbatim code with a
| figure, and another package can format verbatim code. What
| happens if you mix them without limiting their scope?
|
| But so far, I think the compatibility problems in typst are
| more of the "well, what do you expect?" kind. Compare to
| LaTeX where sensible code is broken when a package makes a
| small changes somewhere deep in the macro pile of cards.
|
| For example someone here mentioned the example of one package
| changing "the" to red and another changing "the" to blue.
| This can be done declaratively in typst, and won't cause an
| error, but the result will depend on the order of
| declarations.
| flakiness wrote:
| So your books are like these?
| https://store.metasnake.com/effective-pandas-book
|
| Jupyter-to-PDF sounds like a perfect match here!
| __mharrison__ wrote:
| Yes. I've gone from rST to epub/LaTeX, to markdown to
| epub/LaTeX (via Pandoc), to Jupyter (with markdown) to
| epub/Typst.
| Jach wrote:
| > (I often had to compile twice due to indexing)
|
| This trips people up a lot once they do anything involving
| cross-referencing or bibliographies. But for some reason some
| people use latex for a long time and never hear about latexmk,
| which automates all that, and can even "watch" your files so
| you can edit and save and see your PDF refresh all in real
| time. (I've only used latex for papers or blog math, not big
| books; I can't imagine waiting a minute per change back in
| college, let alone on modern hardware...)
| __mharrison__ wrote:
| I use rubber. For some reason it worked better than latexmk
| for me. (Don't remember now.)
|
| However, it also had index issues.
| vestingz wrote:
| > Easy to script--Okay, I did write some Typst the other day. I
| migrated my LaTeX-based invoicing system to Typst. I created a
| list of objects with pricing and count and was able to throw it
| into a table easily.
|
| Interesting! Would you share your solution and/or tell us a
| little more about it? Thanks!
| heisenzombie wrote:
| Ooh, very interesting! I produce lots of reports using Jupyter
| and nbconvert. I have a custom nbconvert template (which uses
| pandoc+jinja+latex under the hood).
|
| I find the whole system to be a bit house-of-cards and I'd love
| to try alternatives. What's your workflow for using Typst with
| Jupyter?
| __mharrison__ wrote:
| I've always bike shedded my own solutions because none of the
| existing tools did what I needed for physical books.
|
| Pandoc does a decent job with connecting markdown to Typst. I
| have a few filters that I run to convert the notebook to
| markdown and some other filters that I run to change the
| output from Pandoc.
| andrepd wrote:
| LaTeX-based invoicing system? Okay, you got me curious.
| laurmaedje wrote:
| If you're talking about weak widow/orphan support for headings
| in particular, that will finally be fixed in Typst 0.12.
| __mharrison__ wrote:
| Great news!
| humanfromearth9 wrote:
| Regarding math stuff and graphics/diagrams, it works well too.
|
| What I enjoy about Typst is the fact that the code is easy to
| write and read. Even code from some third-party library or
| template is easy to understand. There is a world of difference
| between this and LaTeX, which abstracts over TeX, and whose
| inner workings remain obscure even to experienced developers
| having used LaTeX over decades for tens of documents.
|
| The compilation of Typst documents is indeed also extremely
| fast compared to LaTeX.
|
| The runtime and libraries are lightweight and easy to install,
| compared to LaTeX distributions.
|
| Writing custom logic or even a fully-fledged template with
| Typst is easy to do from day one.
|
| The only reason I still see to use LaTeX nowadays is writing
| books and papers whose editor only accepts LaTeX.
|
| I've switched to Typst some months ago and not once have I
| thought it might have been a mistake. The only thing I regret
| is that there is no automatic migration of older LaTeX
| documents to Typst.
|
| Editors still have to be improved, though the Vscode plugin is
| absolutely usable.
| CoastalCoder wrote:
| Is there a typst to reasonable-LaTeX back end?
|
| Apologies if this is a stupid question, I've never used
| typst.
| mbo wrote:
| First of all, I will commend the Typst community for attempting
| to rectify the trainwreck that is LaTeX typesetting. It appears
| that they have succeeded.
|
| So Typst has its own styling system, and its own scripting
| system, and plugin system via WASM... isn't this just HTML with
| extra steps? Not to mention that Typst doesn't support HTML
| export
| https://github.com/typst/typst/issues/188#issuecomment-14933...,
| which is a major impediment to vision-impaired accessibility in
| the academic community.
|
| I think this is all a bit of a shame that there's been no major
| efforts to reform HTML as the go-to file format for scientific
| publishing instead. All the elements are there - <cite>,
| citation.js, KaTex, Web Components, good plotting libraries
| (Observable Plot), WASM. Was all this extra engineering effort
| required to get us a Markdown style syntax? I know people hate
| XML-based markup... but it's not _that_ bad, right?
| Onavo wrote:
| The key difference between print systems and web tech is
| responsiveness. Anything print related is primarily designed
| with dead tree format in mind, so the layout won't change, and
| you don't have to worry about text reflowing after editing.
|
| It's also why LaTeX/PDF to HTML converters are so difficult to
| build, because the underlying engine has no semantic
| information about the structure (this may be changing with LLMs
| and multimodal setups).
| aniviacat wrote:
| One could ask if responsiveness is relevant for documents.
|
| You could simply use a static layout for your html, and then
| add borders or zoom (just like in a pdf viewer).
|
| Then you'd have the editability, accessibility and
| performance of html, with the same responsiveness as a pdf
| (none).
|
| I've never really given this much thought, but html could
| reallly become the standard file format for documents.
| mbo wrote:
| > The key difference between print systems and web tech is
| responsiveness.
|
| True, but... we were very good at building unresponsive
| websites in the early 2000s. Can't we just return to
| tradition and disable a lot of the responsive behaviour that
| we've layered onto HTML with an off-the-shelf stylesheet?
| Hardcode some width properties, ya know? (This is not a
| rhetorical question, genuinely curious).
| Onavo wrote:
| Then you might as well just use PDF.js and render the PDF
| in its entirety.
| necovek wrote:
| You can trivially define a CSS stylesheet that eg. hides
| all the interactive elements like INPUTs and FORMs, or
| renders <A> tags like plain text.
|
| But "H" in "HTML" is for "Hyper(text)", which really talks
| about the interactivity. And then you get a really bad
| language for typesetting that simply lacks a gazillion
| features of true typesetting systems like TeX or even
| Typst.
| ykonstant wrote:
| Regarding LaTeX to HTML, I have had some success with pandoc,
| e.g. https://ykonstant1.github.io/power-draft.html
|
| It is much trickier if you are using tikz heavily, but it
| still doable.
| necovek wrote:
| Publishing is heavily dependent on the output media, and multi-
| format output is still hard for anyone desiring a high quality
| output.
|
| HTML is specifically designed as a publishing system for our
| screens and has mostly evolved that way (media CSS tags
| excluded) and as a web _application_ UI language, along with
| some push into semantic markup (but TEI or DocBook are much
| more comprehensive when it comes to semantic markup).
|
| Some of the large problems of typesetting printed documents
| (page layout, with hyphenation, figure placement, orphans,
| justification...) are simply unsolved (or badly solved) with
| HTML+CSS, and they are hard problems even if you focus only on
| them (TeX systems will sometimes ask you to manually "pick"
| your poison -- if you've ever seen those black bars in the
| margins).
|
| Some of the beauty of TeX box model could have been transferred
| to screens though (like tunable and collapsible whitespace),
| and to an extent they have, but TeX's model remains
| incompatible with the HTML/CSS box model.
|
| The fact that no language does all 3 (UI for apps, screen
| rendering of documents, paper rendering of documents) perfectly
| or even acceptably well -- not to mention a fourth class that's
| a mix between screen and paper: ePub/eBooks -- should tell
| anyone that this is a very hard problem to solve generically.
| SkiFire13 wrote:
| PDF was designed to look the same on any device/viewer and
| that's something that HTML/CSS/JS will likely never be able to
| do (every browser does things slightly different!). HTML also
| lacks good support for embedding resources in a single file and
| is much heavier to display (try coding a whole HTML + CSS + JS
| engine vs a basic PDF/A viewer!). Moreover HTML/CSS lacks all
| the typesetting features that Latex/Typst support out of the
| box.
|
| But anyway here's a challenge for you: take some random small
| document in Latex/Typst and try converting it to HTML/CSS/JS
| while keeping the same layout and visual feelings. Make it a
| single file you can share with people and try seeing if all
| browsers display it the same way.
| quotemstr wrote:
| C-f r u s t RET
|
| But of course.
|
| I'd rather see effort go into improving LaTeX performance instead
| of creating some new incompatible thing in a trendy language. One
| could also imagine an Elixer-style "resyntaxing" of LaTeX that
| would preserve compatibility with decades of packages. I don't
| think a long-developed ecosystem should be given up lightly.
| lapinot wrote:
| Speed and nice error messages in (La)TeX, and to some extent
| ease of programming, are entirely doomed because of fundamental
| design choices. Being based on unhygienic macro expansion means
| that there is only one way to evaluate (the slow way), there
| will never be incremental compilation (everything can possibly
| be stateful in horrible ways), there will never be good error
| messages because there's basically no AST information anywhere
| (begin/end is a joke).
|
| Regarding ecosystem: tons of undecipherable LaTeX packages are
| basically one-liners (ok, 10 liners) in typst. I know it from
| experience: I've written my PhD manuscript in typst. So perhaps
| one reason why there are so many (basically frozen) packages in
| LaTeX is because they are so hard to write and maintain.
|
| edit: of course, being only a few years old, typst is nowhere
| near as solid as TeX, but you can already use it for a lot of
| things and its a breeze to use.
| thangalin wrote:
| > Speed and nice error messages in (La)TeX are entirely
| doomed because of fundamental design choices.
|
| Have you checked out KeenType?
|
| https://gitlab.com/DaveJarvis/KeenType
|
| It's a Java-based implementation of TeX, forked from NTS,
| that was optimized to render 500 to 1,000 equations in real-
| time on commodity hardware. My text editor, KeenWrite, uses
| the KeenType library to preview the document. The final
| output is passed to ConTeXt for typesetting, by way of first
| converting Markdown to an XHTML file. (This means that
| KeenWrite can export as both HTML and PDF.)
|
| https://keenwrite.com/screenshots.html
| samatman wrote:
| TeX has three actively-maintained engines, and there are a lot
| of folk putting work into improving LaTeX and its ecosystem. So
| effort is going into LaTeX, including performance, right now.
| Probably someone committed a perf improvement today, or in the
| last week.
|
| There are problems with TeX which can't be fixed, problems
| which Typst is directly addressing. I wish them all success. I
| will never understand the attitude which holds that because
| some established system exists, nothing in the same category of
| program should ever be written. Let people cook.
|
| I do understand Rust fatigue but the swipe here is uncalled
| for. This isn't a "rewrite it in Rust", it's a new language
| which happens to be implemented in Rust, and y'know what? Good
| choice frankly. There are tasks where "fast enough" isn't a
| meaningful concept, and compiling raw documents into a finished
| form is one of those tasks.
|
| TeX and LaTeX aren't going anywhere, and Typst has years of
| work ahead of it to ever offer a comparable richness of
| capability. If it incrementally replaces the use of LaTeX over
| time, that will be because it earned it.
|
| Have you used troff lately? Probably not. Things change. And
| yet man pages are written in nroff to this day. Dr. Knuth wrote
| TeX because what existed at the time wasn't working for him.
| Typst likewise.
| beezle wrote:
| Real men use TeX or troff!
| volemo wrote:
| Real men write formulae by hand in their typewriter typed
| papers.
| cozzyd wrote:
| Until the arxiv gets typst support, I imagine this will get
| relatively little traction.
| aragilar wrote:
| The two baseline criteria I have for better-than-LaTeX options
| are:
|
| 1. Maths support equal to or better than amsmath 2. LaTeX-style
| macros
|
| Both are needed to make writing large amounts of complex
| equations acceptable.
|
| There should also be something similar to unicode-math, cleveref
| and biblatex, easy-to-use options to control layout/style/output
| (including metadata).
| josephg wrote:
| I wrote a recent paper in typst. We ended up converting it to
| latex at the last minute to work with the conference's
| submission guidelines, and work around a small bug (now fixed)
| in typst. But I would 100% use typst again. I wish it output
| html so I could use it for blogs & documentation.
|
| The maths support was more than good enough for what we needed,
| and I enjoyed writing it a lot more than latex maths. The
| macro-equivalent support in typst is _fantastic_. It's a
| standout feature. It has a full, modern-feeling programming
| language built in, complete with modules, functions, variables,
| arrays, the whole works. And there's a growing ecosystem of 3rd
| party packages you can use with typst. Our benchmark scripts
| output the results into json files. Then when the typst
| document compiled, our typst source pulled in the benchmarking
| data directly from those json files. Then it used that data to
| populate tables and render charts directly, straight into the
| pdf. It was a lovely way to work.
|
| (Though that said, I ended up swapping to a more fully featured
| external charting library because the charts it created looked
| better).
| aragilar wrote:
| LaTeX maths or amsmath maths? TeX maths != LaTeX maths !=
| amsmaths maths, and usually what I see described as "LaTeX
| maths" is TeX maths (or a subset, when someone claiming
| "LaTeX support" but not actually using LaTeX).
|
| I'm not interested in a programming language (though
| naturally being able to write plugins would be useful ala
| luatex), but a textual macro system. I have things like
| (which is one of the simpler macros):
| \newcommand{\dt}[1]{\frac{[?]#1}{[?]t}}
|
| so I can write things quickly and efficiently. _That_ is the
| power of (La)TeX, and most examples I 've seen of LaTeX
| alternatives seem to miss that use case, and instead focus on
| other things (e.g. HTML generation, alternate programming
| languages).
| josephg wrote:
| I'm not a latex expert. I don't know what the difference is
| between tex math, latex math and amsmath is. (And please
| don't explain it, I don't care.) Maybe there are some weird
| expressions out there that don't have a typst equivalent,
| if we really looked for them. But I haven't run into
| anything myself, despite writing a pretty math-heavy CS
| paper. (Or at least, the early drafts were math heavy.)
|
| > I'm not interested in a programming language (though
| naturally being able to write plugins would be useful ala
| luatex), but a textual macro system.
|
| Are you sure? Because latex macros like that are really
| horrible to read & write, and latex gives you notoriously
| hard to read error messages for your trouble. Here's the
| equivalent in typst: #let dt(x) =
| $([?]#x) / ([?]t)$
|
| In my opinion, this is way more readable. That code defines
| a lambda function (like arrow functions in javascript) that
| returns a "math mode" block ($this is a math block$). #x
| escapes the math block to evaluate x - which is just the
| function parameter we defined earlier.
|
| And you'd use it simply: The result is
| $dt(y)$
|
| Its not a macro system. Its just a function that you can
| call anywhere - including from other functions. And the
| function returns a block. I personally think its much
| nicer, and more familiar than the latex macro equivalent.
| aragilar wrote:
| I'm curious, how does typst work out that I want the
| function expanded or I want the literal string if there's
| no marker.
| lapinot wrote:
| There are 3 syntactic modes in typst: markup, code and
| math. In markup, everything is literal, unless you put a
| `#` sigil like `#expr` in which case `expr` is parsed in
| code mode. In code mode everything is an identifier, as
| usual in programming. In math its a bit of an ugly
| tradeoff but its ok: single-letter things are parsed as
| literals but multi-letter tokens are parsed as
| identifiers. Finally, in code you can enclose in `[...]`
| to parse in markup mode. So typically, your document will
| be mostly in markup mode and you will encounter stuff
| like `#something[An argument]`, which is a function call
| to which you pass one content-typed argument.
|
| So above, `y` is parsed as literal, while `dt` is parsed
| as an identifier, hence function call.
| teo_zero wrote:
| > In markup, everything is literal, unless you put a `#`
| sigil
|
| Unless it's a "=", then it begins a new section. And
| unless it's a "-" or a "+" or a "/", then it's a list
| item. And unless it's a "<", then it defines a label, or
| a "@", then it's a reference to one. And unless it's a
| "_" or "*" or "`", then it changes font or style.
| josephg wrote:
| Right. Markup mode supports markup features - including
| all of that stuff for headings, lists, bold, italics and
| so on. It's clearly inspired by markdown and similar
| languages. Personally I prefer * to \em{xxx} since it's
| easier to type and it makes the text easier to read while
| I'm editing. (Or maybe just more familiar since give
| written so much markdown at this point).
| mixmastamyk wrote:
| Does this allow a book to be split into parts? One problem I had
| with Sphinx.
| bitwize wrote:
| Ah, Typst -- the Wayland of formatting systems.
| hyperbrainer wrote:
| Wayland is far more feature-complete than Typst is. Typst is
| Wayland 5-6 years ago maybe.
| zamazan4ik wrote:
| For anyone who is interested in speeding up Typst, I can
| recommend taking a look at this issue:
| https://github.com/typst/typst/issues/1733
|
| TL;DR - Profile-Guided Optimization (PGO) can improve Typst's
| performance for 10%+
| knuckleheads wrote:
| Typst is a lot of fun and lets you do some really cool stuff.
| However! In the process of doing that cool stuff, you may need to
| debug things and that's when it's no longer fun. There is no way
| to print anything out to console and debug anything about what is
| going on. People have asked for it for over a year now and the
| authors have refused/ignored their requests. I would be using it
| a lot more except for this.
| https://github.com/typst/typst/issues/1669
| cbolton wrote:
| The author of this issue is the main developer so I guess they
| want it done, just had other priorities.
|
| I agree typst needs better debugging tools, but you're a bit
| harsh. It has things like `repr` that can often be used to
| inspect objects, and `panic` can be used as a (admittedly
| crappy) substitute for printing a value to the console.
| knuckleheads wrote:
| Would you prefer that I not say exactly why I am not using
| typst right now as I would like to? The debugging experience
| is jarring compared to everything else and it put me off. I'd
| like to be using it but for the things that I want to do, I
| need to be able to figure out the mistakes I was making
| faster and easier.
| cbolton wrote:
| Maybe I was a bit harsh too :)
|
| I don't think the debugging experience is worse than in
| LaTeX (a low bar admittedly): you can print to the console
| in LaTeX but it's drowned in other messages. Instead of
| grepping the console in practice I use \show\thing, which
| is basically the same as doing panic(thing) in typst. What
| I do is put commented-out "panic(variable)" here and there,
| and use the comment/uncomment shortcut in the editor to see
| the value of the variable. With typst's incremental
| compilation I get immediate feedback, so a better
| experience than in LaTeX.
| laurmaedje wrote:
| Hey, I'm one of the Typst devs and author of the issue.
|
| The reason there is no logging yet is because we want to get it
| _right_ rather than landing a permanent temporary solution. And
| there were simply more urgent things to do so far.
|
| Also note that if you use an LSP or the web app, you can
| inspect the live values in your code simply by hovering over
| them.
| knuckleheads wrote:
| Thanks for the reply! Happy to consider using typst against
| once this lands, until then though, I have to use other
| tools.
| necovek wrote:
| References in established systems like LaTeX work the way they do
| for a reason: you don't want to embed words in them (like
| "Figure" or "Section") automatically because it does not work
| across languages.
|
| Eg. both the article and docs at
| https://typst.app/docs/reference/model/ref/ use an inline
| reference that wouldn't work in Serbian.
|
| Serbian (and many other languages) have suffix declensions, so
| while "Figure 4" is "Slika 4", when used like "in Figure 4", you
| really need "u Slici 4" (and lowercase, really) instead of "u
| Slika 4" as produced by Typst.
|
| On the plus side, it seems to use OTF locl tables for
| substitution glyphs for language, though it only partially works
| for Serbian (might be due to bad locl tables for LinLibertine
| which seems to be the default font).
|
| I am sure it's not too hard to only get the reference number (eg.
| @foo.context.something?), but defaults should be good or maybe
| per-language?
|
| I can see how they wanted to avoid authors having to hard-code
| the reference type if they change eg. something from an image to
| a table, but it's hard to make it smart enough for any language.
| bboygravity wrote:
| Why would a user who types only in English prefer a system that
| was optimized for all languages?
| superb_dev wrote:
| It's better for all of us if we can collaborate with a common
| system. This tool will have to deal with other languages if
| it's gets popular enough
| phoe-krk wrote:
| If Typst aims for eventually competing with LaTeX, getting
| outside the bubble of "everyone uses English" is a very good
| step to take. And it's good to take it early, when your
| system architecture is still easy to change and not
| implicitly ossified around englishisms.
|
| Things like "if you _ever_ want to translate your document
| from English to XXX, you will also need to port it from Typst
| to LaTeX " tend to be dealbreakers.
| monista wrote:
| Typst authors being germans, one can hardly accuse them in
| the "everyone uses English" attitude. Typst `dif` math
| operator (as in dx/dt) produces upright 'd', quite
| unexpected to ones used to slanted 'd' tradition.
| teo_zero wrote:
| > Typst authors being germans, one can hardly accuse them
| in the "everyone uses English" attitude.
|
| On the other hand, one can easily understand why, bein
| German, they assume Figure, Equation, etc. will always be
| capitalized.
|
| > Typst `dif` math operator (as in dx/dt) produces
| upright 'd', quite unexpected to ones used to slanted 'd'
| tradition.
|
| I would indeed expect an upright 'd'. It's an operator,
| not a variable. I don't recognize the tradition you're
| mentioning.
| monista wrote:
| > I would indeed expect an upright 'd'. It's an operator,
| not a variable. I don't recognize the tradition you're
| mentioning.
|
| That's strange. I've never seen a math article in English
| with upright 'd' differential, only have seen it in
| German and Spanich articles. It's also math italic in TeX
| (you can check Knuth's TeXbook).
| cbolton wrote:
| Hopefully they'll improve the reference system and multilingual
| support. But if you want a simple number for a reference, you
| can call "ref(<label>, supplement: none)", or if you want this
| to be the default for the @label shorthand syntax you can set
| it globally with "#set ref(supplement: none)".
|
| Also typst knows the type of the referenced element. It's easy
| to write more elaborate rules that behave differently depending
| on the type. And the rules can also check the current language
| to generate localized references.
| qhwudbebd wrote:
| I played with this briefly, and saw that supplement can also
| take a function, which presumable how you make @wibble return
| '(34)' instead of 'Equation 34'? The function is passed the
| equation itself, so supplement: x => x makes the reference
| identical to the whole equation (!), but it wasn't obvious to
| me how to extract just the equation number from an equation
| x?
|
| This is a really common idiom in mathematical writing: "from
| (1) we see that..." instead of "from Equation 1 we see that".
| (Randomly capitalising 'Equation' here is another
| controversial implication of using a fixed word string as a
| supplement.)
| cbolton wrote:
| I would just define `#let eqref(target) = "(" + ref(target,
| supplement: none) + ")"` and then use it as in "from
| #eqref(<eq-xy>) we see that..".
|
| You can probably do that with a function given as
| supplement but it looks a bit involved, I think you'd have
| to do something like in this example:
| https://typst.app/docs/reference/model/ref/#customization
|
| (I think the reference system is an area where things can
| be improved to main some common use cases simpler.)
| darrensharm wrote:
| Use `\usepackage{cleveref}` and then `\cref` in LaTeX. Also
| works with babel.
| teo_zero wrote:
| Embedding words like Figure or Section breaks not only
| declensions, but capitalization, too. Germans won't notice it
| because all their nouns are capitalized, and English speakers
| won't care because they're traditionally forgiving with
| unmotivated upper-case words in the middle of a sentence
| (including titles). But formally it shoud be "Figure 4" in the
| caption and "as we see in figure 4" in the reference.
| 4bpp wrote:
| "as we see in figure 4" is simply incorrect, though;
| expressions such as "Figure 4" or "3rd Street" are treated as
| proper names and _must_ be capitalised, as would the non-
| nominal "third" in "Dritte Strasse" if any German-speaking
| city were to have American-style numbered streets.
| dsrtslnd23 wrote:
| is this comparable to asciidoc?
| riedel wrote:
| First of all, today I almost exclusively write all my LateX in
| overleaf, so a lot of pain of LateX distros is taken away. But
| the main thing was always good templates, so I found a collection
| of ML conference templates [0], that shows also that typst still
| has some issues with acutely reproducing existing styles. Also
| when having to submit sources, I guess cross compile to latex
| would be the only possibility (typically they accept Latex or
| sometimes MS Word)
|
| [0] https://github.com/daskol/typst-templates
| Munksgaard wrote:
| I use typst to generate PDFs on the fly in my sass-platform. The
| only other reliable ways I could find to do that was by using
| LaTeX (slow) or various WebKit-based tools (also slow, and in
| carious states of unmaintained/deprecated). It works like a
| charm.
| enriquto wrote:
| It's cute that you can write greek letters by spelling them,
| without any escape: pi, alpha
|
| What I'd really want to type is however p, a
|
| Will this work in typst? I had some trouble installing it.
| cbolton wrote:
| Yes that works.
|
| What trouble did you have installing it? (It's literally a
| single binary with zero dependencies)
| enriquto wrote:
| > Yes that works.
|
| Oh, that great! My _major_ point of friction with LaTeX is
| that using unicode is not straightforward. You sort of can,
| by including the right packages and using the right
| interpreters, but it imposes strange constraints involving
| the fonts that you can use and whatnot.
|
| Regarding the usage, it's probably my fault. I tried to
| compile it locally and it didn't work at first (requires
| newer rustc version).
| jimhefferon wrote:
| > My major point of friction with LaTeX is that using
| unicode is not straightforward.
|
| Possibly you are describing how it used to be before the
| input encoding standard for LaTeX switched to UTF-8?
| enriquto wrote:
| No. I'm talking about modern LaTeX. You can easily write
| e outside of math mode, but not inside. By default, you
| cannot write a either inside nor outside of math. By
| using the right packages, you can do both, but other
| things break.
| aragilar wrote:
| Which engine? I believe XeTeX and LuaTeX support it
| natively?
| enriquto wrote:
| Yes, that is the problem, precisely. Lualatex and xelatex
| do not support all the features of plain latex (mostly
| "hacky" things, like pdf controls, js animations in
| beamer, etc). So, you have to chose between using these
| features and being able to type unicode letters directly.
|
| Probably there is a magic combination of engines and
| packages that allows to do everything at the same time,
| but I haven't found it.
|
| If this works natively in typst, it's a great selling
| point for me (although I dislike the markdown-like
| syntax).
| aragilar wrote:
| Uh, pdftex, xetex and luatex should support everything of
| the original tex engine, but each has extended tex, so
| some things will work on pdftex (which I think is what
| you're thinking of as plain latex), others on xetex and
| then others on luatex (or pairs of engines, I know
| microtype works on pdftex and luatex, but not xetex). I
| don't think this is an tex specific problem, more a
| natural result when there's multiple implementations.
|
| I suspect as typst only has a single implementation (I
| believe), it won't have the problem of different engines
| ;)
| divan wrote:
| I'm using Markdown/LaTex to PDF/HTML converter for preparing
| various legal/rules documents. While this approach works for very
| simple documents, whenever I needed simple change (i.e. specific
| list numbering or break the page for chapters) the path to find
| the solution was long and painful.
|
| Typst was a breath of fresh air, and I'm moving all my document
| generators to it and don't look back.
|
| The only thing I miss at the moment is generation of HTML (in
| addition to PDF). It's possible to achieve via Typst+Pandoc I
| guess, but would be great to have it as an output target
| natively.
| hggigg wrote:
| While I appreciate these projects, I can't see any headway for
| something like this in our academic community. We have a very
| established ecosystem of LaTeX packages, styles and documents,
| some of which are more than 25 years old. Everyone knows it.
| Everyone collaborates with LaTeX. Knowledge is easy to pass on
| because it is well understood. Everyone knows (or are) the people
| who write the packages or maintain things behind the scenes. This
| is all quietly boiling away without a single thing on GitHub.
|
| To move to Typst, we'd have to start again and build all that
| again, because I guarantee there's stuff you just can't do it in
| it. I mean I looked at the options for tikz. One publication we
| have has 520 tikz figures in it for example. And that's dead.
| cbolton wrote:
| Sure but you have to take into account how easier it is to
| build these things in typst. It's like one year since the first
| public typst release and someone already built a very
| functional "TikZ" equivalent called CeTZ. Far from being as
| mature as TikZ but easier to extend yourself.
| Semaphor wrote:
| If the author is reading, there's a bug with dark mode, the
| `aside` (for the TOC) gets a background color of #d3d3d3 which
| results in very bad contrast as the font and heading are adjusted
| for dark mode.
| HerrmannM wrote:
| I have a love-hate relationship with LaTeX... in 2016, I wrote my
| PhD with it, for wich I defined lots of helpers and commands.I
| used xetex for some obscure reasons I don't remember.The final
| result was beautiful but I dread opening any of those files. And
| it doesnt compile anymore.
|
| Among all the systems (tools, languages, devices...) I exploited
| professinaly, LaTeX is the one that remains the most obscure and
| frustrating to me. I'm not sure why.
| tcfhgj wrote:
| It took me a few hours to be able to do things I could never do
| in Latex, which I have had used for a number of documents like
| thesis, project reports, etc.
|
| In Latex I always relied on googling random packages to fix weird
| stuff while in Typist I feel like I can do anything I want
| myself. The scripting capabilities are powerful and compared to
| latex insanely easy to use.
| lapinot wrote:
| This! My first actual project (besides some testing) has been
| my phd manuscript, and after ~2 days i actually had a tufte-
| style 1.5 column layout going, written from scratch. And its
| probably like ~250 lines.
|
| There are some rough edges still, the dom model and advanced
| programming stuff is not quite there yet (user-defined
| elements, user-defined settables, advanced layout like chaining
| blocks for laying text flows). But like the quality of the user
| interface is several orders of magnitude better than (La)TeX.
| rsrsrs86 wrote:
| Typst is simply amazing. I wrote a thesis using latex and boy
| would I love if I had found about typst sooner.
| seanhunter wrote:
| I really want to like this because it seems a lot more accessible
| to folks than latex but I'm getting that "uncanny valley" feeling
| like when I look at equations that have been typeset in MS Word.
| They look almost, but not quite, good.
|
| Like if you look at the equation for Binet's closed form solution
| for Fibonacci numbers in the link below from their github, it
| looks to me like there is a bit too much space on either side of
| the plus sign in the equation for phi on the right hand side. And
| phi^n on the left-hand side looks too close to the 1/sqrt(5).
|
| https://user-images.githubusercontent.com/17899797/228031796...
| cbolton wrote:
| I think you're imagining things... This spacing stuff is mostly
| defined in the font files and typst uses the same math font (or
| a more recent version, depending on your LaTeX config). I made
| a small comparison: https://imgur.com/a/0k6dsok
|
| Note that by default, typst uses the book weight from New
| Computer Modern. This corresponds to the default settings in
| LaTeX with the "fontsetup" package.
|
| The only difference I can see is the spacing after the comma.
| Not sure why typst does it differently. I think typst might be
| doing the right thing here actually, but it's easy to adjust if
| you want.
|
| My typst code: $ round(1 / sqrt(5)
| phi.alt^n), quad phi.alt = (1 + sqrt(5)) / 2 $
|
| My LaTeX code: \[
| \left\lfloor\frac{1}{\sqrt{5}} \phi^n\right\rceil,\quad \phi =
| \frac{1+\sqrt{5}}{2} \]
| seanhunter wrote:
| Thanks for doing the comparison but that just looks to me
| like I'm not imagining it. There's more space around the plus
| sign with typst.
| cbolton wrote:
| Could it be an illusion because the "zoom" is a bit
| different? (I was screenshotting different applications).
|
| Here's a better comparison: 11pt size for both, then
| importing the LaTeX output in typst (using SVG conversion
| since typst cannot import PDF): https://imgur.com/a/aZRx6fs
|
| I removed the "comma" that produced different spacing, and
| added the missing F_n. It seems there's still some
| different in spacing due to the quad.
|
| If you still think the spacing around '+' is different
| you'll have to add some highlight/measurements or something
| to convince me, because they look quite identical to me...
| perlgeek wrote:
| In the near future, I'll have to program the document generation
| part of an invoicing system.
|
| In the past, I've done generated PDF documents through latex, and
| didn't really like the process (for one, escaping is just so
| weird in latex, \ to \textbackslash for example).
|
| I've thought about generating HTML and using a headless browser
| that can produce PDFs for me, but I don't know how well you can
| e.g. control page breaks with CSS these days.
|
| Maybe typst is actually a good alternative here? Does anybody
| have experience with typst and multi-page tables?
| wint3rmute wrote:
| I'm doing PDF document generation in typst, the format I'm
| generating is similar to invoices (specific to how the law in
| my country is, but that's a longer story).
|
| Typst code generation was easy to automate with trivial python
| templates (jinja2). The core part of my document are multi-page
| tables, and typst splits them nicely.
|
| I had to google around a bit, as there are multiple settings on
| how large tables are handled, I suggest that you give Typst a
| try, you can build a working prototype in no time
| perlgeek wrote:
| Thanks! Are you using the json loading feature in typst at
| all?
| niklasei wrote:
| I have been building tools for document generation out of
| templates using Typst for a few months. It works great!
|
| So far, I haven't found any bigger issues with multi-page
| tables in Typst. For example, it was no big deal, to get
| subtotals in an invoice for every page break.
| Onawa wrote:
| I think you're looking for Quarto. Quarto can also compile to
| Typst for typesetting, but you can get simultaneous
| HTML/PDF/Word outputs from a single markdown input.
| lynndotpy wrote:
| I'd like to throw my two cents into the "my experience is limited
| but I like it better than LaTeX" ring. Because, in my limited
| experience, Typst is easier and faster than LaTeX by a lot.
|
| I'd like to emphasize how important it is that Typst is a
| collaborative web-app like Overleaf-- 100% of the LaTeX use I saw
| in academia was on Overleaf.
| tiffanyh wrote:
| My concern would be that this seems like such a niche market that
| only charging $8/month, raises long-term viability concerns.
|
| Last thing you want to do is use a platform that goes defunct.
|
| https://typst.app/pricing/
| nihzm wrote:
| If I understand correctly the fees are only for an overleaf-
| type web collaborative editing experience. The typst program
| itself, the one you install on your computer, is free to use
| and open-source.
| pcranaway wrote:
| That's right. The whole thing is open source -- just, since
| it's hard to make any money from open source, they made the
| online editor (which is pretty good BTW)
| vzaliva wrote:
| Slightly offtopic: many commenters lament that latex is slow. I
| switched to https://tectonic-typesetting.github.io/en-US/ which
| is very fast and have better error reporting.
| pcranaway wrote:
| Yup. I use both LaTeX and Typst (although I prefer Typst when
| possible) and I haven't used anything other than tectonic for
| the past few years. It simply has everything you need included,
| and is pretty darn fast too.
| ratmice wrote:
| FWIW, as a long time user of tectonic I just started a project
| using typst yesterday, I'm really curious if typst will be able
| to do parallel downloading of packages than tectonic.
|
| This is something which I have found can affect initial first
| time document builds since it can cause sequential downloading
| of a lot of small files sequentially.
|
| The reason why it is difficult to parallelize or fix in
| tectonic itself is the way latex itself is parsed in a turing
| complete fashion. Importing a package can affect subsequent
| parsing. This makes it basically impossible to build a map of
| package dependencies without interpreting the entire document.
|
| I'm curious to see how typst handles such things.
| lutusp wrote:
| The central issue for new typesetting methods, unlike most
| software projects, is that to represent a solution, not a new
| problem, they must seamlessly communicate with other similar
| environments. So I have to ask: * Can Typist
| seamlessly export Latex? * Can Typist seamlessly import
| Latex?
|
| And I must link to the definitive XKCD cartoon on this topic:
| "Standards" https://xkcd.com/927/ .
| daedac wrote:
| I've been using Typst for a while. It's a joy to write in but
| currently has very limited scope. There's a good summary of its
| current limitations here
| https://www.reddit.com/r/typst/comments/1ej07al/why_i_use_la... .
|
| For me, it's basically a non-starter for academic work because it
| doesn't support PDF and EPS images (there are currently issues
| with SVG too). They also have no plans to support PDF graphics
| (https://github.com/typst/typst/issues/145).
| thoroughburro wrote:
| In an update to that same thread, a comment claims most of
| those items are fixed in 0.12, in staging now.
|
| https://www.reddit.com/r/typst/comments/1ej07al/comment/lq9u...
| ThinkBeat wrote:
| What is the story with the fonts Typst uses? Does it come with a
| standard library of fonts?
|
| I am not a fan of LaTex myself, but I admire it to some extent.
|
| Other systems come along that are less verbose and easier to
| write, and faster. Yay.
|
| And then people use it, and then someone thinks "oh we should
| have this function", "We need to add a feature for it to work
| well" etc etc and slowly the system either bloats, and at some
| point, a person will look back at LaTeX and go
|
| "Oh that is why this existed, and ah that is why this is slow"
|
| Or one can choose to keep the new system simple and simply use
| LateX when something more is required.
___________________________________________________________________
(page generated 2024-10-13 22:00 UTC)