1

I recently moved away from LyX to TeXstudio and am using XeLaTeX to generate PDF. I cannot use PdfLaTeX because of the fontspec package. I rewrote my resume and went to apply for some positions. To my surprise, CV Parsers did not pick up hyphen characters ("-"). So, I began investigating...

Here is a minimal reproducible example:

\documentclass[letterpaper]{article}

\usepackage[left=0.4in,top=0.4in,right=0.4in,bottom=0.4in]{geometry}
\usepackage{enumitem}
\usepackage{fontspec}
\usepackage{ulem}
\usepackage{xstring}
\usepackage{ifthen}
\usepackage[none]{hyphenat}

\pagenumbering{gobble}

\setmainfont{Times New Roman}
\setlength\parindent{0pt}

\begin{document}

-

\end{document}

In Adobe Acrobat DC, Chrome, and Xournal++, the PDF looks fine.

I tried copying/pasting a hypen in the generated PDF, but nothing seemed to have been copied to the clipboard. Naturally, I quickly wrote an application using Apache PDFBox to list all unicode characters. To my amazement, XeLaTeX does not use unicode Hyphen-Minus (U+002D), it uses Soft Hyphen (U+00AD).

Also, if I copy a block of text in the PDF, sometimes spaces are pasted as newlines.

Note: I am pasting into plaintext areas.

So, my questions are:

  1. Why is XeLaTeX using Soft Hyphens?
  2. How do I configure XeLaTeX to use Hyphen-Minus?
  3. Why do some spaces act like newlines when copied/pasted into plaintext?

Thanks to all.

5
  • cutting and pasting text from a pdf is open to multiple heuristics and guesses by the pdf reader. Did you check what character is actually in your pdf? Also if you want someone to debug please provide a small example that does this. Oct 10, 2020 at 8:09
  • 1
    I checked in a small example, a-b inserts a U+002D into the pdf and it copies fine. You will have to show a small example that demonstrates your issue. Oct 10, 2020 at 8:34
  • I added an example.
    – Oliver
    Oct 10, 2020 at 19:07
  • It seems that XeTeX with fontspec uses U+2010 for hyphens. It bugs me too, since I cannot search terms in my PDF viewer.
    – Lei Zhao
    Dec 11, 2020 at 17:09
  • I ultimately solved this by chaining through DVI.
    – Oliver
    Dec 12, 2020 at 19:17

1 Answer 1

2

This solves my problem. It should probably solve your problem too. Just put \XeTeXgenerateactualtext=1 into your preamble.

\documentclass{article}

\usepackage{fontspec}
\defaultfontfeatures{Ligatures=TeX,Numbers=OldStyle}
\setmainfont{Palatino Linotype}

\XeTeXgenerateactualtext=1

\begin{document}

The three-steps interdependent interdependent interdependent
interdependent interdependent interdependent interdependent
interdependent interdependent interdependent interdependent
interdependent interdependent interdependent independent independent
independent independent independent independent independent
independent independent
\end{document}

However, this solution is not perfect. Actual text (/ActualText) is another PDF technology. The best solution would be just mapping the hyphen character to old ASCII U+002D instead of the less common but normative U+2010. I am still trying to find out how to do that.

Update:

After further investigation, this is actually caused by the font files. For Times New Roman, it's mapped to none. For Palatino Linotype and most other fonts, it is mapped to U+2010, which is normative but less common and not searchable in most PDF viewer. For some other fonts, it is indeed mapped to U+002D. Try and experiment with yourself to see if you can find such fonts. I did.

If this is in LuaTeX, I can always patch the fonts on the fly using \directlua. For this specific case of hyphen, it doesn't happen in LuaTeX. The only drawback I found about LuaTeX is it is very slow when compared to XeTeX.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.