Closed
Bug 113231
Opened 23 years ago
Closed 8 years ago
converting print request to image capture
Categories
(Core :: Printing: Output, enhancement)
Tracking
()
RESOLVED
INCOMPLETE
Future
People
(Reporter: rvj, Assigned: john)
References
Details
I raised a query(RFE 64074) some time back asking whether it would be possible to capture/convert iframe content as a raster image (PNG,GIF, etc). Currently most O/S have screen capture ability but that assumes the required image is on-screen .What is often the case is that it is often required to snapshot the entire contents of an frame (the contents of which may have to be scrolled into view) Is there a possiblity of extending the print engine to capture iframe content as image? It would avoid having to use a misc O/S clipboard methods and hopefully make the creation of thumbnail images a lot simpler.
this is an RFE at best and not a bug.
Severity: normal → enhancement
Updated•23 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•23 years ago
|
||
For which platform do you want this ? Xprt (the Xprint Xserver) supports the XWD (X window dump) output format which can easily be converted to GIF/PNG etc. etc. Or do you want this for all platforms ?! if yes --> "Compoent: Printing", the bugzilla component "Printing: Xprint" is for the Xprint module only ...
have changed component to printing
Component: Printing: Xprint → Printing
Comment 4•23 years ago
|
||
Fixing Owner+QA ...
Assignee: katakai → rods
QA Contact: Roland.Mainz → sujay
Comment 5•23 years ago
|
||
This would also be useful for (for example) showing thumbnails of previously visited pages in the history list.
Comment 6•23 years ago
|
||
sounds like a fun thing to get to do
Status: NEW → ASSIGNED
Target Milestone: --- → Future
PS I think the area of the document captured should also be able to be defined by css crop attributes. This will allow a portion of a larger document area to be snapshot. The only css requirement I am unsure of is a 'resolution' factor but I assume crop size specified in px or pt will solve this?
Comment 8•22 years ago
|
||
*** Bug 128652 has been marked as a duplicate of this bug. ***
Comment 9•22 years ago
|
||
*** Bug 173756 has been marked as a duplicate of this bug. ***
*** Bug 198376 has been marked as a duplicate of this bug. ***
We can already print-to-PS (at least on Unix) and then use ghostscript to rasterize the PS to some image format. So "all" we need for say, thumbnail generation, is a way to do offline printing (e.g., "mozilla --print-to-file mozilla.ps http://www.mozilla.org", or maybe a similar mozilla-remote command). Maybe we could do the same thing with XPrint.
Comment 12•21 years ago
|
||
Postscript isn't very popular on windows and 99% of the users don't know what it is. Please do something platform-independant.
Assignee | ||
Comment 13•21 years ago
|
||
Reassigning some of rod's old bugs. This would be neat.
Assignee: rods → jkeiser
Status: ASSIGNED → NEW
Comment 14•21 years ago
|
||
Using xprint to obtain a screenshot isn't ideal for three reasons: (1) getting xprint to output in xwd format isn't easy; after an hour of looking through the documentation and README files I'm still not sure how to do it -- or even if I was looking in the right place (maybe in printcap?). Even if this were trivial to set up, it's a UNIX-only solution (2) the mozilla print engine still has problems with background/transparent images; see bug #115327 (3) the goal is to produce a screenshot, not a raterized version of the print engine's interpretation of the screen. If we use the print engine, then the screen raster gets converted to a raster-plus-fonts mixture, which is then re-rasterized for output. This "chinese whispers" solution is also why using pstogif or ps2html produces ugly results. The screen raster already exists: dumping it in xwd/png format will result in a 100% pixel-perfect, platform-independant copy that doesn't inherit the bugs, quirks, and interpretations of the print engine.
Comment 15•21 years ago
|
||
*** Bug 220763 has been marked as a duplicate of this bug. ***
Comment 16•21 years ago
|
||
While it's a dupe, bug 220763 also had a good suggestion: in addition to Print To Image, there should be an option to Save As Image in the Save As dialog box. This is the same suggestion as bug 173756, the bug which led me here in the first place. I like the idea,
Updated•21 years ago
|
OS: other → All
Comment 17•20 years ago
|
||
*** Bug 235944 has been marked as a duplicate of this bug. ***
Comment 18•20 years ago
|
||
*** Bug 235944 has been marked as a duplicate of this bug. ***
Comment 19•20 years ago
|
||
I'd like to note that you would want to use the current visible CSS and not the "print" media CSS when doing this screen capture since its final destination is not paper.
Reporter | ||
Comment 20•20 years ago
|
||
I understood 'rods' decided to take this request back in December 2001 but has since left. Given the amount of interest in this feature, is it likely to get back on the development radar in the near future? ... or does it only depend on the vote priority?
Comment 21•20 years ago
|
||
on windows, MS Publisher Imagesetter is a TIFF generator....
Comment 22•20 years ago
|
||
.BMP generation would be better for Windows, imho.
Comment 23•20 years ago
|
||
Yes, that would be the lowest common denominator format, because that is the only format MS Paint for Win95-2k can open. But any format would be ok for those who really want to do something with the image. They would have a more professional image editors. Does this actually have anything with printing? This could be hooked somewhere to the internals of Gecko, when it pushes the rendered page to the screen (or OS).
Comment 24•20 years ago
|
||
acelists@atlas.sk: that's not entirely accurate. if you install office, then mspaint can open and save to more formats. further, most versions of windows have quikview and imaging (formerly wang imaging). imaging can handle: tiff, bmp, jpg, pcx/dcx, xif, gif, and wiff. it kinda sucks that imaging wasn't friendly enough to share its read/write capability w/ the rest of the children as office does.
Comment 25•20 years ago
|
||
The coolest thing to do would be to allow a choice amongst a few formats: .png, .bmp, {NOT .gif because of unysis patent}, .tiff... I can't see that .jpeg would be good because it is not a lossless format. Ok, so maybe in the future supporting a few formats would be cool... But for now, .tiff doesn't sound like a good idea to me because its not a web standard. .png means that people could immediately throw their imaged documents back up on the web for whatever reason (usually debugging purposes). Could we use libpng? Just one caveat... .png transparency is not supported by Microstinks.
Comment 26•20 years ago
|
||
Notice also that if this could be hooked up for images to, it'd allow people to save images in an arbitrary format. Let's say we support saving to .png... Could this be extended through some kinda plugin or extension to support other formats 3rd parties want to add? Something I think we should keep in mind. Its not the same thing as, for instance, a PDF Writer for printing, since it seems people want to hook it in from the rendered image. Therefore, extensibility would be something nice... Especially if other Mozilla developers in the future want to add support for other formats, but it would create bloat for the main binary and we'd want to package the rest in XPCOM extensions or what-not.
Reporter | ||
Comment 27•20 years ago
|
||
... any image fomat that supports transparency is surely the goal ? otherwise the redisplay of symbols appearing on toolbars will be unacceptable. PS do I take it MS Word has licenced GIF as its standard conversion format during Save as HTML otion?
Reporter | ||
Comment 28•20 years ago
|
||
[otherwise the redisplay of symbols appearing on toolbars will be unacceptable...] Im probably wrong about this, however there is probably still a case for being able to crop and save parts of a document including background transparency .. so that they can later be assembled as successive layers (plates)
Comment 29•20 years ago
|
||
Imaging is installed less offen than Paint. But anyway, the is no png in the list of its formats. Anyway, I propose bmp because it is simplest and smallest in code size. Of course, if Moz already has libraries to create image files, use them and choose any format already available, to not add too much new code. I didn't understand what this has to do with transparency. A screenshot can't be transparent. Bmp is enough. If I remember correctly, at least one browser (Arachne for DOS) had this feature years ago.
Comment 30•20 years ago
|
||
I think what was meant was saving the page into multiple layers with the background on a seperate layer. I think there is some confusion of what's intended here. If the background for a page were in fact transparent, which is possible, then a transparent capture would be more reasonable. As for .bmp, we could save some kind of transparency mask of black pixels that people could apply to their image in an image editor called transparency-mask.bmp or something. Remember that although .png transparencies exist, Microstinks doesn't support them :-) I'd say if we support any format, we should support it cross-platform, giving people a few options. I guess we can't use libpng because its GPL? We can write to .png mainly for Unix, but also for all platforms, along with .bmp mainly for Win32, but have it available for other platforms -- giving people an option of .bmp or .png on all platforms. What about Mac? Would they be happy with .png? Memory footprint is pretty much irrelevant, since this could be set up so it is in a library that is only loaded when needed and unloaded when finished. timeless: As for code size, could this be set up as an XPCOM extension that is optional to install? I don't know enough about XPCOM extensions. As for implementation, I think the best way to do this would be to probably have filters that you run the raw bits of the image through. More filters could be added by 3rd parties. The filters could be as code libraries or some scripting language.
Comment 31•20 years ago
|
||
Oh, this is getting complicated. Several layers? In css, any element can have its own background. Would that be merged into the body background or have its own layer? What about z-index? There should first be a plain classic solid non-transparent screenshot, just that it would show also offscreen parts. "Simply" dump the render buffer of the page content area to a file. Of course it would be a separate library, I was talking about the disk size it would take.
Comment 32•20 years ago
|
||
I guess we should really think about what the purpose of this function would
be... I thought it was more of a screenshot-like function that lets you print to
an image everything in the scrolling frame, unlike a normal screenshot which
would only show what's on the screen. Does rjv want one layer for the page minus
the background, and one layer for the background?
I think that we should probably support filters being written in any language
that can interface to XPCOM, including javascript. Using filters as opposed to
something hard-coded will allow people to add formats to save to. For instance,
someone might want to add jpeg2000 support in the future. The screen buffer
would be dumped to this filter in RGBA format. The filter can do whatever it
wants with the information, but it should be common practice for a filter with
support for transparency and alpha to use the A byte. A web page wouldn't have
an alpha background (i.e. not fully transparent), would it? If not, the alpha
byte would only be 255 or 0.
None of the following is meant as anything more than an example of how this
could be implemented. The following might seem complicated at first glance, but
its really simple if you think about it... Its based on a topology of
application <- interface -> filter
Mozilla <-> nsISaveFilter (bad name) <-> the filter (inherits nsISaveFilter)
contains:
queryCapabilities() -- query how transparency will be handled
initDump() -- initialize the image dump
dumpBits() -- sends a row of bits or something
filter libraries kept in the bin/plugins/savefilter directory
Simplified example (left out the common dialog stuff):
+----------------------------------------------------+
| [ ] Save to clibpard |
| |
| Save Image as [ ] |
| Format [ Portable Network Graphics.png |V|] |
| |
| (*) Save page as seen |
| ( ) Discard background information |
| ( ) Save only page background |
+----------------------------------------------------+
Choosing "Save to clipboard would grey out "Save Image as" and "File format" but
could leave the other stuff.
Putting these choices in a dialog would mean that we can simply ignore whether
or not the page has a transparent background and leave it up to the user whether
the background is used or not. I added "save only page background" but I'm not
sure if that would be a good idea... I just put it there because it seems like
it'd be useful for debugging purposes.
Filters for formats that don't support transparency can ignore the alpha byte,
and the RGB information will contain the page including the background... They
could spit out a black and white transparency mask so that someone could load it
into an image editor and use the mask to remove the background on the image.
We could have a required function within the filter called queryCapabilities()
or something, and it could return an integer about its capabilities with respect
to trasnparent backgrounds:
0 Do not use this filter
1 This filter does nothing with transparent backgrounds
2 This filter will give a mask
3 This filter can put transparent backgrounds within the image
Then Mozilla can take the results and do the following actions:
0 This might be used for a nullfilter or something
1 Warn the user that the page's background will be replaced with the default
browser background chosen from prefs because the format doesn't support it OR
just grey out the last two options.
2 If checked, bring up a dialog box to warn the user that the format doesn't
support transparent backgrounds, and therefore an additional mask will be saved.
3 Its all good.
Then if the user has the last two options selected, we'll pass a parameter to an
initialization function within the filter (initialize the dump) that tells the
filter whether we want it to ignore the Alpha information or not.
.bmp would be an example of where a mask would be used, whereas .png would be an
example of where the transparency info would be part of the image. This would
provide two good examples for people who'd be writing filters for other formats.
> I was talking about the disk size it would take.
I don't think this would be significant... We wouldn't need to support writing
to, say, .png, in every way... Just the least common denominator way. That
means the code might be only a few hundred lines.
Transfer time for a feature people don't really need might be a good point. The
XPCOM portion for interfacing the filters will be very small, whereas the
filters could be offered seperately, or perhaps we'll only offer the two
aforementioned since there could be 3rd party filters written.
Comment 33•20 years ago
|
||
I forgot to mention, that I think I heard about some guys (maybe even from mozilla.org) who render the same pages in different version of Mozilla. They take screenshots of them and then compare the bitmaps pixel by pixel to find changes and possible regressions. Maybe they could use this feature too...
Comment 34•20 years ago
|
||
A variation of that would be if you could automate this process through a script that allows you to load and dump a page (then exit mozilla), you'd have a nice way that people could test their pages on a remote server outside their firewall to see if it appears as they expect.
Comment 35•20 years ago
|
||
*** Bug 242585 has been marked as a duplicate of this bug. ***
Comment 36•20 years ago
|
||
*** Bug 256529 has been marked as a duplicate of this bug. ***
Comment 37•20 years ago
|
||
May I add that it would be cool if the render-to-image feature would be scriptable and work without an X-server, so it can be run directly on the web server.
Comment 38•19 years ago
|
||
*** Bug 290742 has been marked as a duplicate of this bug. ***
Comment 39•19 years ago
|
||
From a Mozilla-the-platform point of view, I think something very, very similar was implemented in the meantime: the <canvas> element (specified by the WHATWG) and its drawWindow function. For details, see http://weblogs.mozillazine.org/roc/archives/2005/05/rendering_web_p.html . Saving the canvas contents to an image would be achieved with the toDataURL method that will be introduced by bug 291218, so I think this bug should be resolved as dupe of that bug. However, if this bug's focus is more to an end-user feature, then it should probably stay open. However, if implemented, I'd bet this won't make it into the Firefox core...
Comment 40•19 years ago
|
||
*** Bug 309939 has been marked as a duplicate of this bug. ***
Comment 41•19 years ago
|
||
(In reply to comment #39) > From a Mozilla-the-platform point of view, I think something very, very similar > was implemented in the meantime: the <canvas> element <..> > However, if this bug's focus is more to an end-user feature, then it should > probably stay open. However, if implemented, I'd bet this won't make it into the > Firefox core... Possible workaround: the Pearl Crescent Page Saver extension (via Daniel Glazman http://www.glazman.org/weblog/). http://pearlcrescent.com/products/pagesaver/
Comment 42•19 years ago
|
||
*** Bug 112702 has been marked as a duplicate of this bug. ***
Updated•15 years ago
|
QA Contact: sujay → printing
Comment 44•13 years ago
|
||
All still-supported OSes provide "print to PDF" at a layer below us (except possibly Windows XP). Is it still useful to keep this bug open?
Comment 45•12 years ago
|
||
Yes. Because it is still not possible to print the whole page (long long long) page to one image, without cropping to A4 or whatever is the print size. There was an add-on: https://addons.mozilla.org/en-US/firefox/addon/screengrab/
Comment 46•12 years ago
|
||
Mitar: For that use case, would "print to PDF" with a custom, automatically calculated paper size which is as big as it needs to be to fit the entire webpage on one PDF-page do what you want? That is a thing that could be fit into the existing printing infrastructure; I don't know if it's something we'd want to expose in the stock UI, but I'd be happy to assist in the development of patches that made it easy for an add-on to do that, if it's not easily doable right now. (In my copious free time.) N.B. I don't remember how big a PDF-page is allowed to get. That might be a hindrance.
Comment 47•8 years ago
|
||
(In reply to Mitar from comment #45) >(In reply to Zack Weinberg (:zwol) from comment #44) >> All still-supported OSes provide "print to PDF" at a layer below us (except >> possibly Windows XP). Is it still useful to keep this bug open? > Yes. Because it is still not possible to print the whole page (long long > long) page to one image, without cropping to A4 or whatever is the print > size. > > There was an add-on: > > https://addons.mozilla.org/en-US/firefox/addon/screengrab/ There are various add-ons that seem to be currently supported that provide this functionality, such as: https://addons.mozilla.org/en-GB/firefox/addon/nimbus-screenshot/ This bug has lots of different (but related) ideas and use cases. Besides that, as noted in comment 39, canvas has provided much of the needed functionality. At this point it would be better to have new bug(s) for any outstanding issues. If anyone has any outstanding issues please file them separately along with clear descriptions of your use cases.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•