On Tue, Jul 20, 2010 at 6:35 PM, Gideon King <[email protected]> wrote:
> I absolutely agree that it's possible to moderately easily set up a view 
> hierarchy that will allow for automatic pagination etc and work with object 
> oriented methodologies to accomplish the goal, but there is a certain amount 
> of grunt work in doing this, and the whole point of having frameworks is to 
> handle the common repeatable cases like printing tables.
>
> After all, they are always automatically going to be row based, so with a 
> little bit of work on Apple's part, it would be easy enough to have a 
> configuration item to say for it to print with or without the header, and 
> maybe a callback to find out whether it can split a particular row, and if 
> so, where. Then everyone would automatically get the printing capabilities 
> without everyone having to reinvent the wheel.

I think it's important to recognize the boundary of functionality that
Apple has established for NSTableView. It exists to display data with
a certain appearance, which is appropriate for on-screen display but
not for on-paper. The appearance NSTextView is designed to achieve, on
the other hand, is appropriate for both.

If Apple were to provide a print-oriented table or report class, I
would expect and hope it was separate from NSTableView. NSTableView is
very much an onscreen control, and its design reflects such.

> And besides this, you have already got a component optimised for retrieving 
> the data and displaying it in a table, so it makes sense to be using that for 
> the user interface. So I  don't want to have to be building a separate 
> mechanism just to print it - it's like doubling the work, and from the user's 
> perspective, they can work within the mental framework of getting the table 
> the way they want it (showing the right columns at the right size in the 
> right order), and then saying "print *this*" i.e. wysiwyg.

Speaking from direct experience here: even if you write your own
table-like view, you wind up doing the work twice anyway, once for
screen and once for print. :)

--Kyle Sluder
_______________________________________________

Cocoa-dev mailing list ([email protected])

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]

Reply via email to