This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Printing.


Hello, all.
I posted this to the Classpath list, but since the input of the
gui-branch folks is important here, I'm re-posting it here too.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]