PDFDocuments and CGPDFDocuments

  • Hi everyone, I seem to have run into a little snag recenlty.  I have
    an application that manipulates PDF files (scaling, imposition,
    transforms...).  I am using a PDFView for the interface but performing
    all of the transformations in Quartz.  I find myself shuttling data
    back and forth by using
    CGDataProviderCreateWithCFData((CFDataRef)[pdfDocument
    dataRepresentation]
    before the transformation and
    [[[PDFDocument alloc] initWithData:(NSData *)cgPDFAsMutableData]
    autorelease]
    after to display in the PDFView.

    I'm getting bottlenecks for larger files in the calls to [document
    dataRepresentation].  I think there has to be either a better way of
    doing this or a way to do it where I will not have to convert
    (PDFDocument *) to CGPDFDocumentRef every time I perform a
    transformation.

    Does anyone have any suggestions?  Thanks!

    - Kevin
  • Kevin,

    The PDFAnnotationEditor example program does a lot of this sort of thing; have
    you looked at it?

    Also, any operation you can perform on an NSView also applies to a PDFView;
    plus you have the additional PDFView protocol.

    Other pertinent resources would be Apple's quartz-dev list and David Gelphman's
    beautiful book, Programming With Quartz.

    HTH,
    Joel
  • On May 29, 2008, at 6:50 PM, Kevin Ross wrote:
    > I think there has to be either a better way of doing this or a way
    > to do it where I will not have to convert (PDFDocument *) to
    > CGPDFDocumentRef every time I perform a transformation.

    Joel was right. I think it would be easier for you to stay in PDF Kit
    (PDFView) and do your transforms there.

    Since I don't know exactly what you are doing, I can't recommend
    specific advice.  If you explain what you think you need to do with
    CGPDFDocumentRef, I'll try to suggest a parallel way of doing it in
    PDF Kit.

    John Calhoun—
  • My ultimate goal is an application that is like a printer's PDF
    workflow, that will allow page manipulations like resizing /
    cropping / adding bleed information, and imposing multiple pages onto
    one with crop marks and the like.  After researching it seems like
    some of the functions (imposition with crop marks, page cropping/
    scaling with/without preserving aspects, etc) are best suited for
    quartz, while the rest (page reordering/inserting, rotating, etc) have
    Cocoa APIs.  I'm not clear on how to accomplish the more advanced
    requirements without creating a CGPDFDocumentRef to draw into a custom
    quartz context.

    If there is a more sane way to accomplish these tasks please let me
    know!    :)

    Thank you for your help!

    - Kevin

    On May 30, 2008, at 12:59 PM, John Calhoun wrote:

    > On May 29, 2008, at 6:50 PM, Kevin Ross wrote:
    >> I think there has to be either a better way of doing this or a way
    >> to do it where I will not have to convert (PDFDocument *) to
    >> CGPDFDocumentRef every time I perform a transformation.
    >
    > Joel was right. I think it would be easier for you to stay in PDF
    > Kit (PDFView) and do your transforms there.
    >
    > Since I don't know exactly what you are doing, I can't recommend
    > specific advice.  If you explain what you think you need to do with
    > CGPDFDocumentRef, I'll try to suggest a parallel way of doing it in
    > PDF Kit.
    >
    > John Calhoun—
  • Whoops, I sent this yesterday but didn't hit reply-all...

    Thanks Joel, I just took a look at the PDFAnnotationEditor example.
    It seems to be doing all of it's transformations in the PDFView
    subclass.  I'm not sure if I am able to do this since I would like to
    perform the impositions by working strictly with the data of the
    PDFDocument.

    David's book is fantastic, I'm been using it plus a lot of inspiration
    to get to where I am now.  It has been essential on this journey.

    In my naiveté, I had hoped that I could cast between the two with a
    smaller performance penalty than converting PDFDocument -> NSData ->
    CGPDFDocumentRef.  Needless to say, there has been no headway on that
    front.

    I currently have an "Initilalizing..." document modal window activate
    when I'm initializing the CGPDFDocumentRef so it's not too bad, it
    would just be nice to avoid this behavior completely.

    I realize that perhaps this question might be better suited for quartz-
    dev, thank you for your insight!

    - Kevin

    On May 29, 2008, at 8:52 PM, Joel Norvell wrote:

    > Kevin,
    >
    > The PDFAnnotationEditor example program does a lot of this sort of
    > thing; have
    > you looked at it?
    >
    > Also, any operation you can perform on an NSView also applies to a
    > PDFView;
    > plus you have the additional PDFView protocol.
    >
    > Other pertinent resources would be Apple's quartz-dev list and David
    > Gelphman's
    > beautiful book, Programming With Quartz.
    >
    > HTH,
    > Joel
  • On May 31, 2008, at 3:43 PM, Kevin Ross wrote:
    > My ultimate goal is an application that is like a printer's PDF
    > workflow, that will allow page manipulations like resizing /
    > cropping / adding bleed information, and imposing multiple pages
    > onto one with crop marks and the like.  After researching it seems
    > like some of the functions (imposition with crop marks, page
    > cropping/scaling with/without preserving aspects, etc) are best
    > suited for quartz, while the rest (page reordering/inserting,
    > rotating, etc) have Cocoa APIs.

    Well, FWIW, Apple's Preview is cropping in PDF Kit ... basically you
    call -[setBoundsForBox:] on the PDFPage in question.

    Additionally you should probably look into subclassing PDFPage.
    Within that domain you can overlay crop marks, apply additional
    transforms, etc.

    See PDFCalendar sample code for a PDFPage subclassing example.

    John Calhoun—
previous month may 2008 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Go to today