"Access Denied"

  • Thread starter Thread starter Steve Behman
  • Start date Start date
S

Steve Behman

On the machine I recently replaced I was using an IBM LaserJet printer to
print "Raw PostScript" (i.e., ASCII text that is a Postscript language page
description.) The printer having a PostScript language interpreter translated
the page description text into an image (which that text described) and then
printed it.

On the old machines the printer was attached via a Centronics-to-Parallel
Port cable. Since the new machine does not have a parallel port I have had to
use A USB to Parallel Port adapter.

On the old machine I created a "New Printer" for which I selected a "Generic
Text Only" driver giving it the share name "Direct". Having done that I was
able to print my PostScript job by writing to "\\SBB\direct" using the
command:

"copy file_name \\SBB\direct

where SBB is the name of my computer.

I was also able to accomplish the same thing in programs I have written in
which I open a file named "\\SBB\Direct" and write the PostScript page
description to it.

The Problem:

When I do precisely the same things on the new computer I get the error
"Access Denied" using the copy command (I haven't yet tried the programs I
have written). This was true even though I gave "Everyone" all possible
permissions for the printer.

Being able to print these PostScript page description on this printer is
very important to me, so much so that I would, with despair revert to the old
machine in order to do it. I would, therefore, be extremely grateful if
someone could steer me around this problem.
 
How many computers are we talking about here?

You have the laser printer attached to a PC via a USB-to-parallel adapter
cable. That much I got.

But are you trying to print to this printer from this PC, or from another
networked PC?

I'm also having some problem understanding what you did and why. Don't you
have the proper PostScript drivers for this printer? You should be able to
do what you need with the PostScript driver(s) that came with the printer.
PostScript output is _supposed_ to be text ...

And if, for whatever reason, you can't configure the driver to work
properly, there are other ways to get a "raw" file to a printer without
preprocessing -- like changing the print processor mode on the print queue.

I don't see why you can't set this up as a "normal" printer and have the
print driver and spooler do all the heavy lifting for you. Then all you'd
have to do from your app is open LPT1: or whatever device you choose to use.

What model IBM printer do you have? I've had my share of experiences sending
multiple data streams to IBM printers. Maybe I can help you figure this out.

CL
 
Another possibility, if the computer is a desktop, is adding a parallel port
with a PCI card, which would then be LPT1. A USB to parallel connection
does not always emulate the parallel port exactly.



PCI cards are available from several manufacturers and generally XP will
install the drivers automatically.
 
Charles, thank you very much for your response.

I have actually solved my problem. The details of the solution are too
arcane to get into here.

The purpose of this note is to correct a possible misapprehension that you
may have.

The purpose of the PostScript driver is to translate a document into the
PostScript Page Description Language for rendering on a printer with a
PostScript language interpreter.

A PostScript driver will take any text file,**independent of its content**,
create a PostScript page description of it and then send that description to
the printer for rendering by the printer's PostScript language interpreter.
That is to say: the driver takes no cognizance of the fact that the file is,
itself, a PostScript page description!

If, and only if, you can "get around" the driver to send the PostScript
Language Page Description directly to the printers PostScript Language
Interpreter will the printer render the described page (as opposed to the
text which describes it.)

To illustrate let's take a look at a very small snippet of a PostScript page
description.

400 400 moveto (hello world) show showpage

This snippet will print:

hello world

400 points up from and 400 points to the right of the lower left CORNER of
the page if it is sent AROUND the PostScript driver (i.e., DIRECTLY to the
printer’s PostScript interpreter.) Whereas if it goes through the PostScript
DRIVER exactly the same line will print:


400 400 moveto (hello world) show showpage

Starting at the top left MARGIN of the page!
 
Yes. The printer driver's job, in essense, is to translate not only text
(output using TextOut), but any (largely) device-independant GDI command
into printer language. In this case, PostScript.

If you *want* your output to bypass the driver, and language monitor, use
StartDocPrinter instead of StartDoc.

If you wish to use the printer driver, but also inject some PostScript data
into the stream, ExtEscape should work, though I never tried it.

ExtEscape Function:
http://msdn.microsoft.com/en-us/library/dd162708(VS.85).aspx

Paul
 
Thank you Paul.

From what you said I assume that "StartDocPrinter" is in the GDI API -- is
this assumption correct? If it is, that is at least one level of abstraction
under the level at which I am coding.

The input(s) to my programs are, themselves, PostScript Page Descriptions.
It is, therefore, very much easier to manipulate the PostScript than it is
too abstract it to a "presentation space" and then deal with the image in
that space.

My programs are written in C++ and, during development, the output page
descriptions are written directly to the printers (an IBM 4039 Plus for
monochrome and an HP OfficeJet 9110 for color.)

I am not particularly fond of my solution (creating a separate printer using
a Generic Text Only driver) for the output of my programs and would
appreciate a simpler way but I have not been able to find one. Any
suggestions?

Paul Baker [MVP said:
Yes. The printer driver's job, in essense, is to translate not only text
(output using TextOut), but any (largely) device-independant GDI command
into printer language. In this case, PostScript.

If you *want* your output to bypass the driver, and language monitor, use
StartDocPrinter instead of StartDoc.

If you wish to use the printer driver, but also inject some PostScript data
into the stream, ExtEscape should work, though I never tried it.

ExtEscape Function:
http://msdn.microsoft.com/en-us/library/dd162708(VS.85).aspx

Paul

Steve Behman said:
Charles, thank you very much for your response.

I have actually solved my problem. The details of the solution are too
arcane to get into here.

The purpose of this note is to correct a possible misapprehension that you
may have.

The purpose of the PostScript driver is to translate a document into the
PostScript Page Description Language for rendering on a printer with a
PostScript language interpreter.

A PostScript driver will take any text file,**independent of its
content**,
create a PostScript page description of it and then send that description
to
the printer for rendering by the printer's PostScript language
interpreter.
That is to say: the driver takes no cognizance of the fact that the file
is,
itself, a PostScript page description!

If, and only if, you can "get around" the driver to send the PostScript
Language Page Description directly to the printers PostScript Language
Interpreter will the printer render the described page (as opposed to the
text which describes it.)

To illustrate let's take a look at a very small snippet of a PostScript
page
description.

400 400 moveto (hello world) show showpage

This snippet will print:

hello world

400 points up from and 400 points to the right of the lower left CORNER of
the page if it is sent AROUND the PostScript driver (i.e., DIRECTLY to the
printer's PostScript interpreter.) Whereas if it goes through the
PostScript
DRIVER exactly the same line will print:


400 400 moveto (hello world) show showpage

Starting at the top left MARGIN of the page!
 
Steve,

I am not quite following what you're doing? Are you taking a PostScript
file, manipulating it and printing it using GDI to a PostScript printer in
order to generate a new PostScript file?

There is open source software that handles PostScript and PDF files in this
kind of way independantly of the Print Spooler.

I actually use StartDocPrinter, so that I can send basic text and escape
sequences to a printer and, for performance reasons, bypass the overhead of
the GDI and printer driver. This is easier than writing a driver and trying
to fit it to concepts like CPI, LPI and built in barcodes. Some some
manufacturers have tried and, of course, the Generic / Text Only driver
makes some attempt at this, but it simply fails to do so accurately much of
the time. I too tend to suggest using the Generic / Text Only driver when
installing the printer, even though technically no driver is used at all if
it is configured to bypass the driver and use StartDocPrinter. This is the
source of much confusion and I too would like that situation to "go away",
but it won't.unless I want to attempt to write the above-mentioned driver or
have totally separate configuration in which you specify a port, etc... that
may or may not be in use already by the Print Spooler, ugh.

Paul

Steve Behman said:
Thank you Paul.

From what you said I assume that "StartDocPrinter" is in the GDI API -- is
this assumption correct? If it is, that is at least one level of
abstraction
under the level at which I am coding.

The input(s) to my programs are, themselves, PostScript Page Descriptions.
It is, therefore, very much easier to manipulate the PostScript than it is
too abstract it to a "presentation space" and then deal with the image in
that space.

My programs are written in C++ and, during development, the output page
descriptions are written directly to the printers (an IBM 4039 Plus for
monochrome and an HP OfficeJet 9110 for color.)

I am not particularly fond of my solution (creating a separate printer
using
a Generic Text Only driver) for the output of my programs and would
appreciate a simpler way but I have not been able to find one. Any
suggestions?

Paul Baker [MVP said:
Yes. The printer driver's job, in essense, is to translate not only text
(output using TextOut), but any (largely) device-independant GDI command
into printer language. In this case, PostScript.

If you *want* your output to bypass the driver, and language monitor, use
StartDocPrinter instead of StartDoc.

If you wish to use the printer driver, but also inject some PostScript
data
into the stream, ExtEscape should work, though I never tried it.

ExtEscape Function:
http://msdn.microsoft.com/en-us/library/dd162708(VS.85).aspx

Paul

Steve Behman said:
Charles, thank you very much for your response.

I have actually solved my problem. The details of the solution are too
arcane to get into here.

The purpose of this note is to correct a possible misapprehension that
you
may have.

The purpose of the PostScript driver is to translate a document into
the
PostScript Page Description Language for rendering on a printer with a
PostScript language interpreter.

A PostScript driver will take any text file,**independent of its
content**,
create a PostScript page description of it and then send that
description
to
the printer for rendering by the printer's PostScript language
interpreter.
That is to say: the driver takes no cognizance of the fact that the
file
is,
itself, a PostScript page description!

If, and only if, you can "get around" the driver to send the PostScript
Language Page Description directly to the printers PostScript Language
Interpreter will the printer render the described page (as opposed to
the
text which describes it.)

To illustrate let's take a look at a very small snippet of a PostScript
page
description.

400 400 moveto (hello world) show showpage

This snippet will print:

hello world

400 points up from and 400 points to the right of the lower left CORNER
of
the page if it is sent AROUND the PostScript driver (i.e., DIRECTLY to
the
printer's PostScript interpreter.) Whereas if it goes through the
PostScript
DRIVER exactly the same line will print:


400 400 moveto (hello world) show showpage

Starting at the top left MARGIN of the page!



:

How many computers are we talking about here?

You have the laser printer attached to a PC via a USB-to-parallel
adapter
cable. That much I got.

But are you trying to print to this printer from this PC, or from
another
networked PC?

I'm also having some problem understanding what you did and why. Don't
you
have the proper PostScript drivers for this printer? You should be
able
to
do what you need with the PostScript driver(s) that came with the
printer.
PostScript output is _supposed_ to be text ...

And if, for whatever reason, you can't configure the driver to work
properly, there are other ways to get a "raw" file to a printer
without
preprocessing -- like changing the print processor mode on the print
queue.

I don't see why you can't set this up as a "normal" printer and have
the
print driver and spooler do all the heavy lifting for you. Then all
you'd
have to do from your app is open LPT1: or whatever device you choose
to
use.

What model IBM printer do you have? I've had my share of experiences
sending
multiple data streams to IBM printers. Maybe I can help you figure
this
out.

CL



message
On the machine I recently replaced I was using an IBM LaserJet
printer
to
print "Raw PostScript" (i.e., ASCII text that is a Postscript
language
page
description.) The printer having a PostScript language interpreter
translated
the page description text into an image (which that text described)
and
then
printed it.

On the old machines the printer was attached via a
Centronics-to-Parallel
Port cable. Since the new machine does not have a parallel port I
have
had
to
use A USB to Parallel Port adapter.

On the old machine I created a "New Printer" for which I selected a
"Generic
Text Only" driver giving it the share name "Direct". Having done
that I
was
able to print my PostScript job by writing to "\\SBB\direct" using
the
command:

"copy file_name \\SBB\direct

where SBB is the name of my computer.

I was also able to accomplish the same thing in programs I have
written
in
which I open a file named "\\SBB\Direct" and write the PostScript
page
description to it.

The Problem:

When I do precisely the same things on the new computer I get the
error
"Access Denied" using the copy command (I haven't yet tried the
programs I
have written). This was true even though I gave "Everyone" all
possible
permissions for the printer.

Being able to print these PostScript page description on this
printer
is
very important to me, so much so that I would, with despair revert
to
the
old
machine in order to do it. I would, therefore, be extremely grateful
if
someone could steer me around this problem.
 
Paul, thanks for your continued interest.

Want I did is:

Create a printer named "direct" using Port "DOT004." This port is shared by
several other printer definitions (e.g. "Simplex, Duplex and, Fax".) Direct
uses the Generic Text/Only driver.

The C++ programs open the printer as an "ofstream" and write the PostScript
Page Description to it using the "<<" operator.

This worked on my old systems and is now working on the new one.

What I learned, to my chagrin, is that the problem (Access Denied) arose
from my failure to correctly set the spooling option for "direct." Apparently
allowing spooling on any printer on a given port must be accompanied by
allowing spooling on every printer on that port. Retrospectively this
requirement is obvious -- the joys of 20/20 hindsight!

I hope this clarifies the situation.

Paul Baker [MVP said:
Steve,

I am not quite following what you're doing? Are you taking a PostScript
file, manipulating it and printing it using GDI to a PostScript printer in
order to generate a new PostScript file?

There is open source software that handles PostScript and PDF files in this
kind of way independantly of the Print Spooler.

I actually use StartDocPrinter, so that I can send basic text and escape
sequences to a printer and, for performance reasons, bypass the overhead of
the GDI and printer driver. This is easier than writing a driver and trying
to fit it to concepts like CPI, LPI and built in barcodes. Some some
manufacturers have tried and, of course, the Generic / Text Only driver
makes some attempt at this, but it simply fails to do so accurately much of
the time. I too tend to suggest using the Generic / Text Only driver when
installing the printer, even though technically no driver is used at all if
it is configured to bypass the driver and use StartDocPrinter. This is the
source of much confusion and I too would like that situation to "go away",
but it won't.unless I want to attempt to write the above-mentioned driver or
have totally separate configuration in which you specify a port, etc... that
may or may not be in use already by the Print Spooler, ugh.

Paul

Steve Behman said:
Thank you Paul.

From what you said I assume that "StartDocPrinter" is in the GDI API -- is
this assumption correct? If it is, that is at least one level of
abstraction
under the level at which I am coding.

The input(s) to my programs are, themselves, PostScript Page Descriptions.
It is, therefore, very much easier to manipulate the PostScript than it is
too abstract it to a "presentation space" and then deal with the image in
that space.

My programs are written in C++ and, during development, the output page
descriptions are written directly to the printers (an IBM 4039 Plus for
monochrome and an HP OfficeJet 9110 for color.)

I am not particularly fond of my solution (creating a separate printer
using
a Generic Text Only driver) for the output of my programs and would
appreciate a simpler way but I have not been able to find one. Any
suggestions?

Paul Baker [MVP said:
Yes. The printer driver's job, in essense, is to translate not only text
(output using TextOut), but any (largely) device-independant GDI command
into printer language. In this case, PostScript.

If you *want* your output to bypass the driver, and language monitor, use
StartDocPrinter instead of StartDoc.

If you wish to use the printer driver, but also inject some PostScript
data
into the stream, ExtEscape should work, though I never tried it.

ExtEscape Function:
http://msdn.microsoft.com/en-us/library/dd162708(VS.85).aspx

Paul

Charles, thank you very much for your response.

I have actually solved my problem. The details of the solution are too
arcane to get into here.

The purpose of this note is to correct a possible misapprehension that
you
may have.

The purpose of the PostScript driver is to translate a document into
the
PostScript Page Description Language for rendering on a printer with a
PostScript language interpreter.

A PostScript driver will take any text file,**independent of its
content**,
create a PostScript page description of it and then send that
description
to
the printer for rendering by the printer's PostScript language
interpreter.
That is to say: the driver takes no cognizance of the fact that the
file
is,
itself, a PostScript page description!

If, and only if, you can "get around" the driver to send the PostScript
Language Page Description directly to the printers PostScript Language
Interpreter will the printer render the described page (as opposed to
the
text which describes it.)

To illustrate let's take a look at a very small snippet of a PostScript
page
description.

400 400 moveto (hello world) show showpage

This snippet will print:

hello world

400 points up from and 400 points to the right of the lower left CORNER
of
the page if it is sent AROUND the PostScript driver (i.e., DIRECTLY to
the
printer's PostScript interpreter.) Whereas if it goes through the
PostScript
DRIVER exactly the same line will print:


400 400 moveto (hello world) show showpage

Starting at the top left MARGIN of the page!



:

How many computers are we talking about here?

You have the laser printer attached to a PC via a USB-to-parallel
adapter
cable. That much I got.

But are you trying to print to this printer from this PC, or from
another
networked PC?

I'm also having some problem understanding what you did and why. Don't
you
have the proper PostScript drivers for this printer? You should be
able
to
do what you need with the PostScript driver(s) that came with the
printer.
PostScript output is _supposed_ to be text ...

And if, for whatever reason, you can't configure the driver to work
properly, there are other ways to get a "raw" file to a printer
without
preprocessing -- like changing the print processor mode on the print
queue.

I don't see why you can't set this up as a "normal" printer and have
the
print driver and spooler do all the heavy lifting for you. Then all
you'd
have to do from your app is open LPT1: or whatever device you choose
to
use.

What model IBM printer do you have? I've had my share of experiences
sending
multiple data streams to IBM printers. Maybe I can help you figure
this
out.

CL



message
On the machine I recently replaced I was using an IBM LaserJet
printer
to
print "Raw PostScript" (i.e., ASCII text that is a Postscript
language
page
description.) The printer having a PostScript language interpreter
translated
the page description text into an image (which that text described)
and
then
printed it.

On the old machines the printer was attached via a
Centronics-to-Parallel
Port cable. Since the new machine does not have a parallel port I
have
had
to
use A USB to Parallel Port adapter.

On the old machine I created a "New Printer" for which I selected a
"Generic
Text Only" driver giving it the share name "Direct". Having done
that I
was
able to print my PostScript job by writing to "\\SBB\direct" using
the
command:

"copy file_name \\SBB\direct

where SBB is the name of my computer.

I was also able to accomplish the same thing in programs I have
written
in
which I open a file named "\\SBB\Direct" and write the PostScript
page
description to it.

The Problem:

When I do precisely the same things on the new computer I get the
error
"Access Denied" using the copy command (I haven't yet tried the
programs I
have written). This was true even though I gave "Everyone" all
possible
permissions for the printer.

Being able to print these PostScript page description on this
printer
is
very important to me, so much so that I would, with despair revert
to
the
old
machine in order to do it. I would, therefore, be extremely grateful
if
someone could steer me around this problem.
 
Steve,

That's interetsing, I have never had a problem calling StartDocPrinter(),
regardless of the spooling setting. But I don't think I've been in that
situation. It could be something to do with how it opens the port and if
there are multiple handles on the port. You say it is obvious though, can
you explain that please? StartDocPrinter(), in my mind, just bypasses the
driver not the spooling.

Paul

Steve Behman said:
Paul, thanks for your continued interest.

Want I did is:

Create a printer named "direct" using Port "DOT004." This port is shared
by
several other printer definitions (e.g. "Simplex, Duplex and, Fax".)
Direct
uses the Generic Text/Only driver.

The C++ programs open the printer as an "ofstream" and write the
PostScript
Page Description to it using the "<<" operator.

This worked on my old systems and is now working on the new one.

What I learned, to my chagrin, is that the problem (Access Denied) arose
from my failure to correctly set the spooling option for "direct."
Apparently
allowing spooling on any printer on a given port must be accompanied by
allowing spooling on every printer on that port. Retrospectively this
requirement is obvious -- the joys of 20/20 hindsight!

I hope this clarifies the situation.

Paul Baker [MVP said:
Steve,

I am not quite following what you're doing? Are you taking a PostScript
file, manipulating it and printing it using GDI to a PostScript printer
in
order to generate a new PostScript file?

There is open source software that handles PostScript and PDF files in
this
kind of way independantly of the Print Spooler.

I actually use StartDocPrinter, so that I can send basic text and escape
sequences to a printer and, for performance reasons, bypass the overhead
of
the GDI and printer driver. This is easier than writing a driver and
trying
to fit it to concepts like CPI, LPI and built in barcodes. Some some
manufacturers have tried and, of course, the Generic / Text Only driver
makes some attempt at this, but it simply fails to do so accurately much
of
the time. I too tend to suggest using the Generic / Text Only driver when
installing the printer, even though technically no driver is used at all
if
it is configured to bypass the driver and use StartDocPrinter. This is
the
source of much confusion and I too would like that situation to "go
away",
but it won't.unless I want to attempt to write the above-mentioned driver
or
have totally separate configuration in which you specify a port, etc...
that
may or may not be in use already by the Print Spooler, ugh.

Paul

Steve Behman said:
Thank you Paul.

From what you said I assume that "StartDocPrinter" is in the GDI API --
is
this assumption correct? If it is, that is at least one level of
abstraction
under the level at which I am coding.

The input(s) to my programs are, themselves, PostScript Page
Descriptions.
It is, therefore, very much easier to manipulate the PostScript than it
is
too abstract it to a "presentation space" and then deal with the image
in
that space.

My programs are written in C++ and, during development, the output page
descriptions are written directly to the printers (an IBM 4039 Plus for
monochrome and an HP OfficeJet 9110 for color.)

I am not particularly fond of my solution (creating a separate printer
using
a Generic Text Only driver) for the output of my programs and would
appreciate a simpler way but I have not been able to find one. Any
suggestions?

:

Yes. The printer driver's job, in essense, is to translate not only
text
(output using TextOut), but any (largely) device-independant GDI
command
into printer language. In this case, PostScript.

If you *want* your output to bypass the driver, and language monitor,
use
StartDocPrinter instead of StartDoc.

If you wish to use the printer driver, but also inject some PostScript
data
into the stream, ExtEscape should work, though I never tried it.

ExtEscape Function:
http://msdn.microsoft.com/en-us/library/dd162708(VS.85).aspx

Paul

message
Charles, thank you very much for your response.

I have actually solved my problem. The details of the solution are
too
arcane to get into here.

The purpose of this note is to correct a possible misapprehension
that
you
may have.

The purpose of the PostScript driver is to translate a document into
the
PostScript Page Description Language for rendering on a printer with
a
PostScript language interpreter.

A PostScript driver will take any text file,**independent of its
content**,
create a PostScript page description of it and then send that
description
to
the printer for rendering by the printer's PostScript language
interpreter.
That is to say: the driver takes no cognizance of the fact that the
file
is,
itself, a PostScript page description!

If, and only if, you can "get around" the driver to send the
PostScript
Language Page Description directly to the printers PostScript
Language
Interpreter will the printer render the described page (as opposed
to
the
text which describes it.)

To illustrate let's take a look at a very small snippet of a
PostScript
page
description.

400 400 moveto (hello world) show showpage

This snippet will print:

hello world

400 points up from and 400 points to the right of the lower left
CORNER
of
the page if it is sent AROUND the PostScript driver (i.e., DIRECTLY
to
the
printer's PostScript interpreter.) Whereas if it goes through the
PostScript
DRIVER exactly the same line will print:


400 400 moveto (hello world) show showpage

Starting at the top left MARGIN of the page!



:

How many computers are we talking about here?

You have the laser printer attached to a PC via a USB-to-parallel
adapter
cable. That much I got.

But are you trying to print to this printer from this PC, or from
another
networked PC?

I'm also having some problem understanding what you did and why.
Don't
you
have the proper PostScript drivers for this printer? You should be
able
to
do what you need with the PostScript driver(s) that came with the
printer.
PostScript output is _supposed_ to be text ...

And if, for whatever reason, you can't configure the driver to work
properly, there are other ways to get a "raw" file to a printer
without
preprocessing -- like changing the print processor mode on the
print
queue.

I don't see why you can't set this up as a "normal" printer and
have
the
print driver and spooler do all the heavy lifting for you. Then all
you'd
have to do from your app is open LPT1: or whatever device you
choose
to
use.

What model IBM printer do you have? I've had my share of
experiences
sending
multiple data streams to IBM printers. Maybe I can help you figure
this
out.

CL



message
On the machine I recently replaced I was using an IBM LaserJet
printer
to
print "Raw PostScript" (i.e., ASCII text that is a Postscript
language
page
description.) The printer having a PostScript language
interpreter
translated
the page description text into an image (which that text
described)
and
then
printed it.

On the old machines the printer was attached via a
Centronics-to-Parallel
Port cable. Since the new machine does not have a parallel port I
have
had
to
use A USB to Parallel Port adapter.

On the old machine I created a "New Printer" for which I selected
a
"Generic
Text Only" driver giving it the share name "Direct". Having done
that I
was
able to print my PostScript job by writing to "\\SBB\direct"
using
the
command:

"copy file_name \\SBB\direct

where SBB is the name of my computer.

I was also able to accomplish the same thing in programs I have
written
in
which I open a file named "\\SBB\Direct" and write the PostScript
page
description to it.

The Problem:

When I do precisely the same things on the new computer I get the
error
"Access Denied" using the copy command (I haven't yet tried the
programs I
have written). This was true even though I gave "Everyone" all
possible
permissions for the printer.

Being able to print these PostScript page description on this
printer
is
very important to me, so much so that I would, with despair
revert
to
the
old
machine in order to do it. I would, therefore, be extremely
grateful
if
someone could steer me around this problem.
 
Back
Top