I don't think this is viable solution since it's not backwards compatible. Older devices won't be able to understand the manifest.
----- 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
