literal \) and some\n newlines.\n)`.
* interpreted as hexadecimal data when enclosed in angled brackets:
`<53 61 6D 70 6C 65>` equals `(Sample)`.
+
Names
: starting with a forward slash, like `/Type`. You can think of them like
identifiers in programming languages.
This is just the magic string declaring the document as PDF-1.4, and the root
object with object number 1, which references objects number 2 for Outlines and
-number 3 for pages. We're not interested in outlines, let's look at the pages.
+number 3 for Pages. We're not interested in outlines, let's look at the pages.
[[!format pdf <<EOF
3 0 obj
/BPC 8
/F /FlateDecode
ID
-x\9c$¼[\8b$;¾åù!\ 6f\9eú¥\87¡a\1e\ 6æátq.4§
-% [ ...byte stream shortened... ]
+x$¼[$;¾åù!fú¥¡aæátq.4§ [ ...byte stream shortened... ]
EI
Q
endstream
EOF]]
So now we know why the PDF was so huge: the line `/F /FlateDecode` tells us that
-the image ata is stored losslessly with [Deflate][] compression (this is
+the image data is stored losslessly with [Deflate][] compression (this is
basically what PNG uses). However, scanned images, as well as photographed
pictures, have the tendency to become very big when stored losslessly, due to te
fact that image sensors always add noise from the universe and lossless
multi-page documents, if possible. With PDF as output format, this results in
one input file per page.
-[man-converted]: http://manpages.debian.net/cgi-bin/man.cgi?query=convert "man convert(1)"
+[man-convert]: http://manpages.debian.net/cgi-bin/man.cgi?query=convert "man convert(1)"
The embedded image objects looked somewhat like the following:
$ convert image*jpg document.pdf
(The first command creates the output files `image-1.jpg`, `image-2.jpg`, etc.,
-since JPG does nut support multiple pages in one file.)
+since JPG does not support multiple pages in one file.)
When looking at the PDF, we see that we now have DCT-compressed images inside
the PDF: