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
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.
>
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]
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
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=
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
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}]
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
> >
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
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
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
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
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
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 o
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
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:
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)
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
> 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
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
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&q
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`
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
> &
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
>
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
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
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 int
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"
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()
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
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
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
> > \
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
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
34 matches
Mail list logo
