[Webkit-unassigned] [Bug 29042] Custom printing shrink factors

[bugzilla-daemon at webkit.org]

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





--- Comment #19 from Benjamin Poulain <benjamin.poulain at nokia.com>  2009-11-12 05:35:12 PST ---
(In reply to comment #18)
> I see you just proposed reverting my original patch instead of fixing the
> issue. 
> Is QT pulling WebKit trunk into the QT 4.6 tree, if yes is there real WebKit
> trunk I can submit patches against, or is it only possible to submit QT related
> patches into WebKit at time-windows according with the QT release schedule.  I
> have tried many different strategies for getting patches such as this in,
> submitting to the QT bug-tracker, QT Gitorius and so on but all of them state
> that I should submit here.  Now you seem to claim that one needs some sort of
> QT rewiew, how would that happen.  I'm beginning to wonder if it is at all
> possible to get a QT related patch into WebKit?

You have done the right workflow, it is correct to submit the patches here for
QtWebkit.
We have failed on this patch. Nobody from Qt did notice the patch and it has
been merged without any API review (necessary for public APIs).

I suggest to revert the patch here instead of the 4.6 branch in order to have a
proper API review before it's inclusion for 4.7.

I personally think we could introduce a new class for printing in order to add
more flexibility in the future. E.g.:
void QWebFrame::print (QPrinter* printer, const QWebPrintSettings& settings)

This would have the advantage of giving the right visibility to the parameters
(next to ::print, instead of hidden in the settings). And this would be more
future proof in case of new parameters (zoomFactor, and CSS media type for
example). This is just my point of view, that need to be discussed with the
others.

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