Re: PDFKit guidance
On Jun 26, 2008, at 11:54 AM, Torsten Curdt wrote: The subclassing of PDFDocument and PDFPage was quite straight forward. (Although unexpected as usually everyone tells you "usually you don't subclass in Cocoa land") I think what we usually say is: don't make subclassing your first resort. Try configuration, composition, delegation, or notification before subclassing; but if those don't cover your particular situation, as often happens, most Cocoa classes are designed with subclassing in mind. Subclassing is more powerful and more dangerous than those other mechanisms, and often more work, so it should be reserved for those cases where it is necessary, but it should be available to you when you need it. Douglas Davidson ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: PDFKit guidance
OK, guys thanks for the help so far. I've played a bit. The subclassing of PDFDocument and PDFPage was quite straight forward. (Although unexpected as usually everyone tells you "usually you don't subclass in Cocoa land") Just out of curiosity I've just compiled it with the 10.4 SDK and it compiled just fine. So I guess it will just not work on 10.4 although it has compiled successfully? (I am on Leopard still targeting Tiger. That's why) Well, in a very crude fashion you can still accomplish what it is I think you;re trying to accomplish. You're subclassed PDFPage's could, on Tiger, render a regular PDFPage. It's gross but what I'm describing is basically having two parallel PDFDocuments — one created from a file or data ([PDFDocument initWithURL:] or [PDFDocument initWithData:]) and the other empty PDFDocument you create with -[init]. For each page in the former document you create a new PDFPageSubclass object and add it to the empty document. Your subclass does the various scaling/filtering in it's draw method and calls it's doppleganger PDFPage to render. So I said it was gross Hm ...indeed So should rather look into the CGPDFDocumentRefs (/Developer/Examples/ Quartz/PDF/CGPDFViewer) way of doing it? cheers -- Torsten___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: PDFKit guidance
On Jun 24, 2008, at 7:15 AM, Adam R. Maxwell wrote: On Jun 23, 2008, at 3:01 PM, John Calhoun wrote: You can then either apply it to a context (in your PDFPage subclass) with: - (BOOL) applyToContext:(CGContextRef) aContext; Or better still, pass it in the options dictionary to one of PDFDocument's save routines (key == @"QuartzFilter"): Should I file a bug asking for that key to be documented also? And can that option be used when creating a CGPDFContext? I'm sure I'll think of more questions :). Since the OP was trying to stay in memory, I was avoiding the save routines. The key is "documented" in PDFDocument.h. :-) Yes, you can apply the QuartzFilter to a CGPDFContext with the - [applyToContext:] call listed above. And, yes, they should better document QuartzFilters ... they're nice. I'm feeling dumb now, but I don't see how that helps? You can insert a subclassed PDFPage in an empty PDFDocument, but then what do you do to use it with your PDF file? Well, in a very crude fashion you can still accomplish what it is I think you;re trying to accomplish. You're subclassed PDFPage's could, on Tiger, render a regular PDFPage. It's gross but what I'm describing is basically having two parallel PDFDocuments — one created from a file or data ([PDFDocument initWithURL:] or [PDFDocument initWithData:]) and the other empty PDFDocument you create with - [init]. For each page in the former document you create a new PDFPageSubclass object and add it to the empty document. Your subclass does the various scaling/filtering in it's draw method and calls it's doppleganger PDFPage to render. So I said it was gross John Calhoun—___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: PDFKit guidance
On Jun 23, 2008, at 3:01 PM, John Calhoun wrote: On Jun 21, 2008, at 6:34 PM, Adam R. Maxwell wrote: I appreciated Antonio's (and your) reminder :). If I understand correctly, the OP could create a PDF context with kCGPDFXDestinationOutputProfile set to a grayscale profile QuartzFilters make all that a lot simpler. You would create a QuartzFilter that does grayscale (look at ColorSync Utility for examples and how to create them). The load the QuartzFilter with: + (QuartzFilter*) quartzFilterWithURL:(NSURL*) aURL; Indeed...that QuartzFilter class sounds cool, so I just filed rdar:// problem/6030284 asking that it be documented. Prior to your post, I'd never heard of it, Xcode's doc browser drew a blank, and google just turned up the list of 10.5 symbol changes. You can then either apply it to a context (in your PDFPage subclass) with: - (BOOL) applyToContext:(CGContextRef) aContext; Or better still, pass it in the options dictionary to one of PDFDocument's save routines (key == @"QuartzFilter"): Should I file a bug asking for that key to be documented also? And can that option be used when creating a CGPDFContext? I'm sure I'll think of more questions :). Since the OP was trying to stay in memory, I was avoiding the save routines. Subclassing PDFPage apparently requires 10.5, also, unless I'm missing something. Not strictly speaking. You can subclass PDFPage in 10.4 but you will not be able to get PDFDocument to create instances of your subclass when handed a PDF file (i.e. through -[PDFDocument initWithURL:]). You can however still create an empty PDFDocument on 10.4 and -insertPage your subclassed PDFPage. I'm feeling dumb now, but I don't see how that helps? You can insert a subclassed PDFPage in an empty PDFDocument, but then what do you do to use it with your PDF file? thanks, Adam ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: PDFKit guidance
On Jun 21, 2008, at 6:34 PM, Adam R. Maxwell wrote: I appreciated Antonio's (and your) reminder :). If I understand correctly, the OP could create a PDF context with kCGPDFXDestinationOutputProfile set to a grayscale profile QuartzFilters make all that a lot simpler. You would create a QuartzFilter that does grayscale (look at ColorSync Utility for examples and how to create them). The load the QuartzFilter with: + (QuartzFilter*) quartzFilterWithURL:(NSURL*) aURL; You can then either apply it to a context (in your PDFPage subclass) with: - (BOOL) applyToContext:(CGContextRef) aContext; Or better still, pass it in the options dictionary to one of PDFDocument's save routines (key == @"QuartzFilter"): - (BOOL) writeToFile: (NSString *) path withOptions: (NSDictionary *) options; Subclassing PDFPage apparently requires 10.5, also, unless I'm missing something. Not strictly speaking. You can subclass PDFPage in 10.4 but you will not be able to get PDFDocument to create instances of your subclass when handed a PDF file (i.e. through -[PDFDocument initWithURL:]). You can however still create an empty PDFDocument on 10.4 and - insertPage your subclassed PDFPage. QuartzFilters though were only introduced in 10.5 John Calhoun—___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: PDFKit guidance
On Jun 20, 2008, at 12:53 PM, John Calhoun wrote: On Jun 20, 2008, at 5:21 AM, Adam R. Maxwell wrote: If you want to draw in memory, I think you have to drop down to Quartz; using PDFKit would likely be easier, but it looks like you can only specify a Quartz filter when saving to a file?. I think there may be some confusion with regards to drawing Antonio is correct that PDFPage has a -[drawWithBox:] method that is used not simply for displaying to screen but also for rendering into a PDF context for saving to file as well. So, you can still use PDFPage, override -[drawWithBox:] in an app that has no intention of displaying the PDF to screen. The saving method is in PDFDocument. When called it walks through each PDFPage in the document and calls it to render into a PDF context. (Printing within PDF Kit does something similar, BTW.) Optionally too, you can pass a QuartzFilter to the save method in PDFDocument and get, for example, grayscale output. You can also do something similar in Quartz with CGPDFDocumentRefs and CGPDFPageRefs. The QuartzFilter stuff should work for CGContexts as well. There is I think a perception that PDF Kit is only for displaying PDF's and I like to try to dispell that when I can. :-) I appreciated Antonio's (and your) reminder :). If I understand correctly, the OP could create a PDF context with kCGPDFXDestinationOutputProfile set to a grayscale profile, set it as the current context with [NSGraphicsContext setCurrentContext:], then draw each PDFPage into it. Would you still have to use CGContextBeginPage/CGContextEndPage in that case, or is there an easier way to draw all pages of a PDFDocument into a given context? There's an obvious advantage in using PDFKit if you're saving to disk, but I'm curious to know if there's a distinct advantage in using it to draw to memory. Subclassing PDFPage apparently requires 10.5, also, unless I'm missing something. thanks, adam ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: PDFKit guidance
On 20.6.2008, at 13:47, Torsten Curdt wrote: On Jun 20, 2008, at 13:09, Antonio Nunes wrote: On 20 Jun 2008, at 11:07, Torsten Curdt wrote: you can't go wrong by reading the "Cocoa Drawing Guide." Surely will read through that. Because frankly speaking I didn't think this was Quartz related. Well, you need to know how to generally draw in Cocoa, and you need to know how to take advantage of PDFKit, so both John Calhoun and Joel Norvell provided useful pointers. The scaling is done when a PDFPage needs to be drawn, so you need to implement it in your subclass's drawWithBox: method. Use an affine transform set up to serve your needs and apply it to the current graphics context within the drawWithBox: method before drawing the page. Right. The point though is - I don't really want to display it. So I did not look into the drawing side of things. But I guess I just read up on the Quartz stuff and then get back to you guys (if needed). I assume one could also draw in memory - without displaying. Just didn't know that's the right direction. You just should be aware that Quartz rewrites the PDF from scratch when using this approach. That is, while still showing the same grafics, the result is a completely new PDF file with potentially very different structure. Plus, since Quartz is about displaying, some non- display properties of the original PDF may be lost. Its a while ago that I last checked (Tiger, I think), but I would be surprised if Quartz became perfect in this respect in the meantime. Depending on your application, this may be between no problem and inacceptable. Greetings Kai ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: PDFKit guidance
On Jun 20, 2008, at 5:21 AM, Adam R. Maxwell wrote: If you want to draw in memory, I think you have to drop down to Quartz; using PDFKit would likely be easier, but it looks like you can only specify a Quartz filter when saving to a file?. I think there may be some confusion with regards to drawing Antonio is correct that PDFPage has a -[drawWithBox:] method that is used not simply for displaying to screen but also for rendering into a PDF context for saving to file as well. So, you can still use PDFPage, override -[drawWithBox:] in an app that has no intention of displaying the PDF to screen. The saving method is in PDFDocument. When called it walks through each PDFPage in the document and calls it to render into a PDF context. (Printing within PDF Kit does something similar, BTW.) Optionally too, you can pass a QuartzFilter to the save method in PDFDocument and get, for example, grayscale output. You can also do something similar in Quartz with CGPDFDocumentRefs and CGPDFPageRefs. The QuartzFilter stuff should work for CGContexts as well. There is I think a perception that PDF Kit is only for displaying PDF's and I like to try to dispell that when I can. :-) John Calhoun—___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: PDFKit guidance
On Jun 20, 2008, at 7:47 AM, Torsten Curdt wrote: On Jun 20, 2008, at 13:09, Antonio Nunes wrote: On 20 Jun 2008, at 11:07, Torsten Curdt wrote: you can't go wrong by reading the "Cocoa Drawing Guide." Surely will read through that. Because frankly speaking I didn't think this was Quartz related. Well, you need to know how to generally draw in Cocoa, and you need to know how to take advantage of PDFKit, so both John Calhoun and Joel Norvell provided useful pointers. The scaling is done when a PDFPage needs to be drawn, so you need to implement it in your subclass's drawWithBox: method. Use an affine transform set up to serve your needs and apply it to the current graphics context within the drawWithBox: method before drawing the page. Right. The point though is - I don't really want to display it. So I did not look into the drawing side of things. But I guess I just read up on the Quartz stuff and then get back to you guys (if needed). I assume one could also draw in memory - without displaying. Just didn't know that's the right direction. If you want to draw in memory, I think you have to drop down to Quartz; using PDFKit would likely be easier, but it looks like you can only specify a Quartz filter when saving to a file?. You should be able to create your own CGPDFContext with kCGPDFXDestinationOutputProfile set to an ICC-based grayscale colorspace, then draw your PDF pages into that context. If you use CGPDFDocument, be careful when you use CGContextDrawPDFPage, since it only scales down, not up; you'll need to add an appropriate scale transform to the context (and deal with rotated pages). -- Adam ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: PDFKit guidance
On 20 Jun 2008, at 12:47, Torsten Curdt wrote: The scaling is done when a PDFPage needs to be drawn, so you need to implement it in your subclass's drawWithBox: method. Use an affine transform set up to serve your needs and apply it to the current graphics context within the drawWithBox: method before drawing the page. Right. The point though is - I don't really want to display it. So I did not look into the drawing side of things. But I guess I just read up on the Quartz stuff and then get back to you guys (if needed). I assume one could also draw in memory - without displaying. Just didn't know that's the right direction. Even if you just want to save to file, the drawWithBox: method is going to be called. I.o.w. a PDFDocument is rendered when saved to file. This is what gives you the opportunity to implement such tricks as scaling. António --- What you have inside you expresses itself through both your choice of words and the level of energy you assign to them. The more healed, whole and connected you feel inside, the more healing your words will be. --Rita Goswami --- ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: PDFKit guidance
On Jun 20, 2008, at 13:09, Antonio Nunes wrote: On 20 Jun 2008, at 11:07, Torsten Curdt wrote: you can't go wrong by reading the "Cocoa Drawing Guide." Surely will read through that. Because frankly speaking I didn't think this was Quartz related. Well, you need to know how to generally draw in Cocoa, and you need to know how to take advantage of PDFKit, so both John Calhoun and Joel Norvell provided useful pointers. The scaling is done when a PDFPage needs to be drawn, so you need to implement it in your subclass's drawWithBox: method. Use an affine transform set up to serve your needs and apply it to the current graphics context within the drawWithBox: method before drawing the page. Right. The point though is - I don't really want to display it. So I did not look into the drawing side of things. But I guess I just read up on the Quartz stuff and then get back to you guys (if needed). I assume one could also draw in memory - without displaying. Just didn't know that's the right direction. cheers -- Torsten ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: PDFKit guidance
On 20 Jun 2008, at 11:07, Torsten Curdt wrote: you can't go wrong by reading the "Cocoa Drawing Guide." Surely will read through that. Because frankly speaking I didn't think this was Quartz related. Well, you need to know how to generally draw in Cocoa, and you need to know how to take advantage of PDFKit, so both John Calhoun and Joel Norvell provided useful pointers. The scaling is done when a PDFPage needs to be drawn, so you need to implement it in your subclass's drawWithBox: method. Use an affine transform set up to serve your needs and apply it to the current graphics context within the drawWithBox: method before drawing the page. António I try to take one day at a time, but sometimes, several days attack me all at once! ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: PDFKit guidance
On Jun 20, 2008, at 03:35, Joel Norvell wrote: Torsten, John Calhoun wrote: So, PDF Kit can I think do what you want. I stand corrected! But (to salvage a little face :-) lol ...don't worry you can't go wrong by reading the "Cocoa Drawing Guide." Surely will read through that. Because frankly speaking I didn't think this was Quartz related. cheers -- Torsten ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: PDFKit guidance
On Jun 20, 2008, at 02:40, John Calhoun wrote: On Jun 19, 2008, at 4:35 PM, Torsten Curdt wrote: I would like to convert a PDF of any size so it fits to A4/Letter. I would also like to reduce it to gray scale. This all without displaying anything. PDFKit gives you -[PDFPage setBounds:forBox] which would easily give you A4/Letter size if that is what you specified. However, no scaling is done. A PDFPage subclass could be fairly easily written that would do the scaling though Look at QuartzFilters (in Quartz.framework) — this is where you can create a filter for converting to greyscale. PDFDocument allows you to pass in a QuartzFilter in the save methods (in the options dictionary) if you want to apply this Quartz Filter on saving. So, PDF Kit can I think do what you want. Awesome! Thanks for the pointers, John. cheers -- Torsten___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: PDFKit guidance
Torsten, John Calhoun wrote: > So, PDF Kit can I think do what you want. I stand corrected! But (to salvage a little face :-) you can't go wrong by reading the "Cocoa Drawing Guide." Joel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: PDFKit guidance
Torsten, These aren't really PDFKit issues. PDF is a native Quartz data type. The issues you mentioned, "scaling" and "color," are addressed in the Cocoa Drawing Guide. You probably want to use an Affine Transform for scaling. I'm not sure about how to go grayscale, but looks like NSColorSpace and NSColor would be involved. HTH, Joel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: PDFKit guidance
On Jun 19, 2008, at 4:35 PM, Torsten Curdt wrote: I would like to convert a PDF of any size so it fits to A4/Letter. I would also like to reduce it to gray scale. This all without displaying anything. PDFKit gives you -[PDFPage setBounds:forBox] which would easily give you A4/Letter size if that is what you specified. However, no scaling is done. A PDFPage subclass could be fairly easily written that would do the scaling though Look at QuartzFilters (in Quartz.framework) — this is where you can create a filter for converting to greyscale. PDFDocument allows you to pass in a QuartzFilter in the save methods (in the options dictionary) if you want to apply this Quartz Filter on saving. So, PDF Kit can I think do what you want. John Calhoun—___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
PDFKit guidance
I have been browsing through PDFKit examples and documentation. But it seems most things are about showing PDFs, searching them or annotating them. I would like to convert a PDF of any size so it fits to A4/Letter. I would also like to reduce it to gray scale. This all without displaying anything. Could someone please point me in the right direction? cheers -- Torsten ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
