<br><div class="gmail_quote">On Tue, Sep 4, 2012 at 8:30 PM, Ryosuke Niwa <span dir="ltr">&lt;<a href="mailto:rniwa@webkit.org" target="_blank">rniwa@webkit.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Can we use ref tests?</blockquote><div><br></div><div>I&#39;ll try this first.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>Alternatively, you can compute the with of each character with script (without adding any new feature to WebKit).</div>

</blockquote><div><br></div><div>Unfortunately, that won&#39;t work since I can&#39;t access the width of individual lines produced by formatting a block. For example, &lt;p style=&quot;width:2em&quot;&gt;XYZ&lt;/p:&gt;, where XYZ are certain CJK line break sensitive chars, may format to</div>

<div><br></div><div>line-break: loose</div><div><br></div><div>line1: XY</div><div>lline2: Z</div><div><br></div><div>line-break: strict</div><div><br></div><div>line1: X</div><div>line2: YZ</div><div><br></div><div>The getComputedValue(&#39;width&#39;|&#39;height&#39;| of the two results doesn&#39;t vary since one can&#39;t access the resulting lines.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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.</div>

</blockquote><div><br></div><div>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&#39;t work, I&#39;ll try (1). </div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>(3) seems like a terrible idea as it means that we&#39;ll be either exposing the WebKit internals to the Web without standardizing those properties or we&#39;ll be adding yet-another DRT-specific behavior</div>

</blockquote><div><br></div><div>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).</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="h5"><span></span><br>
<br>On Tuesday, September 4, 2012, Glenn Adams  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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&#39;t seem to be effective.<div>




<br></div><div>From my somewhat limited (i.e., newbie) exposure to WK, I gather one can take one of the following approaches:</div><div><br></div><div>(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;</div>




<div>(2) put font (and thus platform) dependent test cases in platform test directory, possibly ending up with separate tests per platform;</div><div>(3) what would be nice is to not generate rendering dump from DRT but instead use script only; since I&#39;m testing line-breaking logic, what would do nicely is a set of internal styles available via getComputedStyle() on a block element:</div>




<div><ul><li>-webkit-line-count - numeric value indicating number of formatted lines produced from rendering a block</li><li>-webkit-line-chars-1 through -N, which returns the chars of line N as formatted when rendering a block</li>




</ul><div>That is, with these properties, I could use script to determine which line breaks occurred and where. I don&#39;t care about geometries or pixels in these particular tests, just whether breaks occur in specific contexts.</div>




<div><br></div><div>Any recommendations on whether to pursue one of (1) or (2) above, or try the more ambitious (but more platform independent) third approach?</div></div><div><br></div><div>I suppose I could start with (1) or (2) and then pursue (3) as a subsequent task.</div>




<div><br></div><div>Regards,</div><div>Glenn</div><div><br></div>
</blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><br><br>-- <br>Ryosuke Niwa<br><font color="#999999">Software Engineer</font><div><font color="#999999">Google Inc.</font></div><div><font color="#999999"><br>

</font></div><br>
</font></span></blockquote></div><br>