2

When I use the newtxmath package and compile with pdflatex, the output PDF looks correct, but when I select the text in the PDF, the underlying text is incorrect.

Here's a MWE:

\documentclass{article}
\usepackage{newtxmath}

\begin{document}
Test \(a + b\)
\end{document}

The output PDF looks correct, but selecting the text in the PDF (and copying it to some other text area) gives Test 푎 + 푏. The result I expected to get is Test a + b or something similar.

Things I've tried (and failed):

  • Use $ $ instead of \( \)
  • Compiling on Overleaf and my friend's computer
  • Use different PDF viewers (zathura, Firefox, Chromium)

I have no idea if this behavior is intentional, or if it's a bug. Ideally, I would like to learn how to change the behavior so that what I expected to happen occurs.

UPDATE

I've bothered a few more friends about this, and here are a few things I have observed:

  • This occurs when the PDF is compiled with TeX Live (tested on Linux) or MiKTeX (tested on Windows) and when viewed with zathura, Firefox, or Chromium/Chrome. The original bug occurred with TeX Live and zathura.
  • This does not seem to occur when compiled with MacTeX. Correction: did not occur when compiled with TeX Live on a Mac.
  • This does not occur in Gmail file preview.
  • This does not occur when viewing the PDF in the Preview program in MacOS.
3
  • 1
    I cannot reproduce this behavior. Commented Mar 16, 2020 at 1:44
  • I've fiddled around with it more and added to the question a few conditions in which this occurs.
    – chezbgone
    Commented Mar 16, 2020 at 7:21
  • 1
    I doubt that the OS on which you compile matters, but the version/age of the tex system could matter, e.g. if the fonts are different. Commented Mar 16, 2020 at 7:38

1 Answer 1

5

The font, NewTXMI.pfb, uses as glyph names non standard strings reflecting the intended unicode meaning of the char. Viewers don't recognize such strings and so don't know what to do with it. You can use this to map them to something the viewers know:

\documentclass{article}
\usepackage{newtxmath}
\pdfgentounicode=1
\input{glyphtounicode}
\pdfglyphtounicode{u1D44E}{0061}  %  0061= a
%\pdfglyphtounicode{u1D44F}{0062} % b
%\pdfglyphtounicode{u1D44F}{1D44F} % 1D44F= MATHEMATICAL ITALIC SMALL B, does probably nothing

\begin{document}
Test \(a + b\)
\end{document}

which copies as Test a + 𝑏

pdftex seems to ignore large numbers like 1D44F, nevertheless \pdfgentounicode=1 changes the way viewers copy these chars. Sumatra seems to have bug here and shift the result by one. It copies the example as Test a + 𝑐. So uses a mathematical c, instead of b.

You must log in to answer this question.

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