Hi, I uploaded a new version, this time a bit of beta, because of: -- reworked control over callbacks: more restrictive, some protection against overload, better control; as a side effect context can run a bit faster but it depends on the job and features used; if something is not working as expected it might relate to this (easy to fix) -- some preparations for an upgrade of grid snapping, profiling and spacing (mostly related to math in the new columnsets); we're still working on columnsets (side effect of mikael converting some advanced documents to use it) -- overload protection enabled, for the moment only the warnings but at some point we might become more restrictive; keep an eye on messages so that you can see where your styles actually messes with already defined macros or enter the dangerous zone of changing primitives; fwiw: i've been running the highest level of protection already for years now (error mode) .. you can try \enabledirectives [overloadmode=error] at the top of your file to see how badly you behave -- a few fixes here and there (related to mailing list questions and reports); nothing spectacular -- some preparations wrt the new signalling mechanism(s) ... more about that after the meeting -- additional warnings (or abort) in case one runs from tex live and missing or expected files -- we're playing with some potential speedups but given the litle gain they might not make it into the lot eventually (if you run into bottlenecks, lets me know, with examples) if there are unexpected side effects, let me know and i'll fix and upload again Hans ps. i might reintroduce the beta/current updating scheme at some point .. still undecided ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On 6/12/25 13:56, Hans Hagen wrote:
I uploaded a new version, this time a bit of beta, because of: [...] -- some preparations for an upgrade of grid snapping, profiling and spacing (mostly related to math in the new columnsets); we're still working on columnsets (side effect of mikael converting some advanced documents to use it)
Many thanks for the new upload, all fixes and the new stuff, Hans. Regarding columnsets, I was about to ask you to include your presentations for BachoTeX 2025 in the next upload, but I found that some talks have their slides published at https://bachotex.gust.org.pl/2025/talks_en.html. As for your talks (with Mikael and Tove Sundqvist, of course), I have only found https://www.gust.org.pl/bachotex/2025-pl/presentations/columns-hhmps.pdf. Are there other slides which could be included in the next upload?
-- a few fixes here and there (related to mailing list questions and reports); nothing spectacular
There are to issues related to notes. The first one is `\setupnotes[footnote][rule=paragraph]` not following `\setupalign[r2l]` (but only in LMTX, LuaTeX works fine in this regard; https://mailman.ntg.nl/archives/list/ntg-context@ntg.nl/thread/7CDFPXOBO2UEV...). The other one is mainly a question about `compressmethod` behaviour in linennotes. I thought that `compressmethod=separator` adds the command defined in `compressseparator` between the compressed notes, and `compressmethod=stopper` adds the command from `compressstoper` only after the compressed notes. Could you confirm this? I’m afraid that both options add the command between and after the compressed notes (https://mailman.ntg.nl/archives/list/ntg-context@ntg.nl/thread/VAHLDB6KVDJHU...). Many thanks for your help, Pablo
Am 12.06.2025 um 16:40 schrieb Pablo Rodriguez via ntg-context:
The other one is mainly a question about `compressmethod` behaviour in linennotes.
I thought that `compressmethod=separator` adds the command defined in `compressseparator` between the compressed notes, and `compressmethod=stopper` adds the command from `compressstoper` only after the compressed notes.
Could you confirm this? I’m afraid that both options add the command between and after the compressed notes (https://mailman.ntg.nl/archives/list/ntg-context@ntg.nl/thread/VAHLDB6KVDJHU...).
You need something like this: \newconditional\NoNumber \NoNumber \conditionalfalse \newconditional\FirstEntry \FirstEntry\conditionaltrue \define[1]\LineNoteCommand {\doiftextelse{#1}{\NoNumber\conditionalfalse}{\NoNumber\conditionaltrue}% \ifconditional\NoNumber ,\space \else \ifconditional\FirstEntry \iftrialtypesetting\else \global\FirstEntry\conditionalfalse \fi \else \space \fi #1% \fi} \setuplinenote [paragraph=yes, compress=yes, compressseparator=, compressdistance=0pt] \setupnotation [linenote] [alternative=serried, headcommand=\LineNoteCommand] \starttext \startlinenumbering \dorecurse{25}{a\linenote{b}} \stoplinenumbering \stoptext Wolfgang
On 6/12/25 17:36, Wolfgang Schuster wrote:
Am 12.06.2025 um 16:40 schrieb Pablo Rodriguez via ntg-context:
[...] I thought that `compressmethod=separator` adds the command defined in `compressseparator` between the compressed notes, and `compressmethod=stopper` adds the command from `compressstoper` only after the compressed notes.
Could you confirm this? I’m afraid that both options add the command between and after the compressed notes.
You need something like this:
Many thanks for yor reply, Wolfgang. I thought this worked differently in the past (I mean, five years ago). In any case, many thanks for pointing to the cause of this issue. Pablo
On 6/12/2025 4:40 PM, Pablo Rodriguez via ntg-context wrote:
On 6/12/25 13:56, Hans Hagen wrote:
I uploaded a new version, this time a bit of beta, because of: [...] -- some preparations for an upgrade of grid snapping, profiling and spacing (mostly related to math in the new columnsets); we're still working on columnsets (side effect of mikael converting some advanced documents to use it)
Many thanks for the new upload, all fixes and the new stuff, Hans.
well, mikael already ran into an issue with image sin columnsetsheet so ... update later this week
Regarding columnsets, I was about to ask you to include your presentations for BachoTeX 2025 in the next upload, but I found that some talks have their slides published at https://bachotex.gust.org.pl/2025/talks_en.html.
As for your talks (with Mikael and Tove Sundqvist, of course), I have only found https://www.gust.org.pl/bachotex/2025-pl/presentations/columns-hhmps.pdf.
Are there other slides which could be included in the next upload?
i don't dare to push these as they can't compare to the nice ones by mikael so i need to think about it
-- a few fixes here and there (related to mailing list questions and reports); nothing spectacular
There are to issues related to notes.
The first one is `\setupnotes[footnote][rule=paragraph]` not following `\setupalign[r2l]` (but only in LMTX, LuaTeX works fine in this regard; https://mailman.ntg.nl/archives/list/ntg-context@ntg.nl/thread/7CDFPXOBO2UEV...).
ha, that uses soem trick that is for old-school box based inserts, not the newer index based method that we use in lmtx so i need to fix that
The other one is mainly a question about `compressmethod` behaviour in linennotes.
see wolfgangs mail and fix .. so we need to adapt some code
I thought that `compressmethod=separator` adds the command defined in `compressseparator` between the compressed notes, and `compressmethod=stopper` adds the command from `compressstoper` only after the compressed notes.
Could you confirm this? I’m afraid that both options add the command between and after the compressed notes (https://mailman.ntg.nl/archives/list/ntg-context@ntg.nl/thread/VAHLDB6KVDJHU...).
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 -----------------------------------------------------------------
On 6/12/25 18:06, Hans Hagen via ntg-context wrote:
[...] i don't dare to push these as they can't compare to the nice ones by mikael so i need to think about it
We all enjoy beautiful presentations, but presentations are documentation sources too. I compile XML sources with ConTeXt right now thanks to https://www.dante.de/veranstaltungen/Archiv/dante2011/programm/vortraege/fol... (now offline). It contained snippets that I copied and pasted in two files, which allowed me to understand (with my limited knowledge) how ConTeXt deals with XML code. xml-mkiv.pdf is great, but even today my XPath experience is not enough to understand it properly.
see wolfgangs mail and fix .. so we need to adapt some code
Looking forward this new approach. Many thanks for your help, Pablo
Am 12.06.25 um 16:40 schrieb Pablo Rodriguez via ntg-context:
Regarding columnsets, I was about to ask you to include your presentations for BachoTeX 2025 in the next upload, but I found that some talks have their slides published at https://bachotex.gust.org.pl/2025/talks_en.html.
As for your talks (with Mikael and Tove Sundqvist, of course), I have only found https://www.gust.org.pl/bachotex/2025-pl/presentations/columns-hhmps.pdf.
Thanks for the link! I didn’t think to look for it. The columns presentation is very nice. I also read a few of the others (Japanese, GUST fonts). @Tomáš: I’d like to see the “ConTeXt and Lua tutorial & workshop for beginners”, would you share it? Hraban
On 2025-06-12 07:56, Hans Hagen wrote:
Hi,
I uploaded a new version, this time a bit of beta, because of:
-- reworked control over callbacks: more restrictive, some protection against overload, better control; as a side effect context can run a bit faster but it depends on the job and features used; if something is not working as expected it might relate to this (easy to fix)
-- some preparations for an upgrade of grid snapping, profiling and spacing (mostly related to math in the new columnsets); we're still working on columnsets (side effect of mikael converting some advanced documents to use it)
-- overload protection enabled, for the moment only the warnings but at some point we might become more restrictive; keep an eye on messages so that you can see where your styles actually messes with already defined macros or enter the dangerous zone of changing primitives; fwiw: i've been running the highest level of protection already for years now (error mode) .. you can try \enabledirectives [overloadmode=error] at the top of your file to see how badly you behave
-- a few fixes here and there (related to mailing list questions and reports); nothing spectacular
-- some preparations wrt the new signalling mechanism(s) ... more about that after the meeting
-- additional warnings (or abort) in case one runs from tex live and missing or expected files
-- we're playing with some potential speedups but given the litle gain they might not make it into the lot eventually (if you run into bottlenecks, lets me know, with examples)
if there are unexpected side effects, let me know and i'll fix and upload again
The following example fails to generate a label in the makeup page. With 20250428 it does generate the label. With alternative=intext, all is as expected. The counter is incremented in all cases. \definelabel [X] % [alternative=intext] [alternative=inmargin] \definemakeup [mkup] [doublesided=no] \starttext \startmakeup [mkup] abc\X[abc]\par \ref[number][abc]\par \stopmakeup def\X[def]\par \ref[number][def]\par \Context\ version\par \contextversionnumber \stoptext -- Rik
Am 12.06.2025 um 22:08 schrieb Rik Kabel:
The following example fails to generate a label in the makeup page. With 20250428 it does generate the label.
With alternative=intext, all is as expected.
The counter is incremented in all cases.
\definelabel [X] % [alternative=intext] [alternative=inmargin] \definemakeup [mkup] [doublesided=no] \starttext \startmakeup [mkup] abc\X[abc]\par \ref[number][abc]\par \stopmakeup def\X[def]\par \ref[number][def]\par \Context\ version\par \contextversionnumber \stoptext
https://www.mail-archive.com/ntg-context@ntg.nl/msg109609.html Wolfgang
On 2025-06-12 17:33, Wolfgang Schuster wrote:
Am 12.06.2025 um 22:08 schrieb Rik Kabel:
The following example fails to generate a label in the makeup page. With 20250428 it does generate the label.
With alternative=intext, all is as expected.
The counter is incremented in all cases.
\definelabel [X] % [alternative=intext] [alternative=inmargin] \definemakeup [mkup] [doublesided=no] \starttext \startmakeup [mkup] abc\X[abc]\par \ref[number][abc]\par \stopmakeup def\X[def]\par \ref[number][def]\par \Context\ version\par \contextversionnumber \stoptext
https://www.mail-archive.com/ntg-context@ntg.nl/msg109609.html
Wolfgang
Thank you, Wolfgang for the reminder. I must have patched my local copies in the April 1 and April 28 releases and forgotten that I had done so. It looks like nothing was done to incorporate the fix since you proposed it, or (as you suggested might be the case) there are side effects of the change that argue against using it. In any case, I have now rewritten the section to eliminate the need for a makeup. -- Rik
Hi Hans, On Thu, 2025-06-12 at 13:56 +0200, Hans Hagen wrote:
I uploaded a new version,
Looks like my autoupdating scripts worked well, the new version should be available in TeX Live as of a few hours ago. In case anyone ever encounters any critical bugs in the version packaged by TeX Live, it's pretty easy to downgrade the prior version: $ tlmgr restore context 75454 $ tlmgr restore context.x86_64-linux 75425 (run "tlmgr restore context" to list the available versions) Or if you need to downgrade to an even earlier version, it's only slightly more involved: $ rm /usr/local/texlive/2025/bin/x86_64-linux/{mtxrun,mtxrun.lua,context,context.lua,luametatex} $ tlmgr install --reinstall --file \ https://texlive.info/tlnet-archive/2025/06/12/tlnet/archive/context.tar.xz \ https://texlive.info/tlnet-archive/2025/06/12/tlnet/archive/context.x86_64-l... (replace the "2025/06/12" with whatever date you want to downgrade to)
-- additional warnings (or abort) in case one runs from tex live and missing or expected files
Sure, fine by me. One possible idea: instead of relying on the file luametatex.h existing/not existing, I could add a "distributed_by" key (or similar) to the texmfcnf.lua file in TeX Live. Then ConTeXt could display the contents of that key in the log file, right below the ConTeXt version, so that it's clear to users (and people reading messages to the mailing list) that they're using an unofficial version.
ps. i might reintroduce the beta/current updating scheme at some point .. still undecided
Also fine by me; let me know if you ever want me to make any changes to the packaging in TeX Live.
% texmf-dist/tex/context/modules/mkxl/m-texlive.mkxl %D This is a variant on code I found in a \TEXLIVE\ installation in \type %D {cont-sys.mkxl} in 2025. In \type {cont-sys.mkxl} one can add this: %D %D \starttyping %D \usemodule[texlive] %D \stoptyping
I've updated cont-sys.mkxl with your new code, thanks!
%D I guess that the reason for this hackery is that a \TEXLIVE\ doesn't do %D an update of the file database after installing some \CONTEXT\ related %D files. In a similar manner, when a used updated something \CONTEXT\ we %D don't generate an lsr file. Here both are checked.
So TeX Live (tlmgr) always runs "mtxrun [--luatex] --generate" and "context [--luatex] --make" whenever it modifies any ConTeXt files, but since most users install TeX Live to "/usr/local/texlive/$YEAR" (or similar), tlmgr runs as root, so it can only update the caches/formats in "/usr/local/texlive/$YEAR/texmf-var/". But if a someone ever runs "mtxrun --generate" or "context --make" as a regular user, ConTeXt will create caches/formats in "~/.texlive$YEAR/texmf-var/", and then it will ignore all the files in "/usr/local/texlive/$YEAR/texmf-var/", even if they're newer than the user-local ones. I wrote that code as a quick hack back in 2023, but as we all know, quick hacks tend to stay around far longer than they should :). If there's some way to tell ConTeXt to always use the system's filename cache files for "root == 'selfautoparent:texmf-dist'", and then the user-local filename cache files for other roots, that would probably be even better. Thanks again, -- Max
On 6/14/2025 8:47 AM, Max Chernoff via ntg-context wrote:
Hi Hans,
On Thu, 2025-06-12 at 13:56 +0200, Hans Hagen wrote:
I uploaded a new version,
Looks like my autoupdating scripts worked well, the new version should be available in TeX Live as of a few hours ago.
hm, there will be a new upload with some reported issues fixed ... i wonder if a too frequent texlive sync is good, as it sounds pretty beta and isn't tex live also in linux distributions? maybe some delay is better; is there some policy wrt that in texlive? like monthly update or so that we can then adapt to?
In case anyone ever encounters any critical bugs in the version packaged by TeX Live, it's pretty easy to downgrade the prior version:
$ tlmgr restore context 75454 $ tlmgr restore context.x86_64-linux 75425
(run "tlmgr restore context" to list the available versions)
Or if you need to downgrade to an even earlier version, it's only slightly more involved:
$ rm /usr/local/texlive/2025/bin/x86_64-linux/{mtxrun,mtxrun.lua,context,context.lua,luametatex} $ tlmgr install --reinstall --file \ https://texlive.info/tlnet-archive/2025/06/12/tlnet/archive/context.tar.xz \ https://texlive.info/tlnet-archive/2025/06/12/tlnet/archive/context.x86_64-l...
(replace the "2025/06/12" with whatever date you want to downgrade to)
-- additional warnings (or abort) in case one runs from tex live and missing or expected files Sure, fine by me. One possible idea: instead of relying on the file luametatex.h existing/not existing, I could add a "distributed_by" key (or similar) to the texmfcnf.lua file in TeX Live. Then ConTeXt could display the contents of that key in the log file, right below the ConTeXt version, so that it's clear to users (and people reading messages to the mailing list) that they're using an unofficial version.
that would only work for texlive then but it could be an option indeed
ps. i might reintroduce the beta/current updating scheme at some point .. still undecided
Also fine by me; let me know if you ever want me to make any changes to the packaging in TeX Live.
i'll think of it; basically in the installer you can already set it to beta so it's basiclaly just another path then but it might not be worth the trouble in the end
% texmf-dist/tex/context/modules/mkxl/m-texlive.mkxl %D This is a variant on code I found in a \TEXLIVE\ installation in \type %D {cont-sys.mkxl} in 2025. In \type {cont-sys.mkxl} one can add this: %D %D \starttyping %D \usemodule[texlive] %D \stoptyping
I've updated cont-sys.mkxl with your new code, thanks!
Ha, you noticed. I wanted to test that but you beat me on that.
%D I guess that the reason for this hackery is that a \TEXLIVE\ doesn't do %D an update of the file database after installing some \CONTEXT\ related %D files. In a similar manner, when a used updated something \CONTEXT\ we %D don't generate an lsr file. Here both are checked.
So TeX Live (tlmgr) always runs "mtxrun [--luatex] --generate" and "context [--luatex] --make" whenever it modifies any ConTeXt files, but since most users install TeX Live to "/usr/local/texlive/$YEAR" (or similar), tlmgr runs as root, so it can only update the caches/formats in "/usr/local/texlive/$YEAR/texmf-var/". But if a someone ever runs "mtxrun --generate" or "context --make" as a regular user, ConTeXt will create caches/formats in "~/.texlive$YEAR/texmf-var/", and then it will ignore all the files in "/usr/local/texlive/$YEAR/texmf-var/", even if they're newer than the user-local ones.
i suppose it also catched users putting e.g. fonts someplace without runnign file database updaters .. chicken-egg stuff (also becaus ein context we have texmf-fonts and a more flat structure) btw, i installed a texlive in a vm and it seemd to work (i explicitly have to set these paths to a more reliable isolation (i want no funny .foo and mess in ~) but using the same tex related var local and home paths works)
I wrote that code as a quick hack back in 2023, but as we all know, quick hacks tend to stay around far longer than they should :). If there's some way to tell ConTeXt to always use the system's filename cache files for "root == 'selfautoparent:texmf-dist'", and then the user-local filename cache files for other roots, that would probably be even better.
indeed. and having a module has better change of keeping in sync if we need more explanation in that file, we can add it (Just let me know) (i wondered about a warning of using a different than default papersize as set up by texlve - i saw that it's optional in the installer - but that is a bit hard to catch realiable but i'll think about it; manuals are rendered assuming A4) Thanks for the patience and effort. 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 -----------------------------------------------------------------
Hi Hans, On Sat, 2025-06-14 at 09:41 +0200, Hans Hagen wrote:
On 6/14/2025 8:47 AM, Max Chernoff via ntg-context wrote: i wonder if a too frequent texlive sync is good, as it sounds pretty beta
My thinking was that if it's stable enough for the users of the Standalone Distribution (many of whom use ConTeXt professionally), then it should be stable enough for TeX Live. The build script tries compiling a very basic test document https://github.com/gucci-on-fleek/maxchernoff.ca/blob/master/builder/contain... and aborts if it doesn't give the expected output, so the TL version should never be *completely* broken. And it's pretty common for new LaTeX releases to break lots of documents; people have posted tons of duplicates of this question https://tex.stackexchange.com/q/735500 in this past week. Even the perpetually-stable pdfTeX had a few bugs earlier this year.
and isn't tex live also in linux distributions?
Yes, but almost all the distros base their packages off of the annual ISOs, most of which are severely outdated (TL23 and older are common): https://repology.org/project/texlive/versions https://repology.org/project/texlive-base/versions
maybe some delay is better; is there some policy wrt that in texlive?
Karl updates the packages in TL every day; most days there are 3--8 different packages that get updated. And it's pretty common for packages to be updated multiple times in a week (often after a new major version was released), and there are a few packages that are consistently updated almost every week.
like monthly update or so that we can then adapt to?
Sure, I can reduce the update frequency if you want; right now it's set to check for updates daily, but it's easy to change it to every second day/weekly/monthly/etc. My thinking was that since all software has bugs, frequent updates in TL will shorten the interval between people reporting bugs and them receiving the fix. Or I can let the autoupdater run daily most of the time, but then disable it during the weeks of BachoTeX and the ConTeXt Meeting (when updates tend to be more frequent).
(i wondered about a warning of using a different than default papersize as set up by texlve - i saw that it's optional in the installer - [...] but i'll think about it; manuals are rendered assuming A4)
I tried convincing Karl to let me remove the system-dependent paper stuff (which I added in the first place at his request), but he wants to keep it for consistency with the other formats.
but that is a bit hard to catch realiable
If the file "context-papersize.tex" exists (full path: $TEXMFCONFIG/tex/context/user/context-papersize.tex ), then the user has ran "sudo tlmgr paper [letter|a4]"; otherwise, TeX Live will use the default settings. So the only case that you should need to check for is if "context-papersize.tex" contains the following contents: \setuppapersize[letter][letter] Thanks, -- Max
On 6/14/2025 10:47 AM, Max Chernoff via ntg-context wrote:
Hi Hans,
On Sat, 2025-06-14 at 09:41 +0200, Hans Hagen wrote:
On 6/14/2025 8:47 AM, Max Chernoff via ntg-context wrote: i wonder if a too frequent texlive sync is good, as it sounds pretty beta
My thinking was that if it's stable enough for the users of the Standalone Distribution (many of whom use ConTeXt professionally), then it should be stable enough for TeX Live. The build script tries
sure, definitely after a few days (occasionally we have some fundamental update, in this case callback refactoring)
compiling a very basic test document
https://github.com/gucci-on-fleek/maxchernoff.ca/blob/master/builder/contain...
and aborts if it doesn't give the expected output, so the TL version should never be *completely* broken. And it's pretty common for new LaTeX releases to break lots of documents; people have posted tons of duplicates of this question
oh, but latex (instability) is not our benchmark (btw, interesting that latex can be broken because from that end it was always suggested that context is moving target while latex is guaranteed stable due to regression testing but i didn't keep up with the latest perceptions)
in this past week. Even the perpetually-stable pdfTeX had a few bugs earlier this year.
oh ... i thought that pdftex was very stable and admit that i never check mkii with that (i just assume that when we can make a mkii format we're fine) in this recent upload i actually mentioned some changes that needed testing; normally a problem shows up soonish and then we fix, after that we enter a period of no uploads; i consider tex live context users to be more interested in stable while those using the installer (and on the mailing list) are more adventurous, involved in new features, awar eof developments, and they either wait with an update or make a copy of the current tree (which is relatively small compared to texlive) and just help testing
and isn't tex live also in linux distributions?
Yes, but almost all the distros base their packages off of the annual ISOs, most of which are severely outdated (TL23 and older are common):
https://repology.org/project/texlive/versions https://repology.org/project/texlive-base/versions
ok, so we're safe there
maybe some delay is better; is there some policy wrt that in texlive?
Karl updates the packages in TL every day; most days there are 3--8 different packages that get updated. And it's pretty common for packages to be updated multiple times in a week (often after a new major version was released), and there are a few packages that are consistently updated almost every week.
hm, times have changed ... (i wonder how that impacts users who expect for instance fonts and patterns to be the same over time but maybe they juist don't update or at least not hit the update button without checking)
like monthly update or so that we can then adapt to?
Sure, I can reduce the update frequency if you want; right now it's set to check for updates daily, but it's easy to change it to every second day/weekly/monthly/etc. My thinking was that since all software has bugs, frequent updates in TL will shorten the interval between people reporting bugs and them receiving the fix. Or I can let the autoupdater run daily most of the time, but then disable it during the weeks of BachoTeX and the ConTeXt Meeting (when updates tend to be more frequent).
let's for now keep an eye on matters and evaluate later
(i wondered about a warning of using a different than default papersize as set up by texlve - i saw that it's optional in the installer - [...] but i'll think about it; manuals are rendered assuming A4)
I tried convincing Karl to let me remove the system-dependent paper stuff (which I added in the first place at his request), but he wants to keep it for consistency with the other formats.
thanks for trying
but that is a bit hard to catch realiable
If the file "context-papersize.tex" exists (full path:
$TEXMFCONFIG/tex/context/user/context-papersize.tex
), then the user has ran "sudo tlmgr paper [letter|a4]"; otherwise, TeX Live will use the default settings. So the only case that you should need to check for is if "context-papersize.tex" contains the following contents:
\setuppapersize[letter][letter]
if maybe just if that file is there, right? 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 -----------------------------------------------------------------
Hi Hans, On Sat, 2025-06-14 at 11:45 +0200, Hans Hagen wrote:
in this past week. Even the perpetually-stable pdfTeX had a few bugs earlier this year.
oh ... i thought that pdftex was very stable and admit that i never check mkii with that (i just assume that when we can make a mkii format we're fine)
I remember the one bug being a spacing issue that only showed up with very specific documents, the other bug I accidentally introduced while fixing a different bug (oops). Both bugs were fixed before TL25 was released (or maybe it was shortly after?), so MkII should be fine.
Karl updates the packages in TL every day; most days there are 3--8 different packages that get updated. And it's pretty common for packages to be updated multiple times in a week (often after a new major version was released), and there are a few packages that are consistently updated almost every week.
hm, times have changed ... (i wonder how that impacts users who expect for instance fonts and patterns to be the same over time but maybe they juist don't update or at least not hit the update button without checking)
Most of the font authors are pretty careful to not change the metrics in updates, so that's not usually a big deal. But hyphenation patterns definitely change, so most users who care about identical page breaks will just use a frozen (and usually ancient) version of TeX Live and never upgrade.
like monthly update or so that we can then adapt to?
Sure, I can reduce the update frequency if you want; right now it's set to check for updates daily, but it's easy to change it to every second day/weekly/monthly/etc. My thinking was that since all software has bugs, frequent updates in TL will shorten the interval between people reporting bugs and them receiving the fix. Or I can let the autoupdater run daily most of the time, but then disable it during the weeks of BachoTeX and the ConTeXt Meeting (when updates tend to be more frequent).
let's for now keep an eye on matters and evaluate later
Ok, sounds good to me. Let me know if/when you want me to change anything.
but that is a bit hard to catch realiable
If the file "context-papersize.tex" exists (full path:
$TEXMFCONFIG/tex/context/user/context-papersize.tex
), then the user has ran "sudo tlmgr paper [letter|a4]"; otherwise, TeX Live will use the default settings. So the only case that you should need to check for is if "context-papersize.tex" contains the following contents:
\setuppapersize[letter][letter]
if maybe just if that file is there, right?
If you run "tlmgr paper a4" the file will contain \setuppapersize[A4][A4] which is probably not worth warning over. Thanks, -- Max
On Sat, Jun 14, 2025 at 04:24:32AM -0600, Max Chernoff via ntg-context wrote:
But hyphenation patterns definitely change, so most users who care about identical page breaks will just use a frozen (and usually ancient) version of TeX Live and never upgrade.
Actually, it really depends on the language. For a few languages, the patterns are updated pretty often, but for all the others, including English, they never do. Arthur
participants (8)
-
Arthur Rosendahl -
Hans Hagen -
Hans Hagen -
Henning Hraban Ramm -
Max Chernoff -
Pablo Rodriguez -
Rik Kabel -
Wolfgang Schuster