On Thu, Mar 29, 2012 at 9:59 AM, <[email protected]> wrote:
> The points above seem to work in a very hacked up first version :) > Impressive!!! > Instead of the event I use callback style for now. The first argument gets > the rendering context and the second argument is an object, that contains > additional data. > What does the print engine pass as the second argument? You shouldn't really need to use a second argument to carry around data for rendering. You can use a JS closure for that. -- What should be the unit system for the context used in the > mozPrintCallback? Right now, one unit corresponds to the length that one > pixel of the canvas gets mapped to in the actual printout. That has nothing > to do with the 1/72 inch or 1/92 inch mentioned in this thread. However, > the way it's right now is what people might expect. If they write a > rendering function like I did in the gist file, then they just can reuse it > during rendering as well and don't have to adjust the unit system depending > on printing to screen or printer. > I think that's definitely the right thing to do. -- Is there a way to figure out the DPI resolution of the printout in C++? > Yes, cairo_surface_get_fallback_resolution. You should add a wrapper to gfxContext to return it. -- ctx.getImageData and ctx.putImageData work as expected. The second > rectangle you see in the example PDF on the bottom right was created using > getImageData and putImageData. During this process, the vector information > gets rastered and therefore the text quality of the second rectangle is > poor compared to the original one. The resolution stays the same during the > rastering process as it would in the "normal" DOM case. For the printing > case, it might be useful to request imageData with a higher resolution. > Should there be a new parameter for the getImageData and putImageData to > specify the resolution? E.g getImageData(x, y, width, height, 100) returns > imageData where each "normal" pixel corresponds to 100 pixel. > getImageData/putImageData were originally designed to be able to return high-res versions of the canvas data. However, Web authors don't use them as designed so we'll probably need new APIs for this. See the recent thread http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035112.html. -- How can one figure out the actual size of the canvas when printed to > paper? I guess I can get some size-information from the CanvasFrame, but is > that the actual/resulting size on paper? > When printing, CSS units are rendered as physical units if the zoom factor is 100%. Each CSS px is 1/96 of an inch. Changing the zoom factor will change this of course. What do you need this for? >> In addition, there need to be a way to scratch an element onto an entire > print page. E.g. a canvas should take up the entire page if the margin is > set to zero. Can that be done using something similar to > style="width:100%;height:100%"? > > > > Yes. > > Rob, what was your idea to use for this? > Easiest way is probably to make the canvas position:absolute; top:0; left:0; width:100%; height:100%. Of course you'll need to zero out margins as well. Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others?" [Matthew 5:43-47] _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
