Since updating TeX Live yesterday (luaotfload was among the packages updated, to version 2.9, dated 2018/09/24), I’m having difficulty with glyphs in the Corporate Use Area and the MicroSoft Symbol Area.

For example, here is a glyph in Coelacanth which FontForge reports is named uniF58C:

FontForge screenshot

However, the following produces a page which is blank except for the page number:




\symbol{62860}% a converter called gbase tells me that f58c = 62860


The \fontchar macro described at access all characters in an OpenType font with LuaLaTeX likewise produces thin air.

Searching for the glyph name uniF58C in coelacanth.lua yields no result.

The only method I’ve found that works since the update is to make a font table as explained at Font table for OpenType/TrueType fonts. Then I can see that the glyph is U+0f0366, which can be converted to 983910, and both \symbol{"0F0366} and \symbol{983910} give the glyph desired.

My question is how to understand this change. Is is just a bug or an intended change? And why is there so little likeness between the information provided by FontForge and that obtained from the font table?


1 Answer 1


The generic/context fontloader moved "all private chars in the font to a dedicated private range" and so broke the access of this glyphs. If this change is permanent (unclear yet) all packages and documents which access such glyphs with \char will probably have to adapt their code for lualatex.

Edit 2018-10-04

With todays update of luaotfload the problem should be resolved.

Currently available work-arounds

use an older fontloader

access with a lua function


      for k, v in pairs(fonts.hashes.identifiers[font.current()].characters) do
          if v.unicode == #1 then


\byunicode{62860} \byunicode{\number"F58C}

  • Thanks very much, Ulrike! I’m just catching up with the thread on the ConTeXt list. Hans wonders what the use of these Coelacanth glyphs is: I don’t know. My real use case involves some Goudy fleurons, but I prefer to illustrate problems with freely available fonts if possible.
    – Thérèse
    Commented Oct 1, 2018 at 11:16
  • 1
    I've created alternative version which builds character table in the first use of \byunicode, the subsequent calls are more efficient, as it uses the cached version: gist.github.com/michal-h21/5922487ed74f3c1b6a34c49904971b0d
    – michal.h21
    Commented Oct 1, 2018 at 12:31
  • @michal.h21 nice. If we need something like this permantly we certain should use such a cache (and something so that \byunicode{"F58C} works without the \number). Commented Oct 1, 2018 at 12:43
  • @UlrikeFischer I've updated the gist so it supports the \byunicode{"F58C}
    – michal.h21
    Commented Oct 1, 2018 at 12:55
  • Seems to work on macOS. :-)
    – egreg
    Commented Oct 4, 2018 at 9:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .