> Which solutions do you propose in order to make it evolves ?
I've already proposed (in bugs and on this mailing list) a means of specifying
icons by platform and potentially density.
Assuming that the format that Mounir proposes were to become a reality, I'd
prefer--rather than breaking backwards compatibility--that we create a new
field ("graphics" or something along those lines) and deprecate "icons".
Developers could support older devices indefinitely in that way without
affecting forward compatibility.
----- Original Message -----
From: "Vivien" <[email protected]>
To: "Matt Basta" <[email protected]>, "Mounir Lamouri" <[email protected]>
Cc: "Marcos Caceres" <[email protected]>, "Jonas Sicking"
<[email protected]>, "Tim Guan-tin Chien" <[email protected]>, "dev-webapps"
<[email protected]>
Sent: Monday, June 17, 2013 10:44:20 AM
Subject: Re: Icon sizes and display densities
I won't be against implementing the support of something that is closer
to srcset in Gaia.
On 17/06/2013 19:01, Matt Basta wrote:
> I don't think this is viable solution since it's not backwards compatible.
> Older devices won't be able to understand the manif
That's true but this is pretty obvious that some changes will (and
should) happen in the manifest format. Which solutions do you propose in
order to make it evolves ? (I assume you think about that when designing
the manifest format)
>
> ----- Original Message -----
> From: "Mounir Lamouri" <[email protected]>
> To: "dev-webapps" <[email protected]>
> Cc: "Marcos Caceres" <[email protected]>, "Vivien Nicolas"
> <[email protected]>, "Jonas Sicking" <[email protected]>, "Tim Guan-tin
> Chien" <[email protected]>
> Sent: Monday, June 17, 2013 9:11:43 AM
> Subject: Re: Icon sizes and display densities
>
> 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
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
