[webkit-dev] Printer font is different from screen font
Hi, I've noticed WebKit uses slightly different font size for printing on Mac. My colleague told me Mac's font API has a feature to select the best font for printing. This feature isn't good for a team in Google because they want exactly same results between screen and printing. I searched a workaround for this, but I couldn't find. I'm not sure if it actually improves the printing results, so it would be best if we can remove this code (FontDescription::usePrinterFont). But I guess this proposal will be objected :) Another proposal is adding a -webkit prefixed CSS property to allow users to customize the behavior. Like -webkit-font-media: auto | printer | screen (auto is the default) I'm not sure if this is a good name though. Does this plan sounds good? If so, we'd like to start implementing this. Any comments will be really appreciated. Thanks! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Sharing WebKit mocks across platforms
Why wasn't it done that way originally? That sounds (to my uneducated ear) much better than what's done today. J On Thu, Jul 29, 2010 at 11:19 PM, Adam Barth aba...@webkit.org wrote: WebCore::LayoutTestController would be exposed to JavaScript running in LayoutTests directly (like the DOM), so we can skip the type conversions. Adam On Thu, Jul 29, 2010 at 9:20 AM, Satish Sampath sat...@google.com wrote: With a WebCore::LayoutTestController, would there be a need for code in WebKit to convert the call parameters from WebKit types (which DRT uses) to WebCore types (which the mocks may use) ? If yes seems like we need wrappers to proxy the mock calls anyway on different platforms.. Cheers Satish On Thu, Jul 29, 2010 at 4:16 PM, Adam Barth aba...@webkit.org wrote: Thanks for bring this question to the list. I don't have a strong opinion here, but I want to make sure we think project-wide and pick something scalable. This discussion is also related to the discussion about adding something like a layoutTestController object to WebCore. Plumbing this mock API all the way through WebKit for each port seems like a waste. If we had something like a WebCore::LayoutTestController, it would make a lot more sense to expose that functionality there. Adam On Wed, Jul 28, 2010 at 11:30 AM, Steve Block stevebl...@google.com wrote: I'm in the process of adding a mock client for DeviceOrientation, which will be used in DumpRenderTree to test the feature. In order to share the mock across platforms, I'd like to add the mock to WebCore/platform/mock. An interface to the mock will have to be exposed to the embedder through the platform's WebKit API, so that it can be configured by DRT, eg ... mWebView.getDeviceOrientationClientMock().setOrientation(...); To avoid each platform having to produce it's own WebKit wrapper for the mock, I'm considering adding a common WebKit wrapper, perhaps to WebKit/common, and I wanted to get some feedback on the idea. The mock would be shared between all C++ WebKit platforms. (Note that this is for convenience only, a platform could equally use it's own WebKit wrapper around the WebCore mock (eg Mac may do so in ObjectiveC), or use its own mock altogether.) Of course we also need WebKit wrappers for all of the non-POD types used by the mock's interface, and these have to be common between all platforms. One obvious potential difficulty is the wrapper for WebCore::String. Each platforms already has a wrapper for this type, but there's no guarantee of interoperability, so we'd need to write a new common interface if we're to use the string type. If a wrapper for string ends up being too problematic, the approach could still be used for mocks that don't need the string type (of which DeviceOrientation is one), but the approach then seems less compelling. Do people think that this is a reasonable proposal and worth pursuing? Has there been any attempt to do anything similar before? Or is any attempt to write this kind of common WebKit code not worth the effort and destined to failure? You can see the work in progress for DeviceOrientation at https://bugs.webkit.org/show_bug.cgi?id=39589 and a similar patch for SpeechInput mocks at https://bugs.webkit.org/show_bug.cgi?id=42603 I'd appreciate any feedback you may have. Thanks, Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Sharing WebKit mocks across platforms
WebCore::LayoutTestController would be exposed to JavaScript running in LayoutTests directly (like the DOM), so we can skip the type conversions. There might still be the need for some plumbing though. In the case of DeviceOrientation and SpeechInput, we're mocking a client which is provided by WebKit. Even though the mock implementation happens to live in WebCore, it's instantiated and owned by the WebKit layer. So in order for LayoutTestController to configure the mock (eg layoutTestController.setMockOrientation(...)), we need to route calls from the WebCore LayoutTestController up to WebKit. I guess you could use a new LayoutTestControllerClient. I think you're right though that this could be done without the need for type conversions, as none of this is exposed in the WebKit API. Steve ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Sharing WebKit mocks across platforms
I suspect, originally, layoutTestController was more about poking DumpRenderTree than about poking WebCore. Adam On Fri, Jul 30, 2010 at 2:42 AM, Jeremy Orlow jor...@chromium.org wrote: Why wasn't it done that way originally? That sounds (to my uneducated ear) much better than what's done today. On Thu, Jul 29, 2010 at 11:19 PM, Adam Barth aba...@webkit.org wrote: WebCore::LayoutTestController would be exposed to JavaScript running in LayoutTests directly (like the DOM), so we can skip the type conversions. On Thu, Jul 29, 2010 at 9:20 AM, Satish Sampath sat...@google.com wrote: With a WebCore::LayoutTestController, would there be a need for code in WebKit to convert the call parameters from WebKit types (which DRT uses) to WebCore types (which the mocks may use) ? If yes seems like we need wrappers to proxy the mock calls anyway on different platforms.. Cheers Satish On Thu, Jul 29, 2010 at 4:16 PM, Adam Barth aba...@webkit.org wrote: Thanks for bring this question to the list. I don't have a strong opinion here, but I want to make sure we think project-wide and pick something scalable. This discussion is also related to the discussion about adding something like a layoutTestController object to WebCore. Plumbing this mock API all the way through WebKit for each port seems like a waste. If we had something like a WebCore::LayoutTestController, it would make a lot more sense to expose that functionality there. Adam On Wed, Jul 28, 2010 at 11:30 AM, Steve Block stevebl...@google.com wrote: I'm in the process of adding a mock client for DeviceOrientation, which will be used in DumpRenderTree to test the feature. In order to share the mock across platforms, I'd like to add the mock to WebCore/platform/mock. An interface to the mock will have to be exposed to the embedder through the platform's WebKit API, so that it can be configured by DRT, eg ... mWebView.getDeviceOrientationClientMock().setOrientation(...); To avoid each platform having to produce it's own WebKit wrapper for the mock, I'm considering adding a common WebKit wrapper, perhaps to WebKit/common, and I wanted to get some feedback on the idea. The mock would be shared between all C++ WebKit platforms. (Note that this is for convenience only, a platform could equally use it's own WebKit wrapper around the WebCore mock (eg Mac may do so in ObjectiveC), or use its own mock altogether.) Of course we also need WebKit wrappers for all of the non-POD types used by the mock's interface, and these have to be common between all platforms. One obvious potential difficulty is the wrapper for WebCore::String. Each platforms already has a wrapper for this type, but there's no guarantee of interoperability, so we'd need to write a new common interface if we're to use the string type. If a wrapper for string ends up being too problematic, the approach could still be used for mocks that don't need the string type (of which DeviceOrientation is one), but the approach then seems less compelling. Do people think that this is a reasonable proposal and worth pursuing? Has there been any attempt to do anything similar before? Or is any attempt to write this kind of common WebKit code not worth the effort and destined to failure? You can see the work in progress for DeviceOrientation at https://bugs.webkit.org/show_bug.cgi?id=39589 and a similar patch for SpeechInput mocks at https://bugs.webkit.org/show_bug.cgi?id=42603 I'd appreciate any feedback you may have. Thanks, Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Sharing WebKit mocks across platforms
On Fri, Jul 30, 2010 at 2:56 AM, Steve Block stevebl...@google.com wrote: WebCore::LayoutTestController would be exposed to JavaScript running in LayoutTests directly (like the DOM), so we can skip the type conversions. There might still be the need for some plumbing though. In the case of DeviceOrientation and SpeechInput, we're mocking a client which is provided by WebKit. Even though the mock implementation happens to live in WebCore, it's instantiated and owned by the WebKit layer. Why not instantiate and own the object in WebCore? In fact, perhaps the testController (or whatever we want to call the WebCore test helper object) so both instantiate and own the client. So in order for LayoutTestController to configure the mock (eg layoutTestController.setMockOrientation(...)), we need to route calls from the WebCore LayoutTestController up to WebKit. I guess you could use a new LayoutTestControllerClient. I think you're right though that this could be done without the need for type conversions, as none of this is exposed in the WebKit API. Yep. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Grant Gayed is out of the office.
I will be out of the office starting 07/30/2010 and will not return until 08/16/2010. I will respond to your message when I return.___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Printer font is different from screen font
On Jul 30, 2010, at 2:10 AM, Shinichiro Hamaji wrote: I've noticed WebKit uses slightly different font size for printing on Mac. We should discuss specifics instead of this broad issue. There’s a good chance this is something that has been misdiagnosed. My colleague told me Mac's font API has a feature to select the best font for printing. Your colleague may be talking about the -[NSFont printerFont] method. That method is used to select a font that is supported for printing. It is not optimizing for printing, but rather must be used to guarantee that WebKit doesn’t try to use a font for printing that is incompatible with the printing machinery. The documentation for this is at http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSFont_Class/Reference/Reference.html#//apple_ref/occ/instm/NSFont/printerFont. This feature isn't good for a team in Google because they want exactly same results between screen and printing. We’ll have to discuss a specific example. You could test this by modifying your copy of WebKit to turn bypass the calls to the printerFont method in FontCacheMac.mm, FontMac.mm, and SimpleFontDataMac.mm. If you get your improved results from that we can continue the discussion. I think it’s more likely you will find that printing doesn’t work any more. Before we start discussing adding features and modes to control this behavior you should do the experiment to see if this would do something helpful. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Patches saying “Unreviewed”
Hi folks. It’s come to my attention that some webkit-patch or some other script requires that patches without review contain the string “Unreviewed” somewhere in their change log message. I personally think this is not helpful. In my opinion patches that are don’t need review, such as some simple build fixes, need not list a reviewer, but also need not call attention to that fact. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patches saying “Unreviewed”
On Fri, Jul 30, 2010 at 1:10 PM, Darin Adler da...@apple.com wrote: It’s come to my attention that some webkit-patch or some other script requires that patches without review contain the string “Unreviewed” somewhere in their change log message. I personally think this is not helpful. In my opinion patches that are don’t need review, such as some simple build fixes, need not list a reviewer, but also need not call attention to that fact. The commit-queue requires something like that to make sure it succeeds in filling in the reviewer information from bugs.webkit.org. Running webkit-patch on the command line shouldn't require that. We can figure out another mechanism to make sure the commit-queue fills in the proper reviewer. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patches saying “Unreviewed”
This was added to enable a sane you filled in a reviewer check. Requiring patch submitters to be explicit that the patch was not reviewed instead of the case where they got the reviewer information wrong. We *very* commonly have cases where contributors (especially new ones) just delete the Reviewed by line, or fill it in with Reviewed by nobody. or similar. Not understanding our (admittedly confusing) system. I'm definitely open to other/better solutions. Including removing (at least the unreviewed part of) the check when not in commit-queue mode. -eric On Fri, Jul 30, 2010 at 4:23 PM, Adam Barth aba...@webkit.org wrote: On Fri, Jul 30, 2010 at 1:10 PM, Darin Adler da...@apple.com wrote: It’s come to my attention that some webkit-patch or some other script requires that patches without review contain the string “Unreviewed” somewhere in their change log message. I personally think this is not helpful. In my opinion patches that are don’t need review, such as some simple build fixes, need not list a reviewer, but also need not call attention to that fact. The commit-queue requires something like that to make sure it succeeds in filling in the reviewer information from bugs.webkit.org. Running webkit-patch on the command line shouldn't require that. We can figure out another mechanism to make sure the commit-queue fills in the proper reviewer. Adam ___ 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] Patches saying “Unreviewed”
It’s totally reasonable for the bot to require a reviewer line, because the bot requires a reviewer on the bug too. It’s in non-bot contexts that I think it’s not good. I think that means I agree with you both who said that running webkit-patch on the command line shouldn't require it. We can have the commit bot use an option to tell webkit-patch it wants that rule. As far as the confusion factor is concerned, we could change the wording of the Reviewed by line added by prepare-ChangeLog to make it more explicit. Reviewed by REVIEWER-NAME-WILL-BE-FILLED-IN-HERE-DO-NOT-DELETE (OOPS). Or something nicer than that but with a similar flavor. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patches saying “Unreviewed”
Last time I did that, I was accused of shouting... :) http://trac.webkit.org/changeset/45647 But I support making prepare-ChangeLog less confusing. Our fix up one of the OOPS, but don't touch the other! expectation of contributors is the source of much confusion. :) -eric On Fri, Jul 30, 2010 at 6:57 PM, Darin Adler da...@apple.com wrote: It’s totally reasonable for the bot to require a reviewer line, because the bot requires a reviewer on the bug too. It’s in non-bot contexts that I think it’s not good. I think that means I agree with you both who said that running webkit-patch on the command line shouldn't require it. We can have the commit bot use an option to tell webkit-patch it wants that rule. As far as the confusion factor is concerned, we could change the wording of the Reviewed by line added by prepare-ChangeLog to make it more explicit. Reviewed by REVIEWER-NAME-WILL-BE-FILLED-IN-HERE-DO-NOT-DELETE (OOPS). Or something nicer than that but with a similar flavor. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patches saying “Unreviewed”
On Fri, Jul 30, 2010 at 3:57 PM, Darin Adler da...@apple.com wrote: It’s in non-bot contexts that I think it’s not good. I think that means I agree with you both who said that running webkit-patch on the command line shouldn't require it. We can have the commit bot use an option to tell webkit-patch it wants that rule. Yep. That option is --non-interactive, which does a bunch of things, including turn on stricter error checking like this. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Sharing WebKit mocks across platforms
On Fri, Jul 30, 2010 at 5:42 AM, Jeremy Orlow jor...@chromium.org wrote: Why wasn't it done that way originally? That sounds (to my uneducated ear) much better than what's done today. J The world was very different back then. :) - WebKit was only on one platform (Mac). - Much of what is now WebCore, was up in WebKit. - (As Adam also mentions) LayoutTestController was initially more about faking click events, etc. A lot has changed in 6, 7, 8.. whatever it is now... years. I agree, I think that a better modern solution would be to move huge chunks of DRT into WebCore itself, and have them compiled in Debug and Release builds and removed from Production builds (controlled by some flag). WebKit ports would just pipe another method exposeTestObjectsToJavaScript or similar up to the various DRT ports. We could get rid of a huge amount of boiler-plate DRT code (much of which deals with type conversions). -eric On Thu, Jul 29, 2010 at 11:19 PM, Adam Barth aba...@webkit.org wrote: WebCore::LayoutTestController would be exposed to JavaScript running in LayoutTests directly (like the DOM), so we can skip the type conversions. Adam On Thu, Jul 29, 2010 at 9:20 AM, Satish Sampath sat...@google.com wrote: With a WebCore::LayoutTestController, would there be a need for code in WebKit to convert the call parameters from WebKit types (which DRT uses) to WebCore types (which the mocks may use) ? If yes seems like we need wrappers to proxy the mock calls anyway on different platforms.. Cheers Satish On Thu, Jul 29, 2010 at 4:16 PM, Adam Barth aba...@webkit.org wrote: Thanks for bring this question to the list. I don't have a strong opinion here, but I want to make sure we think project-wide and pick something scalable. This discussion is also related to the discussion about adding something like a layoutTestController object to WebCore. Plumbing this mock API all the way through WebKit for each port seems like a waste. If we had something like a WebCore::LayoutTestController, it would make a lot more sense to expose that functionality there. Adam On Wed, Jul 28, 2010 at 11:30 AM, Steve Block stevebl...@google.com wrote: I'm in the process of adding a mock client for DeviceOrientation, which will be used in DumpRenderTree to test the feature. In order to share the mock across platforms, I'd like to add the mock to WebCore/platform/mock. An interface to the mock will have to be exposed to the embedder through the platform's WebKit API, so that it can be configured by DRT, eg ... mWebView.getDeviceOrientationClientMock().setOrientation(...); To avoid each platform having to produce it's own WebKit wrapper for the mock, I'm considering adding a common WebKit wrapper, perhaps to WebKit/common, and I wanted to get some feedback on the idea. The mock would be shared between all C++ WebKit platforms. (Note that this is for convenience only, a platform could equally use it's own WebKit wrapper around the WebCore mock (eg Mac may do so in ObjectiveC), or use its own mock altogether.) Of course we also need WebKit wrappers for all of the non-POD types used by the mock's interface, and these have to be common between all platforms. One obvious potential difficulty is the wrapper for WebCore::String. Each platforms already has a wrapper for this type, but there's no guarantee of interoperability, so we'd need to write a new common interface if we're to use the string type. If a wrapper for string ends up being too problematic, the approach could still be used for mocks that don't need the string type (of which DeviceOrientation is one), but the approach then seems less compelling. Do people think that this is a reasonable proposal and worth pursuing? Has there been any attempt to do anything similar before? Or is any attempt to write this kind of common WebKit code not worth the effort and destined to failure? You can see the work in progress for DeviceOrientation at https://bugs.webkit.org/show_bug.cgi?id=39589 and a similar patch for SpeechInput mocks at https://bugs.webkit.org/show_bug.cgi?id=42603 I'd appreciate any feedback you may have. Thanks, Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ 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] Sharing WebKit mocks across platforms
On Fri, Jul 30, 2010 at 7:55 PM, Eric Seidel e...@webkit.org wrote: On Fri, Jul 30, 2010 at 5:42 AM, Jeremy Orlow jor...@chromium.org wrote: Why wasn't it done that way originally? That sounds (to my uneducated ear) much better than what's done today. The world was very different back then. :) - WebKit was only on one platform (Mac). - Much of what is now WebCore, was up in WebKit. - (As Adam also mentions) LayoutTestController was initially more about faking click events, etc. A lot has changed in 6, 7, 8.. whatever it is now... years. I agree, I think that a better modern solution would be to move huge chunks of DRT into WebCore itself, and have them compiled in Debug and Release builds and removed from Production builds (controlled by some flag). WebKit ports would just pipe another method exposeTestObjectsToJavaScript or similar up to the various DRT ports. We could get rid of a huge amount of boiler-plate DRT code (much of which deals with type conversions). Mr. Seidel, we might have found our next project. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
