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
