3 ms·

Fun experiment alexwlchan! Two small mistakes in your post: you write "15,000,000,000.00 in" and "that the size of a page is 15 billion inches", but it should b

by mrb 3y ago

Fun experiment alexwlchan! Two small mistakes in your post: you write "15,000,000,000.00 in" and "that the size of a page is 15 billion inches", but it should be 15 million. You said you had difficulty formatting text. Here is a "hello world" pdf that just has these two words on a page: copy and paste this text (stripping leading spaces on each line) and save it in a .pdf file. Basically in order to write text you have to define a font (object 5) and then a stream with a Tf command to use the font, a Td command to position the text, and a Tj command to write it. %PDF-1.2 1 0 obj << /Type /Catalog /Pages 2 0 R >> endobj 2 0 obj << /Type /Pages /Kids [ 3 0 R ] /Count 1 /MediaBox [ 0 0 612 792 ] >> endobj 3 0 obj << /Type /Page /Parent 2 0 R /Resources 4 0 R /Contents 6 0 R >> endobj 4 0 obj << /ProcSet[/PDF/Text] /Font << /F1 5 0 R >> >> endobj 5 0 obj << /Type /Font /Subtype /Type1 /BaseFont /Times-Roman >> endobj 6 0 obj << /Length 52 >> stream BT /F1 48 Tf 185 400 Td (Hello World)Tj ET endstream endobj trailer << /Root 1 0 R >>

puck 3y ago
> Please don’t try to print it. How will I know if I can fold it more than 7 times, though?
whartung 3y ago
Is the xref at the end of a PDF required or not? Seems like it is in the spec.
- mrb 3y ago
  It is required according to the standard. But in practice most PDF viewers don't care. They may complain the PDF is "damaged" or "no valid xref was found", but they will render it perfectly fine.
- jchw 3y ago
  By the spec, yes. Some PDF readers will parse it anyway, some will not. In my experience depending on the renderer the xref table can be varying degrees of malformed before things go wrong. Edge's old PDF reader (the one before Acrobat and after PDFium) for example seemed to tolerate just about anything, falling back to the latest version of objects if the xref table was broken. There's also other mistakes you can make, like for example, the xref table requires carriage returns (each entry in the table is supposed to be an exact number of bytes) but some PDF readers will still interpret the xref table even if the carriage returns are missing.
  - whartung 3y ago
    As I understand it, the xref entries don’t require a carriage return, but they require a fixed line length. If you don’t want to use a CR, you can pad with a space. So CR/LF, space/LF, and space/CR are all valid endings.
    - jchw 3y ago
      Yep:[1] > The byte offset in the decoded stream shall be a 10-digit number, padded with leading zeros if necessary, giving the number of bytes from the beginning of the file to the beginning of the object. It shall be separated from the generation number by a single SPACE. The generation number shall be a 5-digit number, also padded with leading zeros if necessary. Following the generation number shall be a single SPACE, the keyword n, and a 2-character end-of-line sequence consisting of one of the following: SP CR, SP LF, or CR LF. Thus, the overall length of the entry shall always be exactly 20 bytes This is interesting. Never actually saw anything other than CRLF in practice, even inside of PDF files that otherwise were LF-only. [1]: https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008.pdf https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandard... page 41
wodenokoto 3y ago
> "15,000,000,000.00 in" and "that the size of a page is 15 billion inches", but it should be 15 million. Can you help me count zeroes? Why is it million and not billion?
- jetrink 3y ago
  The numerical and word versions are equal, but they're both wrong. 15 billion inches is to the distance from the Earth to the Moon.
- croes 3y ago
  >If we crank it all the way up to the maximum of UserUnit 75000, Acrobat now reports the size of our page as 15,000,000,000.00 x 15,000,000,000.00 in – 381 km along both sides, matching the original claim. If you’re curious, you can download the PDF. 15 billion inches are 381,000km. The original claim is the limit is 15 million inches.
- mrb 3y ago
  He put too many zeroes. It should be "15,000,000.00 in" or 15 million.
alexwlchan 3y ago
Argh! I knew I was going to make a numerical mistake somewhere, thanks for spotting it. Correction will be up shortly. Thanks for spotting it! :D And thanks for the text example! This looks like what I was trying, but clearly I had a mistake somewhere.
- dingensundso 3y ago
  Spotted another math mistake: > The default unit size is 1/72 inch, so the page is 300 × 72 = 4.17 inches.

by mrb 3y ago

puck 3y ago

> Please don’t try to print it. How will I know if I can fold it more than 7 times, though?

whartung 3y ago

Is the xref at the end of a PDF required or not? Seems like it is in the spec.

mrb 3y ago
It is required according to the standard. But in practice most PDF viewers don't care. They may complain the PDF is "damaged" or "no valid xref was found", but they will render it perfectly fine.
jchw 3y ago
By the spec, yes. Some PDF readers will parse it anyway, some will not. In my experience depending on the renderer the xref table can be varying degrees of malformed before things go wrong. Edge's old PDF reader (the one before Acrobat and after PDFium) for example seemed to tolerate just about anything, falling back to the latest version of objects if the xref table was broken. There's also other mistakes you can make, like for example, the xref table requires carriage returns (each entry in the table is supposed to be an exact number of bytes) but some PDF readers will still interpret the xref table even if the carriage returns are missing.
- whartung 3y ago
  As I understand it, the xref entries don’t require a carriage return, but they require a fixed line length. If you don’t want to use a CR, you can pad with a space. So CR/LF, space/LF, and space/CR are all valid endings.
  - jchw 3y ago
    Yep:[1] > The byte offset in the decoded stream shall be a 10-digit number, padded with leading zeros if necessary, giving the number of bytes from the beginning of the file to the beginning of the object. It shall be separated from the generation number by a single SPACE. The generation number shall be a 5-digit number, also padded with leading zeros if necessary. Following the generation number shall be a single SPACE, the keyword n, and a 2-character end-of-line sequence consisting of one of the following: SP CR, SP LF, or CR LF. Thus, the overall length of the entry shall always be exactly 20 bytes This is interesting. Never actually saw anything other than CRLF in practice, even inside of PDF files that otherwise were LF-only. [1]: https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008.pdf https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandard... page 41

wodenokoto 3y ago

> "15,000,000,000.00 in" and "that the size of a page is 15 billion inches", but it should be 15 million. Can you help me count zeroes? Why is it million and not billion?

jetrink 3y ago
The numerical and word versions are equal, but they're both wrong. 15 billion inches is to the distance from the Earth to the Moon.
croes 3y ago
>If we crank it all the way up to the maximum of UserUnit 75000, Acrobat now reports the size of our page as 15,000,000,000.00 x 15,000,000,000.00 in – 381 km along both sides, matching the original claim. If you’re curious, you can download the PDF. 15 billion inches are 381,000km. The original claim is the limit is 15 million inches.
mrb 3y ago
He put too many zeroes. It should be "15,000,000.00 in" or 15 million.

alexwlchan 3y ago

Argh! I knew I was going to make a numerical mistake somewhere, thanks for spotting it. Correction will be up shortly. Thanks for spotting it! :D And thanks for the text example! This looks like what I was trying, but clearly I had a mistake somewhere.

dingensundso 3y ago
Spotted another math mistake: > The default unit size is 1/72 inch, so the page is 300 × 72 = 4.17 inches.