[NTG-context] Re: Most recent context doesn't like synctex?
Hi, On Sat, Apr 13, 2024 at 7:54 PM Jim wrote: > > Thanks for the quick reply. > > On Sat, Apr 13, 2024 at 09:18 (+0200), Hans Hagen wrote: > > > On 4/13/2024 12:39 AM, Jim wrote: > >> Hi, > > >> I have both TeXlive 2024 and the stand-alone ConTeXt distribution on my > >> system. > > >> Recently, the stand-alone ConTeXt distribution seems to not create a > >> synctex file any more. Specifically, > > >> /usr/local/context/tex/texmf-linux-64/bin/context --once --texutil > >> --synctex=1 --nonstop file.tex > > >> does not create a .synctex file (and deletes it, if it is there), whereas > >> the TeXlive version > > >> /usr/local/texlive/2024/bin/x86_64-linux/context --once --texutil > >> --synctex=1 --nonstop nwg_newsletter_2024_04.tex > > >> does create the .synctex file. > > > >> The ConTeXt distribution version *does* create the file if --nonstop is > >> *not* used. Knowing that, I can work around this for now, although > >> emacs+auctex probably won't be happy without --nonstop. > > >> I updated the stand-alone ConTeXt a few minutes ago, so I'm up to date on > >> that. > > >> Is this a bug introduced by some recent change? > > > it's more a feature > > I guess one person's bug is another person's feature. :-) > > > - Mikael S and i spend some time with editor/viewer combinations on linux in > > order to find ways around the different synctex libs that they use > > > - as a result we could make most work ok > > Are these recent changes? And should emacs+auctex+PDFview work now? What will work will depend on the viewers. We noticed a few weeks ago that synctex (pdf -> editor) was not working in a few viewers (okular) while it was working in others. After some debugging, our conclusion was that different versions of the library/application were used, or different approaches. We found a way to generate the stuff in the pdf to make it work for the failing viewers we had. Hans did then not replace this with the old approach, since then the previously working viewers might break. He therefore added repeat as a key, so \setupsynctex[state=repeat] will use the new approach. > > > - we assume that synctex is set up in the document with > > > \setupsynctex[state=start] > > \setupsynctex[state=repeat] % less efficient but gets around issue > > I haven't been using either of those, since auctex does The Right Thing for > me. Or, at least, it used to. > > > - when context is run 'headless' (on a server) it's often done in > > batchmode because one knows that the style works and in that case synctex > > makes no sense so we disable it; this avoids the need to patch the style > > I (think I) see what you are saying, but if one explicitly uses --synctex > on the command line, should that not over-ride the over-ride? Or, put > another way, would the following not make sense: > if --synctex is used on the command line > create synctex file > else if --nonstop is used on the command line > do not create the synctex file > else if \setupsynctex[...] is used in the source file > create the synctex file > else > do not create the synctex file > > > - the manual has been updates workflows-synctex.tex now suggests: "When your viewer doesn't return to the editor, you can try \starttyping \setupsynctex[state=repeat] \stoptyping or \starttyping context --synctex=repeat somefile.tex \stoptyping This will give a bit larger file that tries to fool the areas resolver in the library that the viewer uses." /Mikael ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: Most recent context doesn't like synctex?
Thanks for the quick reply. On Sat, Apr 13, 2024 at 09:18 (+0200), Hans Hagen wrote: > On 4/13/2024 12:39 AM, Jim wrote: >> Hi, >> I have both TeXlive 2024 and the stand-alone ConTeXt distribution on my >> system. >> Recently, the stand-alone ConTeXt distribution seems to not create a >> synctex file any more. Specifically, >> /usr/local/context/tex/texmf-linux-64/bin/context --once --texutil >> --synctex=1 --nonstop file.tex >> does not create a .synctex file (and deletes it, if it is there), whereas >> the TeXlive version >> /usr/local/texlive/2024/bin/x86_64-linux/context --once --texutil >> --synctex=1 --nonstop nwg_newsletter_2024_04.tex >> does create the .synctex file. >> The ConTeXt distribution version *does* create the file if --nonstop is >> *not* used. Knowing that, I can work around this for now, although >> emacs+auctex probably won't be happy without --nonstop. >> I updated the stand-alone ConTeXt a few minutes ago, so I'm up to date on >> that. >> Is this a bug introduced by some recent change? > it's more a feature I guess one person's bug is another person's feature. :-) > - Mikael S and i spend some time with editor/viewer combinations on linux in > order to find ways around the different synctex libs that they use > - as a result we could make most work ok Are these recent changes? And should emacs+auctex+PDFview work now? > - we assume that synctex is set up in the document with > \setupsynctex[state=start] > \setupsynctex[state=repeat] % less efficient but gets around issue I haven't been using either of those, since auctex does The Right Thing for me. Or, at least, it used to. > - when context is run 'headless' (on a server) it's often done in > batchmode because one knows that the style works and in that case synctex > makes no sense so we disable it; this avoids the need to patch the style I (think I) see what you are saying, but if one explicitly uses --synctex on the command line, should that not over-ride the over-ride? Or, put another way, would the following not make sense: if --synctex is used on the command line create synctex file else if --nonstop is used on the command line do not create the synctex file else if \setupsynctex[...] is used in the source file create the synctex file else do not create the synctex file > - the manual has been updates Ummm... I hunted around for a while, but I did not find out which manual was updated. The synctex wiki page has not been updated, nor has the "workflow support in context" manual. Can you tell me which manual I should go look at? > - running context in nonstop mode makes little sense Guessing wildly, I assume the auctex author(s) didn't want processes sitting there waiting for input on errors, like plain TeX would normally do. But perhaps the addition of --nonstopmode for ConTeXt is incorrect and/or redundant in April of 2024. > (maybe, as power user, Mikael remembers more details) Mikael? Any thoughts to share? Cheers. Jim ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: Back in the 90s
On 4/13/2024 2:12 PM, Riviera Taylor wrote: Hello, I was reading about the history of ConTeXt in the Not So Short Introduction To ConTeXt and I have a historical question. I noticed that the PDF specification was published in 1993 yet ConTeXt was invented in 1991. The book suggests that PDF output was handled by the PdfTeX engine in MKII in 2005. What sort of output did the software produce before PdfTeX was introduced? Was this the same as the output produced by the software before the publication of the PDF specification? 2005 is when we started with luatex which is a follow up on pdftex, and pdftex is more a mid 90's thing; we immediately adopted pdftex (which made some believe that context depended on pdftex which is not true) anyway, we started with dvi which needs a postprocessor to go to some printer format like specific hp or more general postscript but also can drive viewers we went from epson dot matrix printer -> early 300 dpi laser -> 600 dpi laser printer -> high speed oce 512 dpi printer (metric) -> high speed oce 600 dpi printer (+ crappy canon color laser printer) -> fast page-wide hp color inkjet office printer in mkii all is controlled by backend drivers, that use so called specials to support color, hyperlinks, images so a workflow can have - dvipsone : high quality postscript - dviwindo : viewer with typeone support and hyperlinks - acrobat : postscript to pdf and as all these external backends have their demands we could handle all these things in an abstract way (that way one could also drive printer properties like duplex or paper bins etc from a tex job) that meant that when pdf came around we could almost immediately support most of the interactive features in a dvi -> ps -> acrobat workflow when pdftex came around the intermediate step of postscript could be avoided which btw was also possible with dvipdfm(x) so we also supported that so to summarize, it went from tex -> dvi -> printer format tex -> dvi -> postscript -> more generic printer format tex -> dvi -> pdf -> print from acrobat tex -> pdf -> print from pdf viewer in the meantime we are pdf (as from that one can produce other formats) Hans (btw, the fact that we could easily support pdf was also a reason why at that time some adobe folk in nl used documents produced by context to show somewhat extrems usage of interactive features, thanks to the fact that tex can adapt to such new situations, also via the dvi route in this case with pdfmarks; at that time pdf usage - and features - was a bit more dualistic: ps replacement format versus storage and preview format, but that's a different story; but it still shows in how the standard evolved) - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Back in the 90s
Hello, I was reading about the history of ConTeXt in the Not So Short Introduction To ConTeXt and I have a historical question. I noticed that the PDF specification was published in 1993 yet ConTeXt was invented in 1991. The book suggests that PDF output was handled by the PdfTeX engine in MKII in 2005. What sort of output did the software produce before PdfTeX was introduced? Was this the same as the output produced by the software before the publication of the PDF specification? Kind regards, Riviera she, her, hers https://wiki.contextgarden.net/User:River ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
[NTG-context] Re: Most recent context doesn't like synctex?
On 4/13/2024 12:39 AM, Jim wrote: Hi, I have both TeXlive 2024 and the stand-alone ConTeXt distribution on my system. Recently, the stand-alone ConTeXt distribution seems to not create a synctex file any more. Specifically, /usr/local/context/tex/texmf-linux-64/bin/context --once --texutil --synctex=1 --nonstop file.tex does not create a .synctex file (and deletes it, if it is there), whereas the TeXlive version /usr/local/texlive/2024/bin/x86_64-linux/context --once --texutil --synctex=1 --nonstop nwg_newsletter_2024_04.tex does create the .synctex file. The ConTeXt distribution version *does* create the file if --nonstop is *not* used. Knowing that, I can work around this for now, although emacs+auctex probably won't be happy without --nonstop. I updated the stand-alone ConTeXt a few minutes ago, so I'm up to date on that. Is this a bug introduced by some recent change? it's more a feature - Mikael S and i spend some time with editor/viewer combinations on linux in order to find ways around the different synctex libs that they use - as a result we could make most work ok - we assume that synctex is set up in the document with \setupsynctex[state=start] \setupsynctex[state=repeat] % less efficient but gets around issue - when context is run 'headless' (on a server) it's often done in batchmode because one knows that the style works and in that case synctex makes no sense so we disable it; this avoids the need to patch the style - the manual has been updates - running context in nonstop mode makes little sense (maybe, as power user, Mikael remembers more details) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___
