Don't we have to re-render the page for printing anyway, since many sites have print-specific CSS? -Nick
On Mon, Jul 27, 2009 at 6:52 PM, Mohamed Mansour <[email protected]>wrote: > Hi all, > I am looking into this again, and we implemented the "print: > http://www.google.com"; hookup functionality into chromium (ToT). So far it > just shows a webpage. > > I am trying to figure out how we could bring the image in there, so I > worked on this CL (http://codereview.chromium.org/159387) which introduces > the concept of "chrome://image/http://www.google.com";, where it fetches > the image from the current tab and places it on the domui. I got the idea > from another CL for extensions (http://codereview.chromium.org/144019). > > The problem is that, we can't rely on that approach because of the > following (Gathered from extension code review comments): > > Aaron Boodman said: > > That is an interesting idea. There would be a few challenges, though: >> >> - We need a way to specify the desired format, size, etc. I guess they >> could be querystring params? >> - For printing in particular, it seems important to print the exact >> thing the user sees, not re-request the URL >> >> Without a solution to the second issue, I don't think the chrome:// >> URL idea is workable. But I do think that the code we used to >> implement this extension API could easily be reused for for print >> preview. > > > > Erik Kay stated: > > The way this code is currently written, it just grabs the backing store >> from the current visible tab. This means that it's the same size as the >> viewport on the visible tab, no new layout happens. >> >> Given this, I don't think this could be made to work with printing. The >> two obvious problems are the my browser width might not match paper width, >> and that anything that's outside of the viewport (scrolled) won't be visible >> in the preview. > > > > I really don't know how to bring over the "printed" image, maybe because I > am inexperienced in the language, and I am asking for advice on what > approach should I take? > > I want to reuse the same functionality of printing but what is the best way > to bring that image into the DOMUI. I tired with the chrome://image/url > approach, but as Erik and Aaron stated above, it wont work. > > If you guys have the UI mockup of the settings, I could implement that now, > but since our previous comments, it is directly hooked up to the Print > Preview. > > Any guidance is appreciated :) > > -- Mohamed Mansour > > > > On Tue, Jun 9, 2009 at 9:50 PM, Nick Baum <[email protected]> wrote: > >> >> >> On Fri, Jun 5, 2009 at 9:03 PM, Mohamed Mansour <[email protected] >> > wrote: >> >>> I really like the mock-up, when can you do one for Settings? >> >> >> I'll put it on our list, but I don't expect to get to this in the next >> couple of weeks. In general, we try not to block engineers on UI, so if you >> make good progress on the preview, we'll prioritize this higher. >> >>> >>> If we are going to include settings to this page (such as margins, >>> headers, footers, etc), does that mean it would be per page? I was thinking >>> of global printer settings which will be persistent. I don't know how that >>> will fit this mock-up, or we could have both. We could have a dialog which >>> sole purpose is for printer settings and the inline page for per page >>> settings/preview customization. The inline page can have a link to the >>> global settings if needed. >>> >> >> I think the settings should just be global and sticky (just like default >> printer on the mac: it just uses the last one you used). Most people >> probably don't want to change print settings when they're not printing. >> >>> >>> That will seem to be too crowded, and my vision would be incorporating >>> all this (preview and settings) into the same page. I am just wondering how >>> the UI's team vision is, wrt to settings. Would be nice to see. >>> >>> We already started with Headers/Footers data persistence in a previous >>> CL. And would like to have a UI that will let the user interact with such >>> data instead of editing the Preference file directly. Later on we could >>> start the print preview implementation, which I "think" is challenging. >>> >> >> >> I think Ben's opinion was that the preferences would be hard to understand >> without the preview, so we should do the preview first. I can't comment on >> the difficulty of it :) >> >>> >>> >>> -- Mohamed Mansour >>> >>> >>> >>> On Thu, Jun 4, 2009 at 9:12 PM, Nick Baum <[email protected]> wrote: >>> >>>> Hi guys, >>>> I've attached an old print settings mock up from >>>> Glen. I think it'd make a lot >>>> of sense to add the print settings on this page as well. >>>> >>>> If someone wants to take a stab at the print preview as pictured here, I >>>> think that'd be a great first step. Once we have that working, I'd be happy >>>> to mock up some ideas for settings. >>>> >>>> Cheers, >>>> >>>> -Nick >>>> >>>> On Thu, Jun 4, 2009 at 7:21 AM, Marc-Antoine Ruel >>>> <[email protected]>wrote: >>>> >>>>> Most of the print preview will be implement in RenderView and friends >>>>> which is in chrome/ ... (previously it was all in browser/ in fact) >>>>> >>>>> On Jun 4, 2009 10:04 AM, "Mohamed Mansour" <[email protected]> >>>>> wrote: >>>>> >>>>> I don't think so, it would be using the same infrastructure of history >>>>> / downloads / and new tab page. Someone can correct me if I am wrong. >>>>> >>>>> -- Mohamed Mansour >>>>> >>>>> On Thu, Jun 4, 2009 at 9:43 AM, Marshall Greenblatt < >>>>> [email protected]> wrote: > > Hi Ben, >... >>>>> >>>>> >>>>> >>>>> >>>> >>> >> > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
