Nowadays, icon fonts are quite popular on the web. There have been latex bindings to these icon fonts through packages such as academicons, fontawesome5 and fontmfizz.
This brings in new possibilities such as using them on documents such as resumes to indicate computing-related skills. While being visually pleasing, there are two issues with them
- The words extracted from the PDF by an Applicant Tracking System (ATS) eg. by using a
pdftotextis non-parseable - More importantly, even if a human recruiter manually reads the PDF of the CV, they won't be able to search for any keywords for job descriptions currently handled by them.
This renders the entire skills section nearly useless and running the risk of a suitable applicant not making it to the interview stage, diminshing the value of icon fonts to mere eye candy.
I think embedding an alt-text is a great workaround for such cases for which I tried the solutions proposed here
However, weirdly the first solution there using accsupp package only works with adobe reader while the second solution works only with sumatrapdf or other mupdf based readers. But both these methods highlight a far greater rectangular area than that corresponding to the searched icon.
My question is Is there a way to combine both these methods into a single solution? I am happy to accept a luatex solution if needed. I know there is no perfect solution, but is there any alternative to this approach that is viewer agnostic?
Here is a MWE
\documentclass{article}
\usepackage{fontmfizz}
\usepackage{tikz}
\newcommand{\archlinux}{\ooalign{\hidewidth\tikz\node[inner sep=0pt,opacity=0]{Linux};\cr \mfArchlinux \cr}}
\begin{document}
I know \Huge \archlinux.
\end{document}
The solution needs to be case-insensitive e.g. here, when searching for either linux or Linux, we need to always find the match/highlight the icon in the PDF.
PS:
Another useful reference question for this situation.
Update:
The tikz based solution in the original link works in mupdf based readers, but weirdly in adobereader only the single letter l or L is matched. Upon entering the next character li, the search stops matching. Totally weird.
linuxusing Okular. Perhaps this is viewer dependent... The case sensitiveness is. Okular has a toggle to switch that on and off. – Phelype Oleinik Feb 13 '19 at 21:38sumatrapdf(amupdfreader) for me, but does not work inadobereaderwhich is the reference reader for thepdfstandard (and the most widely used one, particularly by people outside academia). It is most likely that a recruiter is on Windows/AdobeReader combo just searching a PDF for some keywords. – Dr Krishnakumar Gopalakrishnan Feb 13 '19 at 21:41accsupppackage, usingActualTextorE? – Phelype Oleinik Feb 13 '19 at 21:43ActualTextanswer. I shall much appreciate it if you can try it out and post an answer if it works for you? – Dr Krishnakumar Gopalakrishnan Feb 13 '19 at 21:44actualtextsolution works flawlessly withadobereaderwhile thetikzsolution works only withmupdf-based readers. I am convinced that combining the two is the key! – Dr Krishnakumar Gopalakrishnan Feb 13 '19 at 21:56