On 11 May 2021, at 15:16, Hans Hagen wrote:

On 5/11/2021 2:08 PM, Jairo A. del Rio wrote:

...

Hi, list! Following this thread: https://tex.stackexchange.com/questions/596610/how-to-use-luatex-with-large-... https://tex.stackexchange.com/questions/596610/how-to-use-luatex-with-large-..., I tried to replicate it in ConTeXt. Both LMTX and LMTX fail to display the right symbol and, as it's discussed in the linked page, there's an offset by 14. Is this intentional (in ConTeXt)? A bug? Minimal (non-)working example: %Font available here: https://materialdesignicons.com/ https://materialdesignicons.com/ \starttext \definedfont[file:materialdesignicons-webfont.ttf]\char"F1372\relax \stoptext You need to employ a sense of humour for that font:

\starttext \definefontfeature[materialicons][default][rlig=yes] \definedfont[file:materialiconsregular.ttf*materialicons] baby_changing_station \stoptext

That only works with the regular font, not with the webfont version from the ‘easy download’ link (it is cool, though :)). But that is not the issue. The issue is that you have this super-useful page online: https://pictogrammers.github.io/@mdi/font/5.4.55/ where you can just copy the code point and/or the encoding hex value. But those values do not match the ones in ConTeXt because the duplicates are removed while creating the tma, which condenses the encoding, resulting in an encoding offset, and that in turns make cut&paste useless. :( Also, it is a bit of a shame that the XXX-webfont.ttf has postscript glyph names that map to the online cheat sheet, but these names are not preserved in the tma file (at least not in my lmtx version). Keeping those would make the whole typset-a-specific-glyph procedure be a lot less error-prone, at least. Best wishes, Taco — Taco Hoekwater E: taco@bittext.nl genderfluid (all pronouns)

On 11 May 2021, at 17:31, Hans Hagen wrote:

On 5/11/2021 3:40 PM, Taco Hoekwater wrote:

...

...

On 11 May 2021, at 15:16, Hans Hagen wrote:

On 5/11/2021 2:08 PM, Jairo A. del Rio wrote:

...

Hi, list! Following this thread: https://tex.stackexchange.com/questions/596610/how-to-use-luatex-with-large-... https://tex.stackexchange.com/questions/596610/how-to-use-luatex-with-large-..., I tried to replicate it in ConTeXt. Both LMTX and LMTX fail to display the right symbol and, as it's discussed in the linked page, there's an offset by 14. Is this intentional (in ConTeXt)? A bug? Minimal (non-)working example: %Font available here: https://materialdesignicons.com/ https://materialdesignicons.com/ \starttext \definedfont[file:materialdesignicons-webfont.ttf]\char"F1372\relax \stoptext You need to employ a sense of humour for that font:

\starttext \definefontfeature[materialicons][default][rlig=yes] \definedfont[file:materialiconsregular.ttf*materialicons] baby_changing_station \stoptext That only works with the regular font, not with the webfont version from the ‘easy download’ link (it is cool, though :)). But that is not the issue. The issue is that you have this super-useful page online: https://pictogrammers.github.io/@mdi/font/5.4.55/ where you can just copy the code point and/or the encoding hex value. But those values do not match the ones in ConTeXt because the duplicates are removed while creating the tma, which condenses the encoding, resulting in an encoding offset, and that in turns make cut&paste useless. :( Also, it is a bit of a shame that the XXX-webfont.ttf has postscript glyph names that map to the online cheat sheet, but these names are not preserved in the tma file (at least not in my lmtx version). Keeping those would make the whole typset-a-specific-glyph procedure be a lot less error-prone, at least. i suppose you noted the message -)

can you confirm / check that we can safely assume zero length names to be okay?

local length = readbyte(f) if length > 0 then glyphs[mapping].name = readstring(f,length) else -- report("quit post name fetching at %a of %a: %s",i,maxnames,"overflow") -- break end

i bet this check is there because of some other font needed it in order to get loaded

With that “break" removed glyph naming works and I can safely do: \getnamedglyphdirect{file:materialdesignicons-webfont.ttf}{access-point-check} which is the font glyph encoded at “F1538. The above line produces the correct output now. But \char”F1538 still shows the wrong icon (though probably a different wrong one). I did a bit of digging, and here is where it starts to goes wrong right now (tma excerpt): [983923]={ ["boundingbox"]=1, ["index"]=883, ["name"]="minecraft", ["unicode"]=983923, ["width"]=512, }, [983924]={ ["boundingbox"]={ 0, 0, 406, 214 }, ["index"]=884, ["name"]="minus", ["unicode"]=8722, ["width"]=512, }, [983925]={ ["boundingbox"]=6, ["index"]=885, ["name"]="minus-box", ["unicode"]=983925, ["width"]=512, }, That “minus" is moved back to the spot for Unicode MINUS SIGN, and then the rest of the encoding shifts down by one. That happens a few dozen times in total, for various glyphs with “standard” names. So probably the name-based remapping of glyphs is a bad idea for glyphs that are explicitly PUA-encoded in the font ... Best wishes, Taco — Taco Hoekwater E: taco@bittext.nl genderfluid (all pronouns)

On Tue, May 11, 2021 at 3:41 PM Taco Hoekwater wrote:

...

On 11 May 2021, at 15:16, Hans Hagen wrote:

On 5/11/2021 2:08 PM, Jairo A. del Rio wrote:

...

Hi, list! Following this thread: https://tex.stackexchange.com/questions/596610/how-to-use-luatex-with-large-... < https://tex.stackexchange.com/questions/596610/how-to-use-luatex-with-large-unicode-codepoint>, I tried to replicate it in ConTeXt. Both LMTX and LMTX fail to display the right symbol and, as it's discussed in the linked page, there's an offset by 14. Is this intentional (in ConTeXt)? A bug? Minimal (non-)working example: %Font available here: https://materialdesignicons.com/ < https://materialdesignicons.com/> \starttext \definedfont[file:materialdesignicons-webfont.ttf]\char"F1372\relax \stoptext You need to employ a sense of humour for that font:

\starttext \definefontfeature[materialicons][default][rlig=yes] \definedfont[file:materialiconsregular.ttf*materialicons] baby_changing_station \stoptext

That only works with the regular font, not with the webfont version from the ‘easy download’ link (it is cool, though :)).

But that is not the issue. The issue is that you have this super-useful page online:

https://pictogrammers.github.io/@mdi/font/5.4.55/

another link for the records, just in case https://www.nerdfonts.com -- luigi

On 5/13/2021 8:46 AM, Sergio Callegari wrote:

On 5/11/2021 2:08 PM, Jairo A. del Rio wrote:

...

Hi, list! Following this thread: https://tex.stackexchange.com/questions/596610/how-to-use-luatex-with-large-...

https://tex.stackexchange.com/questions/596610/how-to-use-luatex-with-large-...,

I tried to replicate it in ConTeXt. Both LMTX and LMTX fail to display the right symbol and, as it's discussed in the linked page, there's an offset by 14. Is this intentional (in ConTeXt)? A bug?

Hi! As the original poster of the stackexchange question, I have found this thread and I am quite grateful for your attention on the topic!

In fact, I am a LaTeX user and this is just one more reason why I am quite grateful to the ConTeXt community, since some progress that is recently being enjoyed in LaTeX including the nice support for unicode fonts derives from ConTeXt, I understand.

I would like to add a pointer to the thread at https://github.com/latex3/luaotfload/issues/185#issuecomment-839640563.

For luaotfload the issue is currently being marked as wontfix, since the relevant code and the node shaper come from ConTeXt. If some improvement is made in ConTeXt, I am pretty sure that luaotfload will benefit from it though and I would like to thank in advance! I already see progress on retaining the glyph names is being made.

It is my understanding (please correct me if I am wrong) that the visible issues get triggered by multiple circumstances playing together at once:

- the fact that the current codebase does a name-based remapping of glyphs also for glyphs that are explicitly PUA-encoded;

- the fact that some errors with some glyphnames in the ttf font cause the current code-base to drop the names so that the chars cannot be accessed by name;

- the fact that some naming mistake seems to be present in the ttf font (at least with respect to the tabled codepoint-glyphname-glyphappearance) actually introducing some duplicates.

If this is correct, I wonder if it can make sense to open an issue on the font development site (and maybe keep today's version of the ttf as a test case should there be some change in ConTeXt wrt the glyph name handling and remapping). A next upload will scan the names (read: i commented the possible catch for issues, let's see when the font that needed that pops up again).

The renaming of bad glyphs can technically be fixed but a runtime hack but i try to avoid that .. the more heuristics, the harder to fight. You can try to patch luaotfload. Locate the 'report' line and comment those two as below. local length = readbyte(f) if length > 0 then glyphs[mapping].name = readstring(f,length) else -- report("quit post name fetching at %a of %a: %s",i,maxnames,"overflow") -- break end Did you try to use the regular variant: \starttext \definefontfeature[materialicons][default][rlig=yes] \definedfont[file:materialiconsregular.ttf*materialicons] baby_changing_station % selects symbol as ligature \stoptext (in latex equivalent) .. keep in mind that 'web' fonts are often more minimalistic, so i never use them (when there's a real one). 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 -----------------------------------------------------------------