The proposal to add constraints that help authors achieve predictable crisp result for SVG image presented across various screens and devices.
- 1 Problem statement
- 1.1 Discussion context and source data
- 1.2 Specific examples
- 1.3 Pixel grid alignment
- 1.4 Propagating state or various values to hosted SVG
- 2 Proposals
- 3 Links, references
Discussion context and source data
Microsoft has numerous products with thousands of icon assets. Microsoft Office has some 9000 icons, Visual Studio some 2000. While looking at current icons and associated workflow we’ve identified few common problems:
- Icons are largely stored as retouched rasterized bitmaps, even though there are vector masters
- A lot of icons have largely duplicate content with few changes (active, inactive states; selected, not selected; normal, hover; etc.)
- Mobile and high density screens multiply the problem even more!
In internal discussions we have identified few common explanations why core graphic assets have not moved to vector:
- Hard / impossible to control rasterized output at specific size, unable to achieve predictive designer intent
- (On the meeting it was called out that down sampling of SVG images results in very bad quality image)
- Lack of support in non-web (“native”) frameworks such as XAML, Cocoa
- Performance considerations
Another widely recognized alternative to SVG is fonts (Black and white / color).
- Works with the web AND native applications
- Inherent on many platforms
- Has a well established mechanism to control raster output through hinting / instructing
However fonts have many disadvantages compared to SVG and on their own:
- Cannot be animated other than through key frame animation
- Cannot be combined with / use external resources for efficient workflow
- Raster output hinting / instructing output is not necessarily compatible cross-platform
It would be beneficial to allow SVG rendering engine to take hints / instructions on specific intent to produce predictable pixel results. Let's take a looks at few initial use case to highlight common problems existing today:
- Controlling small details at various zoom levels (especially small)
- Relative alignment and positioning of shapes, points
- Preserving specific shape and whitespace at various sizes (especially small)
- Pixel grid alignment
- Propagating state or various values to hosted SVG
Mozilla Firefox SVG icon - Example of controlling small details
Problem: Similar to general fonts scenarios, sometimes author would prefer to highlight subtle details at small sizes, not visible through normal SVG rendering, or hide other details not expected to be visible at certain size. Raster Firefox logo at small sizes has different presentation with much less details (as expected).
Potential solution: This can possibly achieved today already with media queries for specific size.
Google Chrome SVG icon - Example of alignment of shapes, points
Problem: Authors want control over perfect pixel alignment of related visual parts of the image, such as shapes, points, curves. Currently this requires workaround with larger than required shapes, overlaps and trial and error.
Microsoft Internet Explorer icon - Example of controlling pixel perfect iconic image
Problem: SVG images are engineered for the future and scale (especially up) great by definition. However, just like fonts, designers need control over output at certain size to ensure desired presentation. This is especially important for down scaling, where the risk to lose small subtle detail and whitespace increases as you scale the image smaller and smaller.
Potential solution: One of the potential solution would be specifying certain elements min-, max- values, possibly utilizing constraints for related elements, parts as in previous example.
Pixel grid alignment
During the discussion Chris Lilley noted that subpixel alignment (to middle 0.5 pixel, top pixel or bottom pixel) is a longstanding discussion topic and we should aim to align this aspect as well.
Propagating state or various values to hosted SVG
The overall scenario of containing core artwork and modifying presentation based through passing data from host document to hosted SVG is also important in this discussion. This area needs to be understood more to highlight specific scenarios (active, inactive, hover, high-contrast states perhaps others? arbitrary states?).
The discussions on the topic has showed at least two clear opportunities:
- Improve SVG rendering to have predictable pixel snapping for lines and shapes
- Introduce shapes alignment
In most discussions on the topic of SVG crispness - pixel alignment is a very common theme. Due to sub pixel measurements and layout in modern browsers (a must for text readability and smooth interaction) very often a start and end of an line or polygon ends up at fractional pixel. The proposal is to default to rounding start and end values, so that by default browsers start and end drawing shapes at specific pixel (not sub-pixel). This would result in pixel perfect straight lines as long as stoke is specified in integer number of pixels as well. It is completely possible that some applications would want to preserve existing sub-pixel positioning for lines and dots and to mitigate this this change would include opt-out global flag on SVG declaration. Pixel snapping would solve a class of issues the lead to blurry SVG presentation due to sub-pixel positioning / measuring.
The second common source of feedback is the need for relative positioning and/or sizing of shapes or figures in SVG. This can be addressed by expanding structural attributes to accept relative values, based on existing elements values.
The following considerations would need to apply:
- The syntax should allow absolute values fallback for legacy versions
- The engine would need to detect and bail out in case of circular references
- The referenced values would be based on computed values
- The referenced values would update with source values update