problem loading opentype fonts with the calt feature: wrong 'backtrack' glyph order when implemented as contextual chaining substitution

[orchidee2]

Symptoms: the calt feature only works as expected, when the contextual substitution is applied to one of the first 2 glyphs of a word (phrase)
probable reason: the backtrack glyph order (glyphs before the glyph which is to be substituted) is swapped by the fontloader.
The following example was tested:
a font was modified with fontforge in a way, that it contains the following (useless) contextual substitutions (implemented as contextual chaining substitution):
cat -> fat (1st glyph substitution)
grow -> glow (2nd glyph substitution)
sell -> seal (3rd glyph substitution)
hand -> hang (4th glyph substitution)
The result for the first 2 substitutions is OK, for the last 2 no substitution was observed with enabled calt feature. But instead the following substitutions were found:
esll -> esal
nahd -> nahg
When compiling the test document with xelatex, the result is as desired.
Additionally, I observed that the the calt feature, if implemented as normal contextual substitution (not contextual chaining substitution), doesn't work at all (but this is a different story).

[phi-gamma]

···<date: 2015-12-09, Wednesday>···<from: orchidee2>···

Symptoms: the calt feature only works as expected, when the
contextual substitution is applied to one of the first 2 glyphs
of a word (phrase)

Thanks for the thorough report. Since the 2.6 release has just
been uploaded to CTAN, I’d ask you to wait a couple days for the
new version to propagate into Texlive. (Or just grab the package
from the release page.)
Then check whether the new fontloader improves the situation.

If that isn’t the case, then:

The following example was tested:
a font was modified with fontforge in a way, that it contains
the following (useless) contextual substitutions (implemented as
contextual chaining substitution):

could you make this font available for testing? Reproducibility
is key to getting anything fixed by upstream =)

Best,
Philipp

[orchidee2]

I tried with the new luaotfload package (2.6) but got an error message during compilation of the test document.
Can I upload the testfont and testdocument somewere or send you by e-mail?

[phi-gamma]

···<date: 2015-12-10, Thursday>···<from: orchidee2>···

I tried with the new luaotfload package (2.6) but got an error
message during compilation of the test document.

Wait. What error did you get? How did you install the package?

Can I upload the testfont and testdocument somewere or send you
by e-mail?

If the license allows both modification and redistribution, then
sure, just send the file by mail. Otherwise you might apply the
same modification to some free font (preferably one installable
via tlmgr) so we have a convenient specimen.

Best,
Philipp

[orchidee2]

Oh, Sorry. Probably I didn't do the installation right. I only copied the unzipped package into the local texmf tree and updated the file list (texhash). But I'm not able to load any font.

OK, I will look for a font with a license which allows modification and redistribution.

Best wishes,
Martin

[phi-gamma]

···<date: 2015-12-11, Friday>···<from: orchidee2>···

Oh, Sorry. Probably I didn't do the installation right. I only
copied the unzipped package into the local texmf tree and updated
the file list (texhash). But I'm not able to load any font.

This should work in theory with the TDS package
(luaotfload.tds.zip). But AFAIR in Texlive you’ll have to
replace the symlink for luaotfload-tool with one that points
into the local texmf (or use a different symlink, just make sure
you call the new version of the script). Also, you should install
the latest lualibs (https://github.com/lualatex/lualibs/releases/tag/2.3)
to be safe: the default fontloader itself no longer contains the
libraries.

OK, I will look for a font with a license which allows
modification and redistribution.

Thanks, I appreciate that.

[orchidee2]

The behavior of the new fontloader (luaotfload vers. 2.6-fix-2) concerning the calt feature is quite strange. In all tested cases the calt feature is completely ignored.
In cases, where the font only contains 1st and/ or second position glyph substitutions, the font is anyhow loaded and other features like ligature substitution seem to work as desired.
In cases, where the font contains also 3rd and higher position glyph substitutions, the font is not loaded, but an error message appears:
"LuaTeX error ...texmf-dist/tex/luatex/luaotfload/fontloader-2015-12-12.lua:11013: bad argument #1 to 'for iterator' (table expected, got nil). \begin{document}"
The error appears independent from that, whether the calt feature is activated or not (parameter +calt or Contextuals=Alternate with fontspec).

[phi-gamma]

···<date: 2015-12-14, Monday>···<from: orchidee2>···

The behavior of the new fontloader (luaotfload vers. 2.6-fix-2)
concerning the calt feature is quite strange. In all tested
cases the calt feature is completely ignored. In cases, where
the font only contains 1st and/ or second position glyph
substitutions, the font is anyhow loaded and other features
like ligature substitution seem to work as desired. In cases,
where the font contains also 3rd and higher position glyph
substitutions, the font is not loaded, but an error message
appears: "LuaTeX error
...texmf-dist/tex/luatex/luaotfload/fontloader-2015-12-12.lua:11013:
bad argument #1 to 'for iterator' (table expected, got nil).

That error is reproducible, even in Context which currently uses
a more experimental fontloader. For testing I’ve translated the
example:

https://bitbucket.org/phg/lua-la-tex-tests/src/tip/context/cnt-features-13-calt.tex

Thanks for supplying me with the font, I’ve put it under version
control since it’s under the SIL license:

https://bitbucket.org/phg/lua-la-tex-tests/src/tip/latex/ComicNeuemod.sfd
https://bitbucket.org/phg/lua-la-tex-tests/src/tip/latex/ComicNeuemod.otf

Some issues with the calt features have been reported earlier
this year: http://mailman.ntg.nl/pipermail/ntg-context/2015/080623.html
Here Fontforge rendered the feature correctly which I’m assuming
is the case in the issue at hand as well, considering that you
supplied the .sfd.

[phi-gamma]

···<date: 2015-12-14, Monday>···<from: phg>···

That error is reproducible, even in Context which currently uses
a more experimental fontloader.

I have spoken too soon: The crash only happens with the earlier
fontloader that is currently part of Luaotfload. With the beta
version of Context, the output is as below -- no crashes!

![fat cat](http://i.imgur.com/zOmk2Q1.png]

Does that match your expectations? If so, I’m afraid you’re going
to have to wait until the experimental fontloader is ready for
production. (It’s far from that at them moment, a number of
issues have been reported.)

[orchidee2]

Thank you for your efforts. The result at the picture is as desired :-).
So, I have to wait until the new fontloader is ready.

[phi-gamma]

@orchidee2 With the new release (just submitted) at least it
won’t crash any more.

[phi-gamma]

@orchidee2 Do you have a TeX Live pretest setup for testing the 2.7 version?

[orchidee2]

Ok, I have just installed the 2016 pretest setup.

Am 28.04.2016 um 18:54 schrieb Philipp Gesang:

@orchidee2 https://github.com/orchidee2 Do you have a TeX Live
pretest setup for testing the 2.7 version?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#303 (comment)

Dr. Martin Hein
Institut für Chemie
Abt. Organische Chemie
Universität Rostock
Albert-Einstein-Str. 3a
18059 Rostock

Tel.: +49 381 498 6428
E-mail: [email protected]

[orchidee2]

My first test results show, that with the new fontloader the calt feature seems now to work correctly if it is implemented as contextual chaining substitution (that's very nice :-)). On the other hand, if the calt feature is implemented as normal contextual substitution, it still doesn't work properly. But I will do some more tests for verification.

[phi-gamma]

Hi,

thanks a lot for the feedback!

···<date: 2016-04-29, Friday>···<from: orchidee2>···

My first test results show, that with the new fontloader the
calt feature seems now to work correctly if it is implemented as
contextual chaining substitution (that's very nice :-)).

I agree =)

                                                     On the

other hand, if the calt feature is implemented as normal
contextual substitution, it still doesn't work properly. But I
will do some more tests for verification.

No problem. I’d ask you to open a new item to track this issue.
As always, a test file (or font) are much appreciated.

Best,
Philipp