On Thu, 27 Jan 2011 22:53:51 +0000, "Mirabito, David" <dav...@ok-labs.com> said: >Now the view should print a bunch of data (ideally with a header covering >~20% of the first page). > >I get my calls to -knowsPageRange:aRange and -rectForRange:pageNumber just >fine. Retuning (1,2) and then [self view] for both pages prints my view >(currently just a 'hello world' text view) twice over. Nice. > >My next step was to get different things on each page. Ignoring the banner >for now, I added a switch to rectForPage that would modify the value of the >string depending on page number, and then return [self frame] each time. > >2) Is modifying the contents of the view for each page allowed?
It isn't a matter of what's allowed, it's a matter of what you are supposed to do. If you are thinking of some kind of dynamic system where you generate each page only on demand, forget it; that won't work. (Once upon a time you could sort of get away with it, but not any more, because of the Preview in the print dialog.) What you are supposed to do is simple: (1) Make a view. (2) Print it. That's really all there is to it. Printing means drawing. The view will draw itself in the usual way. So, for example, if your document is "Alice in Wonderland", you make a big tall view containing the entire text of "Alice in Wonderland". Note that you are allowed to decide the height of the view after you've heard that you are printing but before you hand it back for actual printing. So, for example, you might hear that we are going to be printing on paper that is 8.5 inches wide. So you'd start with a view that's 8.5 inches wide (or whatever) and make it long enough to contain all of "Alice in Wonderland". How you work out that length is up to you: basically you might just keep adding stuff to the view and keep lengthening the view until it is long enough to contain everything you added, and no longer. That's it. You are printing. Stop and try it and assure yourself that it works. Now, you might say, what about pages? But pages are a fiction. Okay, they are actually a reality, since there will in fact be pieces of paper in this story eventually, but from *your* point of view they are a fiction. They are just a *division* of your view that Cocoa will perform. If you just do nothing, Cocoa will perform this division perfectly reasonably, so steps (1) and (2) will suffice. Your experiments will show this. If the user wants to print just page 3, Cocoa will still perform its division of your view, working out where page 1 and page 2 are; it just doesn't send them to the printer, that's all. The only reason this might NOT work is that there are things in your view that you don't want split or divided from each other by a page division. So my advice is, *after* you have satisfied yourself that (1) and (2) alone work reasonably well except for the page division problem, then you go back and add: (3) Respond to the framework's questions about where page breaks go. This might require some revision of your technique for laying out the page in the first place. As I've said before here, one approach is to use subviews that can speak up and say "But don't divide *me*!" Another, obviously, is to keep a record of where you put everything in the view when you constructed it, and use that record to do the necessary arithmetic to answer the framework's questions. m. -- matt neuburg, phd = m...@tidbits.com, <http://www.apeth.net/matt/> A fool + a tool + an autorelease pool = cool! AppleScript: the Definitive Guide - Second Edition! http://www.apeth.net/matt/default.html#applescriptthings_______________________________________________ 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 arch...@mail-archive.com
