Re: Printing.

[Andrew John Hughes]

On Sun, 2004-11-14 at 00:40, Sven de Marothy wrote:
> Hello, all.
> Given that we're pretty much up to 1.1-api compatibility at the moment,
> and we'll be there in the forseeable future, perhaps it's time to
> discuss some of the few remaining gaps to Java 1.2.
> 
> One of these is printing. So here's a short intro to printing in Java
> for those not up-to-speed:
> 
> There's java.awt.print, introduced in Java 1.2. It's pretty much a
> simple wrapper around the underlying OS printing interface. Basically
> all the work is done by a native implementation of the class PrinterJob.
> 
> This includes dialog boxes for printing and paper selection. So native
> dialogs are allowed. (And used, on OS X for example) Native dialogs is
> of course desireable out of a desktop-integration standpoint.
> 
> The printing itself is pretty simple, out of the API standpoint. It's
> done by a PrinterGraphics object which inherits Graphics2D and it
> basically works like to-screen drawing, calling a print() method in the
> objects, which works just like paint() except that page layout
> information is passed so the method can transform the drawing to the
> page.
> 
> Then there's javax.print, introduced in Java 1.4. Javax.print does stuff
> like job management, printer selection and control, and such. It does
> not have an image model of its own though, but rather expects data to be
> fed to it as PostScript, JPEGs or raw text.
> 
> Now, the latter is newer, but less of a problem. The capabilities
> javax.print needs are pretty much covered by CUPS, the common unix
> printing system. There is already a LGPL implementation of javax.print
> on cups known as Jipsi out there, which could be adopted.
> 
> So, what concerns me mostly here is the former, java.awt.print.
> Now, since the gui of choice here is Gnome, I'll focus on that.
> Gnome printing is in a rather unsatisfactory situation. 
> 
> First off there's PostScript. PostScript can be fed directly to CUPS (or
> javax.print) and the Java2D imaging model is similar to it, so a
> rudimentary output-via-PostScript driver could be written fairly easily.
> (I've written one myself I could recycle here) The drawbacks here is
> that PostScript only supports a subset of Java2D 'natively' so to speak.
> Most notably, compositing is not supported. A composited image needs to
> be rendered as a bitmap, which isn't a pretty option.
> The other drawback is that we'd need to implement the printing dialogs
> from scratch.
> 
> Secondly, there's gnome-print. Gnome-print provides the dialog boxes
> and widgets used for printing. It also provides a PostScript-like
> imaging model, so it's not much harder to implement than the above. 
> This model does support alpha-channels, but apart from that suffers from
> the same drawbacks as above. On the plus side, gnome-print has the
> well-known Gnome printing dialog boxes. Gnome-print is also integrated
> with Cups, making job control simpler.
> Gnome-print also has nice PS and PDF backends.
> 
> Thirdly, there's Cairo, which is already used for on-screen Java2D
> drawing. Cairo has a Java2D/SVG/PDF 1.4-like drawing model, which means
> that it does support compositing. It also has a PS backend and PDF in
> the works. Unfortunately as of yet, the PS backend isn't that good. It
> solves the mentioned compositing problem by just drawing a high-res
> bitmap. On the plus side, the existing Graphics2D peer could
> easily be used with the PS backend for printing. 
> Also, the Cairo folks do seem to aspire to remedy this PS situation in
> the future, rendering only the composited parts of the page as a bitmap.
> 
> A lot is happening in this area though. Havoc Pennington seems to have
> the opinion that gnome-print should be scrapped for Cairo. I don't think
> he really means all of gnome-print though, but rather just the imaging
> model. (since cairo has no intent of including a bunch of job-control
> code and widgets and such)
> 
> But as of yet, nobody seems to have started the work on creating a new
> gnome-print on top of cairo.
> 
> So the options, as I see them, are:
> - Render to PS directly or via Cairo and send to javax.print/CUPS,
> implement our own dialogs and job-control code.
> (Requires a relatively large amount of work, and in particular, it'll
> require javax.print to be implemented)
> 
> - Use Gnome-print in its existing state as a temporary solution.
> (Least amount of work, but not satisfactory since it doesn't support
> everything we need, and the future of the graphics model is uncertain.)
> 
> - Use some hybrid with gnome-print for widgets but cairo for rendering
> (Could mean less work than the first, but might be quite kludgy)
> 
> - Help out with moving gnome-print to cairo
> (Somewhat comparable to the first option in work, but it's in C, and an
> unrelated project. However it would be helping the long-term interests
> of GNOME, and thus ourselves)
> 
> - Sit around and wait for the situation to resolve itself.
> (Requires no work at all, but won't help us reach 1.2 compatibility
> either)
> 
> Any thoughts?
> 
> /Sven
> 
> 
> 
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/classpath

IMO, a Cairo-supporting GNOME-print seems the best option, especially in
the long term.  Creating the widgets ourself would seem to be a lot of
work, which effectively leads to a situation where GNU Classpath
printing is different (to some degree anyway) from other applications. 
Similarly, joining GNOME print with Cairo ourselves would just seem to
be duplicating work.  As it stands, it seems we either wait for
GNOME-print to sort itself out, or help it get there.

Cheers,
-- 
Andrew :-)

Please avoid sending me Microsoft Office (e.g. Word, PowerPoint) attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

"Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn."
-- Richard Stallman

"We've all been part of the biggest beta test the world has ever known --
Windows"
-- Victor Wheatman, Gartner

signature.asc
Description: This is a digitally signed message part