Re: CSS3-text: line-break - strict

Le Ven 8 février 2013 3:30, taka a écrit :
> Please review this again as I have modified the test case with
> Gerard-san's useful comments.
> Also, I commented my thoughts in line below.
> regards,
> (2013/02/08 10:55), "Gérard Talbot" wrote:
>> Le Jeu 7 février 2013 10:07, taka a écrit :
>>> Hello
>>> Attached I re-submitted the subject test case for your review. I
>> appreciate your kind review for this and your comments back to me.
Please note this is the first outcome of a series of multiple
>> sub-tests
>>> and the rest will be followed after this review process completes.
>> 1-
>> line 5: <title>CSS Test: line-break - strict - Japanese small
>> kana</title>
>> "
>> For specifications other than CSS 2.1, you can include the module
name
>> somewhere before the colon, like “CSS Selectors Test:†or “CSS
Test
>> (Selectors):”. Do not include the module version number, since the
test
>> might get reused for the next version.
>> "
>> http://wiki.csswg.org/test/format#title-element
>> So here,
>> <title>CSS Text Test: line-break - strict - Japanese small
>> kana</title>
>> is ok.
> I agree.
>> 2-
>> line 7: <link rel="help" title="CSS Text Module Level 3: 5.2.
Breaking
>> Rules for Punctuation: the ‘line-break’ property"
>> href="http://www.w3.org/TR/css3-text/#line-break" />
>> <link rel="help" title="5.2. Breaking Rules for Punctuation: the
'line-break' property"
>> href="http://www.w3.org/TR/css3-text/#line-break" />
>> is okay.
> I agree.
>> 3-
>> line 8:		<link rel="match" href=""/>
>> Don't forget to link to a reftest if and when there is one. There should
>> be one for line-break-strict-011.xht
> I believe a reftest is not needed for this test case since the second
line, which source is shown below, gives a reference with a different
rendering technique.


Taka,

Yes, the <p class="control"> is indeed a reference using a different
technique. The main reason to create a reftest is to make automated
checking possible. A software takes a screenshot of the test, then takes
a screenshot of the reftest and then compare them at the pixel level.

"
reftests can be scripted to run and report results automatically.

A test can be both a self-describing tests and a reftest at the same
time. This is preferable, since it allows for both machine comparison
and manual verification – particularly useful if the test and the
reference both render incorrectly in the same way!
"
http://wiki.csswg.org/test/reftest#reftests

Here, your test is already a self-describing test.


> <p class="control">
> <span>サンプル文サンプル<br />文<span
> class="target">&#x3041;</span>サン
> プル文</span>
> </p>
> Even if I develop a reftest, I merely repeat the above <p
> class="control"> ~ </p>, and it must be redundant, I believe.

Yes. Exactly. Many reftests have been done like that, by merely
repeating twice what was the control (the reference) in the test.

So, the reftest for line-break-strict-011.xht test should look like:

http://www.gtalbot.org/BrowserBugsSection/review/line-break-strict-011-ref-review.xht


>> 4-
>> line : <meta http-equiv="content-language" content="en, ja" />
>> Using the lang attribute, you can hint/help browsers about lang; I'm not
>> sure if this makes any significative/worthy difference.
>> <body lang="en">
>> <p class="test" lang="ja">
>> <p class="control" lang="ja">
> As the whole contents are by xml utf-8, I believe an additional "lang"
attribute must be redundant.
> So that, I will delete a line <meta http-equiv="content-language"
content="en, ja" />, and I do not indicate lang="ja" in <body> and <p>
tags, to avoid somewhat vague.
>> 5-
>> line 20: font-family: "IPAMincho", "IPAGothic",
"IPA&#26126;&#26397;",
>> "IPA&#12468;&#12471;&#12483;&#12463;";
>> At the IPA fonts page, there's IPAexMincho Ver.002.01 and IPAexGothic
Ver.002.01 fonts. I'm not sure if installing one of those would make
the
>> test fail anyway... while the CSS declaration is specifically looking
for IPAMincho and IPAGothic fonts.
>> I use Linux Kubuntu (a Debian distribution) and IPAMincho (Ver.
00303-10), IPAexMincho, IPAPMincho, IPAGothic (Ver. 00303-10),
>> IPAexGothic, IPAPGothic packages are installable.
>> Eg
>> [Ku|Lu|U|Xu]buntu 12.10
>> http://packages.ubuntu.com/en/quantal/all/fonts-ipafont-mincho/download
Debian :
>> http://packages.debian.org/en/sid/all/fonts-ipafont-mincho/download
Your test specifies IPAMincho and not IPAexMincho and not
>> IPAPMincho. Same thing for IPAGothic.
>> [Addendum: after a lot of testing, I believe Firefox 18.0.2 requires
both IPAMincho and IPAexMincho fonts to be installed while Opera
12.14
>> and Chrome 24.0.1312.69 only requires IPAMincho font installed: that is
>> the conclusion I reach on my Linux KDE 4.10 i686 system.]
>> I think all of your tests should only have one single text and link
to
>> a
>> list of downloadable and installable set of Japanese fonts: this
would
>> greatly ease the task of testers, I think. Such set of Japanese fonts
would have to be included in or fetchable from
>> http://www.w3.org/Style/CSS/Test/Fonts/


Right now, such set of Japanese fonts have not been included in or
fetchable from
http://www.w3.org/Style/CSS/Test/Fonts/

I think we need to ask Bert Bos to do this...


>> Usually, tests that require a special font to be installed will start
with
>> "
>> PREREQUISITE: Operating system needs to have the 'foobar' font
>> installed.
>> Post Test: Remove test font after running the test.
>> "
>> Eg
>> http://test.csswg.org/shepherd/search/testcase/spec/css21/author/microsoft/flag/font/content/PREREQ/
> Thanks for your careful and thorough investigations, I agree.
> I would like to place the PREREQUISITE statement at the bottom instead
of the top in order to help those who already installed the fonts to
concentrate on continued testings.


Ideally, a good test system would not have such prerequisite statement
if the browser was able to "know" if the test font is already installed
in the operating system.

Adding

	@font-face
	{
	font-family: "IPAMincho";
	src: url("support/ipam.ttf"); /* Filesize: 8046712 bytes */
	}

	@font-face
	{
	font-family: "IPAGothic";
	src: url("support/ipag.ttf"); /* Filesize: 6235344 bytes */
	}

could be another possibility:


http://www.gtalbot.org/BrowserBugsSection/review/line-break-strict-011-review2.xht

Right here, I believe we need a discussion in the mailing list to allow
or disallow @font-face and TTF font embedding in tests.

The loading and processing of the embedded fonts can be long and take 10
seconds.

Gérard


>> 6-
>> line 32: <h1> Japanese small kana </h1>
>> 		<p>
>> 			Test passes if the highlighted character in both rectangles is at
>> the
>> exact same horizontal position.<br />
>> line 35:		</p>
>> I think <h1> Japanese small kana </h1> does not help the testers and is
>> not really part of the test; this could be in <!-- a comment --> in the
>> source code. The <br /> is not needed as p element have default 1em
vertical (top and bottom) margins in all browsers.
> I agree.
>> Finally, a demo-example with all these changes and with increased
font-size + line-height:
> thank you and I agree.
>> http://www.gtalbot.org/BrowserBugsSection/review/line-break-strict-011-review.xht
Gérard
> --
> taka oshiyama 押山 隆
> takaoshiyama@gmail.com


-- 
Contributions to the CSS 2.1 test suite:
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/

CSS 2.1 Test suite RC6, March 23rd 2011:
http://test.csswg.org/suites/css2.1/20110323/html4/toc.html

CSS 2.1 test suite harness:
http://test.csswg.org/harness/

Contributing to to CSS 2.1 test suite:
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html

Received on Friday, 8 February 2013 22:52:07 UTC