4 ms·

PDF is actually quite well specified, there are not many holes in the specification itself.[0] As to what Adobe Reader will do when it encounters an out-of-spec

by gpvos 8y ago

PDF is actually quite well specified, there are not many holes in the specification itself.[0] As to what Adobe Reader will do when it encounters an out-of-spec file, that is a lot fuzzier. On the other hand, the Office file formats (especially Word) have many un- or underspecified cases. [0] The only one I know of is finding the end of compressed inline image data.

tonyedgecombe 8y ago
I found quite a few areas that were vague when I was working with it. The advantage of the office formats is they are Zip files with a ton of XML, ie they are well defined. The application parts are another matter of course.
- BlackFingolfin 8y ago
  Just because something is XML doesn't mean it is "well-defined".
  - tonyedgecombe 8y ago
    No, but XML parsing is a solved problem, PDF parsing isn't.
    - tinus_hn 8y ago
      The original criticism was that some parts are just binary blobs encoded in XML elements, which wouldn’t suprise me at all, with Microsoft being allowed to tick the ‘XML file format’ checkbox and still getting to keep the binary format advantages.
- gpvos 8y ago
  I see. I was mostly referring to semantic problems, of which I heard there are a lot (I haven't really worked with Office internals much), and also I was thinking of the pre-XML Office formats.
hnick 8y ago
I agree, the PDF spec is great, and very easy to understand (if slow to wade through). The hardest parts are when you have to duck out to read another spec for a contained format like TrueType. Regarding Reader, I work with PDFs a lot, and the majority of issues have a fairly common pattern. The supplier has created a PDF in a 3rd party tool, which is invalid in a subtle way (production printers in particular are very specific about what they want to accept). But it works fine in Adobe Reader, since it was built to be very tolerant in what it accepts, so it's often hard to convince the non-technical users that the file has an issue. It's great for end users but has meant that a lot of tools out there just didn't have to try too hard to make PDFs that mostly work, so programming workflows can be an issue.

by gpvos 8y ago

tonyedgecombe 8y ago

I found quite a few areas that were vague when I was working with it. The advantage of the office formats is they are Zip files with a ton of XML, ie they are well defined. The application parts are another matter of course.

BlackFingolfin 8y ago
Just because something is XML doesn't mean it is "well-defined".
- tonyedgecombe 8y ago
  No, but XML parsing is a solved problem, PDF parsing isn't.
  - tinus_hn 8y ago
    The original criticism was that some parts are just binary blobs encoded in XML elements, which wouldn’t suprise me at all, with Microsoft being allowed to tick the ‘XML file format’ checkbox and still getting to keep the binary format advantages.
gpvos 8y ago
I see. I was mostly referring to semantic problems, of which I heard there are a lot (I haven't really worked with Office internals much), and also I was thinking of the pre-XML Office formats.

hnick 8y ago

I agree, the PDF spec is great, and very easy to understand (if slow to wade through). The hardest parts are when you have to duck out to read another spec for a contained format like TrueType. Regarding Reader, I work with PDFs a lot, and the majority of issues have a fairly common pattern. The supplier has created a PDF in a 3rd party tool, which is invalid in a subtle way (production printers in particular are very specific about what they want to accept). But it works fine in Adobe Reader, since it was built to be very tolerant in what it accepts, so it's often hard to convince the non-technical users that the file has an issue. It's great for end users but has meant that a lot of tools out there just didn't have to try too hard to make PDFs that mostly work, so programming workflows can be an issue.