your bit of inscrutable computer hatred for the day

[zwol]

  5 0 obj
  <</Length 6 0 R/Filter /FlateDecode>>
  stream
  ...
  endstream
  endobj
  6 0 obj
  3413
  endobj

STOP DOING THIS. ALL OF YOU.

Comments

ieeee!

[tkil.livejournal.com]

That's somewhere between recommended and required. *gibber* (See example 3.1 in the 5th PDF spec)

Nothin' like hatin' on the PDF on a fine Monday evening, neh?

Re: ieeee!

[zwol.livejournal.com]

You had to make me go look...

I read that as "If you're too damn lazy to buffer the stream contents in memory or a temp file so you can find out how long it is, you can use this awful workaround instead." Note the note on the preceding page assuring you that a direct object is always allowed unless it specifically says it isn't.

I'm more hatin' on lazy PDF generator authors than on PDF itself right now. This was just the short example that everybody and their duck is guilty of.

Re: ieeee!

[tkil.livejournal.com]

You had to make me go look...

Heh. Sorry about that.

And I agree with your interpretation... but the point remains that this exact technique is discussed in the spec -- maybe not blessed, but since they mention it and not the concept of temp files, well.

Finally, there's the awkward but usable workaround of looking at the object index so that you can find objects like the length without having to go through the entire file twice. :(

Ah, it's been too long since I've gone swimming in the dark pools of PDF and PS...

Re: ieeee!

[zwol.livejournal.com]

I agree with your interpretation... but the point remains that this exact technique is discussed in the spec -- maybe not blessed, but since they mention it and not the concept of temp files, well.

Thinking about it a bit more, at root I am hatin' on PDF: Adobe went to some length to make it possible to write PDF in one linear forward pass. This was stupid and wrong, because (a) it's more important to optimize for PDF consumers, not generators; (b) even when PDF first came out, computers had enough memory and CPU grunt that buffering, say, page objects in memory would not have been a problem; (c) the spec could have been substantially simpler that way. [I think I would still put the index at the end, because incremental update by appending to the file is actually a useful feature. However, I would rearrange things so that the capability of doing that incremental update does not extend grubby tentacles all over the original document, dammit.]

Finally, there's the awkward but usable workaround of looking at the object index so that you can find objects like the length without having to go through the entire file twice. :(

One might get the misapprehension, looking at e.g. ghostscript's "pdfwrite" output, that this is what the object index is for, rather than, say, only having to read in the bits associated with a particular page.

And of course this tactic does the poor human, who's trying to figure out just what inkscape's buggy PDF generator did wrong, no good at all.