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: Fri, 18 Jul 2003 10:24:56 -0700
For future reference, you can gather your chunks into PDF documents and
draw the same PDF document over and over. The printing system will
only embed a given PDF document once provided you pass the same
CGPDFDocumentRef into CGContextDrawPDFDocument. That gives you the
ability to control both image embedding and larger chunk embedding to
minimize your output PDF size.
Dave
On Friday, July 18, 2003, at 5:59 AM, Robert Clair wrote:
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.
This is a nice theory, but...
depends on what you mean by "same"
in my app each group of stampings of a given bitmap is held in a
single object. The data for the object are one copy of the bitmap
(NSImage) and a list of positions, rotations and scalings. The
object's draw method does essentially:
loop over points
save context
build matrix
concat
draw bitmap
restore context
end loop
I get the previously described ugly behavior.
As far as delving into the CG layer - maybe later, for now my banding
is finished and seems to work well.
But this is a deeper problem - in addition to the instancing of the
bitmaps,
I use instancing at a coarser grain - entire chunks of the design
(bitmap
stampings and vector drawing) may be instanced and drawn at various
places. What is needed is some way of specifying that this entire
chunk needs to wind up as a Xobject or whatever it is pdf calls it.
(With any contained group of stampings have their own instancing
setup.)
Hence, do it yourself PostScript. I wouldn't start trying to generate
my own pdf but PS is another story (human readable and I once knew how
to write in it).
The app is well organized for this - the displaylist has a "drawMe"
method
which calls each child object's "drawMe" method, etc. The similarity
of the imaging model between Quartz and PS makes it fairly
straight-forward and I have only a few kinds of objects and no text.
One could even add a
category to NSBezierPath to generate the corresponding ASCII PS
instructions .
The catch: The obvious thing is to make each large scale instance a
PS function which gets sent to the RIP and then called to draw where
ever.
The last time I wrote an app like this, the users enthusiastically
made designs so large that they exceeded the memory of the hardware
RIP. What I would like is one of those things that are formally part
of the PS language but have
those little footnotes that say "not all RIPS will have this": the
ability
to do "setfilepos" on the input stream or open an auxiliary file. I
think
GhostScript allows this, I have no idea about the current state of
hardware RIPS.
Thanks for all the comments.
.....Bob Clair
Just came back from the Mac show in NY. My impression from lurking
in the Epson and HP booths is that for the really large printers (30"
role
paper, etc) Postscript and not pdf is what is being used.
-----------------------------------------------------------------------
------------------
_______________________________________________
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.