Re: Ridiculously Enormous PDFs and Printing
Re: Ridiculously Enormous PDFs and Printing
- Subject: Re: Ridiculously Enormous PDFs and Printing
- From: David Hill <email@hidden>
- Date: Thu, 17 Jul 2003 08:45:58 -0700
This is a common problem and even several Apple apps have run into it.
For documents that reuse the same image multiple times, it is important
to give the printing system a clue that the image is the same.
At the CG layer, the printing system knows that if you hand it the same
CGImageRef over and over, you're asking it to draw the same content and
so the resulting PDF spool file will only contain one copy of the image
with multiple references to it.
Note that this has several implications:
1. CGImageRefs are immutable after creation. If you reuse the same
CGImageRef but somehow change the content, we won't know and you'll get
weird results when printing.
2. If you hand us different CGImageRefs, we'll write the contents of
each one in the PDF spool file. You really don't want us comparing the
bits of each image to see if it is really the same as one you've used
before. The end result is an unnecessarily large spool file.
3. This is different than drawing to the screen where we don't have to
worry about PDF file size. We also currently pick up any change to the
contents of a CGImageRef but *don't* rely on that behavior since we
reserve the right to cache the contents of the CGImageRef and reuse
them if you pass in the same ref over and over.
So, how does all of this apply in your case when you're using NSImage?
In theory (I haven't checked the code myself), NSImage is based on
CGImage and you should see the same behavior for NSImage that you would
with CGImage. I.E. if you want the same image drawn in multiple places
but you only want one copy to appear in the spool file, use the same
unmodified NSImage over and over. We should do the right thing down in
the printing system to make sure the image only appears once in the PDF
spool file.
If you see some other behavior, file a bug.
Note that it may be possible to trick the printing system if you send
us the same NSImage but you've somehow swapped out or changed the
bitmap image rep, etc. This could potentially lead to strange bugs
like seeing the first or last of a set of images replicated multiple
times when you expected different images.
I hope that helps.
Dave
On Thursday, July 17, 2003, at 7:07 AM, Robert Clair wrote:
Thanks to all who reminded me of libtiff. I'd gotten so used to Cocoa
doing everything that I'd forgotten about it.
In the course of the discussion I was asked why I'd want to do such
a thing (make printer resolution tiffs) instead of letting the printing
architecture worry about it. The original reasons were allowing the
user to take the image into Photoshop and to be able to drive oddball
output devices that don't have RIPs. I'm not entirely certain of
the current state of the art, but at least some older model laser
engravers
work of off tiff.
Now let me add another reason for doing your own rasterizing. The
printing
architecture makes really BIG pdfs as spool files. This is a well known
complaint, but it can veer towards insanity in certain situations:
I have an application that does a lot of instancing - essentially the
user can stamp little bits of hi-res bitmap around at various
positions,
scales and orientations. Of course I only keep one copy of each bitmap
and draw it where ever it is required. The problem comes when you
print -
the printing architecture makes 1 copy of the bitmap each time you
draw it.
It doesn't know from Form Xobjects or anything like that.
This can lead to absurd situations - I have one test file whose spool
file
was heading past 4 Gig when I killed it, three hours into the process.
From
previous experiments it would have taken days to print on my dumpy
little
HP 842C. This for a design that stores in about 5 Meg in the app's
file format
and draws on the screen in less than a second.
I wrote some code to rasterize and band myself - when printing the
drawRect renders the display list, in bands, into an NSImage and then
draws the bands as the output. It does have the disadvantage that you
must inquire (or guess) for the printer resolution, but the results are
dramatic: the same file took 2 minutes to make a 3 Meg spool file and
printed in 3 minutes. (300dpi, letter size)
This takes care of printing - I guess for the general idea of handing
a resolution independent pdf to someone I'll generate my own (smarter
than default) Postscript and see what's available in terms of
intelligent
PS->pdf conversion.
.....Bob Clair
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.