Re: [NTG-context] \char not working with private unicodes

12 May 2021

...
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)