# Adapt graphic size to surrounding text

I programmatically generate templates to be compiled with pdfTeX 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) to PDF files. At a certain point, I want to replace some text characters with their image equivalent: I have converted a font file to a bunch of .png files. One png file contains one char of the font.

Now I want to insert those png files into the LaTeX template in a way that a human reader will never notice any difference to the "real" text (unless they try to copy&paste, but that's a different story).

The problem is: I need a solution which works for every font size (and other layout settings).

So, how can I make sure that the images always scale exactly to the size of the text surrounding them?

Currently, I'm using includegraphics, but if there is another (free) package capable of my requirement I'm fine with that.

• Welcome to TeX.SE! Although your approach might be possible in some way (I'm not sure how, but it might) there is at least one serious issue, which is kerning and ligatures (i.e., adjusting the positioning of characters based on the surrounding characters, see en.wikipedia.org/wiki/Kerning). LaTeX does that automatically, so if you just put a row of character images next to eachother you will never get the same appearance as the real text with kerning applied. – Marijn May 8 '19 at 8:35
• Maybe more important: why do you want to implement this approach? For copy protection/preventing automatic processing? For preventing font issues? For learning more about LaTeX programming? Some other reason? There might be other methods to accomplish your goals, which are easier to implement than what you propse in your question. – Marijn May 8 '19 at 8:41
• @Marijn Thanks for those hints! Concerning kerning and ligatures, I think I can live with that. I want to do that only for some edge cases chars which I do not expect in legitimate input anyway. The ultimate reason I want to do that is security. I get untrusted data which is processed in a longer toolchain. The risk could be greatly reduced by replacing chars with their image equivalent. – cis May 8 '19 at 8:51
• There is also \baselineskip, \ht\strutbox and \dp\strutbox which are font dependent (not sure precisely when they get reset). – John Kormylo May 8 '19 at 12:46

 \includegraphics[height=1ex]{image.png}


will include the image scaled to 1ex which is a font dependent unit typically the height of an x.

• I don't know why but it's way too small. However, if I set height=1.5ex, then it works for me. – cis May 8 '19 at 9:32
• @cis there may be white space in your image, but anyway yes you may need a 1.5 or some other factor depending on font-specific details – David Carlisle May 8 '19 at 9:44

You need to take care of the height and depth.

\documentclass{article}
\usepackage{graphicx}

\makeatletter
\newcommand{\0}[1]{%
\begingroup
\settoheight{\@tempdima}{#1}%
\settodepth{\@tempdimb}{#1}%
\raisebox{-\@tempdimb}{%
\includegraphics[height=\dimexpr\@tempdima+\@tempdimb]{example-image}%
}%
\endgroup
}
\makeatother

\begin{document}

T\0{T} x\0{x} y\0{y}

\end{document}


Instead of example-image you will have a file name built upon #1.

However, a careful reader will notice the difference: well crafted fonts have glyphs that are not necessarily contained in their bounding box. For instance, the vertex of an A will usually overspill a bit.

An adjustment based on the shape could be added both for the depth and the height.

You can measure chars. The following code does not handle non-ascii chars.

\documentclass{article}
\usepackage{graphicx,expl3}

\ExplSyntaxOn\makeatletter
\newcommand\replacechar[1]{
{
\dim_set:Nn\l_tmpa_dim{\fontcharht\font#1}
#1\includegraphics[height=\l_tmpa_dim]{example-image-duck}
}
}
\ExplSyntaxOff

\begin{document}

\replacechar{b} \replacechar{X} \replacechar{y} \replacechar{.}  \huge
\replacechar{b} \replacechar{X} \replacechar{y} \replacechar{.}

\end{document}


• you could drop the l3 dim setting and simply use \newcommand\replacechar[1]{{#1\includegraphics[height=\fontcharht\font#1]{example-image-duck}}}  – David Carlisle May 8 '19 at 9:17
• @DavidCarlisle yes but it could be that in the real document some more calculations are needed (e.g. that the depth should also be taken into account). Also there are perhaps the non-ascii chars which will need some code too -- and beside this I like to give cis answers with expl3 code ;-) – Ulrike Fischer May 8 '19 at 9:22
• Learning from egreg that (s)he who injects fancy looking _: runs away with the tick? :-) – David Carlisle May 8 '19 at 9:25
• @DavidCarlisle actually I think that in this case (s)he who uses pgf-math commands can get the tick ;-) – Ulrike Fischer May 8 '19 at 9:27