- From: David Singer <singer@apple.com>
- Date: Thu, 07 Jul 2011 13:59:43 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Brad Kemper <brad.kemper@gmail.com>, Yves Lafon <ylafon@w3.org>, Raphaël Troncy <raphael.troncy@eurecom.fr>, fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>, "public-media-fragment@w3.org" <public-media-fragment@w3.org>
On Jul 7, 2011, at 13:46 , Tab Atkins Jr. wrote: > On Thu, Jul 7, 2011 at 1:31 PM, David Singer <singer@apple.com> wrote: >> On Jul 7, 2011, at 12:34 , Brad Kemper wrote: >>>> I agree that it's difficult to find a good answer. If we think the >>>> problem is essentially impossible, then we should just make it >>>> explicitly unsupported, not undefined. >>> >>> I agree that unsupported is better than undefined. But the fragments spec could also just define it, even if it is a bit arbitrary. For instance, I'd probably go with largest in area, then scale clipping based on relative proportions to that "largest size" of horizontal and vertical dimensions (independently) for smaller versions. >> >> Vector images are of potentially infinite resolution and there is no concept of "largest in area". > > Vector image formats and multi-resolution image formats are a disjoint > set currently, right? currently yes, afaik. logically, you could have a vector image that was multi-resolution (less detail in the lower resolutions) -- it used to be done as an optimization for zooming, years ago, but afaik not currently. I was just suggesting that "pick the largest in area" might not be eternally diagnostic. I think I'd prefer to say "don't attempt to pixel-clip an image that doesn't have a single well defined pixel resolution (width and height)", for now. David Singer Multimedia and Software Standards, Apple Inc.
Received on Thursday, 7 July 2011 21:00:12 UTC