[Webkit-unassigned] [Bug 35550] Allow a plugin to participate in the browser's print workflow.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=35550


Darin Fisher (:fishd, Google) <fishd at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #50133|                            |review-
               Flag|                            |




--- Comment #7 from Darin Fisher (:fishd, Google) <fishd at chromium.org>  2010-03-09 16:21:31 PST ---
(From update of attachment 50133)
> Index: WebCore/loader/PluginDocument.cpp
...
> -    
> +
> +Widget* PluginDocument::pluginWidget()
> +{
> +    return PluginTokenizer::pluginWidgetFromDocument(this);
>  }
> +}

nit: please preserve the new line before the last "}"


> Index: WebCore/loader/PluginDocument.h
...

nit: please preserve the new line after the "{"

>  namespace WebCore {
> -    
> +class Widget;
>  class PluginDocument : public HTMLDocument {


> Index: WebKit/chromium/public/WebPlugin.h
...
> +    // Printing interface. In the below methods, printableArea
> +    // is in points (a point is 1/72 of an inch).
> +    // These methods have default implementations so as to not break existing
> +    // Chromium builds. They will be made pure virtual once the corresponding
> +    // Chromium patch lands.
> +    virtual bool supportsCustomPrint() { return false; }

Instead of supportsCustomPrint, how about a name that is consistent with
printPage?  Like supportsPaginatedPrinting or canPrintPage?  That
way it is clear that we mean that the printPage method is supported.


> +    virtual int getNumberOfPages(const WebRect& printableArea, int printerDPI) { return 0; }
> +    virtual bool printPage(int pageNumber, WebCanvas* canvas, const WebRect& printableArea, int printerDPI) { return false; }

I'm still a bit surprised that we wouldn't want there to be some state
held by the plugin here.  This API suggests that any complex page layout
required to compute the number of pages in a document would need to be
done twice.  Or, the implementation would need to do some caching.

This is why the begin/print/end pattern could be better.


R- because of nits, but I would like to discuss the API a bit more.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.