September 2006 - webkit-dev - lists.webkit.org

Re: [webkit-dev] drawComplextText
by Mike Reed 05 Sep '06

05 Sep '06

Thanks! I'll dig in and try them out. On 9/5/06, David Hyatt <hyatt(a)apple.com> wrote: > > It's worth noting that the set of complex text tests has grown > smaller over time as we made the simple fast path able to handle more > and more. We could probably use more complex tests at this point. > > dave > > On Sep 5, 2006, at 12:09 PM, David Hyatt wrote: > > > Yeah, should be some in fast/text/international > > > > dave > > > > On Sep 5, 2006, at 11:59 AM, Mike Reed wrote: > > > >> I'd like to implement/test the ...ComplexText() methods on Font. > >> Are there checked-in layout tests that exercise these functions? > >> > >> thanks, > >> mike > >> > >> _______________________________________________ > >> webkit-dev mailing list > >> webkit-dev(a)opendarwin.org > >> http://www.opendarwin.org/mailman/listinfo/webkit-dev > > > > _______________________________________________ > > webkit-dev mailing list > > webkit-dev(a)opendarwin.org > > http://www.opendarwin.org/mailman/listinfo/webkit-dev > >

1 0

drawComplextText
by Mike Reed 05 Sep '06

05 Sep '06

I'd like to implement/test the ...ComplexText() methods on Font. Are there checked-in layout tests that exercise these functions? thanks, mike

2 2

Problems porting layout tests to linux
by Jean-Charles VERDIE 05 Sep '06

05 Sep '06

Hi, My team is currently working on having the layout tests ported to linux, to ease our future tasks on completing current efforts to make webkit available for linux. We have a big issue, which is that free type does not render text the same way as OSX does. The expected results do not match. We tried to hack freetype to make this work, but no obvious solution revealed. We started today a thread there to see if they have a solution. Here is an example of the diff we get : - RenderTable {TABLE} at (0,18) size 88x52 [bgcolor=#FFA500] [border: (1px outset #808080)] - RenderTableSection {TBODY} at (1,1) size 86x50 - RenderTableRow {TR} at (0,2) size 86x22 - RenderTableCell {TD} at (2,14) size 24x22 [border: (1px inset #808080)] [r=0 c=0 rs=2 cs=1] - RenderText {#text} at (2,2) size 20x18 - text run at (2,2) width 20: "X1" - RenderTableCell {TD} at (28,2) size 27x22 [border: (1px inset #808080)] [r=0 c=1 rs=1 cs=1] - RenderText {#text} at (2,2) size 20x18 - text run at (2,2) width 20: "X2" - RenderTableRow {TR} at (0,26) size 86x22 - RenderTableCell {TD} at (28,26) size 27x22 [border: (1px inset #808080)] [r=1 c=1 rs=2 cs=1] + RenderTable {TABLE} at (0,18) size 87x52 [bgcolor=#FFA500] [border: (1px outset #808080)] + RenderTableSection {TBODY} at (1,1) size 85x50 + RenderTableRow {TR} at (0,2) size 85x22 + RenderTableCell {TD} at (2,14) size 23x22 [border: (1px inset #808080)] [r=0 c=0 rs=2 cs=1] + RenderText {#text} at (2,2) size 19x18 + text run at (2,2) width 19: "X1" + RenderTableCell {TD} at (27,2) size 27x22 [border: (1px inset #808080)] [r=0 c=1 rs=1 cs=1] + RenderText {#text} at (2,2) size 19x18 + text run at (2,2) width 19: "X2" + RenderTableRow {TR} at (0,26) size 85x22 + RenderTableCell {TD} at (27,26) size 27x22 [border: (1px inset #808080)] [r=1 c=1 rs=2 cs=1] We imagine a solution which is to drop our goal to fix the problem, and instead generate "linux"-based -expected.txt files and to modify dump render tree to either chose osx or linux -based expected files, depending on the platform we are testing on. This solution has a major drawback, which is that it will force the community to maintain two version of expected files for every single test. Before starting to work in this direction, I'd appreciate some feedback on the feeling about this solution, and may be, fortunately, others ideas on how to remove this roadblock. Best regards -- Jean-Charles Verdié Origyn Web Browser for Embedded Systems Team CTO

5 9

xmlns attribute
by Rob Burns 02 Sep '06

02 Sep '06

Hello all, I think I've encountered a few bugs, but wanted to post here before I submit them to make sure I'm not doing something wrong. First, when I use "getAttribute:xmlns:SomePrefix" on a DOMElement it returns NUL even though this attribute is set on the root element and is still valid for the current scope. I thought this attribute was inherited and therefore should work on any sub-element in the hierarchy (scope). If that's not the proper way to get the namespaceURI for a namespacePrefix, is there another method for that? Second, when calling className method on a DOMElement I'm getting the class description for the instance rather than the class attribute. My sense was that the "className" was created to avoid collisions with "class" Shouldn't "className" return the "class" attribute while "class" instance method returns the instances class? Do I have these backwards? Best Wishes, Rob

2 2