So, I knocked together a quick Perl script (as one does) to generate a PDF file containing an unusual sort of grid:

In the source I was working from, the polygon was 2x7, so I used PDF::API2 to scale the coordinate system and draw one at 0,0, and then wrote a little loop that translated the origin around the page and drew the same poly all over the place. The resulting PDF is 1,642 bytes.

For comparison, the GIF up there is 5 times larger than the PDF file, and that’s after optimizing it down to 4 colors.

But I thought to myself, “self, you’ve got a gajillion wasted savestate/transform/restorestate operations in there; you should just calculate the locations of each poly and plug the numbers in directly.”

Self can be a bit of a dick, but sometimes he’s right. This time, not so much, because whatever trivial performance gain I might get by avoiding PDF’s highly-optimized state and transform operations turns out to be completely swamped by the 25x increase in file size.

And that’s just on US letter paper; render it on 11x17, and it’s up to 36x. Why? Because in the lazy, naive version of the script, the largest number used in the loop is the integer 7, and itty-bitty integers can be packed in good and tight.

By the way, the code is so simple-minded that it draws the wide grid line at 0,0 and then translates up the page, making it upside-down. So I added a line at the start that transforms the origin to the upper right corner and rotates the page -180 degrees. This added 13 bytes to the output, which I don’t feel the need to optimize out by drawing rightside up. 😁

Update

Rewriting the code to draw every line segment exactly once shaved a whole 87 bytes off of the file size, but cost about twenty minutes of sketching out grid components (5) on a piece of paper and then re-writing the loops.

Comments via Isso

Markdown formatting and simple HTML accepted.

Sometimes you have to double-click to enter text in the form (interaction between Isso and Bootstrap?). Tab is more reliable.