Hi Benjamin, I think there's some confusion here between size and pixel size.
The "size" of an image is the default size of the rect in which it's drawn when the person drawing it doesn't have any more specific information. That's a concept that there can only be one of for the entire image, so it's confusing if the -size for contained reps doesn't match that of the image itself. The -size is unrelated to the number of pixels in a rep. The ratio determines resolution. Reps can definitely have different numbers of pixels. It's pretty common for people to hit cases where they feel like their image has no intrinsic size it wants to be drawn at. Like, it might be equally natural at 32x32 vs 128x128. That's okay, it just means you're going to ignore the size. There still is one, you just don't care what it is. -size is not used in representation selection. Rep selection is based on the number of pixels to be filled in the context and the number of pixels in each candidate rep. So it's perfectly fine to pack in different representations with different numbers of pixels. What the docs encourage is setting the metadata so that the -size of each representation is the same. -Ken On Thu, Sep 3, 2009 at 11:00 AM, Benjamin Rister <bdris...@gmail.com> wrote: > (Apologies if this ends up a duplicate…I sent the original over a week ago, > and as far as I can see it's not in either Apple's or Cocoabuilder's > archives, so I don't see any other explanation besides it just being eaten > by something.) > > The core question: > Is it still the best practice to have conceptually same images of different > sizes in different files, e.g. Foo9x9.tiff, Foo32x32.tiff? icns isn't an > option because they aren't all the standard icns sizes, and several places > in the docs seem to discourage lumping them together (e.g. with tiffutil) > anyway. > > > The details: > > We have several images that are displayed at different sizes at various > places in an application. Our artist has generated several bitmaps for > these different scales. Modeling on the concept of an .icns file, my > inclination would be to try and lump them all together in one > multi-representation file and let NSImage figure out what the best > representation is to draw from at any given point. This not only is > convenient for the various usages around the app, but also for resolution > independence (...maybe...see below). > > However, man tiffutil says: > >> -cat allows combining multiple TIFF files into one. ... If the real sizes >> (pixel size >> divided by dpi) of the images being combined are not the same, a >> warning >> will be generated. This makes sure that NSImage can successfully >> choose >> the right size image out of the generated TIFF file. >> > > And Cocoa Drawing Guide: Images, "How an Image Representation Is Chosen" > gives rules about color space, dpi, and bit depth, but there's no rule about > choosing representations based on size. (But there's icns, right? How is > that supposed to work, then?) > > I'm also concerned for resolution independence that the system might not > choose the 32x32px rep to fill a 16x16pt space at a 2x scale factor, because > everything I've seen in the resolution independence docs only talks about > representations with different dpi. It would be rather inelegant to have to > have multiple representations with the same pixels and just different > metadata. > > So between the resolution independence concern, and the docs seemingly > discouraging having different sized images in one file, this raises the core > question above. What's the best way to arrange this for both drawing the > image at different sizes in different places and resolution independence? > > Best, > Benjamin Rister_______________________________________________ > > 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/kenferry%40gmail.com > > This email sent to kenfe...@gmail.com > _______________________________________________ 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
