mathsize font feature doesn't work

[olsak]

The functionality of mathsize font feature is lost In the recent version of luaotfload. Suppose the example here: olsak/OpTeX#67 (comment)
The example-image (its second part at the right side) shows that the script size and scriptscript size are smaller. The optional sizes are read from the font data. But this is not true in the new version of luaotfload: all three sizes are equal.

This is critical bug because OpTeX Unicode math macros are based on the mathsize font feature.

[zauguin]

Fixed in dev, but we might want to consider additionally rewriting the font name if this is used to make these fonts more usable. Currently they are rather odd.

[olsak]

The OpTeX is broken now, when new luaotfload version was released, which is very bad. We can ask if you are doing some tests with OpTeX before new release. I don't see when you are preparing a new version. So, I am unable to do these tests in the right time.

The correction in dev branch is the first step, but we need to release a critical bug correction as soon as it is possible.

[u-fischer]

I don't see when you are preparing a new version

You can watch the repo and run your tests when they are commits in the dev branch. luaotfload can be easily installed with l3build.

[olsak]

I have no time for continuously "watch the repo". This is full time job. More friendly seems to add some OpTeX tests to your tests which you run before release.

[josephwright]

@olsak Writing tests is usually the barrier, not running then: some suggestions would be useful - as non of the team looking after luaotfload are familiar with specifics for OpTeX. (I might have to check on l3build and OpTeX: that should I think work but is not currently checked.)

[u-fischer]

@olsak

I have no time for continuously "watch the repo".

You can setup some github action to automate the watching.

This is full time job. More friendly seems to add some OpTeX tests to your tests which you run before release.

I don't have the time nor the skill to write OpTeX tests, and I have neither the time nor the skill to debug them if they fail as I don't know anything about OpTeX.

[zauguin]

Do you have some repository where we can trigger a pipeline whenever we push something? Then you can manage some relevant tests there and they automatically run whenever something changes.

[olsak]

I have repositories at github, of course. But I don't know what does mean "we can trigger a pipeline".

Sorry, my OpTeX tests are only imperfectly. My script runs OpTeX over a set of normal documents and I must to see if there is a suspicious change in log files. In this case, some math text causes Overful/Underful boxes while not before.

In this case, I get the bug report from many OpTeX users first, when I returned from my vacation. :(

The question is: how long we must to wait to the new release of luaotfload package where this critical bug will be corrected.

Now, I added a red text to main web page http://petr.olsak.net/optex/ and additional information about it. Unfortunately, I can't do more.

[olsak]

trigger a pipeline

Maybe, it would be enough to contact me if you decides a core design change. I suppose that somebody from you decided that "mathsize" font feature will be cancelled from luaotfload. If I knew about such decision sufficiently in advance, I can say: no, OpTeX is based on this feature.

[u-fischer]

Maybe, it would be enough to contact me if you decides a core design change. I suppose that somebody from you decided that "mathsize" font feature will be cancelled from luaotfload.

No, we didn't decide a core design change. We imported a new fontloader version from context and that has this part commented (in fontloader-font-otl.lua) and we didn't overwrite it.

If I knew about such decision sufficiently in advance, I can say: no, OpTeX is based on this feature.

As I already wrote: I have neither the time nor the skill to decide if such a change affects OpTeX or not. So if you want warnings, implement suitable tests and watch the repository. Or use your own independent fontloader.

[olsak]

We imported a new fontloader version from context and that has this part commented (in fontloader-font-otl.lua) and we didn't overwrite it.

OK. I understand that this was work of Hans Hagen. But where is the time for testing luaotfload? I see that the commit of the file fontloader-font-otl.lua was done two weeks ago at dev branch and the luaotfload was released two weeks ago too. Coincidentally I was at my vacation (off-line, of course) at this time...

[zauguin]

how long we must to wait to the new release of luaotfload package where this critical bug will be corrected.

I will upload a new release today, so it will probably be in TeX Live roughly tomorrow evening.

But where is the time for testing luaotfload?

Generally we rely on automated testing. Especially fontloader updates (for which we don't have any changelog beside seeing the code diff) are mostly tested though l3build.

If you write some stable, well-behaving tests which integrate into our setup I don't see any issue with adding some optex tests there.

[davidcarlisle]

@olsak I'm not directly involved here but all the tests run automatically at github on each commit, so if the new code from context is added and the tests pass then there wouldn't have been particular reason to flag this.

[zauguin]

I have repositories at github, of course. But I don't know what does mean "we can trigger a pipeline".

You can configure a GitHub repository to use GitHub Actions to automatically do something in response to a bunch of events. We use this for example to run tests whenever we push some code. We could configure our repository to automatically trigger such an event in one of your repositories whenever something changes such that you can automatically have some tests executed then.

[davidcarlisle]

We could have a test directory for optex with a build.lua something like

module = "optex"

checkengines = {"luatex"}
stdengine = "luatex"

checkformat = "optex"
specialformats =  { }
specialformats.optex =  { }
specialformats.optex.luatex = 
  {format = "optex"}
supportdir = "."

Then a test file

t1.lvt

like (copied from optex manual)

\input{regression-test}
\START

\OMIT
% avoid cache full path appearing in tlg
\fontfam[Termes] % selecting Unicode font family Termes (section 1.3.1)
\TIMO
\typosize[11/13] % setting default font size and baselineskip (sec. 1.3.2)
\margins/1 a4 (1,1,1,1)in % setting A4 paper, 1 in margins (section 1.2.1)
\cslang
% Czech hyphenation patterns (section 1.7.1)
\setbox0\vbox{Tady je zkušební textík v českém jazyce.}
\showbox0
\bye

and a normalised log t1.tlg (as made by l3build save t1

This is a generated file for the l3build validation system.
Don't change this file in any respect.
Loading hyphenation for Czech: \language=7 (cs)
(../hyph-cs.tex)
> \box...=
\vbox(7.513+2.398)x452.9679, direction TLT
.\hbox(7.513+2.398)x452.9679, glue set 254.07486fil, direction TLT
..\localpar
...\localinterlinepenalty=0
...\localbrokenpenalty=0
...\localleftbox=null
...\localrightbox=null
..\hbox(0.0+0.0)x20.0, direction TLT
..\_tenrm T
..\kern-0.825 (font)
..\_tenrm a
..\_tenrm d
..\_tenrm y
..\glue(\spaceskip) 2.75 plus 1.375 minus 0.91667
..\_tenrm j
..\_tenrm e
..\glue(\spaceskip) 2.75 plus 1.375 minus 0.91667
..\_tenrm z
..\_tenrm k
..\kern0.165 (font)
..\_tenrm u
..\discretionary (penalty 50)
...< \_tenrm -
..\_tenrm š
..\_tenrm e
..\_tenrm b
..\_tenrm n
..\_tenrm ^^ed
..\glue(\spaceskip) 2.75 plus 1.375 minus 0.91667
..\_tenrm t
..\_tenrm e
..\kern-0.385 (font)
..\_tenrm x
..\discretionary (penalty 50)
...< \_tenrm -
..\_tenrm t
..\_tenrm ^^ed
..\_tenrm k
..\glue(\spaceskip) 2.75 plus 1.375 minus 0.91667
..\_tenrm v
..\glue(\spaceskip) 2.75 plus 1.375 minus 0.91667
..\_tenrm č
..\_tenrm e
..\_tenrm s
..\discretionary (penalty 50)
...< \_tenrm -
..\_tenrm k
..\kern-0.22 (font)
..\_tenrm ^^e9
..\_tenrm m
..\glue(\spaceskip) 2.75 plus 1.375 minus 0.91667
..\_tenrm j
..\_tenrm a
..\discretionary (penalty 50)
...< \_tenrm -
..\_tenrm z
..\_tenrm y
..\kern-0.385 (font)
..\_tenrm c
..\_tenrm e
..\_tenrm .
..\penalty 10000
..\glue(\parfillskip) 0.0 plus 1.0fil
..\glue(\rightskip) 0.0
! OK.
l. ...\showbox0
)
warning  (pdf backend): no pages of output.
PDF statistics: 0 PDF objects out of 1000 (max. 8388607)
 0 named destinations out of 1000 (max. 131072)
 1 words of extra memory for PDF output out of 10000 (max. 100000000)

@olsak if there were a few optex files with tests writing anything suitable to a log file they could be run automatically and if an update produces a different log it would flag a fail (l3build normalises dates and file paths away from the log so the generated log files should be stable)

[u-fischer]

@davidcarlisle running optex tests is naturally not difficult. The problem is what should happen if they are failures. I do not want to have to investigate if a change is relevant and if yes if optex or luaotfload or something else is responsable. Imho such tests should therefore run outside of luaotfload and someone else should investigate failures and only report back to us if luaotfload is really involved.

[josephwright]

That's always an issue with any library, really: you can't possibly test all of the consumer code, you hope that the maintainers of the latter test. But of course that usually involves the case where end users don't randomly update the library behind the back of the relevant devs :)

[davidcarlisle]

@u-fischer yes although tests don't have to be on the critical path, but also as Marcel says if the tests were hosted at optex they could be triggered from here. l3build could have some tweaks for optex as it has for context, to set up some default settings and normalisations. of course the optex tests don't have to be l3build but it would simplify some things

[olsak]

Thank you very much for tips and suggestions. I need time to think about the options, then I'll get back to you.