On Sep 11, 12:20 pm, "Marc-Antoine Ruel" <[EMAIL PROTECTED]> wrote: > I disagree with the debug flag. The main issue right now is that you > include chrome/* from webkit/*. That violates the current hierarchy. > The PrintingContext class will need to be moved. > Also, you'll have to turn off tab generation and use spaces instead. I > know, it hurts at first but you get used to it. :)
Now that I know there are rules about dependencies, I of course agree with you ;-) I take it I should be looking in the DEPS files to identify what is and isn't allowed? > > > The TestShell::PrintPage() method implements the suggested approach of > > writing directly to the printer device context. All of the elements of the > > page are printed, but appear very small. > > > If the DPI settings are likely to be the problem, how would I go about > > notifying the WebFrame instance that the DPI settings are different? > > When calling TestShell::PrintPages(), use settings.dpi() / > settings.desired_dpi as the scaling factor. Change the matrix loaded > in print_context_.context() with this additional factor, in addition > to the "shrink" factor which is independent. Changing the input to the ModifyWorldTransform() function results in no visible changes in the printed output. That's what originally led me to believe that the ModifyWorldTransform() call is being lost and/ or ignored. Is there perhaps some additional GDI call that needs to be made on the printer context that I'm missing? > > > One other thing I've noticed is that Google Chrome doesn't remember the > > print settings last selected by the user during the same session. We may > > want to add support for that as well while we're at it. > > I'd rather keep separate changes separate. The first thing to do would > be to move PrintingContext into base/ or webkit/. Since > PrintingContext depends on PrintSettings, PageOverlays, PageRange and > PageSetup, it's non-trivial. Furthermore, PageOverlays requires the > url elider. > > I think the url elider and the emf dumping facilities (which cause the > browser dependency) could be factored away and be "hot pluggable". > That would be nice in fact. What does "hot pluggable" mean in the context of the chromium code base? Abstracting it out into an interface? > > One question though, what about 'chrome.exe --single-process' ? Chrome.exe still prints fine even with the "--single-process" flag set. Regards, Marshall --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
