On Tue, Sep 4, 2012 at 8:30 PM, Ryosuke Niwa <rn...@webkit.org> wrote:
> Can we use ref tests? I'll try this first. > > Alternatively, you can compute the with of each character with script > (without adding any new feature to WebKit). > Unfortunately, that won't work since I can't access the width of individual lines produced by formatting a block. For example, <p style="width:2em">XYZ</p:>, where XYZ are certain CJK line break sensitive chars, may format to line-break: loose line1: XY lline2: Z line-break: strict line1: X line2: YZ The getComputedValue('width'|'height'| of the two results doesn't vary since one can't access the resulting lines. > 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 > platforms. > The feature is not platform specific (other than the fact different platforms may use different versions of ICU and support different fonts). If reftest doesn't work, I'll try (1). > > (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 > Certainly it is not be the intent to expose such props to web content in general. But I could fathom exposing this to WK test content (without necessarily being dependent on DRT framework). > > > 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 effective. >> >> 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. >> >> Regards, >> Glenn >> >> > > -- > Ryosuke Niwa > Software Engineer > Google Inc. > > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev