Possible startxrefPreg extension

[xBambey]

Some PDFs in a project could not be read by the parser.

After a closer examination of the binary data, it was noticed that there is often a space before the reference byte.

After a brief search on the Internet, I could not find any information as to whether this space may be included or not. Perhaps someone here who is more familiar with the subject knows more.

By inserting an optional space in the RegEx at this point, the PDF is recognized again.

RegEx would then look like the following:

'/(?<=[\r\n])startxref[\s]*[\r\n]+[\s]*([0-9]+)[\s]*[\r\n]+%%EOF/i'

pdfparser/src/Smalot/PdfParser/RawData/RawDataParser.php

Lines 884 to 891 in f44ada0

	// Find all startxref tables from this $offset forward
	$startxrefPreg = preg_match_all(
	'/(?<=[\r\n])startxref[\s]*[\r\n]+([0-9]+)[\s]*[\r\n]+%%EOF/i',
	$pdfData,
	$startxrefMatches,
	\PREG_SET_ORDER,
	$offset
	);

[unixnut]

Other files can cause the Uncaught Exception: Unable to find startxref error too.

getXrefData() uses a regex that requires a newline before the offset value. This means that some PDF files (e.g. containing "startxref 1746580") won't parse.

Example PDF details seen in production:
Creator: DocuPrint CM225/228
PDF version: 1.7

A different example will be attached soon.

A combination of my working fix for the problem mentioned in this comment, plus the one above, is:
'/(?<=[\r\n])startxref(?:[\s]*[\r\n]+[\s]*|\s+)([0-9]+)[\s]*[\r\n]+%%EOF/i'

[xBambey]

I also had other cases that caused problems.
Yesterday I had the case that everything was in one line.

My current solution to the problem is

'/(?<=[\r\n])startxref[\s\r\n]+([0-9]+)[\s\r\n]+%%EOF/i'

I am currently not aware of any case where the final values (startxref checksum %%EOF) ​​are in the same line as other information.
The beginning might have to be expanded to include a possible space instead of a new line.

[k00ni]

@xBambey @unixnut Feel free to create a pull request and start a discussion if you think its worth to change the related code.

[unixnut]

My current solution to the problem is

'/(?<=[\r\n])startxref[\s\r\n]+([0-9]+)[\s\r\n]+%%EOF/i'

This seems too general to me, e.g. allows multiple newlines between startxref statement and offset. Also would allow the eof token on the same line as the offset.

@xBambey what did you think of my regex that allows for either newlines or spaces, plus optional leading/trailing spaces around the offset?

[xBambey]

@unixnut your regex looks good. I kept my solution as general as possible because I don't want to keep making further adjustments.

Therefore there is also the possibility that the eof token can be on the same line as the offset.

I know that this doesn't normally happen, but there is the extremely rare case in whis a generation in the last functions of the PDF can throw an error, which cout actually cause this to happen.

[unixnut]

I think the startxref statement and the eof marker are always produced together and it's safer to look for the eof marker on a new line.

Because this is a design decision that is related to a specification I haven't read, can we get @k00ni to make the call on which regex shall be used in the PR?

[k00ni]

Because this is a design decision that is related to a specification I haven't read, can we get @k00ni to make the call on which regex shall be used in the PR?

To be honest, I lack the knowledge to make this call. Could one of you outline again pro's and con's of each approach in a short manner? This might help moving to a decision.

[unixnut]

@Chandlr This looks like a separate issue. Please open a new ticket and include the stack trace that caused your HTTP 500 error, then delete your comment here. Thanks.