Printing API and Attributes

[Marian Schedenig]

Hi!

Forgive me for posting this twice; I originally sent it as a reply to an
older (unresolved) thread, but perhaps that was a bad idea and I do have
a chance to get answers in a new thread.

I can print .ps files with no problems on my windows box at work, but
the printer completely ignores all attributes I specify.

The printer is a HP LaserJet 1320 PS. It correctly gives me a list of
media trays. But regardless of which tray I select, or what orientation
or number of copies, I always get exactly one printout in portrait mode
from the standard tray. Now the printer really has only one tray plus a
manual feed, but I figure even if all other reported trays are
redirected to the standard tray by the driver, at least the manual feed
should work separately - and if not that, I'd still expect it to handle
at least the Copies attribute correctly.

On my Linux box at home my test program doesn't even list any printers,
but perhaps that's because it doesn't see my CUPS server address
configured through KDE; I'll have to try the test prog directly on the
server.

Here's the code I use for printing:

public void print(PrintService ps, MediaTray mt, int copies, boolean
landscape, InputStream in) throws PrintException
{
DocPrintJob pj = ps.createPrintJob();
DocFlavor flavor = DocFlavor.INPUT_STREAM.AUTOSENSE;
Doc doc = new SimpleDoc(in, flavor, null);
PrintRequestAttributeSet attributes = new
HashPrintRequestAttributeSet();

if (mt != null)
{
attributes.add(mt);
}

attributes.add(new Copies(copies));

if(landscape)
{
attributes.add(OrientationRequested.LANDSCAPE);
}
else
{
attributes.add(OrientationRequested.PORTRAIT);
}

pj.print(doc, attributes);
}

I've been scouting the net for days, but I can't find any concrete
information on this (it seems people had unresolved problems with
printing until Java 5, and since then hardly anyone has posted news
about it).

Thanks,
Marian.

 

[Ian Wilson]

Marian Schedenig wrote:

Firstly: I have written Java apps which successfully print Postscript
files to a HP 1320, however I am relatively new to Java so beware:

I can print .ps files with no problems on my windows box at work, but
the printer completely ignores all attributes I specify.

Do you mean your programs reads a disk file that contains Postscript?

The printer is a HP LaserJet 1320 PS. It correctly gives me a list of
media trays. But regardless of which tray I select, or what orientation
or number of copies, I always get exactly one printout in portrait mode
from the standard tray. Now the printer really has only one tray plus a
manual feed, but I figure even if all other reported trays are
redirected to the standard tray by the driver, at least the manual feed
should work separately - and if not that, I'd still expect it to handle
at least the Copies attribute correctly.

Here's the code I use for printing:

public void print(PrintService ps, MediaTray mt, int copies, boolean
landscape, InputStream in) throws PrintException
{
DocPrintJob pj = ps.createPrintJob();
DocFlavor flavor = DocFlavor.INPUT_STREAM.AUTOSENSE;

If the printer is a Postscript printer and the Java print system
AUTOSENSEs that your input stream is postscript - I wonder how the Java
print stream can possibly insert the appropriate setpagedevice
statements into the appropriate place in the existing Postscript from
the InputStream. This isn't trivial for arbitrary Postscript files and I
wouldn't be surprised if the Java print system didn't attempt it.

Doc doc = new SimpleDoc(in, flavor, null);

What is in the InputStream?

PrintRequestAttributeSet attributes = new
HashPrintRequestAttributeSet();

if (mt != null)
{
attributes.add(mt);

I'd do a System.out.println("Media tray '"+mt.someMethod()+"'"); to see
if mt contains what you think it does.

You also need to be sure that the 1320 doesn't simply switch to tray 2
if it thinks tray 1 (manual feed) is empty or if you haven't explicitly
told it to wait for manual feed.

}

attributes.add(new Copies(copies));

if(landscape)
{
attributes.add(OrientationRequested.LANDSCAPE);
}
else
{
attributes.add(OrientationRequested.PORTRAIT);
}

pj.print(doc, attributes);
}

I'd be inclined to get the app to print to file using the Windows driver
for the 1320 and compare that with whatever is in the inputstream (which
I'd simplify for testing purposes).

 

[Ian Wilson]

I can print .ps files with no problems on my windows box at work, but
the printer completely ignores all attributes I specify.

I tried your code. Try inserting code like this in the relevant places

if (! ps.isAttributeValueSupported(
MediaTray.TOP,
flavor, aset)) {
System.out.println("...wont do MediaTray.TOP");
}

It suggests to me that you'll need to embed the Postscript directives in
the inputstream yourself.

 

[Marian Schedenig]

Firstly: I have written Java apps which successfully print Postscript
files to a HP 1320, however I am relatively new to Java so beware:

Well, the printing bit does work, but I always get exactly one copy from
tray 1.

Do you mean your programs reads a disk file that contains Postscript?

Exactly. I create an InputStream from a .ps file and put it in a
SimpleDocument.

If the printer is a Postscript printer and the Java print system
AUTOSENSEs that your input stream is postscript - I wonder how the Java
print stream can possibly insert the appropriate setpagedevice
statements into the appropriate place in the existing Postscript from
the InputStream. This isn't trivial for arbitrary Postscript files and I
wouldn't be surprised if the Java print system didn't attempt it.

I've now changed the program to always use
DocFlavor.INPUT_STREAM.POSTSCRIPT. The only change is that it now
(correctly) only lists PS-capable printers.

What is in the InputStream?

FileInputStream in = new FileInputStream(myPsFile);

I'd do a System.out.println("Media tray '"+mt.someMethod()+"'"); to see
if mt contains what you think it does.

I've done that. The media tray instance is taken from a query that lists
the printers trays, and according to my Eclipse debugger, it's still the
correct tray instance when it's store in the attributes map.

You also need to be sure that the 1320 doesn't simply switch to tray 2
if it thinks tray 1 (manual feed) is empty or if you haven't explicitly
told it to wait for manual feed.

Yes, that worried me a bit. However, the printer seems to have only tray
1 and tray 1 (manual feed) - so I'd expect at least manual feed to
behave differently.

In any case, that's why I added the Copies attribute to my test app -
but I always get exactly 1 printout.

I'd be inclined to get the app to print to file using the Windows driver
for the 1320 and compare that with whatever is in the inputstream (which
I'd simplify for testing purposes).

I'd be happy to e-mail you a ZIP of my program if you like?

I tried your code. Try inserting code like this in the relevant places

if (! ps.isAttributeValueSupported(
MediaTray.TOP,
flavor, aset)) {
System.out.println("...wont do MediaTray.TOP");
}

It suggests to me that you'll need to embed the Postscript directives in the inputstream yourself.

I've modified the program to only include attributes the printer
supports, and skip others plus display a message for those. Result: The
printer claims to accept the tray and copies attributes, I only skip the
orientation flag. Still, no change in the printer's actual behaviour.

Are you suggesting that postscript printing can't handle attributes *at
all*? (In that case, I'd consider the API to be broken, since the
printer service *does* claim to support these attributes in .ps mode).

Thanks a lot!
Marian.

 

[Ian Wilson]

I create an InputStream from a .ps file and put it in a
SimpleDocument.

I've now changed the program to always use
DocFlavor.INPUT_STREAM.POSTSCRIPT. The only change is that it now
(correctly) only lists PS-capable printers. ....
FileInputStream in = new FileInputStream(myPsFile);

I'd be happy to e-mail you a ZIP of my program if you like?

I've spent too long on this already :-(

I've modified the program to only include attributes the printer
supports, and skip others plus display a message for those. Result: The
printer claims to accept the tray and copies attributes, I only skip the
orientation flag. Still, no change in the printer's actual behaviour.

Are you suggesting that postscript printing can't handle attributes *at
all*? (In that case, I'd consider the API to be broken, since the
printer service *does* claim to support these attributes in .ps mode).

I wasn't suggesting that, but I am coming to that point of view.

I've written a few test programs and got nowhere with this.

This problem might only apply when you are simply passing a file (or
byte array) to be printed. Much of the Java printing API seems to expect
you to do page rendering in your Java app. Perhaps things work better
when you do?

When I run the example at
http://java.sun.com/docs/books/tutorial/2d/printing/examples/ShapesPrint.java
I can ask for, and get, two copies, landscape printed to an HP1320 using
the Postscript drivers.

More investigation needed! Meanwhile I have other things to do.

 

[Chris Uppal]

I've now changed the program to always use
DocFlavor.INPUT_STREAM.POSTSCRIPT. The only change is that it now
(correctly) only lists PS-capable printers.

IIRC, printer tray selection, and things like that, are implemented in
PostScript printers by commands contained in the PostScript program itself.
So, if you were sending graphics commands to the printer driver (without caring
whether it was a PostScript printer), it would add the necessary tray-selection
commands automatically.

I find it quite plausible that, when you just send a PostScript file to Java
and/or the real printer driver, it sends that on "raw" to the printer, without
changing it in any way. It would certainly be possible for it to add the
necessary tray selection commands to the PostScript text, but I can easily
imagine that either it just doesn't bother at all, or (perhaps more likely)
that it only does so if the PostScript text conforms to the DSC (Document
Structuring Conventions).

I don't suppose that helps any, but it might explain the problem...

-- chris

 

[Marian Schedenig]

This problem might only apply when you are simply passing a file (or
byte array) to be printed. Much of the Java printing API seems to expect
you to do page rendering in your Java app. Perhaps things work better
when you do?

Unfortunately, the specific task we have to do is printing "externally"
generated (through Apache FOP) .ps documents.

More investigation needed! Meanwhile I have other things to do.

Thanks a lot for your help. I might not have a solution, but at least I
know I'm not the only one who can't get this working.

Marian.

 

[Marian Schedenig]

I find it quite plausible that, when you just send a PostScript file to Java
and/or the real printer driver, it sends that on "raw" to the printer, without
changing it in any way. It would certainly be possible for it to add the
necessary tray selection commands to the PostScript text, but I can easily
imagine that either it just doesn't bother at all, or (perhaps more likely)
that it only does so if the PostScript text conforms to the DSC (Document
Structuring Conventions).

Ok, that would explain a lot.

I don't suppose that helps any, but it might explain the problem...

It helps at least a bit: I now know we have to find another way around
the problem.

Thx,
Marian.