Closed Bug 113231 Opened 23 years ago Closed 8 years ago

converting print request to image capture

Categories

(Core :: Printing: Output, enhancement)

x86
All
enhancement
Not set
normal

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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Fixing Owner+QA ...
Assignee: katakai → rods
QA Contact: Roland.Mainz → sujay
This would also be useful for (for example) showing thumbnails of previously 
visited pages in the history list.
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?
*** Bug 128652 has been marked as a duplicate of this bug. ***
*** Bug 173756 has been marked as a duplicate of this bug. ***
Keywords: oeone
*** 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.
Postscript isn't very popular on windows and 99% of the users don't know what it
is. Please do something platform-independant.
Reassigning some of rod's old bugs.  This would be neat.
Assignee: rods → jkeiser
Status: ASSIGNED → NEW
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.

Depends on: 206347
*** Bug 220763 has been marked as a duplicate of this bug. ***
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,
OS: other → All
*** Bug 235944 has been marked as a duplicate of this bug. ***
*** Bug 235944 has been marked as a duplicate of this bug. ***
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.

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?
on windows, MS Publisher Imagesetter is a TIFF generator....
.BMP generation would be better for Windows, imho.
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).
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.
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.
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.
... 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?
[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)

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.
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.
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.
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.
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...
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.
*** Bug 242585 has been marked as a duplicate of this bug. ***
*** Bug 256529 has been marked as a duplicate of this bug. ***
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.
*** Bug 290742 has been marked as a duplicate of this bug. ***
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...
*** Bug 309939 has been marked as a duplicate of this bug. ***
(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/
*** Bug 112702 has been marked as a duplicate of this bug. ***
QA Contact: sujay → printing
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/
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.
(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.