15_EventMaxiumSpeed_Qualifying.PDF can't be loaded because of overly strict startxref parsing

[jrmuizel]

Loading http://spasummerclassic.alkamelsystems.com/Results/03_2021/01_Spa%20Summer%20Classic/320_Spa%203%20Hours/202106251945_Qualifying/15_EventMaxiumSpeed_Qualifying.PDF
gives Error: Custom { kind: Other, error: "Invalid cross-reference table (invalid start value)" }

[jrmuizel]

Other pdf parsers seem to accept any amount of whitespace and not just a newline.
https://github.com/mozilla/pdf.js/blob/0676ea19cf17023ec8c2d6ad69a859c345c01dc1/src/core/document.js#L994
https://gitlab.freedesktop.org/poppler/poppler/-/blob/e23bd900b7c5f3262c3b6c5fb20d7569ca5193db/poppler/PDFDoc.cc?page=3#L2091

[jrmuizel]

https://github.com/ArtifexSoftware/mupdf/blob/1d58f734a2a0302d9e3b7406509a30f587ada791/source/pdf/pdf-xref.c#L964

[Heinenen]

The code that creates this error is

lopdf/src/reader.rs

Line 436 in ba237d1

None => Err(Error::Xref(XrefError::Start)),

or rather

lopdf/src/nom_parser.rs

Lines 452 to 458 in ba237d1

	pub fn xref_start(input: &[u8]) -> Option<i64> {
	strip_nom(delimited(
	pair(tag(b"startxref"), eol),
	integer,
	tuple((eol, tag(b"%%EOF"), space)),
	)(input))
	}

It only accepts EOL markers (\n, \r\n or \r), whereas the file has \n.

The relevant part of the spec is:

[..] The last line of the file shall contain
only the end-of-file marker, %%EOF. The two preceding lines shall contain, one per line and in order,
the keyword startxref and the byte offset in the decoded stream from the beginning of the PDF file to
the beginning of the xref keyword in the last cross-reference section. The startxref line shall be
preceded by the trailer dictionary [..]

The spec IMO isn't perfectly accurate here, but I understand it that lopdf follows the spec in this regard (feel free to disagree).
Note, that most PDF processors try to salvage as much as they can from PDFs, even if they are not strictly spec compliant. Implementing something like proposed in #41 would help solve this issue.

Even if this would be solved with #41, this issue should still stay opened as a reminder of what exactly needs to be addressed in #41.

[jrmuizel]

I filed an issue with the spec.

[vcsmarts]

+1
It seems also that the code looks for the marker within the last 512 bytes. For one of the pdf files i have here, it would have to be within the last 35416809 bytes.

https://github.com/J-F-Liu/lopdf/blob/main/src/reader.rs#L429-L431