[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 ___
