- From: Erik Dahlstrom <ed@opera.com>
- Date: Tue, 04 Jan 2011 15:43:41 +0100
- To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Hello svg-wg, I'm wondering if Batik is really correct in rendering the space glyphs in this testcase: http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectApproved/interact-pevents-04-t.html. On the question of whether U+0020 should be rendered as a glyph or as a blank space we found http://www.unicode.org/faq/unsup_char.html : --------8<----------- Q. Which characters should be displayed as a visible but blank space? A: This is the easy one: all the characters that have the White_Space property, also generically known as “whitespace characters”. This set includes SPACE, of course, but also such characters as the tab control character, NO-BREAK SPACE, LINE SEPARATOR, and so on. For the full list, see the White_Space values in PropList.txt. -------->8------- That says quite clearly that U+0020 should not be rendered as a glyph but as an empty area in the text. There is one more interesting item on the list: -------------8<-------- Q. Does that mean that a font can never display one of these characters? A: No. Rendering systems may also support special modes such as “Display Hidden”, which are intended to reveal characters that would not otherwise display. Fonts can contain glyphs intended for visible display of default ignorable code points that would otherwise be rendered invisibly when not supported. -------------->8------------ That says that it's alright to have glyphs for "invisible" characters intended for use when an application enables a special mode to show control characters so it's not totally meaningless (though not very meaningful in most cases). Any objections to me making an imagepatch to remove the visible spaces in the reference image and tweaking the test description to make that clear? /Erik -- Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog: http://my.opera.com/macdev_ed
Received on Tuesday, 4 January 2011 14:48:17 UTC