Hi,
I would like to resurrect this thread with the following proposal:
"icons" will contain an array of objects that will have one mandatory
property named 'href'.
There will be three optional properties: 'width', 'height' and
'density'. 'width' and 'height' will be a number expressing the size of
the icon in pixels and 'density' will for the moment be something in the
following set { "1x", "1.5x", "2x", "3x" }. "1x" will be the default
value if the property is missing or has an invalid value. We might
extend this property to include dpi values.
If the entry doesn't contain a width/height information and the image is
a bitmap image, the UA will have to download the entry to find out its size.
When the entry is a vectorial based image, if it has no size
information, it will be used every time an image with a size not in the
array is requested. If a vectorial based image has some size information
that will be considered as "best viewed as x*y". In which case, it will
be preferred to be scaled to another size but if a bitmap image has a
quite closer size it will not. For example, a bitmap image of 60*60 will
still be preferred compared to a SVG image of 8*8 if we want to show a
64*64 image (the bitmap image will be scaled).
An example:
"icons": [
{ "href": "foo.png" },
{ "href": "bar.png", "height": "16px", "width": "16px" },
{ "href": "bar_2.png", "height": "32px", "width": "32px", "density":
"2x" },
{ "href": "foobar.svg" }
],
How does that look? Vivien and Tim? Would you like to implement that in
Gaia?
Cheers,
--
Mounir
On 20/05/13 09:08, Jonas Sicking wrote:
> On Wed, May 15, 2013 at 11:06 AM, Marcos Caceres <[email protected]> wrote:
>>>> # Supporting SVG
>>>> For formats with non-intrinsic sizes (i.e., SVG), we should allow either a
>>>> URL or an object:
>>>>
>>>> {src: "icon.svg", width: "...px", height: "...px", density: "1x"}
>>>> (where the "density" is the device pixel ratio density)
>>>
>>> Do we really need densities or width/height? The idea is that it's the
>>> same picture just in different pixel sizes, right?
>>
>> For SVG, you need a width and height because the SVG file may not have an
>> explicit size. It may also be inappropriate to use on a 1x density device
>> because anti-aliasing would make it illegible/blurry. Sub-pixel
>> anti-aliasing on a 2x or 3x screen would again make this icon suitable for
>> display to a user.
>>> So if it's an SVG
>>> we can just scale it to whatever size we need.
>>
>> Unfortunately, no. SVG only really works for very large icons (anti-aliasing
>> makes a mess at lower resolutions) - [4] states that anything lower than
>> 48px is problematic. Please see the first graphic from [4], which shows the
>> problem clearly. See also [2] (last image), which shows what happens when
>> you scale up!
>>
>> As stated in [2], and echoed in [1] and [3]:
>>
>> "It’s simply not possible to create excellent, detailed icons which can be
>> arbitrarily scaled to very small dimensions while preserving clarity. Small
>> icons are caricatures: they exaggerate some features, drop others, and align
>> shapes to a sharp grid. Even if all icons could be executed as vectors, the
>> largest size would never scale down well."
>>
>> Vector graphic performance is also cited as an issue in both [2] and [3]
>> (though no primary source is given).
>>
>> Also, tool support for exporting SVG is limited/expensive/crappy so it's
>> unlikely a lot of people will use it. We can probably already gather data on
>> SVG usage for icons from the apps that are already in the FxOS store to see
>> if there are any.
>
> It sounds like there are a few separate concerns that we may need to address:
>
> * For SVG icons, provide a minimum size in pixels below which the SVG
> icon is not appropriate to use because it will look blurry.
> * For SVG icons, possibly provide an exact pixel size which is the
> only appropriate pixel size to render the icon.
> * For pixel-based image formats, provide width/height in pixels so
> that implementation can avoid downloading file if not useful.
> * For all icons, provide a minimum size in mm below which the icon is
> not appropriate to use due to containing too small details.
>
> I'm not sure that the last one is useful really. Having used a
> "retina" display for a while now, I'm not convinced that there is ever
> a situation where if the platform wants to render a image at 50x50
> retina-pixels where we couldn't use an icon that was authored for
> 50x50 normal pixels. That goes both for SVG icons or pixel-based
> icons.
>
> In other words, I think only providing the appropriate pixel size for
> each icon is enough.
>
> But if that's not the case, then it seems to me that providing
> information in the form of minimum physical size is more
> understandable than in the form of device resolution.
>
> / Jonas
> _______________________________________________
> dev-webapps mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-webapps
>
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
