[webkit-dev] Antialiasing GraphicsContext::drawLine
I recently began to work on the square root implementation in MatML and I'm near to submit a patch. But as I'm new to WebKit development, I have a beginner question: To draw the square root, the GraphicsContext::drawLine method is called but it is written (in comments) to use it only for borders. Moreover this method enforces to turn antialiasing off. I have two possibilities: - modify that method to allow (optional) antialising - use other methods. It should be better but I don't know which one is adapted. Ideally, a polyline method should be great. Is there such a method? Probably yes, as SVG Canvas need advanced drawing. Any help is welcome! Thanks in advance, François Sausset Le 18 févr. 2010 à 19:38, Alexey Proskuryakov a écrit : Your question is not about WebKit development, so it should be directed to webkit-help mailing list. I've answered below, but please choose a correct e-mail list in the future. Please note that linking directly to WebCore is most definitely unsupported and extremely fragile. One should always be using platform-specific WebKit APIs. On 17.02.2010, at 18:27, Steve Hanna wrote: 136 WebCore::XPathResult* xpr = doc-evaluate(query, dynamic_castWebCore::Node*(doc), NULL, The XPathResult object is destroyed at this point, so the rest of the code operates on freed memory. One needs to keep the reference in RefPtr. Also, you don't need dynamic_cast when downcasting - and we build WebCore with RTTI disabled anyway. RefPtrWebCore::XPathResult xpr = doc-evaluate(query, doc, 0, WebCore::XPathResult::UNORDERED_NODE_ITERATOR_TYPE, NULL, ec); - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Turning on MathML by Default?
I'm also involved in implementing MathML and I share the Alex advice. MathML implementation has been asleep for too long. Turning it on by default should accelerate the recent progress. François Sausset Le 28 avr. 2010 à 14:40, Alex Milowski a écrit : With the latest patch (37044) having been committed, I feel like we're at a point where I'd like the MathML implementation to be available in the nightly builds. The code has been built and tested successfully on the Mac and Gtk builds. I intend to look at the windows build next. We have a growing community of developers and interested users and having a nightly build with MathML would allow testing, submission of issues, and receipt of fixes. What do others think? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] STIX Fonts and MathML Tests
If every is OK with licenses, how DumpRenderTree needs to be modified to use custom fonts? And where the fonts have to be stored? François Sausset Le 7 juil. 2010 à 20:51, Dan Bernstein a écrit : On Jul 7, 2010, at 9:57 AM, Alex Milowski wrote: The STIX fonts are relatively small (2.6MB for the full download) and we probably don't need all of them. Would it be acceptable to check these in like the Ahem font? Subject to WebKit’s licensing requirements, yes. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] STIX Fonts and MathML Tests
I filled a bug and submitted a patch with fonts and license only: https://bugs.webkit.org/show_bug.cgi?id=41961 Does anyone could tell if this license is compatible with the WebKit one? François Sausset Le 7 juil. 2010 à 21:25, Dan Bernstein a écrit : On Jul 7, 2010, at 11:17 AM, Sausset François wrote: If every is OK with licenses, how DumpRenderTree needs to be modified to use custom fonts? This is where the Mac version activates test fonts: http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/mac/DumpRenderTree.mm#L218 and this is where the Windows version does it: http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/win/DumpRenderTree.cpp#L275 You will also need to modify the build system to copy the additional fonts to the right places. And where the fonts have to be stored? Most are here: http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/fonts Ahem is currently in http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/qt/fonts but had better be moved to the cross-platform location. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] HTML5 MathML3 entities
I'm currently working on the MathML3 implementation and I noticed that new XML entities have been defined by the W3C: http://www.w3.org/TR/xml-entity-names/ They are supposed to be used by both HTML 5 MathML 3. I would like to include them in WebCore/html/HTMLEntityNames.gperf. However there is one conflict with the existing XHTML 1.0 entities: \rangle (and \langle) doesn't point to the same Unicode character in XHTML 1.0 and HTML 5 entity definitions. For instance, U+27E9 (⟩) instead of U+3009 (〉). There are two possibilities: - either update WebCore/html/HTMLEntityNames.gperf and overwrite the two conflicting cases with the new standard, but it won't respect the XHTML 1.0 specification anymore. - or use two sets of HTML entities depending on the DTD of the document. It would be the cleanest way, but I don't know how to make WebCore handle two such sets. I think the best solution is the second one, but I'll need help to make WebCore handle two entity sets and switch depending on the DTD. It is outside of my present skills. François Sausset ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 MathML3 entities
I just saw that when looking at the code by myself. What do you exactly mean by a prefix tree? I also noticed that the entity parser does not take into account combined Unicode characters (see §A.3 in: http://www.w3.org/TR/xml-entity-names/). In addition, even without entities, combined characters are displayed as separate ones. François Sausset Le 10 juil. 2010 à 21:00, Adam Barth a écrit : Implementing MathML entities is not as easy as adding them to HTMLEntityNames.gperf. The problem is our entity parsing code (both the legacy entity parser and thew new HTML5 one we're using) assumes that all named entities are = 8 characters: http://trac.webkit.org/browser/trunk/WebCore/html/HTMLEntityParser.cpp#L194 Rather than just bumping up that number, we need to change the data structure we use to store entities. Instead of a perfect hash, we should use a prefix tree. In order to parse entities correctly according to the spec, we need to know whether a given string is a prefix of a named entity, which is what the prefix tree would tell us. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 MathML3 entities
I'm not sure to understand everything, but the given link doesn't deal with the case where an entity should be translated to 2 Unicode characters, instead of only one as it is the case with the current hash table system. Such 2 characters entities don't exist in the HTML 5 entity list, but some are present in the one used by MathML 3 (link in my previous message). François Sausset Le 10 juil. 2010 à 21:17, Adam Barth a écrit : On Sat, Jul 10, 2010 at 11:10 AM, Sausset François saus...@gmail.com wrote: I just saw that when looking at the code by myself. What do you exactly mean by a prefix tree? http://en.wikipedia.org/wiki/Trie I also noticed that the entity parser does not take into account combined Unicode characters (see §A.3 in: http://www.w3.org/TR/xml-entity-names/). In addition, even without entities, combined characters are displayed as separate ones. My understanding is that is the correct behavior w.r.t. the HTML5 specification of entity parsing. Our entity processing aims for perfect compliance with this algorithm: http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#tokenizing-character-references My belief is the only things we're missing for perfect compliance is the expanded list of entity names: http://www.whatwg.org/specs/web-apps/current-work/multipage/named-character-references.html#named-character-references and the prefix tree. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 MathML3 entities
My aim was not to rush. I'm currently looking at what needs to be implemented in WebKit to support MathML 3. I noticed that a lot of entities are not implemented and I first thought it was easy to implement. After this discussion on the mailing list, it appears not to be so simple. I filled a bug to continue the discussion and track the progresses in a refactoring of the entity parser: https://bugs.webkit.org/show_bug.cgi?id=42041 François Sausset Le 11 juil. 2010 à 04:21, Maciej Stachowiak a écrit : On Jul 10, 2010, at 9:36 AM, Alexey Proskuryakov wrote: 10.07.2010, в 04:49, Maciej Stachowiak написал(а): Go with the HTML5 / MathML 3 definitions for everything. Our XHTML implementation targets XHTML5, not XHTML 1.0. I think that xml-entity-names and HTML5 made a poor choice changing the semantics of rang; and lang; (they used to be CJK punctuation, and now they are suddenly math). These are rendered differently. We should probably take a pragmatic approach, and avoid rushing to be the first to implement this aspect of the specs. I agree we shouldn't rush on potential compatibility-breaking changes, if we can get someone else to do some testing for us first. However I believe Firefox dev builds have the new meanings of rang; and lang;. They haven't discovered a problem yet, as far as I know. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?
Le 12 juil. 2010 à 21:01, Beth Dakin a écrit : On Jul 10, 2010, at 1:17 AM, Alex Milowski wrote: I would think we'd close it when we've actually completely implemented MathML. If this is what you want the bug to represent, then it does make sense to keep all feature-implementation bugs related to this master bug, but none of the bug bugs…if that makes any sense.The bug bugs should be in the MathML component, but they shouldn't block the feature-complete bug. Just enabling it seems like something we could do now but our implementation is quite impoverished with respect to MathML 3.0. I think we should consider enabling MathML. Just because we don't have MathML 3.0 implemented yet doesn't mean we need to keep it off; there was a time when we didn't have any CSS 3 implemented, but that didn't mean our CSS implementation had to be turned off! I have been playing around with a MathML-enabled build, and I feel like we do a pretty good job getting a lot of MathML on the web right, and I haven't experienced any crashes in the MathML code either. And if we turn it on, more people will test it, and that is just plain helpful. Just my opinion! Opinion that I share! But I think that Alex was not meaning to wait until a full support of MathML 3. François Sausset ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SIL Open Font License and WebKit
So, it sounds reasonable to use that license for fonts needed in the WebKit project. If nobody has objections, an update of the WebKit licensing policy and a review of the patch [1] including fonts under that license (for MathML) would be great! François Sausset [1] https://bugs.webkit.org/show_bug.cgi?id=41961 Le 16 juil. 2010 à 18:05, Eric Seidel a écrit : A little web searching produced: It's OSI approved: http://www.opensource.org/licenses/openfont.html GNU thinks it's OK, albeit having an unusual requirement: http://www.gnu.org/licenses/license-list.html#Fonts Fedora recommended: https://fedoraproject.org/wiki/Licensing#Font_Licenses It would appear to be the font license. -eric On Fri, Jul 16, 2010 at 5:05 AM, Alex Milowski a...@milowski.org wrote: We have a licensing issue we need to address for MathML. We need the STIX fonts as they will provide consistent rendering for Mathematics. I highly suspect these fonts will find themselves on our desktops somewhere down the road. Meanwhile, we need them for our testing infrastructure to actually work across all the platforms. The STIX Fonts are available under the SIL Open Font License: http://scripts.sil.org/cms/scripts/page.php?site_id=nrsiitem_id=OFL_web You can see the patch that adds these fonts here: https://bugs.webkit.org/show_bug.cgi?id=41961 I think we need to adjust our licensing policy to include font licenses like the above. It is unlikely that the STIX consortium will change their font licensing. In reality, they don't need to do so. The font license is intended to support open source fonts. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SIL Open Font License and WebKit
Le 19 juil. 2010 à 21:04, Maciej Stachowiak a écrit : Apple's legal department would strongly prefer for WebKit's license terms to remain simple. We prefer everything to be licensed under LGPL or BSD terms, or at the very least a license which is clearly compatible with LGPL and BSD. Is this license LGPL-compatible for cases where the fonts are embedded as data in software? See answers 1.4 to 1.7 in the following official FAQ of the license: http://scripts.sil.org/cms/scripts/page.php?site_id=nrsiitem_id=OFL-FAQ_web It is compatible. And as the font is only used by DumpRenderTree for tests, the WebKit API by itself does not need it at all. So, Safari, Chrome/Chromium, etc need to include neither the font, nor the license. For support material that has unusual license terms, another possibility is to have WebKit's support scripts automatically download it, rather than checking it directly into the repository. CSS font-face could be a workaround but a persistent location should be found (and I suppose WebKit website has the same licensing issues?). And with that solution MathML layout tests could not be run without a network connection. François Sausset Regards, Maciej On Jul 16, 2010, at 8:05 AM, Eric Seidel wrote: A little web searching produced: It's OSI approved: http://www.opensource.org/licenses/openfont.html GNU thinks it's OK, albeit having an unusual requirement: http://www.gnu.org/licenses/license-list.html#Fonts Fedora recommended: https://fedoraproject.org/wiki/Licensing#Font_Licenses It would appear to be the font license. -eric On Fri, Jul 16, 2010 at 5:05 AM, Alex Milowski a...@milowski.org wrote: We have a licensing issue we need to address for MathML. We need the STIX fonts as they will provide consistent rendering for Mathematics. I highly suspect these fonts will find themselves on our desktops somewhere down the road. Meanwhile, we need them for our testing infrastructure to actually work across all the platforms. The STIX Fonts are available under the SIL Open Font License: http://scripts.sil.org/cms/scripts/page.php?site_id=nrsiitem_id=OFL_web You can see the patch that adds these fonts here: https://bugs.webkit.org/show_bug.cgi?id=41961 I think we need to adjust our licensing policy to include font licenses like the above. It is unlikely that the STIX consortium will change their font licensing. In reality, they don't need to do so. The font license is intended to support open source fonts. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SIL Open Font License and WebKit
Le 20 juil. 2010 à 18:30, Antonio Gomes (:tonikitoo) a écrit : Again, maybe something like http://gitorious.org/qtwebkit/testfonts as QtWebKit does for the exactly same propose? But, with that method, fonts should be locally included on all test machines and as MathML implementation should be testable on all platforms, all build bots should include them locally. And I'm not sure it could be possible. Perhaps the build bots maintainers could answer? Once again, it does not solve the license problem when fonts are included in the DumpRenderTree binary as Maciej Stachowiak said. I think that CSS font-face is right now the only clean workaround for licensing issues. And, as Alex said, we have to find a persistent location for the fonts. François Sausset ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
