#334 arrows.meta: no p in font nullfont (or t)

[karl berry]

The following document produces a bunch of warnings in the log like this:

Missing character: There is no p in font nullfont!
Missing character: There is no t in font nullfont!

Here is the test document, just drawing a trivial arrow as one of the
types from arrows.meta:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentclass{article}
\usepackage{tikz}
\usetikzlibrary{arrows.meta}

\begin{document}
\loggingall
\begin{tikzpicture}
\tikzset{>={Stealth}}
\draw[->] (0,0) to (1,0);
\end{tikzpicture}
\end{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

It happens with most or all of the arrow types, not just Stealth.

The cause is the \pgfmathdivide@ lines in
pgflibraryarrows.meta.code.tex, for example:
\pgfmathdivide@\pgfarrowlength\pgfarrowwidth%

However, \pgfmathdivide@ (the version in use here, anyway) expects a
literal number, not a register. From the log file:

\pgfmathdivide@ #1#2->\begingroup \pgfmath@x =#1pt\relax ...
...

1<-\pgfarrowlength

2<-\pgfarrowwidth

{\begingroup}
{\dimen107}
{the letter p}
Missing character: There is no p in font nullfont!
{the letter t}
Missing character: There is no t in font nullfont!
{\relax}
...

Since #1 is a dimen register in this call, it is a complete <dimen> in
itself and the following "pt" is taken as literal text to be typeset,
hence the warning is emitted.

Since the font is \nullfont, no output is produced. So you might ask,
why do I care and why did I invest the effort to track down and report
this? The answer is, in my work with TUGboat and elsewhere, I have
found that a common problem is receiving a source file with various
binary octets that are not interpreted properly and do not match up with
any character in the font being used.

The only reliable way I've found to deal with this problem is to grep
the log file for the "Missing character:" message. But here the message
is being generated spuriously. I have never seen this before with any
document. So I would be very appreciative if this "false positive"
could be eliminated.

Unfortunately I could not imagine a simple change to handle this, so I
have no patch to offer. Sorry. I figured there might be some other
division function somewhere in the vast world of pgf that would work, or
something ... so didn't go to great lengths to figure out a fix.

Help?

Thanks,
Karl

[karl berry]

i didn't know i was typing markdown. obviously the 1<- and 2<- log lines above actually start with a sharp sign. evidently i'm not allowed to edit my own post, either. whatever.

[percusse]

Hello Karl,

I think this is the duplicate of bug 314.

[karl berry]

evidently yes, i guess the bugs should be combined or something (sf gives me no power to do anything, as far as i know). i unknowingly reproduced the research done in the tex.sx post. regardless, it would be nice if it got fixed.

thanks.

[Christian Feuersänger]

Duplicate of bug #314