The only way to diagnose this problem is to turn your document into a truly minimal example that shows the problem, and then show the log message from that document. The one you've posted is far from minimal: in particular, your image inclusion commands are almost certainly irrelevant and also, what's the relation to Sweave here?
–
Alan MunnFeb 28 '12 at 15:29

This is the problem. I'm not at all sure what is relevant. Although, in reviewing my document, I did find an area where \subsection was written as \subection (missing the s). Once I added the s all of these errors went away. The relation to Sweave is that I'm using it, nothing more. I'm kind of surprised that latex is so unforgiving or at least unhelpful in finding these tiny mistakes. Frustrating, really.
–
Brandon BertelsenFeb 28 '12 at 16:54

I would see that as a minimal example (with the "s" in \subection producing the error)
–
Frank MittelbachFeb 28 '12 at 17:13

2 Answers
2

This error message is low-level TeX output which shows up if you are typesetting material in a font (external name "cmr12" in your example) and you are trying to typeset a glyph that is not in the font. The ? is not a real question mark it stands for a character that is unknown.

When you are typesetting a word, say, "aha" then deep down this is all translated to glyph positions in a font. For example, the "a" in most encodings represents the font position octal:141 and "h" is octal:150. Whatever glyphs are in these positions in the current font will be typeset (which may not look remotely like "a" or "h").

Now, the font in question has only the first 128 slots filled (it is a 7 bit font) and what happened most likely is that your document contains diacritical characters which in most encodings map to positions with number in the range from 128-255. And if these slots do not exist you get the error message.

Possible resolutions:

Use only 7 bit input, e.g., \'a instead of straight á

Use the "correct" input encoding for your document, e.g. \usepackage[latin1]{inputenc} if the document is written in the 8 bit Latin1 coding, or \usepackage[utf8]{inputenc} if it is in UTF8. Chosing the correct input encoding results in characters like á are automatically translated back internally by LaTeX to \'a.

In either case it is sensible to add \usepackage[T1]{fontenc} in your preamble so that 8 bit fonts are used as these will result in better quality if accented characters are used. If an 8 bit font encoding is used then commands like \'a are no longer constructing the diacritical characts but instead select the real glyph in the font.

Using only inputenc would help too: then e.g ä would be active and mapped to \"a and this is defined for OT1.
–
Ulrike FischerFeb 28 '12 at 22:31

@Ulrike you are right, looks like I don't remember how the stuff was designed that I once wrote.
–
Frank MittelbachFeb 28 '12 at 23:12

@Mico I owe you an apology, Ulrike is quite right that your suggested answer would have worked as well if the document was in UTF8 and not in say Latin1
–
Frank MittelbachFeb 28 '12 at 23:14

Is there a difference in \usepackage[utf8]{inputenc} and \usepackage[UTF8]{inputenc}?
–
mooseFeb 9 '14 at 11:49

@moose in case of inputenc the option is passed on to \inputencoding{option-name} which in turn loads a file option-name.def. On operating systems where file names are case sensitive that makes a difference (because UTF8.def may not exist). So it is better to use the official option name which is "utf8" in this case.
–
Frank MittelbachFeb 15 '14 at 16:51