September 2010 - webkit-dev - lists.webkit.org

Ruby Text Enhancements
by Eric Mader 22 Sep '10

22 Sep '10

Hi, I'm working on making the following enhancements to Ruby Text: 1) Implement the behavior of ruby-overhang:auto 2) implement the behavior of ruby-line-stacking:exclude-ruby 3) Add some Mac OS specific character properties to the ruby text 4) Turn off the underline when the ruby text is in a link I've looked at the code enough to know that the layout or ruby text is done by the normal block stacking in BlockLayout. I'm guessing that I can do at lest the first two tasks by changing the RenderRuby code to report a different width and / or height for the ruby block. Does this seem like the right way to do what I want? Assuming for the moment that it is, I have some questions: 1) What methods should I subclass to report the adjusted width and height? 2) If the ruby text is wider than the ruby base and I report the width of the base as the width of the whole block will some of the ruby text get clipped, or will it all still draw? 3) Ruby text is only allowed to overhang the base in some cases. To know when it's OK, I'll need to examine the neighboring text. Can I always find the neighboring text by walking the render tree? About turning off the underline if the ruby is in a link: I've looked at the styles and tried adding code to change the parts that I think relate to this, but haven't found anything that makes a difference. It's also occurred to me that I might be able to do this by writing a rule in <WebKit>WebCore/css/html.css, but I can't figure out exactly what the rule would look like. I tried adding "text-decoration: none" to the "ruby > rt" section, but that doesn't do it. (at first, I thought that is was probably overkill, but now I think that turning text-decoration off for all ruby text is probably right.) Regards, Eric Mader

4 7

Testing XHR
by Luke Macpherson 21 Sep '10

21 Sep '10

WebKit (or at least Chrome) is currently failing a bunch opera's tests located at: http://tc.labs.opera.com/apis/XMLHttpRequest/ It seems that it would be a good idea for us to make use of these tests in WebKit, so I was thinking of importing them into the codebase. This raises the question: Should we import the tests one at a time as we fix the bugs, or should we import the whole suite? The tests look like they will fit into the existing LayoutTests infrastructure pretty easily, but if we import the whole lot it would be good to figure out if it is possible to keep our copy in sync with Opera's, possibly along the lines of WebKitTools/Scripts/update-webgl-conformance-tests . Should they end up in a subdirectory of LayoutTests/http/tests? (They require php scripts on the server). Thanks, Luke

6 7

testing
by asadulla ansari 21 Sep '10

21 Sep '10

-- Regards " Navigate Today For Better Tomorrow!!!" mEeT mE LivE wItH tEcH cAkE @ http://hitechi.19.forumer.com/ http://go4expert.com/ http://www.liveperson.com/asadullah-ansari/ http://go4hitech.wordpress.com/

1 0

please add me
by asadulla ansari 21 Sep '10

21 Sep '10

-- Regards " Navigate Today For Better Tomorrow!!!" mEeT mE LivE wItH tEcH cAkE @ http://hitechi.19.forumer.com/ http://go4expert.com/ http://www.liveperson.com/asadullah-ansari/ http://go4hitech.wordpress.com/

1 0

Review tool changes
by Darin Adler 20 Sep '10

20 Sep '10

Hi Adam. A few thoughts on the review tools on bugs.webkit.org. 1) I am happy with the review tool. I have been using it for a lot of reviews. There may be no one left who prefers the old review page. 2) It’s kind of crazy that the review tool’s URL is "...&action=prettypatch". It was nice of you to leave the old review tool unchanged, at least in part to placate me, but you’re squatting on another feature’s territory! I think we want a plain old formatted diff for other purposes. We need to get your tool out of there! 3) I suggest you make your review tool the default at "...&action=review" and move the old style review tool to another URL; we can put a link in yours. I haven’t tried to use it on an iPad yet. -- Darin

16 25

Fwd: Fwd: Fwd: HTML5 & MathML3 entities
by Alexey Proskuryakov 20 Sep '10

20 Sep '10

Начало переадресованного сообщения: > От: David Carlisle <davidc(a)nag.co.uk> > Дата: 17 сентября 2010 г. 18:02:39 Тихоокеанское летнее время > Кому: Alexey Proskuryakov <ap(a)webkit.org> > Тема: Ответ: [webkit-dev] Fwd: Fwd: HTML5 & MathML3 entities > > On 18/09/2010 00:05, Alexey Proskuryakov wrote: >> >> 17.09.2010, в 15:32, David Carlisle написал(а): >> >>> adding a canonical decomposition doesn't imply deprecation. >>> Depending on which canonical form is chosen, the canonicalisation >>> mapping can go either way, loosely speaking some forms prefer >>> composite characters, some use combining characters in preference >>> (not that combining characters are involved here) >> >> This is not accurate. For singleton decomposition, both NFC and NFD >> contain the decomposed form. See Unicode 5.2.0 section D113 (full >> composition exclusion) for details. > > yes NFC and NFD are the same in these cases, but that doesn[t really change the main point that deprecation here is nothing to do with the character having a different normal form. Compare > ANGSTROM SIGN (212B) and > LATIN CAPITAL LETTER A WITH RING ABOVE (00C5) > these are similarly related by canonical form and so clearly C5 is preferred but 212B is not deprecated in the same way as 2329 is. > see the entry for 212B in > > http://www.unicode.org/charts/PDF/U2100.pdf > > 2329 is deprecated because it is replaced by 27E8 not because it > maps to something else in NFC. > >> >>> 2329 was deprecated some years after the canonical mapping was >>> added because it was realised that that mapping was wrong, but >>> mappings are never changed once added. It became deprecated not >>> when the mapping to 3008 was added; it became deprecated when it >>> was replaced by 27E8 I described it as a two step process because >>> it happened in two stages. >> >> Because of the above, I don't see how it could happen in two stages. >> Adding a singleton decomposition logically implies deprecation. And >> it wasn't until Unicode 5.2 that "deprecated" had a clearly defined >> meaning anyway. > If that were the meaning of deprecated in this case, the deprecated character would be deprecated in favour of its canonically equivalent character but that isn't the case. It is deprecated _because_ that incorrect decomposition exists, and is deprecated in favour of a new character added specifically to avoid the problem. >> >>> It was conformant to unicode 2 yes, the fact that unicode then >>> added a canonical form to 3xxx doesn't make them non conformant, >>> systems don't have to use NFC form and they don't have to use any >>> particular glyph, so for either reason it's perfectly conformant to >>> use a math character for 2329. >> >> Again, both composition and decomposition of U+2329 produces U+3008. > Yes but a system isn't obliged to compose or decompose (and most do not automatically in my experience) >> >>> The point is that there have been documents using those entities as >>> math character names in continuous use since the '80s why should >>> they all be broken? Not to mention the fact that the vast majority >>> of use of those entities in html will also be expecting a >>> mathematical bracket (even if on some systems, with some fonts the >>> character glyph used was actually designed for CJK punctuation). >>> >>> In fact where classical ISO usage and HTML usage differed I >>> followed HTML usage in all cases (for all the obvious reasons) even >>> when the HTML definitions make no sense at all (eg asymp) but in >>> this case external factors (ie Unicode moving the goalposts) meant >>> that the "new" Uniocde 3.2 character should be used here. >> >> Do these documents use the entities with the same "&...;" notation? > > yes, of course. > >> MathML didn't exist in the 80's, so what are the documents that >> actually conflict with HTML, or with compound XHTML documents? > > Well the point of breaking the mathml (and html) entities into a separate spec was to get a uniform set of definitions across different uses. If (as was the case) the same entity name (used via the same syntax) means different things in docbook, mathml and html, then formally you may argue that everything is OK and consistent, each document obeys its own language definition, but in practice moving fragments between documents results in silent data corruption. > the entity spec was separated out from the mathml spec in 2003 and went through numerous public revisions, people in the old and the new HTML groups were asked to commnt on it, people in the UTC/Unicode list and people on the original ISO working groups who defined the entitiy names originally, after 7 years of open review it went to REC earlier this year (and MathML3 depending on it will hopefully go to REC this month) > > >>>>> the only fix the UTC suggest for that is just not using 2329 at >>>>> all and use 27E8 instead. Which is what the entity spec >>>>> recommends. >>>> >>>> >>>> Did they actually suggest to use it for the lang entity in HTML, >>>> or did they suggest to use it when a math character is desired? > > the comments were in relation to the entities draft which has the explicit intention of being a common set of definitions for any uses of these entity names. > >>> xhtml entities have document scope it is not possible for an >>> xhtml+mathml document to have different definitions for html and >>> mathml use, but even for pure html use it is fairly clear that 27e8 >>> is the correct choice. >> >> I wasn't asking about HTML vs. XHTML - both used to define&rang; in >> the same way. > > The same way as MathML2, actually. This change isn't about matching XHTML or MathML2, it's about tracking changes to Unicode. > > I can re-phrase my question as "Did they actually >> suggest to use it for the lang entity in (X)HTML, or did they suggest >> to use it when a math character is desired?" >> > >> >> I don't think that characterizing what we did in WebKit as bizarre in >> the extreme is fair. > > fair or not, I think it is was clearly the wrong thing to do (even if well intentioned) nothing in HTML or XHTML specifications would licence such a definition. You could claim perhaps that you were using HTML followed by NFC normalisation, but that's a very weak argument I think. > > The Unicode spec (or at least the code chart page at http://www.unicode.org/charts/PDF/U2300.pdf which is what I have to hand) doesn't say it is deprecated in favour of 3009 it says that it is deprecated _because_ of the equivalence to CJK punctuation and that mathematical use is strongly recommended to use 27e8 instead. > > It is very hard to think that anyone using CJK characters (and so presumably with access to some convenient keyboarding scheme for those code ranges) suddenly requires an ascii entity name reference to access a punctuation character. Conversely mathematical usage habitually uses long ascii names for characters, It is clear that rang and lang have always been intended as mathematical characters, and I ask again whether you really think that (barring artificial test cases) anyone writing in CJK languages uses these english ascii entity references for just those two characters? I don't see how it is possible to read Uniocde as saying anything other than rang ought to point to 27e8 > > Unicode techical report 25 says > > Unicode 3.2 added two new mathematical angle bracket characters ⟨ ⟩ (U+27E8 and U+27E9) that are unequivocally intended for mathematical use and should be used instead of U+2329 and U+232A. > > > > David > > - WBR, Alexey Proskuryakov

3 4

Canvas component in Bugzilla
by Andreas Kling 20 Sep '10

20 Sep '10

Hey folks! I propose we add a "Canvas" component in Bugzilla. Thoughts? -Kling

3 2

map.d.co.il broken - back out r66156?
by Jeremy Moskovich 19 Sep '10

19 Sep '10

Hi, http://trac.webkit.org/changeset/66156/ broke map.d.co.il which is one of the larger maps sites in Israel. https://bugs.webkit.org/show_bug.cgi?id=45679 was filed to track this. Andy: do you have an eta for a fix? Are you ok reverting the change in the interim? Best regards, Jeremy

3 3

Path::createEllipse() - why not leverage port paths?
by Andreas Kling 19 Sep '10

19 Sep '10

Hey folks, Is there a reason we're manually creating the ellipses in Path::createEllipse() instead of using the port-specific Path::addEllipse()? For the SVG version of the benchmark at http://www.themaninblue.com/writing/perspective/2010/03/22/ we're spending roughly 25% of runtime in Path::createEllipse(), whereas if I let it use Qt's Path::addEllipse() it drops to 2.5%. (Qt is also much better at rendering the paths generated by QPainterPath::addEllipse() instead of the 100x LineTo paths from Path::createEllipse - time spent filling paths goes down from 30% to 25%.) All in all, these are 15 additional FPS that I'd love to get if possible. So lay it on me :-) Curiously yours, -Kling

3 4

Re: [webkit-dev] Fwd: Fwd: HTML5 & MathML3 entities
by Alexey Proskuryakov 17 Sep '10

17 Sep '10

17.09.2010, в 15:32, David Carlisle написал(а): > adding a canonical decomposition doesn't imply deprecation. > Depending on which canonical form is chosen, the canonicalisation mapping can go either way, loosely speaking some forms prefer composite characters, some use combining characters in preference (not that combining characters are involved here) This is not accurate. For singleton decomposition, both NFC and NFD contain the decomposed form. See Unicode 5.2.0 section D113 (full composition exclusion) for details. > 2329 was deprecated some years after the canonical mapping was added > because it was realised that that mapping was wrong, but mappings are never changed once added. It became deprecated not when the mapping to 3008 was added; it became deprecated when it was replaced by 27E8 > I described it as a two step process because it happened in two stages. Because of the above, I don't see how it could happen in two stages. Adding a singleton decomposition logically implies deprecation. And it wasn't until Unicode 5.2 that "deprecated" had a clearly defined meaning anyway. > It was conformant to unicode 2 yes, the fact that unicode then added a canonical form to 3xxx doesn't make them non conformant, systems don't have to use NFC form and they don't have to use any particular glyph, so for either reason it's perfectly conformant to use a math character for 2329. Again, both composition and decomposition of U+2329 produces U+3008. > The point is that there have been documents using those entities as math character names in continuous use since the '80s why should they all be broken? Not to mention the fact that the vast majority of use of those entities in html will also be expecting a mathematical bracket (even if on some systems, with some fonts the character glyph used was actually designed for CJK punctuation). > > In fact where classical ISO usage and HTML usage differed I followed HTML usage in all cases (for all the obvious reasons) even when the HTML definitions make no sense at all (eg asymp) but in this case > external factors (ie Unicode moving the goalposts) meant that the "new" Uniocde 3.2 character should be used here. Do these documents use the entities with the same "&...;" notation? MathML didn't exist in the 80's, so what are the documents that actually conflict with HTML, or with compound XHTML documents? I see that <http://www.w3.org/TR/xml-entity-names/> defines multiple names for the same code points: "lang, langle, LeftAngleBracket and rang, rangle, RightAngleBracket". Do they all really need to have the same meaning? >>> the only fix the UTC suggest for that is just not using 2329 at all >>> and use 27E8 instead. Which is what the entity spec recommends. >> >> >> Did they actually suggest to use it for the lang entity in HTML, or >> did they suggest to use it when a math character is desired? > > xhtml entities have document scope it is not possible for an xhtml+mathml document to have different definitions for html and mathml use, but even for pure html use it is fairly clear that 27e8 is the correct choice. I wasn't asking about HTML vs. XHTML - both used to define &rang; in the same way. I can re-phrase my question as "Did they actually suggest to use it for the lang entity in (X)HTML, or did they suggest to use it when a math character is desired?" > rang was never defined to be 3009, it was defined to be 232A and documented as being a math angle bracket. Unicode have deprecated 232A and suggest that any uses of that be replaced by 27E9 because 232A is effectively unusable as it is subject to an essentially accidental and incorrect normalisation to 3009. > > It would be bizarre in the extreme to redefine rang to be 3009 (is there any evidence of anyone ever having used that entity name and wanting a CJK character?) I don't think that characterizing what we did in WebKit as bizarre in the extreme is fair. The Unicode spec said that 232A is deprecated in favor of 3009, so it was the only formally correct thing to do. - WBR, Alexey Proskuryakov

1 0