Corrupted NFSS tables' is written to stdout, but document is correctly produced, and the whole process is normal (i.e. no error) with Kile

[GoogleCodeExporter]

Hi,

When compiling the files at
`http://gitorious.org/angstrom-manual/angstrom-manual/trees/master' with
the most recent latex makefile, I receive this at stdout:

==
! Corrupted NFSS tables.
wrong@fontshape ...message {Corrupted NFSS tables}
                                                  error@fontshape else let f...
l.1 \AA
        ngstr\"{o}m was started by a small group of people who worked on the...
This error message was generated by an \errmessage
command, so I can't give any explicit help.
Pretend that you're Hercule Poirot: Examine all clues,
and deduce the truth by order and method.

! LaTeX Error: Missing \begin{document}.

! Emergency stop.
<*> history.tex

*** (job aborted, no legal \end found)
==

Strange, as the resulting PDF is correctly produced. Furthermore, there
cannot be any errors in the source files, as the whole process goes
normally under Kile. Why? Files are available at the git repo. (The
included makefile is not the most recent one, but I used the up-to-date
makefile to try compilation too.)

Original issue reported on code.google.com by merciadr...@gmail.com on 14 May 2010 at 4:35

[GoogleCodeExporter]

Kile doesn't output all of the errors that it should.  I have had other bugs 
submitted where Kile was silently 
pretending that errors didn't happen, and people thought everything was working 
fine.  In reality, there were 
subtle problems with their documents, and the makefile properly caught them 
where Kile did not.

When building with Kile, take a look at your .log files and I bet you'll see 
the errors in there.

Original comment by shiblon on 17 May 2010 at 5:34

[GoogleCodeExporter]

Sorry, I should have mentioned it, but I had checked kile's compilation's 
resulting
log after compilation. You'll find it attached. 

Original comment by merciadr...@gmail.com on 17 May 2010 at 5:52

Attachments:

• angstrom-manual.log

[GoogleCodeExporter]

Note also that the last resulting .log file for the project, but, this time, 
using
the makefile, gives no error. 

Original comment by merciadr...@gmail.com on 17 May 2010 at 5:54

Attachments:

• angstrom-manual.3.log

[GoogleCodeExporter]

Interesting.  Are you still having this problem, or did it somehow resolve 
itself?  I don't really know what an NFSS table is...

Original comment by shiblon on 17 Jun 2010 at 8:39

[GoogleCodeExporter]

I don't know neither what it is. I'll ask on comp.text.tex. But I am still 
having the issue, yes.

Original comment by merciadr...@gmail.com on 18 Jun 2010 at 11:14

[GoogleCodeExporter]

Well, at http://tug.org/pipermail/yandytex/2004-July/000902.html some things 
are explained, and at http://www.latex-project.org/guides/lc2fr-apb.pdf, p. 
10/61, it is explained that `Corrupted NFSS tables' actually means that LaTeX 
has tried some font substitutions, and has detected some inconsistency in its 
intern tables. This error habitually comes when a font substitution has been 
launched and that substitution's rules contain some loop (sub-circular 
declarations), or when the arguments of the default substitution (in the 
current coding) point to a group of inexisting fonts.

It is certainly due to the LaTeX makefile, because my related .log file 
contains no related errors/warnings, after Kile's compilation's invocation.

Original comment by merciadr...@gmail.com on 18 Jun 2010 at 11:29

[GoogleCodeExporter]

This last bit might be overstated.  Have you tried just running latex directly 
on your file and then checking the log?  The log file is overwritten with 
subsequent invocations, so it probably only shows up (and gets swallowed) in 
the first invocation that Kile performs.

Original comment by shiblon on 18 Jun 2010 at 12:52

[GoogleCodeExporter]

Yes, and it shows nothing. :(

Original comment by merciadr...@gmail.com on 18 Jun 2010 at 1:02

[GoogleCodeExporter]

OK - I'm happy to look at this in greater detail, but unfortunately the log 
entry isn't giving me the information that I need.  If it is possible, can you 
produce and attach a minimal document that has this behavior?  Then I can try 
it on my end and attempt to track it down.

Original comment by shiblon on 18 Jun 2010 at 1:07

[GoogleCodeExporter]

Well, I would like to, but I cannot reproduce this problem. This problem arises 
with a very long preamble, and a very long (> 1000 pg.) document containing lot 
of equations.

Original comment by merciadr...@gmail.com on 18 Jun 2010 at 1:59

[GoogleCodeExporter]

:-/

So, let's see.  Would demoting this to a warning satisfy your needs for now?  
That way it will at least display, but won't keep your document from compiling.

Original comment by shiblon on 23 Jun 2010 at 7:25

[GoogleCodeExporter]

Nice idea. :)

Original comment by merciadr...@gmail.com on 23 Jun 2010 at 7:52

[GoogleCodeExporter]

Demoting this to a warning won't work, since LaTeX itself is barfing on the 
files.  I'll have to find something else to do.  I'm currently downloading a 
tarball of the project to see what I can find.

Meanwhile, some questions that might generate leads:

1) Is Kile using the same "pdflatex" binary as the makefile?  Or is it using an 
alternative installation not in the $PATH?

2) Does this happen every time, or intermittently?

3) If you fully clean things up before building, does it change the behavior?

4) The makefile is really not happy with subdirectories.  Sometimes things work 
okay, but generally speaking, having source files in subdirectories is fraught 
with peril.  Have you tried flattening your directory structure?  That might 
tell us something, too.

Original comment by shiblon on 29 Jun 2010 at 7:35

• Changed title: Corrupted NFSS tables' is written to stdout, but document is correctly produced, and the whole process is normal (i.e. no error) with Kile

[GoogleCodeExporter]

Also, I noticed that you are using 2.1.34, but 2.2.0-rc2 is a much more recent 
(and in many ways completely reworked) version of the Makefile.   Have you 
tried that instead?

Original comment by shiblon on 29 Jun 2010 at 7:36

[GoogleCodeExporter]

1) Kile uses the same PDFLaTeX, but I don't understand why you speak about 
PDFLaTeX, as it is here question of the latex -> dvi2ps -> ps2pdf route. If you 
wanted to speak about these three tools, yes, the sames are shared for Kile and 
the makefile.

2) Every time.

3) No. I tried.

4) I know. But it worked like a charm some days before the bug I encountered 
(happened); I don't know what I changed since then, but that was not that much 
(and not to the preamble). So, this must not be the directories.

5) I'll try it now.

Original comment by merciadr...@gmail.com on 29 Jun 2010 at 7:41

[GoogleCodeExporter]

5) Well, with the most recent Makefile, things do not get better:

==
--- Graphics extension error:
     ! LaTeX Error: Unknown graphics extension: .eps.
--- If you specified the extension explicitly in your .tex file, try removing 
it.

--- Graphics extension error:
     ! LaTeX Error: Unknown graphics extension: .eps.
--- If you specified the extension explicitly in your .tex file, try removing 
it.

--- Graphics extension error:
     ! LaTeX Error: Unknown graphics extension: .eps.
--- If you specified the extension explicitly in your .tex file, try removing 
it.
==

while Kile compiles the whole without any problem (and without such comments in 
the .log). Sorry, I'd have preferred it to be okay. :(

Original comment by merciadr...@gmail.com on 29 Jun 2010 at 7:46

[GoogleCodeExporter]

First, I was actually using 2.1.40 as an `old makefile.'

Second, fresh news. Here you are:

* With 2.1.40, everything now compiles like a charm (don't know why): no error 
as before,
* With 2.2.0-rc2, I get the error of my Comment #16.

Original comment by merciadr...@gmail.com on 29 Jun 2010 at 7:52

[GoogleCodeExporter]

The error message using the latest rc2 of the makefile actually contains the 
solution within it.  Instead of specifying, e.g.,

{_img/kexecboot-0-4-1.eps}

instead, take the extension away and specify it like this:

{_img/kexecboot-0-4-1}

I'm happy that the later version of the old makefile is working for you, and 
I'm confident that the new rc2 version will be good, too.  You'll notice that 
cleaning doesn't work properly for images in subdirectories - not much I can do 
about that, unfortunately, but otherwise you should be fine.

I'm marking this WontFix, but do feel free to reopen it if you still have 
problems.

Original comment by shiblon on 29 Jun 2010 at 8:00

• Changed state: WontFix

[GoogleCodeExporter]

Thanks. But I don't agree for the eps problem. I know that .eps is the default 
extension, and that, once you define a default extension for images, appending 
other extensions (even if these are the same) to the images' calls might cause 
trouble. But, here, I never declared .eps as my default extension. So, why do I 
get these messages? The Makefile might consider .eps as the default extension, 
but that obliges (since the latest rc2) the user not to append .eps extensions 
to images' calls, which is not consistent with the fact that it was not 
necessary in previous releases.

Original comment by merciadr...@gmail.com on 29 Jun 2010 at 8:06

[GoogleCodeExporter]

The move to pdflatex has made this necessary: there's no way to get it to do 
the right thing (from a dependency detection point of view) with specified 
extensions using pdflatex vs. plain old latex.  Therefore, the removal of the 
extension has to stay.  The good news is that not specifying an extension still 
works in both worlds.

In greater detail, the problem is this: if you specify an extension in your 
file, then pdflatex *quits immediately* if that file is not found, even in 
batch mode!  Obviously, this breaks all kinds of auto-generation stuff.  If you 
don't specify the extension, then pdflatex emits an error in the log and moves 
on, which is what the makefile uses to determine which graphics need to be 
built and included.  Removing the extension is the only way to make it do the 
right thing.  I even tried monkeypatching latex to get around this limitation, 
to no avail.

Sorry I can't do much about that - I know it sort of feels ugly, but we're 
running headlong into LaTeX problems here, and I'm very much constrained by the 
underlying toolset.

Original comment by shiblon on 30 Jun 2010 at 1:33

[GoogleCodeExporter]

No problem. :-)

Original comment by merciadr...@gmail.com on 30 Jun 2010 at 3:23