cross-platform list of printers, etc.
Robert Heller
in Tcl/Tk applications. Under UNIX/Linux, things are straight forward:
"exec [auto_execok lpstat] -a" gives me a list of printers, "exec
[auto_execok lpstat] -d" gives me the default printer, and [open "|lp
-P$printer" w] gives me a channel to stream (Postscript) to (ala <some
canvas> postscript -channel ...).
After a bit of googling, I found a web page somewhere on www.apple.com
that stated that Mac OSX's print system is based on CUPS. Does this
mean that I can treat MacOSX like any (other) UNIX/Linux system, and
just use lpstat and lp?
Under MS-Windows it appears that if Ghostscript is installed, I can
open a pipe to Ghostscript with the proper device spec and have
Ghostscript process a Postscript stream and send it to a printer. I did
not find any way to get a list of printers (other than Michael I.
Schwartz's printer package). Is there a MS-Windows *program* (not an
extension) that returns (ie to stdout) a list of available printers,
much like 'lpstat -a'?
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
hel...@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk
Larry W. Virden
Robert Heller wrote:
> I've been doing some research on how to deal with cross-platform printing
Heh heh heh. This is one of those "holy grail" quests that, if solved,
brings glory and honor to the developer ;-) .
Seriously, the whole idea of what printing means, the interface, etc.
is painful, as you are discovering.
Good luck. I suspect that while there might be programs that one can
download and then use to get the info you want, said programs are not
generally installed on machines. But I could easily be wrong.
Robert Heller
>
>
> Robert Heller wrote:
> > I've been doing some research on how to deal with cross-platform printing
>
> Heh heh heh. This is one of those "holy grail" quests that, if solved,
> brings glory and honor to the developer ;-) .
>
> Seriously, the whole idea of what printing means, the interface, etc.
> is painful, as you are discovering.
I am only interested in printing the contents of a canvas widget. Not
painful. It appears that only MS-Windows is 'broken' in not having a
'standard' toolset WRT printing (specificly *CLI* tools). All of the
*real* operating systems do have ALL of the basic tools needed...
>
> Good luck. I suspect that while there might be programs that one can
> download and then use to get the info you want, said programs are not
> generally installed on machines. But I could easily be wrong.
>
>
--
Kevin Walzer
>
> After a bit of googling, I found a web page somewhere on www.apple.com
> that stated that Mac OSX's print system is based on CUPS. Does this
> mean that I can treat MacOSX like any (other) UNIX/Linux system, and
> just use lpstat and lp?
>
I've used this approach on OS X with success.
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
Bryan Oakley
> Robert Heller wrote:
>> I've been doing some research on how to deal with cross-platform printing
>
> Heh heh heh. This is one of those "holy grail" quests that, if solved,
> brings glory and honor to the developer ;-) .
>
> Seriously, the whole idea of what printing means, the interface, etc.
> is painful, as you are discovering.
I have come to the conclusion that tcl or tk does *not* need a cross
platform printing solution. What we need are three (or maybe two)
distinct printing solutions, optimized for each platform.
The tcl community loves cross-platform solutions -- and I'm definitely
part of that love fest -- but some things just can't be done in a cross
platform way (at least, not cross platform and available in this decade).
I think if we could at least solve each platform separately we would be
closer to seeing what the different solutions have in common and so
closer to creating a cross-platform solution.
I'd even vote for a separate executable (with a Tcl license) that does
nothing but pop up a native print dialog and then somehow succeeds to
send HTML to the printer and have it print more-or-less as it should.
Kevin Walzer
Mats Bengtsson's tclbitprint (http://tclbitprint.sourceforge.net)
accomplishes at least some of this. I've done some work recently on the
MacCarbonPrint bits (adding a command to handle text printing better).
It works via the canvas widget. I'm not sure how it works on other Unix
platforms, but the Mac part is pretty solid.
http://www.schwartzcomputer.com/tcl-tk/tcl-tk.html#printerTbl has an
extension that supposedly works on Windows--I've not tested this.
lpr/lpstat might just be the appropriate solution for X11-based
platforms. Qt wraps these commands on *Nix, while using Aqua and win32
frameworks on the other platforms.
Larry W. Virden
Bryan Oakley wrote:
> Larry W. Virden wrote:
> > Robert Heller wrote:
> >> I've been doing some research on how to deal with cross-platform printing
> >
> > Heh heh heh. This is one of those "holy grail" quests that, if solved,
> > brings glory and honor to the developer ;-) .
> >
> > Seriously, the whole idea of what printing means, the interface, etc.
> > is painful, as you are discovering.
>
> I have come to the conclusion that tcl or tk does *not* need a cross
> platform printing solution. What we need are three (or maybe two)
> distinct printing solutions, optimized for each platform.
It surely would be nice, though, if the tcl interface to the solution
was common, even if, underneath, things were wildly different.
Donal K. Fellows
> It surely would be nice, though, if the tcl interface to the solution
> was common, even if, underneath, things were wildly different.
It surely would be nice, though, if there was an interface (or
interfaces) to the solution at all, even if things were wildly
different underneath.
Donal.
suchenwi
Donal K. Fellows schrieb:
> It surely would be nice, though, if there was an interface (or
> interfaces) to the solution at all, even if things were wildly
> different underneath.
Somehow like:
printer names ?pattern?
printer status name
printer print name item
...
Larry W. Virden
I have no idea why it has been so hard to get people to at least draw
up specifications on what they want done. Knowing SPECIFICALLY what
they want to do would at least let us see if there were ways to come to
an interface.
Let's see - what kinds of things does a developer want to do in their
program that is printer related?
1. Pass one or more strings of text to the printer to be printed.
2a. Determine a list of names of the printers that are available , so
the user of the program can select a printer
2b. Determine the status of a printer
3. Print a simulation of what one or more of the widgets on the screen
look like.
4. Determine whether a job sent to the printer was successfully printed
or not.
5. Pass a file name to the printer to be printed.
What other operations need to be supported?
Robert Heller
ALL *I* have ever wanted was:
1) List of printers, ala lpstat -a
1a) Name of the default printer, ala lpstat -d
2) Something to pipe Postscript to, ala lp/lpr ("|lp -d <printer>" or
"|lpr -P<printer>").
I don't need anything else. All other functions (eg printer status or
sending a file to the printer, etc.) are presumed to be to O/S supplied
functions outside of any random application I might write.
I can write my own print dialog box, if I need one.
As far as I can tell, the only 'oddball' O/S is mess-windows, which
*seems* to lack CLI tools of the lpstat/lp[r] flavor. UNIX/Linux and
Mac OSX seem to have the standard CLI tools (lpstat and lp/lpr).
Darren New
> 1) List of printers, ala lpstat -a
> 1a) Name of the default printer, ala lpstat -d
You mean, "list of printers already installed and connected". Without
the option for the person to go "Oh, they must have turned off that
server, let me print to Accounting instead."
> 2) Something to pipe Postscript to, ala lp/lpr ("|lp -d <printer>" or
> "|lpr -P<printer>").
Not every printer supports postscript.
> As far as I can tell, the only 'oddball' O/S is mess-windows, which
> *seems* to lack CLI tools of the lpstat/lp[r] flavor.
That's because launching new processes and taking their stdout isn't the
normal way of getting information out of the system in Windows. All this
stuff is exposed thru standard COM interfaces, including all the
standard dialog boxes, printer options, etc.
I think if you were the only program that didn't allow double-sided
printing on the very expensive double-sided printer, or didn't allow
selection of letterhead for the first page, etc, it wouldn't seem a very
professional program.
I'll grant you, it's a good start, tho. Certainly better than nothing.
It probably wouldn't be difficult to whip together a set of command-line
tools to do just what you're looking for.
--
Darren New / San Diego, CA, USA (PST)
Scruffitarianism - Where T-shirt, jeans,
and a three-day beard are "Sunday Best."
Robert Heller
>
> Robert Heller wrote:
> > 1) List of printers, ala lpstat -a
> > 1a) Name of the default printer, ala lpstat -d
>
> You mean, "list of printers already installed and connected". Without
> the option for the person to go "Oh, they must have turned off that
> server, let me print to Accounting instead."
>
> > 2) Something to pipe Postscript to, ala lp/lpr ("|lp -d <printer>" or
> > "|lpr -P<printer>").
>
> Not every printer supports postscript.
Under Linux and many (all?) *UNIX* systems, every *print queue* does.
If the printer does not natively support postscript, a ghostscript
filter or CUPS driver is used. From an *application* (lpr/lp) POV, all
printers support postscript.
>
> > As far as I can tell, the only 'oddball' O/S is mess-windows, which
> > *seems* to lack CLI tools of the lpstat/lp[r] flavor.
>
> That's because launching new processes and taking their stdout isn't the
> normal way of getting information out of the system in Windows. All this
> stuff is exposed thru standard COM interfaces, including all the
> standard dialog boxes, printer options, etc.
>
> I think if you were the only program that didn't allow double-sided
> printing on the very expensive double-sided printer, or didn't allow
> selection of letterhead for the first page, etc, it wouldn't seem a very
> professional program.
These are all options to the lp command or implied by the print queue.
I guess this is a 'UNIX' way of doing things -- delegating little tasks
to simple, standardized, CLI programs, rather than having a (bloated?)
system API where every program has to re-invent the wheel on some
level.
>
> I'll grant you, it's a good start, tho. Certainly better than nothing.
> It probably wouldn't be difficult to whip together a set of command-line
> tools to do just what you're looking for.
>
--
Bryan Oakley
> At Fri, 19 Jan 2007 09:03:46 -0800 Darren New <dn...@san.rr.com> wrote:
>
>> Robert Heller wrote:
>>> 1) List of printers, ala lpstat -a
>>> 1a) Name of the default printer, ala lpstat -d
>> You mean, "list of printers already installed and connected". Without
>> the option for the person to go "Oh, they must have turned off that
>> server, let me print to Accounting instead."
>>
>>> 2) Something to pipe Postscript to, ala lp/lpr ("|lp -d <printer>" or
>>> "|lpr -P<printer>").
>> Not every printer supports postscript.
>
> Under Linux and many (all?) *UNIX* systems, every *print queue* does.
> If the printer does not natively support postscript, a ghostscript
> filter or CUPS driver is used. From an *application* (lpr/lp) POV, all
> printers support postscript.
Interesting; I didn't know that (a *lot* falls into that category :-).
Is that really a truism or an "in my experience" statement?
Still, I want to be able to print a text widget way more often than I
want to print a canvas. I guess it's may be somewhat trivial to write a
program to dump a text widget to a canvas, though I haven't tried. Has
anyone written such a thing?
What I pine for is a way to send HTML to a printer, since it is
(presently, at least) easier for me to create HTML from a text widget
than to create a canvas.
--
Bryan Oakley
www.tclscripting.com
Darren New
> Under Linux and many (all?) *UNIX* systems, every *print queue* does.
> If the printer does not natively support postscript, a ghostscript
> filter or CUPS driver is used. From an *application* (lpr/lp) POV, all
> printers support postscript.
Right. And since it's not the printers, it's not really a "portable" way
of generating output, unless you want to include ghostscript in the core
of Tcl, which seems overkill.
> These are all options to the lp command or implied by the print queue.
Unless you're going to do a complete emulation of the lp command,
including all the stuff you need to build standard dialog boxes (which
are already built into Windows), this doesn't help the portability
mechanism. Especially since Windows supports things in the API that
weren't there when they designed the API, which is why you don't have an
lp-like interface to it in the first place.
In other words, the reason Windows doesn't work like Unix is so you
don't have to upgrade the printer queue software every time someone
comes out with a new option in a printer driver. If you want a printer
that automatically supports "red-blue glasses output", you can access
that from every program written from before that printer was invented.
> I guess this is a 'UNIX' way of doing things -- delegating little tasks
> to simple, standardized, CLI programs, rather than having a (bloated?)
> system API where every program has to re-invent the wheel on some
> level.
It's not the case that every program has to reinvent the wheel. They
just use a different axle. In UNIX, the hammer is exec(), so every API
uses exec(). In Windows, the hammer is COM, so every API uses COM. The
UNIX mechanism is easier to build on for simpler stuff, but harder to
make work in the face of changes, since every program has to know all
possible options and their meanings, and the valid input and output
formats of every utility program.
Alternately, in Windows, all you have to do is open the printer and draw
on it exactly the same way you draw on the screen. Under
printers-support-postscript, you have to deal with both X11 and with
Postscript.
Robert Heller
>
> Robert Heller wrote:
> > At Fri, 19 Jan 2007 09:03:46 -0800 Darren New <dn...@san.rr.com> wrote:
> >
> >> Robert Heller wrote:
> >>> 1) List of printers, ala lpstat -a
> >>> 1a) Name of the default printer, ala lpstat -d
> >> You mean, "list of printers already installed and connected". Without
> >> the option for the person to go "Oh, they must have turned off that
> >> server, let me print to Accounting instead."
> >>
> >>> 2) Something to pipe Postscript to, ala lp/lpr ("|lp -d <printer>" or
> >>> "|lpr -P<printer>").
> >> Not every printer supports postscript.
> >
> > Under Linux and many (all?) *UNIX* systems, every *print queue* does.
> > If the printer does not natively support postscript, a ghostscript
> > filter or CUPS driver is used. From an *application* (lpr/lp) POV, all
> > printers support postscript.
>
> Interesting; I didn't know that (a *lot* falls into that category :-).
> Is that really a truism or an "in my experience" statement?
*Every* linux system I have ever used had ghostscript installed and the
printer subsystem (from the old lpd through CUPS) used ghostscript or
something simular as a postscript-to-printer-raster filter. I would
guess all of the *BSD systems work that was as well. MacOSX probably
does (or else converts to PDF and goes from there). This filter
mechanizm is available for commercial UNIXes, which I suspect are all
pretty much adopting CUPS (MacOSX certainly has).
>
> Still, I want to be able to print a text widget way more often than I
> want to print a canvas. I guess it's may be somewhat trivial to write a
> program to dump a text widget to a canvas, though I haven't tried. Has
> anyone written such a thing?
Under *Linux* it is common to include several 'filters' for different
file types (and can certainly be done under any UNIX system), where the
filter 'detects' the file type (uses the UNIX file command). Some of
these filters will automagically run a2ps if the source is text or dvips
if the source is a dvi file.
And yes, I have written a function that dumps a block of text into a
canvas and prints the resulting canvas a page at a time.
>
> What I pine for is a way to send HTML to a printer, since it is
> (presently, at least) easier for me to create HTML from a text widget
> than to create a canvas.
Yes. I find it a pain to just print a random HTML file (other than
printing the currently displayed web page from a browser. PDFs are
actually easier:
pdf2ps foo.pdf - | lpr -Pprinter
>
>
> --
> Bryan Oakley
> www.tclscripting.com
Larry W. Virden
Robert Heller wrote:
> At 18 Jan 2007 12:52:53 -0800 "Larry W. Virden" <lvi...@gmail.com> wrote:
> ALL *I* have ever wanted was:
>
> 1) List of printers, ala lpstat -a
> 1a) Name of the default printer, ala lpstat -d
>
> 2) Something to pipe Postscript to, ala lp/lpr ("|lp -d <printer>" or
> "|lpr -P<printer>").
And you have those two commands, so then do you consider your needs
met? Or are you wanting something beyond lpstat and lp?
I know, for instance, that I've seen a "show me a list of printers"
type command generate several hundred entries at a site. That "show me
the name of a default printer" seems useful. But then, I also sometimes
need "show me the name of a color printer" or "show me the name of a
printer which can print duplex".
>
> As far as I can tell, the only 'oddball' O/S is mess-windows, which
> *seems* to lack CLI tools of the lpstat/lp[r] flavor. UNIX/Linux and
> Mac OSX seem to have the standard CLI tools (lpstat and lp/lpr).
And for MS-DOS, I presume there is something that one of the Windows
specific extensions - TCOM or TWAPI or some such - could do to provide
similar functionality. It would be nice to have a pair of Tcl functions
which translated its arguments into the right calls for a variety of
common platforms (lp vs lpr vs Windows vs CUPS for instance)
Larry W. Virden
> > Still, I want to be able to print a text widget way more often than I
> > want to print a canvas.
> And yes, I have written a function that dumps a block of text into a
> canvas and prints the resulting canvas a page at a time.
Does your function print out text from various fonts, in various
colors, with colored tags, embedded stuff, etc.?
Just curious whether your function is a "print plain vanilla text" or
something more.
Robert Heller
It is plain vanilla text -- this is all I needed. The code is certainly
extendable. In is in pure Tcl using BWidget and snit.
Robert Heller
>
>
> Robert Heller wrote:
> > At 18 Jan 2007 12:52:53 -0800 "Larry W. Virden" <lvi...@gmail.com> wrote:
> > ALL *I* have ever wanted was:
> >
> > 1) List of printers, ala lpstat -a
> > 1a) Name of the default printer, ala lpstat -d
> >
> > 2) Something to pipe Postscript to, ala lp/lpr ("|lp -d <printer>" or
> > "|lpr -P<printer>").
>
> And you have those two commands, so then do you consider your needs
> met? Or are you wanting something beyond lpstat and lp?
My needs are met under Linux/UNIX and MacOS. Not under MS-Windows.
For now, my application does not support printing to the printer/print
queue under MS-Windows. The user can only create a Postscript file and
has to find his/her own way getting that to the printer (ie manually
firing up ghostview/ghostscript and printing from there).
>
> I know, for instance, that I've seen a "show me a list of printers"
> type command generate several hundred entries at a site. That "show me
> the name of a default printer" seems useful. But then, I also sometimes
> need "show me the name of a color printer" or "show me the name of a
> printer which can print duplex".
>
> >
> > As far as I can tell, the only 'oddball' O/S is mess-windows, which
> > *seems* to lack CLI tools of the lpstat/lp[r] flavor. UNIX/Linux and
> > Mac OSX seem to have the standard CLI tools (lpstat and lp/lpr).
>
> And for MS-DOS, I presume there is something that one of the Windows
> specific extensions - TCOM or TWAPI or some such - could do to provide
> similar functionality. It would be nice to have a pair of Tcl functions
> which translated its arguments into the right calls for a variety of
> common platforms (lp vs lpr vs Windows vs CUPS for instance)
>
>
--
Larry W. Virden
Robert Heller wrote:
> > > ALL *I* have ever wanted was:
> > >
> > > 1) List of printers, ala lpstat -a
> > > 1a) Name of the default printer, ala lpstat -d
> > >
> > > 2) Something to pipe Postscript to, ala lp/lpr ("|lp -d <printer>" or
> > > "|lpr -P<printer>").
> >
>
> My needs are [not met] under MS-Windows.
> For now, my application does not support printing to the printer/print
> queue under MS-Windows. The user can only create a Postscript file and
> has to find his/her own way getting that to the printer (ie manually
> firing up ghostview/ghostscript and printing from there).
So what control do you have for the use of your application under
MS-Windows? Can you provide the application in some wrapped form? Can
you include some COM or other Windows related extension with your
application?
Anyone on Windows have a specific solution for this gentleman - a way
that his program can get a list of available printers, the user's
default printer, and a Tcl command for taking PostScript and sending it
to a printer?
Robert Heller
>
>
> Robert Heller wrote:
> > > > ALL *I* have ever wanted was:
> > > >
> > > > 1) List of printers, ala lpstat -a
> > > > 1a) Name of the default printer, ala lpstat -d
> > > >
> > > > 2) Something to pipe Postscript to, ala lp/lpr ("|lp -d <printer>" or
> > > > "|lpr -P<printer>").
> > >
>
>
> >
> > My needs are [not met] under MS-Windows.
> > For now, my application does not support printing to the printer/print
> > queue under MS-Windows. The user can only create a Postscript file and
> > has to find his/her own way getting that to the printer (ie manually
> > firing up ghostview/ghostscript and printing from there).
>
> So what control do you have for the use of your application under
> MS-Windows? Can you provide the application in some wrapped form? Can
> you include some COM or other Windows related extension with your
> application?
I'm wrapping my application as a starpack (http://www.equi4.com/208).
Right now it is pure Tcl, using piped connection to lp/lpr and lpstat
(under Linux/UNIX and MacOSX). Under MS-Windows, it does nothing to get
a list of printers and if the user selects 'Printer' as the print
target, they get an error message.
I do the development under Linux and use a downloaded tclkit binary as
the -runtime argument to sdx. I can cross-compile MS-Windows dlls, but
have no programming knowledge of the COM API (and no way of testing a
dll either, since I don't have a MS-Windows machine).
>
> Anyone on Windows have a specific solution for this gentleman - a way
> that his program can get a list of available printers, the user's
> default printer, and a Tcl command for taking PostScript and sending it
> to a printer?
I have the wiki page showing how to use ghostscript, but since
ghostscript is not a 'stock' installed program under MS-Windows, it is
problematical to use it, esp. if it is not in the PATH.
Larry W. Virden
On Jan 23, 1:21 pm, Robert Heller <hel...@deepsoft.com> wrote:
> > Anyone on Windows have a specific solution for this gentleman - a way
> > that his program can get a list of available printers, the user's
> > default printer, and a Tcl command for taking PostScript and sending it
> > to a printer?I have the wiki page showing how to use ghostscript, but since
> ghostscript is not a 'stock' installed program under MS-Windows, it is
> problematical to use it, esp. if it is not in the PATH.
I understand. And executing full programs which reside inside the
starpack, I think, is still a problem.
I know that many people point to http://wiki.tcl.tk/print , which
covers some info, and then points to some info on the
http://wiki.tcl.tk/tkprint page (in particular, the Scwartz extension).
Note that I just took a look at Michael's page (you have to follow the
rabbit down the hole, so to speak, following links until you get to
http://www.schwartzcomputer.com/tcl-tk/tcl-tk.html#printerTbl , but the
info about his extensions seems, to me, to be right down the alley of
what you are needing.
Robert Heller
>
>
>
> On Jan 23, 1:21 pm, Robert Heller <hel...@deepsoft.com> wrote:
>
> > > Anyone on Windows have a specific solution for this gentleman - a way
> > > that his program can get a list of available printers, the user's
> > > default printer, and a Tcl command for taking PostScript and sending it
> > > to a printer?I have the wiki page showing how to use ghostscript, but since
> > ghostscript is not a 'stock' installed program under MS-Windows, it is
> > problematical to use it, esp. if it is not in the PATH.
>
> I understand. And executing full programs which reside inside the
> starpack, I think, is still a problem.
And ghostscript is not just a self-contained .exe file either -- there
is a pile of support files (fonts, ps library files/scripts, etc.).
>
> I know that many people point to http://wiki.tcl.tk/print , which
> covers some info, and then points to some info on the
> http://wiki.tcl.tk/tkprint page (in particular, the Scwartz extension).
> Note that I just took a look at Michael's page (you have to follow the
> rabbit down the hole, so to speak, following links until you get to
> http://www.schwartzcomputer.com/tcl-tk/tcl-tk.html#printerTbl , but the
> info about his extensions seems, to me, to be right down the alley of
> what you are needing.
Yes, but it is an *extension* and does not include a
postscript-to-raster filter. (Yes, I followed the links and downloaded
the package, including the pure-Tcl version for UNIX (which should also
work for MacOSX), which by the way uses both lpstat and lp/lpr via
pipes, just as my code does.)
It does plainly 'suck' that MS-Windows is such an odd-ball platform (at
least from *my* point-of-view). A GUI interface is all very well, but
*I've* always implemented programs first as CLI-based -- it is easier to
debug them and get the basic algorthim and API worked out that way.
Trying to debug an algorthim and API with a GUI just makes the whole
process more complex and problematical (how does one tell if a bug is
in the base algorthim or API and not a GUI bug?).
For the time being, I guess I just won't be supporting printing under
MS-Windows...
Darren New
> A GUI interface is all very well, but
> *I've* always implemented programs first as CLI-based
Nothing wrong with that, if all you want to print is Postscript and you
have a postscript printer, or if you have text to be printed.
Under Windows, printing graphics is a graphical user interface kind of
thing. Since the graphical interface is always available (at least,
whenever printers are), it's not really a problem for any Windows
programs that want to print something more complex than text, yes?
Why not simply require a postscript-capable printer under Windows? It's
quite easy to print either text to a text printer or postscript (i.e.,
raw) to a postscript printer.
--
Darren New / San Diego, CA, USA (PST)
You know it's time to trim your beard when your
wife stops calling you Husband and starts calling
you Husbollah.
Robert Heller
>
> Robert Heller wrote:
> > A GUI interface is all very well, but
> > *I've* always implemented programs first as CLI-based
>
> Nothing wrong with that, if all you want to print is Postscript and you
> have a postscript printer, or if you have text to be printed.
>
> Under Windows, printing graphics is a graphical user interface kind of
> thing. Since the graphical interface is always available (at least,
> whenever printers are), it's not really a problem for any Windows
> programs that want to print something more complex than text, yes?
>
> Why not simply require a postscript-capable printer under Windows? It's
> quite easy to print either text to a text printer or postscript (i.e.,
> raw) to a postscript printer.
I guess I am effectively requiring a postscript-capable printer, by only
supporting the creation of a Postscript file under MS-Windows (since
there is the lack of a lp or lpr type command as a standard component of
the system). Basically, my application 'punts' and leaves it up to the
user to arrange to get the Postscript file to the printer, either via
some 'raw' print function or by installing and use ghostscript or ghostview.
Darren New
> there is the lack of a lp or lpr type command as a standard component of
> the system).
The "lpr" command is "copy". You can send your postscript to the
postscript printer yourself, by opening the printer and writing to it.
I've used [open \\pserver\\laserjet w] to print to printers before.
There's just nothing built into Windows to interpret Postscript and turn
it into rasters specific to the printer.
Robert Heller
>
> Robert Heller wrote:
> > there is the lack of a lp or lpr type command as a standard component of
> > the system).
>
> The "lpr" command is "copy". You can send your postscript to the
> postscript printer yourself, by opening the printer and writing to it.
> I've used [open \\pserver\\laserjet w] to print to printers before.
OK, that is fine *if you have the path to the printer. In my
application, entering '\\pserver\\laserjet' (assuming that
\\pserver\\laserjet is in fact a ligit postscript printer) as a file to
'print' to in the file name entry and selecting 'print to file' will
problem work just fine. But without a list of viable Postscript
printers, it means there is not any way to support 'print to printer' in
my application.
> There's just nothing built into Windows to interpret Postscript and turn
> it into rasters specific to the printer.
Right. MS-Windows == the *only* O/S without any 'native' support for
Postscript (or PDF for that matter).