I've just implemented the reading and writing of the property image-rendering. This property can be used to control how scaling is done. The current SVG 1.1 spec[1] dictates the values:
auto | optimizeSpeed | optimizeQuality | inherit
The spec specifically statues that 'optimizeSpeed' not use nearest neighbor scaling if performance goals can be achieved using a "higher quality" algorithm. However, Batik, Opera, and Firefox all use nearest neighbor for 'optimizedSpeed' (Chrome does not) and there is at least some SVG content out there that relies on this.
The new CSS4 Image spec defines[2]:
auto | crisp-edges | pixelated
with the previous SVG 1.1 values deprecated. There may be an additional value of 'smooth' added. We could use these values to control up scaling (with a '-inkscape' prefix). Some browsers already support these values... but unfortunately not in SVG.[3]
There won't be a quick fix from the SVG WG as SVG 2 will reference CSS and CSS4 Images is sometime off.
Tav
[1] http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty [2] http://www.w3.org/TR/css4-images/#the-image-rendering [3] https://developer.mozilla.org/en-US/docs/CSS/image-rendering
On Wed, 2013-04-03 at 15:43 +0200, Tavmjong Bah wrote:
On Wed, 2013-04-03 at 14:38 +0200, Jasper van de Gronde wrote:
On 03-04-13 13:25, Tavmjong Bah wrote:
... I've just had a quick look at how the web browsers and Batik handle bitmap scaling. When scaling up they all smooth the bitmaps.I This seems to be what the SVG 1.1 spec requires. There is no provision for turning this off, the closest is to set the 'image-rendering' value to 'optimizeSpeed'.
It has been proposed in CSS to take the SVG 'image-rendering' property and add new values. Currently Firefox and Opera support the value 'crisp-edges'. See:
https://developer.mozilla.org/en-US/docs/CSS/image-rendering
It doesn't appear that anybody supports in inside SVG (only in HTML).
Would it make sense to start supporting this in Inkscape? Obviously support in other renderers would be absent (at least for now), but as it is mostly a hint anyway... Put differently, if our choice is between adding a global preference for Inkscape that toggles between resampling methods and adding support for image-rendering with crisp-edges and/or pixelated, what would be preferable?
Adding a global toggle is not a good idea. Our SVG would then never be rendered the same as by others. Using image-rendering is a much better solution.
BTW, just to be clear, I'm assuming that these values live purely in the CSS domain (and even there are not standardized, yet), and would thus have to live in the style attribute.
I have asked that this topic be added to the agenda for tomorrow's SVG working group meeting. If it receives a favorable response, we can then add it with the "-inkscape" prefix. Once the standard is approved, we can then remove the prefix. This avoids half the problem we face with flowed text.
This brings up the question of how to handle SVG2/CSS3/etc. features in general. I have a proposal but don't have time at the moment to write it all out.
Tav
Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel