Closed kmccurley closed 1 year ago
I'm nearing completion on a latex log parser that is able to keep track of errors that appear in the logs. This addresses the issue that the latex log doesn't make it clear what file was the source of an error. It will require using pfdlatex -recorder (or lualatex -recorder).
I've now addressed this in the code, with a new LatexLogParser
and new CompileError
entries in the Compilation
data structure.
class CompileError(BaseModel):
error_type: ErrorType = Field(...,
title='type of error',
description='This tells you which fields should be populated')
text: str = Field(...,
title = 'Description of problem',
description = 'Textual description of problem for author. A required field.')
logline: int = Field(...,
title='Line in log where it occurs',
description='This is the start of where the error occurs, but there may be lines after it.')
package: str = Field(None,
title='LaTeX package name',
description='Populated when we find it. Not required')
pageno: int = Field(0,
title = 'Page number in PDF',
description = 'Page number where problem appears. May required.')
pdf_line: int = Field(0,
title = 'Line number in PDF',
description = 'Line number in copyedit version. Not required.')
filepath: str = Field(None,
title='path to LaTeX file',
description = 'Location of LaTeX error or warning. Not required.')
filepath_line: int = Field(0,
title = 'Line number location for LaTeX warning',
description = 'Line number in filepath where LaTeX warning occurred. Not required.')
severity: float = Field(0,
title='Severity of overfull or underfull hbox or vbox.',
description='For overfull boxes, it is the size in pts. For underfull boxes it is badness.')
help: str = Field(None,
title='Help for authors',
description='The parser may have more to say about an error')
The web UI for authors now shows a much better list of errors and warnings, with the ability to click on things to see where the problem occurred in the log, the source files, and the PDF (sort of). Only a copy editor would indicate the PDF line number.
There are a few caveats:
I'm now satisfied that we've addressed the basic issue, though there is always opportunity to improve it in the future.
One of the miserable things about LaTeX is the awful state of logs. In the paper by Nigel, I saw:
It's not at all obvious from reading the logs what file is referred to in the
line 16
, because you have to go back in the log to see a linethat wasn't closed by another
)
, because this is how LaTeX logs show which files are open. Moreover, lines are wrapped at 79 columns. This makes it hard for humans to parse, and also difficult for a program to parse because the ) character can occur inside another warning message.There are several reasons for wanting better logs
I've discovered several approaches to this:
-file-line-error
on pdflatex, then when it encounters a fatal error, it will print the current file and line number. This is convenient and easy, so we should do it. There is unfortunately nothing comparable for warnings.\PackageWarning
and we can trap these using the new hook mechanism. The following accomplishes this by patching the\PackageWarning
macro:This produces useful things about the current file where
\PackageWarning
was called. This turnsinto
Package amsfonts Warning: Obsolete command \bold; \mathbf should be used instea d on input line 56.