Cannot build with newest context current version: 2024.11.01 19:19
Dear all, I get this error with context from current version: 2024.11.01 19:19 1 >> \environment env-alegreya 2 \environment env-alegreya-trimsize5-8 3 \environment env-deutsch 4 \environment env-makeups 5 \environment env-umbruch 6 \environment env-heading-sans 7 \environment env-layout 8 \environment env-figures 9 \environment env-pandoc 10 \setupcaptions[number=yes] 11 \setupdocument [ A number should have been here; I inserted '0'. (If you can't figure out why I needed to see a number, look up 'weird error' in the index to The TeXbook.) No problems with this versions: current version: 2023.02.07 19:06 current version: 2024.04.01 08:59 Were there changes how we have to treat environment files? The error only occurs when I use "--mode=trimsize" but I cannot track down the error by removing environments with mode-specific definitions. The first environment file does not contain any mode-specific definitions. Any hints? TIA juh
Addition: In an other project with mode specific buildings I have no problems with version 2024.09.25 11:53. juh
Hi, I have noticed something with the way ConTeXt is treating math kerns that I do not understand. Consider a prescript such as \startformula H^^^M \stopformula If the math.tl anchor on H is negative then the M is moved to the left (i.e away from the H). This is the opposite of what I would have expected, but perhaps I am confused. Also if the math.tl anchor on H is positive then ConTexT appears to be ignoring this kerning, and the position of the M is unchanged. Is this expected, or is this behaviour subject to some setting? The version of ConTeXt used is pasted below. Thanks! Julius context --version mtx-context | ConTeXt Process Management 1.06 mtx-context | mtx-context | main context file: /Users/juliusross/context/tex/texmf-context/tex/context/base/mkiv/context.mkiv mtx-context | current version: 2024.11.01 19:19 mtx-context | main context file: /Users/juliusross/context/tex/texmf-context/tex/context/base/mkxl/context.mkxl mtx-context | current version: 2024.11.01 19:19
Hi,
On Mon, Dec 23, 2024 at 6:03 PM Julius Ross
Hi,
I have noticed something with the way ConTeXt is treating math kerns that I do not understand.
Consider a prescript such as \startformula H^^^M \stopformula
If the math.tl anchor on H is negative then the M is moved to the left (i.e away from the H). This is the opposite of what I would have expected, but perhaps I am confused. Also if the math.tl anchor on H is positive then ConTexT appears to be ignoring this kerning, and the position of the M is unchanged.
Is this expected, or is this behaviour subject to some setting? The version of ConTeXt used is pasted below.
Thanks!
Julius
You can try to also set the leftbottom kern to a negative value. These were at some point made to align, because prescripts were mainly used for chemistry, and different alignment on top and bottom did look weird in the examples we looked at. I think that if the logic is about to change, real user examples are needed, with explanations on what one expects, where, and also why. /Mikael
Mikael,
Thank you. Your reply is enough for me to understand that I am not doing
anything (obviously) wrong!
I am not sure I have the expertise enough to contribute. But having a
negative kern value in a font move glyphs apart feels more like a
sign-error/bug than a choice/convention.
I never use (and rarely see) prescripts in mathematics, and I only learned
of their existence in TeX from your "math in context" document :-)
The opentype math spec certainly implies they were thinking of postscripts,
and I just presumed symmetry. So.for a symmetric letter (e.g. V) I would
expect the presubscript and postsubscript to be placed symmetrically as
they would both be qualifying the variable V.
That said, it seems that other fonts have not bothered taking care with
this (e.g. STIX has bottom right corner kerns on V but not bottom left).
So perhaps just not worrying too much about prescripts (for mathematics) is
the way to go.
Happy holidays to you all.
Julius
On Tue, Dec 24, 2024 at 10:45 AM Mikael Sundqvist
Hi,
On Mon, Dec 23, 2024 at 6:03 PM Julius Ross
wrote: Hi,
I have noticed something with the way ConTeXt is treating math kerns
that I do not understand.
Consider a prescript such as \startformula H^^^M \stopformula
If the math.tl anchor on H is negative then the M is moved to the left
(i.e away from the H). This is the opposite of what I would have expected, but perhaps I am confused. Also if the math.tl anchor on H is positive then ConTexT appears to be ignoring this kerning, and the position of the M is unchanged.
Is this expected, or is this behaviour subject to some setting? The
version of ConTeXt used is pasted below.
Thanks!
Julius
You can try to also set the leftbottom kern to a negative value. These were at some point made to align, because prescripts were mainly used for chemistry, and different alignment on top and bottom did look weird in the examples we looked at. I think that if the logic is about to change, real user examples are needed, with explanations on what one expects, where, and also why.
/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
___________________________________________________________________________________
On 12/29/2024 1:29 AM, Julius Ross wrote:
Mikael,
Thank you. Your reply is enough for me to understand that I am not doing anything (obviously) wrong!
I am not sure I have the expertise enough to contribute. But having a negative kern value in a font move glyphs apart feels more like a sign- error/bug than a choice/convention.
A next upload will have a better check and catch the issue.
I never use (and rarely see) prescripts in mathematics, and I only learned of their existence in TeX from your "math in context" document :-)
The opentype math spec certainly implies they were thinking of postscripts, and I just presumed symmetry. So.for a symmetric letter (e.g. V) I would expect the presubscript and postsubscript to be placed symmetrically as they would both be qualifying the variable V.
I'm not sure what they were thinking. It looks a bit like a 'maybe nice' feature. Even cambria (the reference font) is very incomplete and we noticed issues (unwanted overlaps) so in the we just ditched the whole concept as unreliable (other fonts had weird staircase kerns too) and went for a variant.
That said, it seems that other fonts have not bothered taking care with this (e.g. STIX has bottom right corner kerns on V but not bottom left). So perhaps just not worrying too much about prescripts (for mathematics) is the way to go.
Indeed, a rather inconsistent and semi-random feature. In the end it doesn't bring much to the table. FWIW, we have discussed this in articles and progress reports. 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 -----------------------------------------------------------------
juh+ntg-context--- via ntg-context schrieb am 22.12.2024 um 12:54:
Dear all,
I get this error with context from current version: 2024.11.01 19:19
1 >> \environment env-alegreya 2 \environment env-alegreya-trimsize5-8 3 \environment env-deutsch 4 \environment env-makeups 5 \environment env-umbruch 6 \environment env-heading-sans 7 \environment env-layout 8 \environment env-figures 9 \environment env-pandoc 10 \setupcaptions[number=yes] 11 \setupdocument [ A number should have been here; I inserted '0'. (If you can't figure out why I needed to see a number, look up 'weird error' in the index to The TeXbook.)
No problems with this versions:
current version: 2023.02.07 19:06 current version: 2024.04.01 08:59
Were there changes how we have to treat environment files?
The error only occurs when I use "--mode=trimsize" but I cannot track down the error by removing environments with mode-specific definitions. The first environment file does not contain any mode-specific definitions.
Can you send the log file, you can also add \tracingless at the begin of the file to increase the log information. Wolfgang
participants (5)
-
Hans Hagen
-
juh+ntg-context@mailbox.org
-
Julius Ross
-
Mikael Sundqvist
-
Wolfgang Schuster