Log of #ghostscript at irc.freenode.net.

 <<<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 bag11: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 \r11:35.19 
  which, admittedly, there is a lot of software generating PDFs that get wrong11:35.49 
  I would use (%%EOF\n) if you want a the most robust file11: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 pdfref1714:54.02 
  I can find no trace of these in ISO 32000-1:2008 though15:00.26 
ator myopia: yes, the ISO "helpfully" removed all the references to implementation limits and compatibility15: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 others15: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 termination15:37.44 
  the second sentence of the paragraph also implies the presence of line termination for every comment15: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 CRLF15:41.36 
ator yes. %%EOF without a newline would not be good since a comment token ends with a newline16:18.20 
 <<<Back 1 day (to 2020/09/01)Forward 1 day (to 2020/09/03)>>> 
ghostscript.com #mupdf