Inputting glyphtounicode when compiling with pdflatex makes sure that various ligatures in the output are copy- and searchable. With the Alegreya package, however, the ligatures for fj and ffj aren't rendered correctly. Is there a way to work around it?
\documentclass{article}
\usepackage{Alegreya}
\input glyphtounicode
\pdfgentounicode=1
\begin{document}
fb ffb ff fh ffh fi ffi fj ffj fk ffk fl ffl ft fft
\end{document}
Copy-and-paste from .pdf:
fb ffb ff fh ffh fi ffi f fk ffk fl ffl ft fft
glyphtounicodeshould be in tex live 2015, because I haven't installed or downloaded anything manually. (I have an idea about howAlegreyais mapping those non-unicode ligatures, but I'm on my way out now, so I'll come back to that. But in short, I believe thefin inputs likefb,fk, etc. is mapped to a differentfglyph, which thenglyphtounicodeis able to map back onto anf. So, the outputfkhere is not a single ligature, it's just the combination of a differentf+k. I guessfjis a real ligature, andglyphtounicodecan't deal with it. – Sverre Aug 13 '15 at 18:18fjligatures (nor tofb,fh,fkorftligatures), it's not clear to me howAlegreyais making these connections. they're not defined inglyphtounicode. under the circumstances, this seems to be something that should be reported to the maintainers ofAlegreya. – barbara beeton Aug 13 '15 at 18:23fjshould be a real ligature! (and norwegians should complain otherwise, as should slartibartfast.) (and i have since foundglyphtounicodein tex live 2015, although i'm unable to locate it directly on ctan.) – barbara beeton Aug 13 '15 at 18:28fb,fkandftaren't "real" ligatures in theAlegreyafont in the sense that they are composed of a single glyph - they just look like ligatures because the font provides context sensitive variants off. Whereas it seems likefjis a single glyph in the font, and that's whyglyphtounicodecan't do anything about it (since the ligature is not included in Unicode). (And yes, as a Norwegian I am very unhappy about fonts without afjligature:)) – Sverre Aug 13 '15 at 18:32glyphtounicodedoesn't even contain anything i could recognize as anfiofffligature, so they are recognized in some other way which i can only speculate about. you say that they "aren't rendered correctly", but it's implied that they do appear correct in the output, and the problem is with cutting and pasting that result back to input form. if you could add the output view of your example, that would be more clear. (there must be some way of determining the "unicode" orutf8value of these glyphs; i suspect this one is in the private use area.) – barbara beeton Aug 13 '15 at 19:01