| <<<Back 1 day (to 2020/09/01) | Fwd 1 day (to 2020/09/03) >>> | 20200902 |
myopia | should a conforming (let's say 1.7) PDF terminates with string (in PDF string notation) (%%EOF) or (%%EOF\n) or (%%EOF\r\n)? | 11:26.03 |
| unix text files would terminate with (\n) but then, PDF is a mixed bag | 11:27.08 |
ator | myopia: from pdfref17: "Acrobat viewers require only that the %%EOF marker appear somewhere within the last 1024 bytes of the file." | 11:34.10 |
| the spec says "last line" | 11:34.23 |
| line endings in PDF can be either \n, \r, or \r\n (except for in a few special places where \r is forbidden since it's ambiguous) | 11:34.56 |
| like after the "stream" keyword, it must be either \n or \r\n, but NOT \r | 11:35.19 |
| which, admittedly, there is a lot of software generating PDFs that get wrong | 11:35.49 |
| I would use (%%EOF\n) if you want a the most robust file | 11:36.58 |
| don't use \r and don't use \r\n (but take care when writing the xref subsections -- those are 20 byte fixed length records and need padding if using \n) | 11:38.18 |
myopia | yes, these are present in the appendix H of pdfref17 | 14:54.02 |
| I can find no trace of these in ISO 32000-1:2008 though | 15:00.26 |
ator | myopia: yes, the ISO "helpfully" removed all the references to implementation limits and compatibility | 15:18.28 |
| unless you need pdf 2.0 features, stick to the pdf 1.7 reference manual. it's much more readable. | 15:18.49 |
myopia | ISO 32000-1:2008 also contain these words in 7.5.6 Incremental Updates (or 3.4.5 Incremental Updates for ref17): "The contents of a PDF file can be updated incrementally without rewriting the entire file. When updating a PDF file incrementally, changes shall be *appended* to the end of the file, leaving its original contents intact." and since LF is but one of the whitespace characters, this seems to offer more support for (in PDF string notation) | 15:20.42 |
| (%%EOF) over others | 15:20.42 |
| but then, 3.1.2 Comments (ref17) says "a comment separates the token preceding it from the one following it", this would lean towards the EOF plus line termination | 15:37.44 |
| the second sentence of the paragraph also implies the presence of line termination for every comment | 15:39.30 |
| so, I think I end up favoring (in PDF string notation) (%%EOF\r\n). the CRLF part is to avoid having to pad a preceding space for xref and "modern" protocols like http mandate CRLF | 15:41.36 |
ator | yes. %%EOF without a newline would not be good since a comment token ends with a newline | 16:18.20 |
| <<<Back 1 day (to 2020/09/01) | Forward 1 day (to 2020/09/03)>>> | |