using glyphs in the Corporate Use or Microsoft Symbol Areas

Question

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:

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

\documentclass{article}
\usepackage{fontspec}
\setmainfont{Coelacanth}
\begin{document}


^^^^f58c

\symbol{"F58C}

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

\char62860
\end{document}

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?

luaotfload has been updated to the current context fontloader. So in one sense the change is intended. To know if it is a bug I will have to pass the question to the context mailing list. Can you please open an issue at https://github.com/u-fischer/luaotfload/issues so that I don't forget it. — Ulrike Fischer, Sep 30 '18 at 17:56
Thanks @UlrikeFischer It’s https://github.com/u-fischer/luaotfload/issues/7 — Thérèse, Sep 30 '18 at 18:02

Ulrike Fischer · Accepted Answer · 2018-10-04T08:18:13.033

5

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

Get the 2018-07-20 (or 2018-07-20-patched) fontloader from https://github.com/u-fischer/fontloader-archive/tree/master/archive
create a luaotfload.conf in the search path with

[run] fontloader= fontloader-reference-2018-07-20.lua;

access with a lua function

\documentclass{book}

\usepackage{fontspec}
\setmainfont{Coelacanth}
\newcommand\byunicode[1]{\directlua{
      for k, v in pairs(fonts.hashes.identifiers[font.current()].characters) do
          if v.unicode == #1 then
              tex.print(utf.char(k))
              break
          end
      end
 }}


\begin{document}

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

\end{document}

edited Oct 04 '18 at 08:18

answered Oct 01 '18 at 10:58

Ulrike Fischer

327,261

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 Oct 01 '18 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: https://gist.github.com/michal-h21/5922487ed74f3c1b6a34c49904971b0d – michal.h21 Oct 01 '18 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). – Ulrike Fischer Oct 01 '18 at 12:43
@UlrikeFischer I've updated the gist so it supports the \byunicode{"F58C} – michal.h21 Oct 01 '18 at 12:55
Seems to work on macOS. :-) – egreg Oct 04 '18 at 09:28
@egreg Uff ;-). – Ulrike Fischer Oct 04 '18 at 09:33

using glyphs in the Corporate Use or Microsoft Symbol Areas

1 Answers1

Edit 2018-10-04

Currently available work-arounds

use an older fontloader

access with a lua function

Linked