Re: Caching intermediate compilation results for near-real-time PDF re-renders during editing
Jamie Vicary <[email protected]> Fri, 14 Jan 2022 15:20:40 +0000
| Newsgroups | gmane.comp.tex.pdftex |
|---|---|
| Message-ID | <CANr23v3raabO_tRfjnDjKcRY4JjMCroffAuePXGQoiubaxCuog@mail.gmail.com> |
Thanks so much to Karl and Jim for your replies! I am very heartened by what I am hearing. Perhaps what I am hoping for might be possible, and maybe even not too difficult. > > Plus about a million global variables representing the state of > > the compiler. > > I wonder... just how many variables > are in play after a shipout? This sounds great. So we have a family of global variables, which we could easily organize into a struct and clone into a cache as necessary. A million atomic registers doesn't sound so bad, that's just a few megabytes of data if allocated efficiently in memory. Plus, given that many of these values will change only rarely, there are much more efficient structures that could be used -- for example, only caching a new value of a register when it actually changes, recording the page index on which that takes place. > Currently, various editors and document viewers can do lookups and > reverse lookups so that one can go from a point in the source doc to > the corresponding line in the compiled document, and vice versa. Right, this seems to me already to be a standard feature. > ***Except for multi-page paragraphs (bah!), > tables and similar***, is it possible for a change on page N of a > document to affect anything before page N-1? (While I can see change > to a word in a continued paragraph on page N changing the typesetting > of that paragraph, and thus possibly how page N-1 should be laid out, > can page N-2 be affected?) Surely pdflatex already has a way to know when a page is fully rendered, that's when it sends it to the output file. So the relevant information already exists and is well-defined. If in some rare cases a change on page N can affect something on some smaller page number K, then that is of course important to consider carefully. But it could be that these cases are few and can be handled suitably. > >> possible in principle because this is the basis of operation of BaKoMa > >> TeX, which I have used for years. > > > That is amazing. I wonder if Malyshev's heirs can somehow be contacted > > to get the source freed. We have had no luck even finding notices > > beyond the bare fact of his death :(. Unfortunately Basil Malyshev's relative, who has taken control of the software, is not maintaining it, and is not prepared to make the source code available. He is currently still selling licences to the most recent version, so I guess he sees it as a static income stream. There is an active discord server for the BaKoMa TeX user community, which includes some experts on the system's mechanism of operation. If anybody here would like to join they could let me know and I could try to arrange that. Best wishes, Jamie