While looking at the log file of my document, I see a lot of paired error message lines that look like this (there might be slight inaccuracies, I am typing this on another computer for reasons I won't go into):

Missing character: There is no . in font nullfont!
Missing character: There is no 5 in font nullfont!

These occur together in pairs, always one that is a "." and one that is a "5", and always in that order. Generally there are a handful of them together in one place. From other questions I have gleaned that this error message generally occurs when extraneous text (i.e. text that is neither TikZ commands nor TeX comments) is entered inside a tikzpicture environment. The places in the log file that these errors appear do indeed appear to correspond to places where tikzpictures are found in my document. Moreover, bigger collections of them generally seem to correspond to bigger tikzpictures (in the sense of more TikZ code). However, as far as I can tell there is no extraneous text in my tikzpicture environments. In this question the questioner was unwittingly causing this sort of error by putting two []-delimited sets of options in the same place, but I do not think that is what is happening here.

I can try to put together an example file later today, if that would be helpful. I say "try" because I don't know for certain that I'll be able to create another, sufficiently small document that exhibits the same behaviour (the document whose log file displays this issue is too large for posting it here, inline, to be practical.)


It turns out this has something to do with code that was generously written for me by another TeX/LaTeX Stack Exchange user, in response to another question I asked. As such, this is slightly embarrassing, because it makes me look somewhat ungrateful if I point out defects (if indeed that is what this is) in something someone gave me for free. But I didn't know that's what was going wrong before I asked the question. I'd be interested to know what is going wrong though.

Anyway, if you compile the below example document (taken without modification from Qrrbrbirlbel's answer to the linked question) and look at the log afterwards, you will see these lines:

Missing character: There is no . in font nullfont!
Missing character: There is no 0 in font nullfont!
Missing character: There is no . in font nullfont!
Missing character: There is no 0 in font nullfont!
Missing character: There is no . in font nullfont!
Missing character: There is no 0 in font nullfont!
Missing character: There is no . in font nullfont!
Missing character: There is no 0 in font nullfont!

(Why is it a 0 instead of a 5 this time? I don't know.)


\tikzset{nomorepostaction/.code = \let\tikz@postactions\pgfutil@empty}
  {\PackageError{pgf}{Arrow #1 type ``#2'' unknown}{}}
    \ifx\pgf@arrow@temp\pgfutil@empty% ah. clear!
      \expandafter\let\csname pgf@#1arrow\endcsname=\pgfutil@empty%
      \expandafter\let\csname pgf@shorten@#1\endcsname=\pgfutil@empty%
      \expandafter\def\csname pgf@#1arrow\endcsname{\multiply\pgflinewidth by \pgflinewidth@arrow\relax\pgf@arrow@call{#2}}%
      \expandafter\edef\csname pgf@shorten@#1\endcsname{\multiply\pgflinewidth by \noexpand\pgflinewidth@arrow\relax\expandafter\noexpand\csname pgf@arrow@right@#2\endcsname}%
    bigdiagramarrow/.style = {
        arrow thick
    arrow line width/.code={
    arrow line width=1,
    arrow ultra thin/.style={arrow line width=0.25},
    arrow very thin/.style={arrow line width=0.5},
    arrow thin/.style={arrow line width=1},
    arrow semithick/.style={arrow line width=1.5},
    arrow thick/.style={arrow line width=2},
    arrow very thick/.style={arrow line width=3},
    arrow ultra thick/.style={arrow line width=4},
        \node [draw] (A) at (0, 0) {$A$};
        \node [draw] (B) at (0, 1) {$B$};
        \node [draw] (C) at (2, 1) {$C$};
        \draw [bigdiagramarrow] (A) to (B);
        \draw [out = 0, in = 180][bigdiagramarrow] (A) to (C);
  • 1
    There is little chance we can help you unless you post a minimal working example (MWE) that reproduces the behaviour you describe.
    – jub0bs
    Nov 30 '13 at 15:30
  • Updated with example.
    – Hammerite
    Nov 30 '13 at 20:37
  • I don't see any warnings. Which version of TikZ are you using? You can check it by putting \listfiles in your preamble and then looking at your log file.
    – percusse
    Nov 30 '13 at 20:48
  • There are several lines that seem relevant to TikZ/PGF. tikz.sty 2010/10/13 v2.10 (rcs-revision 1.76) pgf.sty 2008/01/15 v2.10 (rcs-revision 1.12) pgfcore.sty 2010/04/11 v2.10 (rcs-revision 1.7) and several others containing "pgf".
    – Hammerite
    Nov 30 '13 at 21:11
  • 1
    I noticed warnings like this some years ago when trying to recreate tikz's own documentation. When I tracked them down then, they corresponded to bugs in pgf code that used integer operations on decimals. In such operations, the "." ends the integer and becomes ordinary text, as do the digits after the decimal. As do the letters "pt" if the number happens to be a dimension. Tikz pictures switch to nullfont so extraneous spaces (and text) don't spoil the picture.
    – Dan
    Dec 1 '13 at 2:19

After testing your example, these warnings seem to be the result of the \multiply commands in the code of \pgf@arrowset. The expression after by in a \multiply command must be an integer. If it expands to a decimal number the . and the digits following are seen as text. The following changes should be made: change

\multiply\pgflinewidth by \pgflinewidth@arrow\relax


\pgflinewidth = \pgflinewidth@arrow \pgflinewidth \relax


\multiply\pgflinewidth by \noexpand\pgflinewidth@arrow\relax


\pgflinewidth = \noexpand\pgflinewidth@arrow \pgflinewidth \relax

These use the fact that a dimension (\pdflinewidth in this case) can be preceded by a factor (stored in the macro \pgflinewidth@arrow in this case) to effect a multiplication. I don't know much about pgf, so I can't say that this will be free of other problems.

  • I made these changes and the offending lines went away in the log file. I didn't see any side effects from the changes, either in the posted example or in my main document, but I'll bear in mind the possibility that side effects might exist. As it stands though, this seems to solve the problem. Cheers!
    – Hammerite
    Dec 1 '13 at 11:49

If you take my tikz answer and add 0.5pt between the two \draw commands, you get no error, and the output looks the same but the log warns:

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

If you want to see where the error is, you can make \nullfont have the characters add


Then again you get no error but this time no warning in the log, but the output is very messed up and you can see the offending characters.

enter image description here

Don't use that redefinition of \nullfont in production code but as a temporary redefinition while debugging, it can be useful.

  • 1
    I like the redefinition trick :)
    – rainer
    Nov 30 '13 at 17:11
  • So simple and so gut! Oct 28 '15 at 13:14
  • Why shouldn't we use the \font\nullfont=cmr10 trick in production code?
    – Jim Newton
    Aug 29 '18 at 21:04
  • @JimNewton because things will break:-) \nullfont is a built in font guaranteed to have no characters and so if you break that then characters and spacing will go wrong in any code that relies on that guarantee (tikz being a famous example) which uses nullfont as the default font outside node contents to avoid having to catch all spurious characters. Aug 30 '18 at 8:42
  • 1
    @JimNewton this specific case that I looked at 5 years ago, i have no idea, it's probably a bug that the characters are there, but the tikz author explictly invokes nullfont with the documented reason that it avoids the need to catch spurious characters (notably space) in some case. but it's not just tikz, any code has a right really to assume that \nullfont gives a minimally valid font with no characters, as that is what the texbook say it does. Aug 30 '18 at 10:57

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.