# Why LuxiMono's dashes disappear when copying-pasting from Acrobat Reader?

Consider the following MCE:

\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage{luximono}
\begin{document}
\texttt{foo-bar}
\end{document}


When copying-pasting "foo-bar" from Acrobat Reader, the dash disappears: one obtains "foobar".

AFAICS, this trouble doesn't arise:

• with PDF viewers other than Acrobat Reader,
• or with fonts other than LuxiMono.

Do you know why and how to get the expected behavior?

• Confirmed on my Mac. – egreg May 13 '17 at 17:43

You can map the glyph name to the correct unicode position:

\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage{luximono}
\pdfglyphtounicode{hyphen}{002D}

\pdfgentounicode=1
\begin{document}
\texttt{foo-bar}
\end{document}


(I don't know why adobe doesn't copy it, when the name is hyphen, perhaps it tries to be too clever and removes hyphenation dashes).

I unpacked the vf and followed the way of the hyphen:

In ul9r8t.vpl contains (shortened)

(CHARACTER O 55
...
(MAP
(SETCHAR O 255)
)
)


This means that the hyphen (dec 45=octal 55) is mapped to octal 255=dec 173. This is also what one gets in the pdf: (foo\255bar) and not (foo-bar).

8r.enc encodes /hyphen twice: once at position 45, and once at 173.

The luximono font (in ul9r8a.afm) has hyphen at position 45, and sfthyphen ("soft hyphen") at position 173.

So imho adobe is doing the right thing, a sfthyphen should disappear at copy&paste and the fault is faulty: A typewriter which even sets \hyphenchar to -1 shouldn't remap the hyphen like this.

• Is it worth reporting to the LuxiMono font pack's maintainer (well, the last update dates from 2004-01-26)? – Denis Bitouzé May 14 '17 at 7:37
• I added some remarks regarding the source of the problem, but I have no idea if there is anyone who could correct it. – Ulrike Fischer May 14 '17 at 10:32
• The strange thing is that the other PDF viewers have the expected behavior. I reported to the maintainer. – Denis Bitouzé May 14 '17 at 14:47
• Well at first, a pdf viewer needs to be clever enough to suppress a soft hyphen and at second the encoding file (8r.enc) uses /hyphen as name, so the situation is a bit messy. – Ulrike Fischer May 14 '17 at 14:52