-
Enhancement
-
Resolution: Fixed
-
P4
-
1.3.0
-
beta
-
generic
-
generic
Name: rlT66838 Date: 04/06/2000
Feature request for all versions
Here's what I really really really want to be able to do:
I'm working on a JDBC2 applet/application which will pull variant
Postscript templates from various sources (e.g., a CLOB in a
database), filter the Postscript based on runtime data (e.g.,
other stuff from database(s), and stream the result to a printer.
I like the Graphics2D stuff I've been able to find in the printing
API so far, but for this application that's not what I need, and
haven't been able to locate anything anywhere that seems to address
this.
Also, I would strongly suggest that the "page" model of the API
doesn't really work for Postscript templates, as the number of pages
isn't really known (it's determined by the Postscript itself, which
can call showpage as often as it likes). What's needed is a simple
dialog to choose the printer, followed by opening some kind of stream
to pump the postscript to.
Currently the only apparent way to get this to work is to open a
socket to connect to the printer directly? (However, this doesn't work
when the printer is attached in some other way; for this I guess a
local server is probably necessary.)
This application would also be greatly aided by a regular expression
package (OK, I know, that's probably a separate feature request.)
What I'm looking for instead is just a way to open a stream to a printer; basically
this is not really a "strictly Postscript" issue - virtually all printer drivers have a way of
accepting straight ASCII text from some kind of input character stream. If it's not Postscript,
it usually gets printed in Courier (not very interesting), but if it's Postscript, the first line
starts with "%!", which tells a Postscript printer that the following text should be interpreted
instead of simply printed as text.
This should be comparatively *much* easier for Sun to implement that 4252111; it's
just a simple output stream to a printer driver. There may be a minor Unicode to ASCII
mapping issue, but it's hard to imagine anything too difficult (of course, that's easy
to say when it's somebody else who would be doing the implementation!)
(Review ID: 102180)
======================================================================