PDF Metadata not properly encoded about one-file-pdf HOT 5 CLOSED

Thank you very much! I have now added it. Could you share the code you used to catch this? It could be used to create some unit tests, as there are none now and PDFs are finicky.

from one-file-pdf.

Also, observe the block below. It looks wrong: writing another /Info after the trailer. I'm going to dust off the PDF_Reference.pdf, and check the specs.

	// write the trailer
	pdf.write("trailer\n<</Size %d/Root 1 0 R", len(pdf.objOffsets))
	if infoIndex > 0 {
		pdf.write("/Info %d 0 R", infoIndex)
	}

from one-file-pdf.

Yeah, I don't know how the "trailer" works but I took it to be a "Table of Contents" referring back to the /Type/Info object.

I am just doing simple ad-hoc testing. An automated test for a PDF generator will likely require a PDF parser.

A simpler alternative (no full parser) would be a test app designed to utilize all the generator's options, paired with simple grep based checking for the right strings in the output. This bug could have been caught by utilize pdf.SetDocTitle, then grep'ing the output for "/Type/Info/Title", right?

from one-file-pdf.

I'll look into writing some tests, starting with the metadata. For tests, I'm thinking of disabling compression so the PDF will just be a long string, then strip all whitespaces from both the check and the generated strings. Then just compare the two. It could be a brittle test, but not too much to worry. Just a matter of figuring the right expected PDF layout first.

from one-file-pdf.

I checked some specs. The /Info I mentioned is part of the trailer, along with /Size and /Root, so It's OK for it to be there. It's just an index in the trailer to locate the info.

from one-file-pdf.