5

I realize I am using a proprietary font here, but this is where I discovered this problem (it also applies to other ligatures as well as old style numbers).

\documentclass{article}
\usepackage{fontspec}
\setmainfont[
        Path = M:/MyStuff/Fonts/timesnewroman6.80/,
        UprightFont = times.ttf,
        Ligatures = Discretionary]{tnr}
\begin{document}
Th
\end{document}

enter image description here

When I copy and paste this from the pdf, on the other hand, I get instead of the expected Th. Looking at how this ligature has been encoded (using FontForge), everything seems to have been done properly:

enter image description here enter image description here enter image description here enter image description here

Sverre
  • 20,729
  • Is the resulting PDF available any where? – خالد حسني Sep 12 '13 at 21:51
  • You mean you want the actual file? It's now here: http://s000.tinyupload.com/index.php?file_id=03340620415189837770 – Sverre Sep 13 '13 at 09:01
  • Could it be, that you need something along these lines: http://tex.stackexchange.com/questions/86614/can-we-make-ligatures-copy-and-pastable – bodo Sep 13 '13 at 09:23
  • @canaaerus No, glyphtounicode is for pdfTeX, not XeTeX. Cf. http://tex.stackexchange.com/questions/110354/pdfglyphtounicode-with-xetex – Sverre Sep 13 '13 at 09:47
  • Good to know. Unfortunately in the pdf file you provided I can not select th as text with my pdf reader okular. Is the font you use publicly available, so we could try to compile the document ourselves? – bodo Sep 13 '13 at 10:06
  • @canaaerus No, I'm afraid not. It's propitiatory, as I apologized for in my question. It's the Times New Roman font that came with Windows 8 (the font version is 6.80). – Sverre Sep 13 '13 at 10:24

1 Answers1

8

The Times New Roman font (at least the version shipped with Windows) has a version 3 post table which does not include any glyph names (post is the table that contains glyph names in TrueType fonts). As a result, the PDF driver (xdvipdfmx) will give the glyph synthetic names; for unencoded glyph like this it will simply be glyphXXXX where XXXX is the glyph id.

The names you see in FontForge UI are simply synthetic names generated by FontForge itself, and it seems to apply some heuristic to guess glyph names for unencoded glyphs based on font’s glyph substitution rules.

xdvipdfmx does not currently do such a heuristic as it would require parsing the GSUB table of the font (which is not something the driver usually does; the OpenType layout is done by XeTeX itself), and is not always bulletproof (what if the same glyph is re-used for two different ligatures?).

خالد حسني
  • 22,859
  • I see. Meaning, I understand your explanation (but have no idea how you figured that out). Relatedly, I've found that the Th ligature works fine with LuaTeX. Is that expected behavior? Does LuateX make some guess in this case what the glyph name is? If you're interested in the LuaTeX output pdf: http://s000.tinyupload.com/index.php?file_id=02282326599062751228 – Sverre Sep 13 '13 at 17:35
  • I think LuaTeX guesses a proper glyph name based on the fact that it is a ligature (would be interesting to see what happens if one inserts the glyph directly using its font id), unfortunately this information is not available to xdvipdfmx at the time of PDF creation. – خالد حسني Sep 13 '13 at 17:38
  • I can find out if you tell me how I do that. I'm used to inserting glyphs directly from fonts with \char"XXXX, where XXXX is the Unicode points, but glyphs like these don't have Unicode points. – Sverre Sep 13 '13 at 17:44
  • Check http://tex.stackexchange.com/a/120762/729. – خالد حسني Sep 13 '13 at 18:11
  • You're expecting too much of me ... I don't understand how to modify that answer to fit my case. – Sverre Sep 13 '13 at 18:23
  • Never-mind, I forgot that LuaTeX uses a FontForge-based font loader, that is probably where the T_h mapping came from. – خالد حسني Sep 15 '13 at 13:44