[webkit-dev] testing strategy? - CJK line breaking tests
rniwa at webkit.org
Tue Sep 4 05:30:27 PDT 2012
Can we use ref tests?
Alternatively, you can compute the with of each character with script
(without adding any new feature to WebKit).
If neither is possible, then you should use (1) unless the test tests a
platform specific feature; I.e. the feature isnt available on other
(3) seems like a terrible idea as it means that we'll be either exposing
the WebKit internals to the Web without standardizing those properties or
we'll be adding yet-another DRT-specific behavior
On Tuesday, September 4, 2012, Glenn Adams wrote:
> What is the recommended approach to test cases when one needs to use a CJK
> font that covers the test data? I could use DRT text results as expected
> but given lack of common font across platforms, that doesn't seem to be
> From my somewhat limited (i.e., newbie) exposure to WK, I gather one can
> take one of the following approaches:
> (1) put font (and thus platform) dependent test cases in non-platform test
> directory, then add entries to Skipped for other platforms; this seems the
> current approach with many platform/font dependent tests, especially
> related to I18N features;
> (2) put font (and thus platform) dependent test cases in platform test
> directory, possibly ending up with separate tests per platform;
> (3) what would be nice is to not generate rendering dump from DRT but
> instead use script only; since I'm testing line-breaking logic, what would
> do nicely is a set of internal styles available via getComputedStyle() on a
> block element:
> - -webkit-line-count - numeric value indicating number of formatted
> lines produced from rendering a block
> - -webkit-line-chars-1 through -N, which returns the chars of line N
> as formatted when rendering a block
> That is, with these properties, I could use script to determine which line
> breaks occurred and where. I don't care about geometries or pixels in these
> particular tests, just whether breaks occur in specific contexts.
> Any recommendations on whether to pursue one of (1) or (2) above, or try
> the more ambitious (but more platform independent) third approach?
> I suppose I could start with (1) or (2) and then pursue (3) as a
> subsequent task.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev