I want to be able use Typst locally with similar to WebApp workflow: typst watch ‹filename›.typ will automatically update my .pdf-file and I need a PDF viewer which will automatically jump to changed/added text. I tried KDE Okular but it’s only can automatically update file but not jump to current work point so I need to manually scroll up or down. That’s not comfortable. Please suggest me an app if you know one.
1 Like
Have you considered using VSCode with GitHub - Myriad-Dreamin/tinymist: Tinymist [ˈtaɪni mɪst] is an integrated language service for Typst [taɪpst]. ? Here, the preview jumps to the position that you are currently editing in the text.
1 Like
That’s the only option which I found for now. But isn’t there a standalone PDF viewer which have this functionality? That sounds not so much to even be a problem…
I’m not sure about the jumping to changed content, but it might be worth trying SumatraPDF, which used to be my default viewer in the days when I was mainly typesetting on a Windows computer (using LaTeX). It will automatic reload changed PDFs.
2 Likes
I have tried it and it acts same as Okular =(
1 Like
This is a very interesting requirement. To have it work we’d need three things:
- The PDF standard would need a way to tag a specific point in the document.
- Typst would need to know how to write such a tag into the generated PDF
- The PDF viewer would need to know to look for that tag when it reloads the PDF
2 Likes
For those unfamiliar with LaTeX, it offers the synctex CLI option for use in many TeX-oriented editors, but also with extensions in Sublime Text and Visual Studio Code. It enables jumping between the editor and the viewer.
This option was mentioned in an early issue SyncTeX but for Typst, which in turn mentions the ide module. From my observations, certain Typst editors decided to make use of this feature. One that I find works both ways, forward and backward, is part of Katvan. And to be clear, its viewer can’t be used outside of the editor.
I can’t tell if extensions in editors like Sublime Text could also take advantage of that ide module. Because if so, we wouldn’t have to rely on Typst-specific editors, just like we don’t have to in LaTeX. Even then, I don’t see how the synctex-supported PDF viewers could be able to understand the syncing as implemented through Typst’s ide module.
So from what I have gathered about the current state of forward and backward search in Typst is that you can only use the viewer which comes binded to the editor.
I thought that compiler already knows where the last changes made (if I understood it correctly) so need to be a way for viewer get this information from compiler rather than seeking changes on it’s own (what they are not doing anywar right now)? This requirement basically unbinds Typst compiler from VSCode (or Nvim) plus Tinymist to enable user have smooth workflow like in WebApp but locally and with any text editor even if it’s notepad or Vim without extensions
Can this be considered as a good reason to making issue on GitHub? As Google says (but I’m not completely sure about it) SyncTex creates additional service files to synchronize different applications. I don’t know much but maybe there should be a way for different applications share some data in standardized shape even without this mess (even if it’s hidden files) in project’s directory?
As far as I understand, the instant live preview in the webapp and Tinymist is not a pdf view, but an svg view. So is it not more likely that the answer is to hook up some svg viewer in some way? (Not that I would know how to do this.)
The web app uses PNG export and Tinymist uses a custom SVG exporter (developed by them, not by Typst).
2 Likes
Interesting. How you think will there be someday something like a standard for linking three different kinds of software (compiler, compatible editor and compatible PDF viewer) to make local Typst workflow more smooth? I think that kinda allows to shift responsibility to PDF viewers and code editors on how provide compatibility no matter if it’s a 3rd party plugin or full Typst IDE…
1 Like
Being fairly old-school, my local-first approach to working with Typst is to have three windows open:
- A terminal running
typst watch main.typ - A terminal running
vi main.typ - A PDF viewer displaying
main.pdf
3 Likes
I think you would be interested in more smart standalone PDF viewer which will jump to changes…
vscode with vim plug-in would be a good alternative for you
I would be very cautious about using VSCode after reading Dismantling a Critical Supply Chain Risk in VSCode Extension Marketplaces. VSCode is cross-platform which makes the danger of getting an infection all more onerous.
The CLI compiler has all the required information to map (almost) every location in the PDF output to a corresponding source location, but no one wrote code that formats this information as a SyncTex file.
The format is arcane and poorly documented, and while there is a standalone parser library (which is used by the PDF readers that support it), there is no standalone generator library that is independent of TeX engine code. I briefly considered implementing a Typst to SyncTex generator early during Katvan development, but quickly came to the conclusion that it is not worth the trouble to the extent that FFI bridging from C++ to Rust would be less painful.
So while SyncTex output would for sure be useful for many people, it is apparently not useful enough for anyone to decide to go through the effort given the existing alternatives.
4 Likes