- From: Masataka Yakura <myakura.web@gmail.com>
- Date: Thu, 9 Jul 2015 17:57:33 +0900
- To: Gérard Talbot <css21testsuite@gtalbot.org>
- Cc: Public CSS Test suite mailing list <public-css-testsuite@w3.org>, Koji Ishii <kojiishi@gluesoft.co.jp>
- Message-ID: <CANJXhd3Kn7mA264EqTw74R1kffRTDadYemTjSfc=ZJifHLMzxA@mail.gmail.com>
Hi Gérard, On Mon, Jun 22, 2015 at 9:10 AM, Gérard Talbot <css21testsuite@gtalbot.org> wrote: > Masataka, > > [src] > http://test.csswg.org/source/css-writing-modes-3/value-all-002.html > > [nightly-unstable] > > http://test.csswg.org/suites/css-writing-modes-3_dev/nightly-unstable/html/value-all-002.htm > > [reference file] > > http://test.csswg.org/source/css-writing-modes-3/reference/vertical-ahem-1x1-ref.html > > If you use the Ahem font, then it is preferable to also define the > line-height on block elements when you define the Ahem font size. > Otherwise, the gap between line boxes will be different from browsers to > browsers. > > When line-height is not defined, then 'line-height' defaults to 'normal' > and 'normal' computes to 1 in Webkit-based browsers and IE while it will > compute to 1.2 in Firefox for the Ahem font. > > Try this page in several browsers: > > > http://www.gtalbot.org/BrowserBugsSection/css21testsuite/experiments-va-lineheight-02.html > > Not specifying the line-height can make your reference file or your test > unreliable. Here, how you created the reference file vertical-ahem-1x1-ref > does not make your test incorrect. > Thanks for reviewing. I didn't know the default value for line-height differs by browser. Updated tests (including others needing the same fix) and sent a PR. https://github.com/w3c/csswg-test/pull/798 Personally, I try to use images in reference file: that way, I am sure the > reference file uses a different method from the test. What you did in the > reference file vertical-ahem-1x1-ref looks fine. > > If the test should create an 80px by 80px black area, then I recommend to > replace "rectangles" with "squares": this will help the person taking that > test in the test harness. > Updated. I examined your value-all-002 test because the black shapes are not > perfectly identical (Koji also noticed this! [1]) in Chrome 45.0.2431.0 ... > for unknown reasons right now. I tried to use a font-size of 75px which > would be dividable by 3 and dividable by 5 to avoid rounding issues but > this does not seem to be the reason why the black areas are not perfectly > identical. So, there may be a bug in Chrome after all. > > [1] : > > http://test.csswg.org/shepherd/testcase/value-all-002/spec/css-writing-modes-3/status/issue/#comment-2f386058f4ee > Yeah... I noticed that while developing these test cases but thought that might be a bug in Chrome. > [src] > http://test.csswg.org/source/css-writing-modes-3/value-all-003.html > > [nightly-unstable] > > http://test.csswg.org/suites/css-writing-modes-3_dev/nightly-unstable/html/value-all-003.htm > > [reference file] > > http://test.csswg.org/source/css-writing-modes-3/reference/vertical-ahem-1x1-ref.html > > I would like you to help me understand the spec thanks to this test. > > " > all > Attempt to typeset horizontally all consecutive characters within the > box such that they take up the space of a single character within the > vertical line box. > > digits <integer>? > > Attempt to typeset horizontally each maximal sequence of consecutive > ASCII digits (U+0030–U+0039) that has as many or fewer characters than the > specified integer such that it takes up the space of a single character > within the vertical line box. If the integer is omitted, it computes to 2. > Integers outside the range 2-4 are invalid. > " > 9.1 Horizontal-in-Vertical Composition: the text-combine-upright property > http://www.w3.org/TR/css-writing-modes-3/#text-combine-upright > > There seems to be no implicit (and no explicit) range limit to the number > of consecutive characters when using 'text-combine-upright: all' but there > is a range 2-4 limit with 'text-combine-upright: digits n': is that > correct? To me, this seems odd and incoherent. > > If there is no range limitation with 'text-combine-upright: all', then why > should there be one with 'text-combine-upright: digits n' where 'n' would > be a [2-9] digit? > So sorry for catching up late; it looks like editors have already answered the questions... -- Masataka Yakura <myakura.web@gmail.com>
Received on Thursday, 9 July 2015 08:58:42 UTC