I always hate that idea too, say the author of the application doesn't update the software for a while - the 100MB issue will not be a issue forever - with more powerful computers being inevitable - yet so much software like this posing illogical restrictions - its like the Y2K shortsightedness all over again.

p.s. Its cool to see a science/technology guy not afraid to openly reveal what he believes. I really enjoyed reading your 'Why "Hacking for Christ"?' post, especially - "I see it simply as sensible code reuse"

mmm, OpenStreetMap is so much fun, especially when you can correct the map of your area. I'm glad I don't have a gps device, or I probably would be addicted. Have you gotten into the mapping yet?

The obvious technical response to the code is that it should subdivide the rendering into smaller chunks, and stitch them back together later. In fact, the stitching is really easy if you divide the area not with a grid, but into horizontal slices, since you have to write the rows of image data into the image file in the same order that they exist in your buffer. Just figure out how many rows will fit in the buffer, partition the vector data by the same amount and just render each partition in turn, writing the buffer to the file and recreating it after each one.

In the end I recompiled it from the source package and changed the number to 1Gb. But it was dog slow, although it did complete eventually. Now I just need an image viewer that can open a 1.3GB file; the GIMP, again, is very slow although it does manage it eventually.

Gerv

Why can't your Firefox just render the SVG directly ?

Mentioned it on #inkscape

stelt: it can, but (at least in Firefox 2 on Linux) it's both ugly and slow. Also, I want a nice high-res map for printing; Firefox scales the SVG to fit the window.