The specific operating system being targeted by this request is Linux/Unix; but the solution could be applied to other operating systems as well. To support Thin Clients; such as Internet Appliance, PDA, cellular phone, etc., on Linux/Unix it is not practical to implement the current PostScript printing solution for typical consumer printers (those costing approximately $100.00). PostScript rendering for these types of devices is not done within the printer but is typically be done through the use of Ghost Script which requires considerable system resources (memory). This situation can be solved by the generation of a raster image print output format using the current Mozilla parsing and rendering engine with a DeviceContext for (describing) the printer output requirements (resolution, page size, etc.). However, this leads to a resource issue. Currently Mozilla is "page" orientated; that is it processes a entire "page" for the current device. Thus, a 300 dpi printer with 24-bit color on a 8.5" by 11" paper it would require about a 25 Mbytes image to be generated! This is exceed the resources for most Thin Clients. The solution is to have the View/Rendering engine of Mozilla support banding. That is, Mozilla renders to the output raster DeviceContext (printer) image as a set of bands where the band size is determined by available system resources. This solution can be implemented independent of or in the context of XPrint; but the more general case of independent of XPrint is preferred. I would vote for Don Cone to be the bug owner for this new request.

Is there code that this requested component would cover?

This is not the correct Product or Component to file Feature Requests. If this feature exists and there are enough bugs being filed on that code then I will consider creating a Component.

Can someone comment on this please.

What about using Xprint for this ? Client-side does not need much resources and server-side (Xprt) only requires a new Xprint server driver for "banded raster image generation"... BTW: Xprt has a PCL-driver, too...

XPrint is one solution. If used, I suggest using the X-window dump (xwd) raster driver (or output mode) in XPrint versus the pcl-driver. (This output can be supplied to consumer level printer driver directly without an additional rendering step.) Whether XPrint is used or not, the initial step of this output processing is in the view-manager of Mozilla. It must comperhend and output in bands verus pages and supply the band to the printing sub-system. As to the use of XPrint; I believe Mozilla already is capable of rendering to bitmaps for the screen (device-context) and with some modification should be able to render to other "device-contexts" without XPrint. Nothing against using XPrint but for thin-clients XPrint represents more code and overhead. Also, when ported to Windows or Mac or ??? platform the rendering engines of the OS can be used with out the need of XPrint.

Question is "how many" print systems shuld be integrated... I would still vote for Xprint because it was designed for low-resource usage in mind. Main work is done in the Xprint server (Xprt) which is not required to run on the same machine as the Xprint client - this is a _huge_ advantage and a unique feature which isn't present in any other print system (AFAIK... :-) last-but-not-least Xprint lowers the administration costs because configuration is done at the server side, not at the client side as most print systems do... > Nothing against using XPrint but for thin-clients XPrint represents more code and overhead. > Also, when ported to Windows or Mac or ??? platform the rendering engines of the OS can be used with out the need of XPrint. Xprint server is portable - and even a JAVA2 version is currently in development - and Xprint may use platform-specific rendering engines may be used by Xprint, too...

This component is not the place for feature requests. It is reserved for maintenance of bugzilla.mozilla.org copmponent definitions and assignees as well as keywords. Sending this to Browser Product Printing

To Glen Petrie: Recently posted in news:comp.windows.x -- snip -- > All the time I thought that Xprint tracks all drawing > commands between XpStartPage() and XpEndPage() and > transforms them into PS/PCL data - but today someone > said that Xprint simply does a "xwd"-like dump of the > screen... > ... who is right ? You are - Whoever said Xprint simply does an "xwd"-like dump is wrong. In short, Xprint supports *three* drivers: 1) X to native Postscript, 2) X to native PCL5, and 3) X to a raster which is then feed to something like xpr to create PS or PCL5 wrapped rasters. [snip] A 8.5"x11" @ 300 DPI pixmap is huge, and PCL5 at least supported run-length and delta-row image compression, and on the printer side the decompression was in firmware, so it was reasonable to convert the pixmap into a fairly-well compressed binary PCL5 stream for transmission over parallel printer lines. Postscript on the other hand did not handle rasters well. Though HP had just started shipping PS Level 2.0 which had instructions and firmware support for LZW compression, SUN's Sparc printers were still at PS Level 1.0, so we had to limit the raster-PS driver to PS Level 1.0 and in general keep the PS stream in ASCII. Wrapping a 8.5"x11" @ 300DPI raster in a PS image instruction yielded a *huge* output stream that transmitted slowly, and using run-length-encoding (RLE) (see the xpr code) meant you could transmit a smaller file, but it took forever to decode it in the printer. As CDE 2.0 came around, Bob Schiefler and others at the X Consortium were determined to make another run at XPS, and didn't want to see it die. It was immediately agreed that the X Consortium would work on a X to native PS Level 2 driver and HP would work on a X to native PCL5 driver. Just for reference, PCL5 is really PCL4 + HPGL, where HPGL was HP's printer language specially designed for graphics. In both cases, X calls could be mapped within reason to PS and PCL5 equivalents. We were even able to handle fonts. When we did our first native PS and PCL5 prints, we were overjoyed at how small the printer spool files were, and how quickly they printed. The only issue with the native PS and PCL5 drivers is that they did not necessarily follow all the X pixelazation rules (e.g. in X, a width 1-n line must follow specific pixelazation rules, where-as a width 0 (zero) line is allowed to bypass the rules and take advantage of any hardware acceleration). For those who required perfect X pixelazation while printing, the old raster driver was retained, although I'm not sure if it was ever refined into dependable product quality like it should have been. It was probably the CDE 1.0 effect that left many people with the impression that XPS is all about xwd-like window dumps. No! XPS has native PS and PCL5 printing. For that matter, it was our hopes to see many more native drivers: at the time, maybe FAX, and certainly now, one would want a native PDF driver. -- snip --

To Glen Petrie (again :-): AFAIK the "easiest" solution would be to hack Xprt's "raster" driver to match/fit your demands/requirements... Xprt does not consume huge resources (~3MB on SPARC (RISC - x86 or thumb-ARM should be _much_ smaller - and even a JAVA2-based Xprt will be available in the near future)) and would avoid adding more code on Mozilla's side...

I have the same understanding of XPrint and of "xwd" rendering as discussed in the comment dated 02-26-01 @ 09:39 by Roland Mainz. The issues which this request is trying to address are 1.) a non-vendor specific and/or Postscript output format 2.) an output mechanism that can be applied to thin-client (limited memory solutions); thus, the concept of a banded-raster output format has been proposed/suggested. ( A note: I was told this was the correct forum for submitting "new" request for Mozilla. Can someone send me the URL for the correct enter point for Mozilla new submissions. I will submit my discussion here for now. ) In general, individual vendors do not generally support other vendor specific print formats within the print devices; in this case PCL. As discussed in the original submission, PostScript (and PCL) rendering at the printer increases the cost of the printer in the consumer-printer market, so that, PostScript rendering by the printer is not viable. The alternative used to date is rendering with GhostScript. However, GhostScript rendering dramatically increases the memory requirements for a thin-client since GhostScript uses a page-concept (like "xwd") thus requiring a huge memory buffer to store the rendered page. For a thin-client version of Mozilla that could be used on many of today's and the next generation, web-appliance, a banded process is needed where rendering is done using gfx of gecko within Mozilla. The need is have (all) printing supported, for thin client, using 1 Mbyte or less of memory (code plus buffers but not including the rendering).

Questions: 1. To avoid any misunderstanding: What do you mean with "_banded_" ? 2. Where's the problem with implemeting this via Xprint ? If you strip Xprt and remove everything except Xserver core and raster DDX driver support it should work like a charm on your loca thin-client... ...and: Xprint would "enable" your thin-client to use remote Xprt's for printing without running a whole print spooler (lp/lpr) on your local thin-client... Last but not least: Xprint config is completely done on server-side - no more print configuration on client side...

1. Banded means a strip or horizontal segment of the page. Example, the first band would be from the top of the page to 1" down; the next band is 1" down to 2" down and so-forth. Yes, this may require multiple rendering of a single object and speed could be an issue but the situation is one of limited resources (memory). 2. I have not implemented this solution myself but am aware of someone else that has attempted it. The solution had some rendering problems from within gfx and Xprint but I have not attempted to work out the exact details of the problems. It is important that the banding mechanism be integrated with Mozilla and that Xprint understand that it is processing bands and must expect a sequence of bands to be send to the printer until a page is complete. To do this, I believe that first step is to create the banding mechanism within the View Manager of Mozilla. Once that is complete, then introduce bands to Xprint. If complete band rendering can be done with gfx, then, in theory, the rasterized band could be sent directly to a printer driver without Xprint. I think this is a later refinement.

I dont think we will do this.

verified.

This package provides the implementation of the Rprint (Raster Print) print model for Mozilla browser Linux-based printing. Rprint is a new print model proposed by Epson for Mozilla browser to directly render HTML documents to banded raster output for print drivers in Linux environment. This package includes Rprint White Paper, README files, scripts, the source code for modified Mozilla modules incorporating Rprint and IJS, Rprint configuration files, Mozilla browser binary with Rprint enable, and Epson IJS print service server binary. Please read the README.epMozilla for more detail info. Please download this package from http://www.eitcsv.com/sps/2003/ep-firebird100-rel-071703.tar.gz. (112MB)

I would suggest creating a mozdev project for rprint, or registering it as Mozilla Firebird extensions, or whatever is appropriate. That way people can actually find this piece of technology.