Closed GoogleCodeExporter closed 9 years ago
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
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:
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:
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
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
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
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
Yes, and it shows nothing. :(
Original comment by merciadr...@gmail.com
on 18 Jun 2010 at 1:02
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
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
:-/
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
Nice idea. :)
Original comment by merciadr...@gmail.com
on 23 Jun 2010 at 7:52
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
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
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
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
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
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
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
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
No problem. :-)
Original comment by merciadr...@gmail.com
on 30 Jun 2010 at 3:23
Original issue reported on code.google.com by
merciadr...@gmail.com
on 14 May 2010 at 4:35