[NTG-context] gzip.compress in ConTeXt mkiv
Hi,
The following document
\directlua{
local arch = gzip.compress"I will become much much smaller, once the
overhead is compensated"
local orig = gzip.decompress(arch)
print(arch:len(), orig:len(), orig)
}
\starttext
\stoptext
used to work in ConTeXt mkiv and still works in ConTeXt lmtx, but for
current mkiv versions it breaks with
...mtx/tex/texmf-context/tex/context/base/mkiv/util-zip.lua:610: attempt to
call a nil value (upvalue 'tocardinal1')
stack traceback:
...mtx/tex/texmf-context/tex/context/base/mkiv/util-zip.lua:610: in
upvalue 'putcompressed'
...mtx/tex/texmf-context/tex/context/base/mkiv/util-zip.lua:662: in
function 'gzip.compress'
[ctxlua]:1: in main chunk
Best regards,
Marcel
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] ConTeXt inserts additional dots for Iosevka font
Hi, On Sun, Sep 12, 2021 at 12:01:08AM +0200, Hans Hagen wrote: > > \definefontfeature > >[default:test] > >[default] > >[cv36=2,cv26=6] > > What is the number supposed to indicate ? It is not an alternate, right? Actually it is an alternate, but only partially. > > > \definefont > >[SomeFont] > >[name:iosevka*default:test] > > \starttext > > \SomeFont > > I live in a dot-heavy world. > > \stoptext > > > > has six dots instead of one dot over each "i". Tests with multiple other > > font shapers and inspection of the font file confirmed that this is not > > intentional behavior. > > > > Could you take a look at that? > > (Based on a luotfload bug report at > > https://github.com/latex3/luaotfload/issues/202) > when a number is specified for a multiple and the is > 1 we repeat the last > glyph ... this is a 'secret' feature that (already a while ago) we added > when discussing / testing a experimental arabic font in combination with a > paragraph optimizer ... normally users will say 'yes' and not give a number Thanks, this explains a lot. In this font it's problematic though because the cv.. features have multiple loopup tables, one of which is a "multiple" lookup (used to decompose characters before applying the replacements, especially decomposing i into the stem and the dot) and another one is an "alternate" lookup providing multiple character variants. So selecting one of the other alternates requires that a number is passed, but passing the number enables the repetition in the multiple lookup... > > i can make that a 'context only' feature if needed That would certainly solve the issue for me, but it might be nice to provide a solution for context users too. Maybe the feature could be adapted to only interpret the argument as a replication factor if the "multiple" is the only lookup for the feature or if no other lookup for the feature is an alternate lookup? Best, Marcel ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
[NTG-context] ConTeXt inserts additional dots for Iosevka font
Hi, ConTeXt has some issues with the character variant features of the Iosevka font available at https://github.com/be5invis/Iosevka/releases/download/v10.1.1/super-ttc-iosevka-10.1.1.zip E.g. the following document \definefontfeature [default:test] [default] [cv36=2,cv26=6] \definefont [SomeFont] [name:iosevka*default:test] \starttext \SomeFont I live in a dot-heavy world. \stoptext has six dots instead of one dot over each "i". Tests with multiple other font shapers and inspection of the font file confirmed that this is not intentional behavior. Could you take a look at that? (Based on a luotfload bug report at https://github.com/latex3/luaotfload/issues/202) Best regards, Marcel ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] Failure when loading variable font
Hi, On Sat, Aug 14, 2021 at 09:05:45PM +0200, Hans Hagen wrote: > that's because since then we check for the cycle (otherwise artifacts) > > it probably relates to these extra points (the 'standard' is somewhat fuzzy > in that respect also because some fonts have them and some don't so it's the > usual wait till we run into something issue) As far as I understand the spec the phantom points shouldn't influence this since the next and previous points are only looked up in the current contour and the phantom point are not on any contour, so they can never appear as next or previous point anyway. That doesn't seem to be implemented though. > > we can check for bounds > > for i=1,nofpoints do > local d1, d2, d3 = find(i) > local p2 = points[i] > if d2 then > xv[i] = xvalues[d2] > yv[i] = yvalues[d2] > else > local n1 = dpoints[d1] > local n3 = dpoints[d3] > if n1 > nofpoints then > n1 = nofpoints > end > if n3 > nofpoints then > n3 = nofpoints > end > > no crash then (the resulting shapes look good enough to me, assumign that > the weird f is intended) Thanks, with this change ConTeXt seems to give the expected output for this font. (Yes, the weird f is intentional. Evn though IMO it's not siginificantly weirder than the other glyphs in that font) Best, Marcel ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
[NTG-context] No kerning across discretionary nodes in latest ConTeXt upload
Hi,
since the latest upload, ConTeXt no longer applies kerning across
discretionary nodes:
\starttext
\setbox0\hbox{V\-a}
\showboxdepth\maxdimen
\showboxbreadth\maxdimen
\tracingonline1
\showbox0
\stoptext
used to show
> \box0=
\hbox(8.1915+0.25186)x13.69647, direction TLT
.<1: lmroman12-regular @ 12.0pt> V
.\discretionary (penalty 50)
..< <1: lmroman12-regular @ 12.0pt> -
..= \kern-0.98346 (font)
.<1: lmroman12-regular @ 12.0pt> a
but now changed to
> \box0=
\hbox(8.1915+0.25186)x14.67993, direction TLT
.<1: lmroman12-regular @ 12.0pt> V
.\discretionary (penalty 50)
..< <1: lmroman12-regular @ 12.0pt> -
.<1: lmroman12-regular @ 12.0pt> a
This seems like a regression.
Best regards,
Marcel
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Variable OTF font resulting in invalid font due to stack overflow
On Thu, May 13, 2021 at 04:23:21PM +0200, Hans Hagen wrote:
> On 5/12/2021 11:46 PM, Marcel Fabian Krüger wrote:
> > Hi,
> >
> > recently we got an interesting bug report in luaotfload (the original report
> > is at https://github.com/latex3/luaotfload/issues/184) which relates to the
> > ConTeXt fontloader. Take the following ConTeXt example:
> >
> > \starttext
> > \definefontfeature [default:bold] [default] [axis={weight=500}]
> > \definedfont[file:NotoSansCJKsc-VF.otf*default:bold @ 10pt]
> > U+5E2E 帮
> > \stoptext
> >
> > The font is available at
> > https://github.com/googlefonts/noto-cjk/raw/main/Sans/Variable/OTF/NotoSansCJKsc-VF.otf.
> >
> > This compiles correctly, but the CJK glyph do not appear since
> > it's Type2 CharString is invalid. The CFF2 CharStrings of this
> > glyph invokes the rrcurveto operator with 63 arguments, which is
>
> 66 etc .. multiples of 6
Counting is hard... (I assumed that all arguments are created through
blend operators)
>
> > allowed in CFF2 where the argument limit is 513, but not allowed in
> > Type2 where the limit is at 48.
>
> a rather low limit right from the start (we can assume only rrcurveto is
> affected)
>
> > It would be great if ConTeXt could check for this and insert additional
> > rrcuveto operators when necessary to avoid this issue.
> after some experiments ... attached
Thanks you very much for looking into this so quickly.
>
> (no upload yet as i'm renaming some low level helpers which needs testing)
I've noticed that both issues are fixed in the latest upload and testing
showed that it works, except for two small issues:
1. The cache version of the streams cache didn't change, therefore the
fix only gets picked up if the old cache is manually deleted.
Could it be increased to automatically trigger a rebuilt?
2. The change to f_convert in font-ocl.lua relies on `new` being set,
which only happens when inkscapeformat is first called which happens
later in the same function. Therefore it does not work for the
first SVG font loaded, while others work fine.
Best regards,
Marcel
>
> Hans
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
[NTG-context] Variable OTF font resulting in invalid font due to stack overflow
Hi,
recently we got an interesting bug report in luaotfload (the original report
is at https://github.com/latex3/luaotfload/issues/184) which relates to the
ConTeXt fontloader. Take the following ConTeXt example:
\starttext
\definefontfeature [default:bold] [default] [axis={weight=500}]
\definedfont[file:NotoSansCJKsc-VF.otf*default:bold @ 10pt]
U+5E2E 帮
\stoptext
The font is available at
https://github.com/googlefonts/noto-cjk/raw/main/Sans/Variable/OTF/NotoSansCJKsc-VF.otf.
This compiles correctly, but the CJK glyph do not appear since
it's Type2 CharString is invalid. The CFF2 CharStrings of this
glyph invokes the rrcurveto operator with 63 arguments, which is
allowed in CFF2 where the argument limit is 513, but not allowed in
Type2 where the limit is at 48.
It would be great if ConTeXt could check for this and insert additional
rrcuveto operators when necessary to avoid this issue.
Additionally we got a report that inkscape 1.0 seems to be incompatible
with the way commmands are passed to it for SVG files. Hendrik Seliger
suggested to set f_convert (defined in font-ocl.lua, otfsvg.topdf, line 435)
to `formatters["file-open:%s; export-%s:%s; export-do\n"]` when a new
inkscape version is detected. (See
https://github.com/latex3/luaotfload/issues/183)
I wasn't able to reproduce the issue in ConTeXt yet.
Best regards,
Marcel
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Generic fontloader and flush_components
On Sun, Dec 27, 2020 at 10:50:03PM +0100, Hans Hagen wrote: > On 12/27/2020 7:19 PM, Marcel Fabian Krüger wrote: > > Hi, > > > > in font-ots.lua (which becomes part of the generic fontloader) > > nuts.flush_components is used, while it seems to be defined for > > mkiv and generic in node-gcm.lua, but this file is not included in the > > packaged generic fontloader. Therefore the current luatex-fonts-merged.lua > > breaks with "trying to call a nil value (upvalue flush_components)". > > > > Could you please add a definition for nuts.flush_components in the > > generic version? > I'll add it to (the rest in): > > luatex-basics-nod.lua > > (it's a dummy function) > Thank you. Marcel ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
[NTG-context] Generic fontloader and flush_components
Hi, in font-ots.lua (which becomes part of the generic fontloader) nuts.flush_components is used, while it seems to be defined for mkiv and generic in node-gcm.lua, but this file is not included in the packaged generic fontloader. Therefore the current luatex-fonts-merged.lua breaks with "trying to call a nil value (upvalue flush_components)". Could you please add a definition for nuts.flush_components in the generic version? Thanks, Marcel ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
[NTG-context] LuaMetaTex dereferences NULL pointer
Hi,
with the latest LuaMetaTeX upload (running on Linux x64),
\normalunexpanded tries to write to address 0 and therefore
segfaults:
\normalunexpanded{abc}
\starttext
\stoptext
ConTeXt fails with
mtx-context | fatal error: return code: 139
The most interesting message from valgrind is
==53200== Invalid write of size 4
==53200==at 0x17113D: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==53200==by 0x151625: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==53200==by 0x151E40: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==53200==by 0x15E1A2: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==53200==by 0x154AA1: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==53200==by 0x122347: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==53200==by 0x4A0C151: (below main) (in /usr/lib/libc-2.32.so)
==53200== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==53200==
==53200==
==53200== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==53200== Access not within mapped region at address 0x0
==53200==at 0x17113D: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==53200==by 0x151625: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==53200==by 0x151E40: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==53200==by 0x15E1A2: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==53200==by 0x154AA1: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==53200==by 0x122347: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==53200==by 0x4A0C151: (below main) (in /usr/lib/libc-2.32.so)
==53200== If you believe this happened as a result of a stack
==53200== overflow in your program's main thread (unlikely but
==53200== possible), you can try to increase the size of the
==53200== main thread stack using the --main-stacksize= flag.
==53200== The main thread stack size used in this run was 8388608.
Best regards,
Marcel
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
[NTG-context] CFF2 based variable fonts with SubRS
Hi,
I was playing with the variable font support of ConTeXt's font loader
and noticed some issues.
1. While parsing the LocalSubRS and GlobalSubRS Indices, ConTeXt tries
to use 16bit count fields as in CFF(1) instead of 32bit fields as in
CFF2, reducing the number of found subroutines by a factor of 65536.
Effectivly this suppressed all subroutines in the fonts I tested.
2. For fonts where the Top DICT does not contain an FDSelect entry,
ConTeXt tries to read the Private dictionary offset from the Top
dictionary as in name-keyed CFF1 fonts. This is not the expected
behavior for CFF2, where the Top dictionary never contains the Privte
offset.
Instead, a missing FDSelect means that exactly one entry exists in
FDArray which should be used for all CIDs. This caused problems
when ConTeXt tried to find the Private directory in order to find
local subroutines.
A test font demonstrating both issues is "SourceCode Variable"
https://github.com/adobe-fonts/source-code-pro/releases:
The document
\definefontfeature
[light]
[default]
[axis={weight=200}]
\definefont
[sourcelight]
[file:SourceCodeVariable-Roman.otf*light]
\starttext
\sourcelight Hallo
\stoptext
generates
[...]
otf reader > cff > unknown local call 14, case 2 : [] n=0
otf reader > cff > unknown local call 11, case 2 : [] n=0
otf reader > cff > unknown local call 138, case 2 : [] n=0
otf reader > cff > unknown local call 314, case 2 : [300 -12] n=2
otf reader > cff > unknown local call 607, case 2 : [-99 -66 99 174]
n=4
otf reader > fatal error in file 'SourceCodeVariable-Roman.otf':
...e0dde776fb1556f32e/formats/luametatex/font-cff-macro.lua:1517: attempt to
perform arithmetic on a nil value (local 'v')
stack traceback:
...e0dde776fb1556f32e/formats/luametatex/font-otr-macro.lua:2339: in
metamethod 'add'
...e0dde776fb1556f32e/formats/luametatex/font-cff-macro.lua:1517: in
local 'a'
...e0dde776fb1556f32e/formats/luametatex/font-cff-macro.lua:1980: in
upvalue 'process'
[...]
A possible fix for both issues would be
diff --git a/tex/context/base/mkiv/font-cff.lua
b/tex/context/base/mkiv/font-cff.lua
index c2cf0e699..d00637b8e 100644
--- a/tex/context/base/mkiv/font-cff.lua
+++ b/tex/context/base/mkiv/font-cff.lua
@@ -2265,8 +2265,8 @@ do
end
-local function readglobals(f,data)
-local routines = readlengths(f)
+local function readglobals(f,data,version)
+local routines = readlengths(f,version == "cff2")
for i=1,#routines do
routines[i] = readbytetable(f,routines[i])
end
@@ -2324,14 +2324,14 @@ local function readprivates(f,data)
end
end
-local function readlocals(f,data,dictionary)
+local function readlocals(f,data,dictionary,version)
local header = data.header
local private = dictionary.private
if private then
local subroutineoffset = private.data.subroutines
if subroutineoffset ~= 0 then
setposition(f,header.offset+private.offset+subroutineoffset)
-local subroutines = readlengths(f)
+local subroutines = readlengths(f,version=="cff2")
for i=1,#subroutines do
subroutines[i] = readbytetable(f,subroutines[i])
end
@@ -2394,7 +2394,7 @@ readers.parsecharstrings = parsecharstrings -- used in
font-onr.lua (type 1)
local function readnoselect(f,fontdata,data,glyphs,doshapes,version,streams)
local dictionaries = data.dictionaries
local dictionary = dictionaries[1]
-readglobals(f,data)
+readglobals(f,data,version)
readcharstrings(f,data,version)
if version == "cff2" then
dictionary.charset = nil
@@ -2402,9 +2402,19 @@ local function
readnoselect(f,fontdata,data,glyphs,doshapes,version,streams)
readencodings(f,data)
readcharsets(f,data,dictionary)
end
+local cid = dictionary.cid
+local fdarray = cid and cid.fdarray
+if fdarray and not dictionary.private then
+setposition(f,data.header.offset+fdarray)
+local dictionaries = readlengths(f,version=="cff2")
+assert(#dictionaries == 1)
+dictionaries[1] = readstring(f,dictionaries[1])
+parsedictionaries(data,dictionaries)
+dictionary.private = dictionaries[1].private
+end
readprivates(f,data)
parseprivates(data,data.dictionaries)
-readlocals(f,data,dictionary)
+readlocals(f,data,dictionary,version)
startparsing(fontdata,data,streams)
parsecharstrings(fontdata,data,glyphs,doshapes,version,streams)
stopparsing(fontdata,data)
@@ -2416,7 +2426,7 @@ local function
readfdselect(f,fontdata,data,glyphs,doshapes,version,streams)
local dictionary = dictionaries[1]
local cid = dictionary.cid
local cidselect= cid and cid.fdselect
-readglobals(f,data)
+readglobals(f,data,version)
readcharstrings(f,data,version)
Re: [NTG-context] set_lua freezes control sequences
On Tue, Aug 25, 2020 at 04:48:27PM +0200, Hans Hagen wrote: > > I noticed that recent LuaMetaTeX versions treats control sequences > > defined using token.set_lua with `value` or `condition` as frozen and > > does not allow redefining them. Given that these are not macros, we also > > can't "unfreeze" them using \unletfrozen. > > > > 1. Would it be possible to add a variant of Lua value and condition > > control sequences that are not frozen? > > > > 2. Also is there some way to disable the \frozen restrictions > > altogether? Maybe \suppressfrozenerror? > > > > 3. I also noticed that `token.set_lua` is not affected by control > > sequences being frozen. Therefore it allows redefining frozen > > control sequences which seems inconsistent. > It's all on purpose. Btw, these mechanisms are very experimental (and > undocumented and might to evolve). I know, but they are fun to play with. Especially the `value` kind was one of the most important things I always missed in LuaTeX. Marcel ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
[NTG-context] set_lua freezes control sequences
Hi, I noticed that recent LuaMetaTeX versions treats control sequences defined using token.set_lua with `value` or `condition` as frozen and does not allow redefining them. Given that these are not macros, we also can't "unfreeze" them using \unletfrozen. 1. Would it be possible to add a variant of Lua value and condition control sequences that are not frozen? 2. Also is there some way to disable the \frozen restrictions altogether? Maybe \suppressfrozenerror? 3. I also noticed that `token.set_lua` is not affected by control sequences being frozen. Therefore it allows redefining frozen control sequences which seems inconsistent. Best regards, Marcel ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] \scantokens in luametatex
Thank you for fixing this!
On Thu, Aug 13, 2020 at 02:31:51PM +0200, Marcel Fabian Krüger wrote:
> Hi,
>
> in the current luametatex upload, \scantokens (and also \scantextokens)
> behave odd: They seem to act like \detokenize, except that spaces get
> catcode other instead of catcode space:
>
> \starttext
> \edef\abc{\scantokens{\relax}}
> \abc
> \edef\abc{\scantextokens{\relax}}
> \abc
> \stoptext
>
> used to result in an empty output file but with luametatex, it writes \relax
> \relax to the output.
>
> \starttext
> \def\showsecond#1{\show}
> \edef\abc{\scantokens{a b}}
> \expandafter\showsecond\abc
> \edef\abc{\detokenize{a b}}
> \expandafter\showsecond\abc
> \stoptext
>
> prints
>
> > the character
> > blank space
>
> Best regard,
> Marcel Krüger
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
[NTG-context] \scantokens in luametatex
Hi,
in the current luametatex upload, \scantokens (and also \scantextokens)
behave odd: They seem to act like \detokenize, except that spaces get
catcode other instead of catcode space:
\starttext
\edef\abc{\scantokens{\relax}}
\abc
\edef\abc{\scantextokens{\relax}}
\abc
\stoptext
used to result in an empty output file but with luametatex, it writes \relax
\relax to the output.
\starttext
\def\showsecond#1{\show}
\edef\abc{\scantokens{a b}}
\expandafter\showsecond\abc
\edef\abc{\detokenize{a b}}
\expandafter\showsecond\abc
\stoptext
prints
> the character
> blank space
Best regard,
Marcel Krüger
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
[NTG-context] \fontdimen in LuaMetaTeX
Hi,
recent LuaMetaTeX versions no longer automatically resize the fontdimen
arrays on assignments.
Is there a way to manually resize them or is it necessary to reload a
patched font you want more fontdimens?
Also, there is an issue with the error message (I guess) for font.setfontdimen:
\starttext
\directlua{font.setfontdimen(0, 8, 0)}
\stoptext
gives
token call, execute: invalid option '%i' to 'lua_pushfstring'
stack traceback:
[C]: in function 'font.setfontdimen'
[ctxlua]:1: in main chunk
1 \starttext
2 >> \directlua{font.setfontdimen(0, 8, 0)}
3 \stoptext
4
Best regards,
Marcel
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
[NTG-context] handle_error_hook in LuaMetaTeX
Hi,
thanks for handling
f file consition in LuaMetaTeX. While playing with that, I encountered a
potential bug in the latest LuaMetaTeX version: If handle_error_hook is
executed and returns any number, LuaMetaTeX segfaults. (I'm pretty sure
that this still worked with the previous version) Minimal ConTeXt
example:
\enabledirectives[system.quitonerror=false]
\directlua{
print(callbacks.register('handle_error_hook', function(...)
return 3
end))
}
\undefined % Trigger an error
\starttext
\stoptext
This triggers
[...]
system > ConTeXt ver: 2020.07.31 10:20 LMTX fmt: 2020.7.31 int:
english/english
[...]
tex error > tex error on line 7 in file ./test_empty_input.tex: !
Undefined control sequence
l.7 \undefined
[...]
9 \stoptext
segmentation fault (core dumped)
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatexcont-yes.mkiv
valgrind suggests that this is caused by an attempt to access a null
pointer:
==382632== Invalid write of size 4
==382632==at 0x1A581F: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==382632==by 0x1A662F: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==382632==by 0x14BAA8: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==382632==by 0x1DA50E: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==382632==by 0x1DA802: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==382632==by 0x15F956: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==382632==by 0x156E2E: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==382632==by 0x121E97: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==382632==by 0x4A16001: (below main) (in /usr/lib/libc-2.31.so)
==382632== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==382632==
==382632==
==382632== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==382632== Access not within mapped region at address 0x0
==382632==at 0x1A581F: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==382632==by 0x1A662F: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==382632==by 0x14BAA8: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==382632==by 0x1DA50E: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==382632==by 0x1DA802: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==382632==by 0x15F956: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==382632==by 0x156E2E: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==382632==by 0x121E97: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==382632==by 0x4A16001: (below main) (in /usr/lib/libc-2.31.so)
That me know if you are interested in the coredump.
Best regards,
Marcel
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Lua related change in LuaMetaTeX?
On Wed, Jul 29, 2020 at 09:37:13PM -0700, Hans Hagen wrote:
> > One other question about LuaMetaTeX 2.7.1: I noticed that the
> > terminal_input callback is gone. Does this mean that the current
> > behaviour of basically freezing when previously terminal input was
> > requested is hardcoded or is some other callback invoked which can then
> > provide some tokens?
> >
> > Marcel
>
> first line on console was already gone (only the filename gets pushed into
> the input because tex forces an input
I think this is a misunderstanding. I wasn't referring to the first
line, but to lines after the main input is fully evaluated. E.g. as a
ConTeXt example
\starttext
\def\dosomethinguseful#1{Do something useful with #1}
\dosomethinguseful{
Ups, I "forgot" to close this brace
\stoptext
This used to end up asking for terminal input. Especially since the
terminal_input callback was available, it was possible to detect such
situations and trigger an error. With the current ConTeXt code, I
couldn't find a nice solution for this and when running such documents,
the interpreter basically freezes, starts consuming memory and finally
gets killed by the out of memory handler. Experients with
token.scan_next suggest that instead of asking for input, TeX keeps
seeing a special relax-like token. I was hoping that there is some
callback which can be used to intercept this and either fail gracefully
with an error message or to provide more useful tokens.
>
> anyway, read/write channel zero are for the terminal
>
That's good to know, thank you.
Marcel
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Lua related change in LuaMetaTeX?
> there have been a couple of bug fixes after the formal 5.4.0 release but > afaik not in the virtual machine code (which normally is the most sensitive); > i used to mark low level changes so that it got signaled (in context) but the > byte code version info changed late in 5.4 dev so i no longer do that now > > although i occasionally have run into buglets in 5.4 code - which to me is > quite natural as it concerns dev / exp versions so one gets what one > downloads, i.e. one can only blame oneself for using such versions and hardly > complain - lua is quite stable and reliable (given the massive amount of lua > code that we use in context) ... so, normally patience - read: wait for > updates - is the answer Oh I see, I wasn't aware that the dev versions are used. After recompiling with the latest development code the error is gone. One other question about LuaMetaTeX 2.7.1: I noticed that the terminal_input callback is gone. Does this mean that the current behaviour of basically freezing when previously terminal input was requested is hardcoded or is some other callback invoked which can then provide some tokens? Marcel ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
[NTG-context] Lua related change in LuaMetaTeX?
Hi, starting with LuaMetaTeX 2.07.01, a C library I load from Lua started to segfault and valgrind indicates that it accesses invalid memory in multiple places in the middle of Lua internal functions?! The whole thing looks almost like the Lua versions in LuaMetaTeX and in the library are incompatible, but both seem to use 5.4.0. So I asked myself if there might be changes not reflected by the version number. tl;dr: Has the embedded Lua interpreter changed in some non ABI-compatible way in LuaMetaTeX 2.07.01? (Especially on Linux, x86-64. I didn't test other platforms yet) Best regards, Marcel ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] Multiple cases of unexpected behaviour in luametatex
On Fri, Jul 03, 2020 at 09:56:28PM +0200, Hans Hagen wrote:
> On 7/3/2020 2:55 PM, Marcel Fabian Krüger wrote:
> > Hi,
> >
> > I recently noticed some cases where luametatex behaved in unexpected
> > ways:
> >
> >- The "Extra \fi" error isn't triggered, instead an extra `\fi`
> > freezes luametatex. (Can be reproduced by compiling a document which
> > only consists of a single \fi)
>
> i already fixed here (noticed it when documenting some conditionals)
Great.
>
> >- token.new can only create some `data` tokens, but it doesn't apply
> > bound checking on it's arguments:
>
> there is no checking yet, there is an upper limit of 0x1F, so i'll add a
> check for that
OK, that explains it.
[...]
>
> eventually i want all to have reasonable ranges in the token interface (not
> per se the same as in the engine itself but that's a black box anyway) which
> involves some offsetting .. i do that stepwise in order to keep a working
> engine (the token interface is not used in context that much)
Please let me know if there is anything I can do to help with that.
Anyway, tehre is another thing I am wondering about: In the latest
luametatex versions, error help strings do not seem to work like they used to.
Especially after \errhelp{some help}\errmessage{error} or
tex.error('fdfd', {'some help'}) in the 'handle_error_hook'
callback, tex.gethelptext returns nil. gethelptext still works for
errors triggered by TeX itself.
One completely different question:
When running luametatex (of course with appropriate format/lua init
script options) but without a TeX file or command, luametatex does not
expect interactive input but instead tries to read the input file
'luametatex.tex'. (Where luametatex does not seem to be hardcoded but
derived from argv[0]) Is there a way to overwrite this default input
file name?
Marcel
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
[NTG-context] Multiple cases of unexpected behaviour in luametatex
Hi,
I recently noticed some cases where luametatex behaved in unexpected
ways:
- The "Extra \fi" error isn't triggered, instead an extra `\fi`
freezes luametatex. (Can be reproduced by compiling a document which
only consists of a single \fi)
- token.new can only create some `data` tokens, but it doesn't apply
bound checking on it's arguments:
Take
```
\directlua{
t = token.new(0x20, token.command_id'data')
print(t.cmdname, t.command, t.mode)
}
```
which prints
register102 0
The issue does not seem to be that such tokens do not exists because
\letdatacode\somedata="20
\directlua{
local t = token.create'somedata'
print(t.cmdname, t.command, t.index)
}
does print
data101 2097152
Also for all other commands LuaTeX seems to apply range-checks to
ensure that such overflows don't happen, even if invalid values are
passed as firstargument.
- There is token.primitives(). My assumption is that the returned
table is meant to indicate the command is, mode and name
corresponding to every primitive. (I think it is awesome that such a
table is made available in luametatex) But especially the mode
field sometimes has values which do not correspond to the mode of
the actual primitives:
I tried running the following in an almost iniTeX setting where all
primitives aside from \shipout and \Umathcodenum have their default
definitions:
```
\catcode`\%=12
\catcode`\~=12
\directlua{
local sorted = token.primitives()
table.sort(sorted, function(a,b) return a[1]http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Yet another cornercase of ^^ handling in LuaMetaTeX
On Wed, Jun 17, 2020 at 03:43:49PM +0200, Hans Hagen wrote:
> On 6/17/2020 12:10 PM, Marcel Fabian Krüger wrote:
> > On Mon, Jun 15, 2020 at 04:16:06PM +0200, Hans Hagen wrote:
> > >
> > > ah, i removed some doee that i though was never seen; i'll add that bit
> > > again
> > >
> > > > Beside that, I noticed a smaller weird thing when using LuaMetaTeX in
> > > > ini
> > > > mode without Context: The default mathcodes for digits and letters have
> > > > their class and family values switched. So e.g. "A" has a default
> > > > mathcode of 119537729=0x7200041, indicating class 1 and family 7,
> > > > instead of the expected 31457345=0x1E00041, indicating class 7 and
> > > > family 1. Of course this isn't really a problem because the format will
> > > > normally assign new mathcodes anyway, but especially class 1 seems like
> > > > a *very* unnatural default for normal letters.
> > > i'll check it (digits get class 0) ... indeed these defaults nowadays
> > > never
> > > kick in this way
> >
> > Thanks. Is there any way to convert either a token number (as given e.g.
> > by t.tok) or a numeric cs identifier (as given e.g. by t.tok-cs_token_flag)
> > to a token uservalue?
> > In LuaTeX I used to use `token.new(tok, 0)` for this, but LuaMetaTeX
> > seems to do more checking here.
>
> Indeed there is more checking. So, when you create a token you need to use a
> valid cmd code and a valid chr code.
>
> \ctxlua{
> local t = token.new(string.byte("X"),token.command_id("letter"))
> tex.print(t)
> }
>
> The interface might evolve a bit more. Valid commands (at this moment) are:
>
> \ctxlua{
> for k, v in ipairs(token.values("command")) do
> print(k,v)
> end
> }
>
> So, things like this should work
>
> \dimen3456=1234pt
>
> \dimen3467=
> \ctxlua{
> local t = token.new(3456,token.command_id("register_dimen"))
> % local t = token.new("register_dimen",3456) % in upcoming version
> tex.sprint(t)
> }
>
> \the\dimen3467
>
> As does:
>
> \ctxlua{
> local t1 = token.new(string.byte("{"),token.command_id("letter"))
> local t2 = token.new(string.byte("}"),token.command_id("letter"))
> tex.print(t1)
> tex.print(t2)
> }
>
> Properties like cs_token_flag are not user level and have no meaning in the
> interface. In fact, the 'token-as-number' is just some representation with
> no intended meaning. Also, tokens that are problematic or can interfere
> badly might become inaccessible in future versions.
>
> (I don't expect many users to use the low level token interface anyway but
> it's there as part of the package.)
>
> Hans
>
How does this work with mark nodes? Their mark field has a table
containing triples of command, character and "cs" value. How can the
actual csname of a controlsequence be extracted from this in LuaMetaTeX?
Marcel
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
[NTG-context] \the\font in luametatex
Hi, in the latest luametatex version, \the\font does ... something weird: E.g. with a current, fully updated lmtx, I get for \starttext \showthe\font \stoptext the output > }\ifempty \currentstyleparameter \else \dousecurrentstyleparameter \fi instead of the expected > \3>modern-designsize-12pt-rm-tf-0--0 (or similar) (given that this contains an unmatched `}`, it causes havoc if \the\font is used in unsuspecting macro code.) Best regards, Marcel ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] Changed behavior of ^^ in csname
Hi, thank you for fixing this in the latest version. I found another problem with ^^, this time when followed by hexadecimal digits: \starttext \normalsupmarkmode\zerocount \catcode\circumflexasciicode=\superscriptcatcode% Ensure correct catcodes \let\ß\relax \show\ß % Shows "> \ß=\relax", no surprise here \show\^^df % Should be the same, but actually shows "> \� %=undefined" \show ß % Shows "> the letter ß" \show ^^df % Should be the same, but actually shows "> the character " % and "luatex warning > print: bad string offset" \showthe\numexpr`\ß % Shows "> 223" \showthe\numexpr`\^^df % Gives an error "! Improper alphabetic constant" \stoptext Best regards, Marcel ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] Changed behavior of ^^ in csname
On Thu, Jun 11, 2020 at 07:51:56PM +0200, Hans Hagen wrote:
> On 6/11/2020 12:24 PM, Marcel Fabian Krüger wrote:
>
> > shows exactly the same behavior.
> Looks like i don't catch the case where a cs is constructed, so i'll add
> some checking there too (it is tempting to remove all that ^^ stuff).
Thanks. I think "the ^^ stuff" is actually quite useful, especially when
debugging international documents. Especially when the glyphs come from
a language you are not used to, it is quite nice to just have a hex
representation without needing pecial editors and ^^ is the only way to get
that without introducing actual changes to behavior.
I had another issue with the latest luametatex:
The following document:
\starttext
\def\mymacro#1 bc{}
{\mymacro a b bc}
\stoptext
used to work and lead to no output. But in the new luametatex version,
it complains about "! Argument of \mymacro has an extra }" as if it
doesn't see the " bc" argument delimiter.
Marcel
>
> Hans
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] Changed behavior of ^^ in csname
On Thu, Jun 11, 2020 at 10:07:34AM +0200, Hans Hagen wrote:
> On 6/11/2020 4:06 AM, Marcel Fabian Krüger wrote:
> > Hi,
> >
> > I noticed that in the latest LMTX version, ^^ (with ^ of catcode 7)
> > is no longer interpreted inside csnames. Is this intentional?
> >
> > (Example:
> >
> > \starttext
> > \catcode\circumflexasciicode=\superscriptcatcode% Ensure correct catcodes
> >
> > \show ^^41 % This still works and shows "> the letter A"
> >
> > \show^^41 % This used to be an error "Undefined control sequence \showA",
> >% now show "> The letter A"
> >
> > \show\^^41 % Used to show "> \A=undefined", now shows ">
> > \^=macro:->\enco_handle_accent {^}"
> > % and "! Missing $ inserted"
> > \stoptext
> >
> > )
> Indeed that is intentional because in lmtx we disable them (partially). You
> have to say:
>
> \normalsupmarkmode\zerocount % we use 1 as default in lmtx
Hi,
shouldn't \supmarkmode=1 only disable these in math mode?
In any case, \normalsupmarkmode\zerocount doesn't make a difference
here:
\starttext
\normalsupmarkmode\zerocount
\catcode\circumflexasciicode=\superscriptcatcode% Ensure correct catcodes
\show ^^41 % This still works and shows "> the letter A"
\show^^41 % This used to be an error "Undefined control sequence \showA",
% now show "> The letter A"
\show\^^41 % Used to show "> \A=undefined", now shows ">
\^=macro:->\enco_handle_accent {^}"
% and "! Missing $ inserted"
\stoptext
shows exactly the same behavior.
Best regards,
Marcel
>
> This is because in lmtx we have native prescript support, as in:
>
> $ x^{rt}_{rb}^^{lt}__{lb} $
>
> so, double _ ^ can have a different meaning there.
>
> 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 / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
[NTG-context] Changed behavior of ^^ in csname
Hi,
I noticed that in the latest LMTX version, ^^ (with ^ of catcode 7)
is no longer interpreted inside csnames. Is this intentional?
(Example:
\starttext
\catcode\circumflexasciicode=\superscriptcatcode% Ensure correct catcodes
\show ^^41 % This still works and shows "> the letter A"
\show^^41 % This used to be an error "Undefined control sequence \showA",
% now show "> The letter A"
\show\^^41 % Used to show "> \A=undefined", now shows ">
\^=macro:->\enco_handle_accent {^}"
% and "! Missing $ inserted"
\stoptext
)
Best regards,
Marcel
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
[NTG-context] \Umathcodenum and get...dir in lmtx
Hi,
I had two issues with luametatex:
The manual documents getters and setters for the directions:
The direction states can be queried and set with:
tex.gettextdir() tex.getpardir() tex.setmathdir()
tex.getlinedir() tex.settextdir() tex.setpardir()
tex.getmathdir() tex.setlinedir()
While there is no problem with the set...dir commands, the get...dir
commands don't actually exists. (They can be implemented using tex.get,
but it would be nice if either they were added to luametatex or if they
were removed from te documentation to avoid confusion.)
Additionally the scanning variant of \Umathcodenum seems broken:
Take the example document
\starttext
\directlua{
print('gettextdir:', tex.gettextdir)
}
\the\Umathcodenum`a
\stoptext
It works in ConTeXt mkiv, but in lmtx it shown a (non-informative) error:
gettextdir: nil
tex error > tex error on line 5 in file ./contfail.tex: ! This can't
happen (scan char)
l.5 \the\Umathcodenum`a
1 \starttext
2 \directlua{
3 print('gettextdir:', tex.gettextdir)
4 }
5 >> \the\Umathcodenum`a
6 \stoptext
7
I'm broken. Please show this to someone who can fix me.
mtx-context | fatal error: return code: 256
(\Umathcodenum`a=123 seems to work though)
Also especially these "This can't happen" errors a a it of pain debug
without having the option to look into the source which I can't find
anywhere. Has that been released? Is it still planned to make it
available at some point?
Best regards,
Marcel Krüger
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] \read segfaults in lmtx
On Wed, May 20, 2020 at 12:13:01PM +0200, Hans Hagen wrote:
> On 5/20/2020 2:39 AM, Marcel Fabian Krüger wrote:
> > Hi,
> >
> > using \read on any existing file seems to trigger a
> > segfault on lmtx. For example, take the document
> >
> > \starttext
> > \newread\myread
> > \openinputfile\myread{test}
> > \read\myread to \abc
> > \closeinputfile\myread
> > \stoptext
> >
> > where test.tex is any file (It doesn't matter if the file is empty or
> > not). On my system (linux x64, latest lmtx) this results in
> >
> > mtx-context | fatal error: return code: 139
>
> hm, looks like i close the file too soon (these read files are autoclosed on
> read) .. i'll fix it
Which file is closed here? Experiments with a custom format suggest that the
read
files are opened through the `open_data_file` callback, so even if they
are closed they probably should be closed by calling the `.close` member
of the returned table. But that never happens (This might be a related
bug: In my experiments, even for files loaded with `\input`, the close
function is never called.) and the issue seems to occur even if there is
no real file opened for this. So I don't see why LuaMetaTeX should call
fclose here at all. But anyway, thanks for looking into this.
Marcel
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
[NTG-context] \read segfaults in lmtx
Hi,
using \read on any existing file seems to trigger a
segfault on lmtx. For example, take the document
\starttext
\newread\myread
\openinputfile\myread{test}
\read\myread to \abc
\closeinputfile\myread
\stoptext
where test.tex is any file (It doesn't matter if the file is empty or
not). On my system (linux x64, latest lmtx) this results in
mtx-context | fatal error: return code: 139
Running the command after "executing runner 'run luametatex format':"
directly gives
segmentation fault (core dumped)
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatexcont-yes.mkiv
Tracing this command using valgrind shows
==51536== Conditional jump or move depends on uninitialised value(s)
==51536==at 0x1789A6: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x14D074: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x199599: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x15B03B: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x15838C: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x154A39: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x12090D: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x4A12001: (below main) (in /usr/lib/libc-2.31.so)
==51536==
==51536== Use of uninitialised value of size 8
==51536==at 0x4A6003B: fclose@@GLIBC_2.2.5 (in /usr/lib/libc-2.31.so)
==51536==by 0x14D074: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x199599: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x15B03B: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x15838C: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x154A39: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x12090D: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x4A12001: (below main) (in /usr/lib/libc-2.31.so)
==51536==
==51536== Invalid read of size 4
==51536==at 0x4A6003B: fclose@@GLIBC_2.2.5 (in /usr/lib/libc-2.31.so)
==51536==by 0x14D074: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x199599: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x15B03B: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x15838C: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x154A39: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x12090D: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x4A12001: (below main) (in /usr/lib/libc-2.31.so)
==51536== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==51536==
==51536==
==51536== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==51536== Access not within mapped region at address 0x0
==51536==at 0x4A6003B: fclose@@GLIBC_2.2.5 (in /usr/lib/libc-2.31.so)
==51536==by 0x14D074: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x199599: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x15B03B: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x15838C: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x154A39: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x12090D: ??? (in
/home/marcel/lmtx-install/tex/texmf-linux-64/bin/luametatex)
==51536==by 0x4A12001: (below main) (in /usr/lib/libc-2.31.so)
==51536== If you believe this happened as a result of a stack
==51536== overflow in your program's main thread (unlikely but
==51536== possible), you can try to increase the size of the
==51536== main thread stack using the --main-stacksize= flag.
==51536== The main thread stack size used in this run was 8388608.
==51536==
==51536== HEAP SUMMARY:
==51536== in use at exit: 85,957,820 bytes in 639,104 blocks
==51536== total heap usage: 971,974 allocs, 332,870 frees, 174,449,076 bytes
allocated
==51536==
==51536== LEAK SUMMARY:
==51536==definitely lost: 4,552 bytes in 236 blocks
==51536==indirectly lost: 0 bytes in 0 blocks
==51536== possibly lost: 50,271,367 bytes in 532,242 blocks
==51536==still reachable: 35,681,901 bytes in 106,626 blocks
==51536== suppressed: 0 bytes in 0 blocks
==51536== Rerun with --leak-check=full to see details of leaked memory
==51536==
==51536== Use --track-origins=yes to see where uninitialised values come from
==51536== For lists of detected and suppressed errors, rerun with: -s
Re: [NTG-context] \glueexpr in lmtx
On Tue, Jul 23, 2019 at 12:54:45AM +0200, Hans Hagen wrote: > On 7/23/2019 1:16 AM, Marcel Fabian Krüger wrote: > > Hi, > > > > I stumbled upon some odd behaviour of \glueexpr in lmtx. Take the > > following document: > > > > \starttext > > \the\glueexpr 0.0pt \relax > > \newskip\myskip > > \myskip=\glueexpr 0.0pt \relax > > \stoptext > > > > Without lmtx this works fine. Under lmtx, the *first* use of > > `\glueexpr`, after `\the`, works fine too. On the other hand, the other > > `\glueexpr`, after `\myskip=`, complains about a "Illegal unit of > > measure (pt inserted)". It does not seem to accept the fractional part, > > everything works again if I use > > > > \starttext > > \the\glueexpr 0.0pt \relax > > \newskip\myskip > > \myskip=\glueexpr 0pt \relax > > \stoptext > > > > Am I missing something here or is this a bug? > fixed in next lmtx beta (was a wrong symbolic constant someplace) > > (context never uses gluexpr so it went unnoticed) Thank you. --Marcel ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
[NTG-context] \glueexpr in lmtx
Hi, I stumbled upon some odd behaviour of \glueexpr in lmtx. Take the following document: \starttext \the\glueexpr 0.0pt \relax \newskip\myskip \myskip=\glueexpr 0.0pt \relax \stoptext Without lmtx this works fine. Under lmtx, the *first* use of `\glueexpr`, after `\the`, works fine too. On the other hand, the other `\glueexpr`, after `\myskip=`, complains about a "Illegal unit of measure (pt inserted)". It does not seem to accept the fractional part, everything works again if I use \starttext \the\glueexpr 0.0pt \relax \newskip\myskip \myskip=\glueexpr 0pt \relax \stoptext Am I missing something here or is this a bug? Best regards, Marcel Krueger ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
[NTG-context] crappy names in the fontloader
Hi everyone, under default settings, the fontloaders discards all glyph names which are considered "crappy", meaning matching the "p_crappyname" pattern in "font-oup.lua". For some names this makes a lot of sense. For example the name "uni0303" is considered "crappy" and it really provides no useful information. Then there are other names like "t_uni0303" which are still considered "crappy" while they actually aren't completely useless. So I think there would be some value in preserving them. Of course, you can always enable "otf.keepnames" if you need names like this. But I actually want to talk about another class of names: Look at "Udotbelow". This is IMHO a perfectly normal and useful name, but the fontloader still considers it "crappy" because it starts with a "U" followed by a letter which could be a hexadecimal number. I think this is a bit over-agressive. Maybe the "p_crappyname" pattern could be changed to only look for "u" if followed by "p_done", marking the end of a component? Best regards, Marcel Krüger ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
