Re: [webkit-dev] svg/filters/filter-empty-g.svg ASSERTs on Leopard Intel Debug (Tests)
On Sun, Jul 18, 2010 at 2:06 PM, Nikolas Zimmermann zimmerm...@physik.rwth-aachen.de wrote: Am 18.07.2010 um 18:36 schrieb Adam Barth: I'm not sure it's working properly. It says: SUCCESS: Build 17401 (r63531) was the first to show failures: set([u'svg/filters/filter-empty-g.svg']) but then it goes on to list all the commits from r63492 to r63531. I already notified the orginal author at https://bugs.webkit.org/show_bug.cgi?id=41175 that something is broken -- if nothing happens please can someone revert it, I'm not here until Tuesday. Thanks. Hopefully we'll be able to resolve the issue before midday Monday. Adam ___ 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
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? 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. 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
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
On Jul 19, 2010, at 11:45 AM, Sausset François wrote: 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. I don't see a claim that the font is LGPL-compatible when embedded in a program. The FSF discussion of this license doesn't say, unfortunately. 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. Good point. However, at least some versions of DumpRenderTree build with test fonts embedded directly into the binary. 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. I'm not suggesting WebFonts. Rather, the fonts could be downloaded on demand when running the tests if not present, the way we do with some Python modules. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding window.layoutTestInspector
Let me summarize to make sure I understand the proposal: Expose a new object
to layout tests that is entirely in WebCore instead of in the DRT layer.
Then, only put things in layoutTestController that need to be at the WebKit
layer, e.g. notifyDone, waitUntilDone, etc. APIs that only need to touch
WebCore can live in WebCore.
Overall, I like the idea of making it easier to add bits exposed just for
the sake of testing. Right now, it's really difficult to make simple
extensions to layoutTestController because they need to be made many times
over for each platform and there are many bits in layoutTestController that
only need to touch WebCore. Spelling/grammer markers is a good example.
setEditingBehavior is another good one.
Ojan
On Wed, Jul 14, 2010 at 10:16 PM, Hajime Morita morr...@google.com wrote:
Hi WebKit folks,
I'm planning to add window.layoutTestInspector or something like that to
DRT.
And I'd like to hear your opinions.
Background:
Adding new method to LayoutTestController is hard. It
- requires to add new WebKit API to each ports, when the method is to
access WebCore.
- requires to export extra WebCore symbols to access it from WebKit
API implementation.
- cannot use WebIDL so we need to write binding code manually.
In some case, these steps are unavoidable.
But in some other case, especially when we just want to access WebCore
from the test, we might be able to skip these steps.
A concrete example (my first motivation) is to test DocumentMarker
for http://webkit.org/b/41423.
DocumentMarker is WebCore's internal state and cannot access neither
from DOM nor LayoutTestController.
To test it,
- the first idea is to use a pixel test.
But it has some shortcomings as you know well.
- The second idea is to extend render tree's dump format to
include markers. But it is also platform-specific,
and hard to interpret for humans.
- The third idea is to add an API to LayoutTestController.
But it is hard as I mentioned above.
Is there another way? DocumentMarker is
- WebCore's internal state,
- so we don't need to inspect it except for testing purpose,
- so it's better to avoid an extra WebKit API for that.
I think there are similar demands other than for DocumentMarker,
and it might be worth to invest a common way to handle them.
Plans:
To deal with such cases, we can add a test-specific object named
LayoutTestInspector to window object. (The name is tentative.)
With this object, We'll be able to write a LayoutTest like:
if (window.layoutTestInspector) {
var target = document.getElementById(target)
var markerStr = layoutTestInspector.nodeMarkerString(target);
if (markerStr == Spelling:0:6)
log(PASS);
else
log(FAIL);
}
Here is a plan to do this:
- LayoutTestInspector will be defined in WebCore,
and implemented as a usual DOM object using WebIDL.
(placed under, for example, WebCore/page/LayoutTestInspector.{idl,h,cpp})
- window object will expose a non-enumerable
windows.layoutTestInspector property
for that.
- Settings::m_enableLayoutTestInspector will control
windows.layoutTestInspector
availability. This flag should be true only on DRT.
Tests with LayoutTestInspector would have several advantages:
- Compared to LayoutTestController,
we don't need to add new APIs to WebKit layer for test purpose.
- Compared to LayoutTestController,
we don't need to export extra WebCore APIs to WebKit layer.
- Compared to Render-tree dump,
the test can be more portable, focused and understandable.
But there are some concerns:
- WebCore need to have a test-specific code, that might be a waste of
space.
Test-specific WebKit APIs would have a same problem, though.
- LayoutTestInspector may introduce some potential security risks.
I have no idea about this area.
Do you have any other use-cases or better approaches?
Are there concerns I've missed? Do we have similar discussions in the past?
Any ideas/suggestions are welcome.
If there are no strong objections, I'll start to work on this.
Regards.
--
morita
___
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] Adding window.layoutTestInspector
Hi Ojan, thank you for the response!
Let me summarize to make sure I understand the proposal: Expose a new object
to layout tests that is entirely in WebCore instead of in the DRT layer.
Then, only put things in layoutTestController that need to be at the WebKit
layer, e.g. notifyDone, waitUntilDone, etc. APIs that only need to touch
WebCore can live in WebCore.
Exactly.
I'd like to note that I have no intention to remove existing
LayoutTestController APIs.
Overall, I like the idea of making it easier to add bits exposed just for
the sake of testing. Right now, it's really difficult to make simple
extensions to layoutTestController because they need to be made many times
over for each platform and there are many bits in layoutTestController that
only need to touch WebCore. Spelling/grammer markers is a good example.
setEditingBehavior is another good one.
Agreed. Exposing setEditingBehavior will be good for testing around editing
selection.
Re-defining enum on the WebKit layer is essentially redundant, and nice to
avoid.
I filed the bug for this: https://bugs.webkit.org/show_bug.cgi?id=42612
A patch will come shortly.
--
morita
Ojan
On Wed, Jul 14, 2010 at 10:16 PM, Hajime Morita morr...@google.comwrote:
Hi WebKit folks,
I'm planning to add window.layoutTestInspector or something like that to
DRT.
And I'd like to hear your opinions.
Background:
Adding new method to LayoutTestController is hard. It
- requires to add new WebKit API to each ports, when the method is to
access WebCore.
- requires to export extra WebCore symbols to access it from WebKit
API implementation.
- cannot use WebIDL so we need to write binding code manually.
In some case, these steps are unavoidable.
But in some other case, especially when we just want to access WebCore
from the test, we might be able to skip these steps.
A concrete example (my first motivation) is to test DocumentMarker
for http://webkit.org/b/41423.
DocumentMarker is WebCore's internal state and cannot access neither
from DOM nor LayoutTestController.
To test it,
- the first idea is to use a pixel test.
But it has some shortcomings as you know well.
- The second idea is to extend render tree's dump format to
include markers. But it is also platform-specific,
and hard to interpret for humans.
- The third idea is to add an API to LayoutTestController.
But it is hard as I mentioned above.
Is there another way? DocumentMarker is
- WebCore's internal state,
- so we don't need to inspect it except for testing purpose,
- so it's better to avoid an extra WebKit API for that.
I think there are similar demands other than for DocumentMarker,
and it might be worth to invest a common way to handle them.
Plans:
To deal with such cases, we can add a test-specific object named
LayoutTestInspector to window object. (The name is tentative.)
With this object, We'll be able to write a LayoutTest like:
if (window.layoutTestInspector) {
var target = document.getElementById(target)
var markerStr = layoutTestInspector.nodeMarkerString(target);
if (markerStr == Spelling:0:6)
log(PASS);
else
log(FAIL);
}
Here is a plan to do this:
- LayoutTestInspector will be defined in WebCore,
and implemented as a usual DOM object using WebIDL.
(placed under, for example, WebCore/page/LayoutTestInspector.{idl,h,cpp})
- window object will expose a non-enumerable
windows.layoutTestInspector property
for that.
- Settings::m_enableLayoutTestInspector will control
windows.layoutTestInspector
availability. This flag should be true only on DRT.
Tests with LayoutTestInspector would have several advantages:
- Compared to LayoutTestController,
we don't need to add new APIs to WebKit layer for test purpose.
- Compared to LayoutTestController,
we don't need to export extra WebCore APIs to WebKit layer.
- Compared to Render-tree dump,
the test can be more portable, focused and understandable.
But there are some concerns:
- WebCore need to have a test-specific code, that might be a waste of
space.
Test-specific WebKit APIs would have a same problem, though.
- LayoutTestInspector may introduce some potential security risks.
I have no idea about this area.
Do you have any other use-cases or better approaches?
Are there concerns I've missed? Do we have similar discussions in the
past?
Any ideas/suggestions are welcome.
If there are no strong objections, I'll start to work on this.
Regards.
--
morita
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
morita
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding window.layoutTestInspector
Darin and I discussed this proposal, and we had a few thoughts to share:
(1) It seems a little odd that we'll end up with two different objects that
have similar names and a very similar purpose, but just differ in how they are
implemented. Maybe there's a way to define layoutTestController in WebCore and
have DumpRenderTree extend it.
(2) It does seem like for some test-specific methods, implementing then in
WebCore would be simpler and would save the work of plumbing them through the
WebKit layers.
(3) On the other hand, LayoutTestController seems like it has too much stuff in
it. Originally DumpRenderTree exposed a very modest set of functionality,
mostly to control output (dumpAsText) or to emulate things that you could do by
hand when running the test in the browser (waitUntilDone, eventSender).
Nowadays, there are dozens of methods. A lot of them are used in only one or
two tests. And in many cases, the methods have no interactive equivalent, so a
lot of our tests are not runnable in the browser at all. Those seem like bad
trends. Maybe instead of making it easier to add to LayoutTestController, we
should look at whether we can consolidate functionality, factor it into more
objects, and find ways to test things that don't require quite so much custom
functionality.
I'll add on my own behalf that layoutTestInspector doesn't seem like a great
name and doesn't express the relationship to layoutTestController. It's not
used to examine layout tests.
Regards,
Maciej
On Jul 14, 2010, at 10:16 PM, Hajime Morita wrote:
Hi WebKit folks,
I'm planning to add window.layoutTestInspector or something like that to
DRT.
And I'd like to hear your opinions.
Background:
Adding new method to LayoutTestController is hard. It
- requires to add new WebKit API to each ports, when the method is to
access WebCore.
- requires to export extra WebCore symbols to access it from WebKit
API implementation.
- cannot use WebIDL so we need to write binding code manually.
In some case, these steps are unavoidable.
But in some other case, especially when we just want to access WebCore
from the test, we might be able to skip these steps.
A concrete example (my first motivation) is to test DocumentMarker
for http://webkit.org/b/41423.
DocumentMarker is WebCore's internal state and cannot access neither
from DOM nor LayoutTestController.
To test it,
- the first idea is to use a pixel test.
But it has some shortcomings as you know well.
- The second idea is to extend render tree's dump format to
include markers. But it is also platform-specific,
and hard to interpret for humans.
- The third idea is to add an API to LayoutTestController.
But it is hard as I mentioned above.
Is there another way? DocumentMarker is
- WebCore's internal state,
- so we don't need to inspect it except for testing purpose,
- so it's better to avoid an extra WebKit API for that.
I think there are similar demands other than for DocumentMarker,
and it might be worth to invest a common way to handle them.
Plans:
To deal with such cases, we can add a test-specific object named
LayoutTestInspector to window object. (The name is tentative.)
With this object, We'll be able to write a LayoutTest like:
if (window.layoutTestInspector) {
var target = document.getElementById(target)
var markerStr = layoutTestInspector.nodeMarkerString(target);
if (markerStr == Spelling:0:6)
log(PASS);
else
log(FAIL);
}
Here is a plan to do this:
- LayoutTestInspector will be defined in WebCore,
and implemented as a usual DOM object using WebIDL.
(placed under, for example, WebCore/page/LayoutTestInspector.{idl,h,cpp})
- window object will expose a non-enumerable
windows.layoutTestInspector property
for that.
- Settings::m_enableLayoutTestInspector will control
windows.layoutTestInspector
availability. This flag should be true only on DRT.
Tests with LayoutTestInspector would have several advantages:
- Compared to LayoutTestController,
we don't need to add new APIs to WebKit layer for test purpose.
- Compared to LayoutTestController,
we don't need to export extra WebCore APIs to WebKit layer.
- Compared to Render-tree dump,
the test can be more portable, focused and understandable.
But there are some concerns:
- WebCore need to have a test-specific code, that might be a waste of space.
Test-specific WebKit APIs would have a same problem, though.
- LayoutTestInspector may introduce some potential security risks.
I have no idea about this area.
Do you have any other use-cases or better approaches?
Are there concerns I've missed? Do we have similar discussions in the past?
Any ideas/suggestions are welcome.
If there are no strong objections, I'll start to work on this.
Regards.
--
morita
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
