[luatex] Problematic "tounicode" entries for ligatures in luatex-cache

[Philipp Gesang]

···<Datum: Wednesday, 11. March 2015>···<Von: Ulrike Fischer>···

> Am Tue, 10 Mar 2015 00:34:27 +0100 schrieb Valery Yundin:
> 
> > There seems to be a problem in how cache files for fonts are saved.
> > 
> > The font loader (?) writes "tounicode" entries as numbers if they do
> > not contain digits A-F. Which means that if such entry has leading
> > zeros, they will be lost, because Lua ignores leading zeros in numeric
> > literals. This leads to wrong CMap entries in PDF and
> > non-copy-pasteable glyphs. (Apparently this problem does not affect
> > single code point glyphs, probably because string format has a minimum
> > width of 4)
> > 
> > For example Carlito font has ligature for "ti", which doesn't have
> > standard unicode code point and has to be represented as a pair of "t"
> > and "i'.
> > 
> > The luatex generates the following cache file
> > $HOME/.cache/texmf/fonts/luatex-cache/generic/fonts/otf/carlito-regular.lua:
> > ["tounicode"]={
> > ...
> > [2210]=00740069,
> > ...
> > 
> 
> I tried with a current texlive 2014 on windows and luaotfload
> 2014/08/10 v2.5-4 OpenType layout system
> , and also in a current
> miktex and got with both systems the entry
> 
> [2210]="00740069",
> 
> in carlito-regular.lua. I had no problems to copy & paste the
> ligature: Beautiful fjord
> 
> Is your system up-to-date?

That’s the right question. We had a similar discussion a while
ago on the Context list:

    http://www.ntg.nl/pipermail/ntg-context/2013/073958.html

The problem was fixed then, IIRC.

If it persists or resurfaced somewhere, please post the output of
``luaotfload-tool --version``.

Best,
Philipp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://tug.org/pipermail/luatex/attachments/20150312/348aef22/attachment.bin>