- From: Cameron McCormack <cam@mcc.id.au>
- Date: Mon, 21 Jan 2008 17:12:17 +1100
- To: www-svg <www-svg@w3.org>
- Message-ID: <20080121061217.GD7466@arc.mcc.id.au>
Doug Schepers:
> Given the popularity of the ACID tests for browser interoperability,
> we'd like to get some SVG tests in there for the next version. A few of
> us on the SVG WG put together some tests, and I thought some of your
> might be interested in them as well. I'm forwarding on Erik
> Dahlstrom's explanatory email, with the tests attached. If anyone has
> any suggestions for good SVG interoperability tests, either for the
> official ACID tests or for a dedicated "SVG ACID Test", feel free to let
> us know.
Here’s my (one) test, too, attached. Here’s the description of the
test, from the contents of the file:
This tests various features of SVG fonts from SVG 1.1. It consists of
a <text> element with 33 characters, styled using an SVG font that has
different advance values for each glyph. The script uses
SVGTextElementContent.getStartPositionOfChar() to determine where the
glyph corresponding to each character was placed, and thus to work out
whether the SVG font was used correctly.
The font uses 100 units per em, and the text is set in 100px. Since
font-size gives the size of the em box
(http://www.w3.org/TR/SVG11/text.html#DOMInterfaces), the scale of the
coordinate system for the glyphs is the same as the SVG document.
The expectedAdvances array holds the expected advance value for each
character, and expectedKerning holds the (negative) kerning for each
character. getPositionOfChar() returns the actual x coordinate for the
glyph, corresponding to the given character, and if multiple characters
correspond to the same glyph, the same position value is returned for
each of those characters.
Here are the reasonings for the advance/kerning values. Note that for
a given character at index i, the expected position is
sum(expectedAdvances[0:i-1] + expectedKerning[0:i-1]).
char advance kerning reasoning
------- ------- ------- --------------------------------------------------
A 10000 0 Normal character mapping to a single glyph.
B 0 0 First character of a two character glyph, so the
current position isn't advanced until the second
character.
C 200 0 Second character of a two character glyph, so now
the position is advanced.
B 300 0 Although there is a glyph for "BC" in the font,
it appears after the glyph for "B", so the single
character glyph for "B" should be chosen instead.
D 1100 0 Normal character mapping to a single glyph.
A 10000 200 Kerning of -200 is specified in the font between
the "A" and "EE" glyphs.
E 0 0 The first character of a two character glyph "EE".
E 1300 0 The second character of a two character glyph.
U 0 0 This is a glyph for the six characters "U+0046",
which happen to look like a valid unicode range.
This tests that the <glyph unicode=""> in the
font matches exact strings rather than a range,
as used in the kerning elements.
+ 0 0 Second character of six character glyph.
0 0 0 Third character of six character glyph.
0 0 0 Fourth character of six character glyph.
4 0 0 Fifth character of six character glyph.
6 1700 0 Sixth character of six character glyph.
U 0 0 The same six character glyph that looks like a
Unicode range. One of the kerning elements has
u1="U+0046" u2="U+0046", which shouldn't match
this, because those attributes are interpreted
as Unicode ranges if they are, and normal
strings otherwise. Thus there should be no
kerning between these two glyphs.
G 2300 200 Kerning is between this character and the next
"G", since there is an <hkern> element that
uses a Unicode range on its u1="" attribute
and a glyph name on its g2="" attribute which
both match "G".
G 2300 0 Normal character with kerning before it.
H 3100 0 A glyph with graphical content describing the
glyph, rather than a d="" attribute.
I 4300 0 Glyphs are checked in document order for one
that matches, but the first glyph with
unicode="I" also has lang="zh", which disqualifies
it. Thus the second glyph with unicode="I"
is chosen.
I 4100 0 Since this I has xml:lang="zh" on it in the text,
the first glyph with lang="zh" matches.
J 4700 -4700 A normal glyph with kerning between the "J" and the
next glyph "A" equal to the advance of the "J"
glyph, so the position should stay the same.
A 10000 0 Normal glyph with kerning before it.
K 5900 0 The first glyph with unicode="K" does not match,
since it has orientation="v", so the second
glyph with unicode="K" is chosen.
<spc> 6100 0 The space character should select the glyph with
unicode=" ", despite it having a misleading
glyph-name="L".
L 6700 0 The "L" character should select the glyph with
unicode=" ", despite it having a misleading
glyph-name="spacev".
A 2900 0 An <altGlyph> element is used to select the
glyph for U+10085 instead of the one for "A".
U+10085 2900 0 Tests glyph selection with a non-plane-0
character.
A 10000 0 A final normal character.
In addition, the script tests the value returned by
SVGTextContentElement.getNumberOfChars(), which in this case should be 33.
If it returned 34, then it incorrectly counted UTF-16 codepoints or
something.
See http://www.w3.org/TR/SVG11/fonts.html for a description of the glyph
matching rules, and http://www.w3.org/TR/SVG11/text.html#DOMInterfaces
for a description of getStartPositionOfChar() and getNumberOfChars().
Note also that the test uses DOMImplementation.createDocument() to create
the SVG document. This seems to cause browsers trouble for the SVG DOM
interfaces, since the document isn't being "rendered" as it might be
if it were in an <iframe>. Changing the test to use an <iframe> will
at least let you see the main part of the test running.
--
Cameron McCormack, http://mcc.id.au/
xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
Attachments
- application/x-javascript attachment: submission.js
Received on Monday, 21 January 2008 06:12:33 UTC