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
