Re: SVG Tiny bidi tests

Hello Richard,

Richard Ishida:
> Hello Olaf,
>
> Thanks for your comments.  See responses below...
>
....
>
> > - add pass/fail condition in the description
> > (or note the description completely as pass condition)
>
> I'm not quite sure what you mean here.  Each test has an assertion (eg. "
> Assertion: In the default context, if direction(rtl)+unicode-bidi(embed)
> are applied to an inline element containing mixed direction text, the text
> in that element will be displayed correctly. ") and pass/fail condition
> (eg. "The characters in the text immediately below should be in the same
> order as in the reference graphic below it. Font glyph differences are
> ok."). Is this not enough?  Or do you mean that I should put the text in a
> particular place in the markup?
>

That is mainly only about wording.
Some stereotype wording like
'The ... is tested.'
'The test is passed if ...'
'The main indications for a passed test are ...'
etc common to all tests indicate more clearly about what a
tester has to care, even if he is tired or not an expert for the
tested issue.
At least this was my impression reading both the  
http://dev.w3.org/SVG/docs/SVGTestSuite-howto.html
and some comments about some tests I provided earlier.
Typically I put some text into the test too, but such stereotypes
are pretty fine in the descriptions of the tests.


> > - One idea to improve several tests: the first and last glyph of
> > each test text could be decorated with two different colors,
> > this simplifies testing and identifying direction errors,
> > even if the tester does not know the meaning of the glyphs
> > or there are only missing glyph symbols, if the viewer has no
> > fitting font.
>
> Thanks for the idea.  I think this is relevant to the tests at
> http://www.w3.org/International/tests/svg/test-direction-unicode-bidi-0
> (rather than those at
> http://www.w3.org/International/tests/svg/test-direction-alignment-0 which
> test alignment only and for which direction of the text itself is factored
> out).  

For me it is always suspicious, what viewers might do.
For example the current version of Opera even manages to mix up
the rendering order (painters model) due to the animation of some
text attributes ;o)

> The problem in my mind is that the tests require you to check the 
> positions of characters at various points in each test result, rather than
> just look at what appears first and last. In many cases the first and last
> characters are not important for assessing the test.

The main problem I see is, that the font SVGFreeSans.svg#ascii covers
only some basic latin glyphs, not even sufficient to write for example
a german, french or spanish text. By the way, in your current versions,
this font is used/referenced by the tests, but seems to be not at that
indicated URI, therefore the viewer will currently always use the
generic font sans-serif. Even if the file is at the noted URI, the viewer
has to use anyway the generic font, if there is no fitting glyph in 
SVGFreeSans.svg#ascii, what is the case for all non basic latin glyphs
(the identifier is already called 'ascii', unicode range is restricted :o).

Due to my experience, it cannot be expected, that the generic font,
the viewer uses will have hebrew or arabic glyphs 
(Opera for example manages this on my system, Geckos or 
Konqueror+KSVG not, Squiggle gets an error 406 from the server.
On my computer system the adobe plugin uses only
exactly one font and this contains mainly latin glyphs).
Depending on the viewer, the font and some other circumstances
one can often expect to see either nothing at all or a missing glyph
symbol in such a situation. The first is a bad solution, because there
is no indication, that something is missing, the second is typically
sufficient, if the user does not understand the language anyway.
Then there is no need to install the fonts either ;o)

A way out could be of course, to provide an SVG-font-document
together with the tests to have all required glyphs or to define 
only the required glyphs within the document or to use some 
basic fantasy font only for the test, defined within the document to
ensure, that the tests really work for any tester.

Therefore the idea with the colors is indeed not sufficient, if
the viewer does not display anything for a missing glyph.
I think, these tests need their own glyphs to get some defined
and relyable behaviour.


>
> I also worried that the extra markup could introduce additional
> uncontrolled factors into the test.  It may, however, be worth making some
> tests with such markup to check that the markup doesn't affect things like
> direction and Arabic script joining.  But that's for another day.
>

Yes, indeed, this ensures a lot of more testing fun ;o)
'uncontrolled factors' are always interesting results from writing tests, 
they indicate either implementation problems, gaps or even worse 
gaps in the specification or problems in the understanding of the
specification, therefore this is the most exciting information one 
can get as an author of such tests ;o)

> Thank you, however, for taking the time to make the suggestion.
>

No problem.

Olaf


PS: Note, that the title elements for direction-unicode-bidi.php currently
contain "$_GET['test']; ?>"
I think, you have to write something like
"<?php echo $_GET['test']; ?>" to get what you want...

Received on Saturday, 15 November 2008 15:38:17 UTC