I have created a PS file from TeX document on my Linux RH9 which print
fine on a networked PS printer. If I send the same PS file to Windows
users, while they can view the file using ghostview, but printing to
the same PS printer is painfully slow. It seems gv sends a bit map to
the printer as the job is shown as 100 times larger than the size of
the PS file. The document has no images. Any suggestion?

Vinod

vrak58@yahoo.com (Vinod Gupta),
In a message on 28 Feb 2004 16:25:48 -0800, wrote :

VG> I have created a PS file from TeX document on my Linux RH9 which print
VG> fine on a networked PS printer. If I send the same PS file to Windows
VG> users, while they can view the file using ghostview, but printing to
VG> the same PS printer is painfully slow. It seems gv sends a bit map to
VG> the printer as the job is shown as 100 times larger than the size of
VG> the PS file. The document has no images. Any suggestion?

If the printer IS a PostScript printer, the MS-Windows users *probably
should not* be using ghostview to print it -- they really should be
sending the file *directly* to the printer. There are some shareware /
freeware utilities for doing thie.

I suspect that what is happening is that ghostview is using ghostscript to
'convert' the PostScript to the MS-Windows print driver API (GDI?),
which is being turned *back* into PostScript by the MS-Windows
PostScript 'driver'. To print a *PostScript* file on a *PostScript*
printer, the file just needs to be sent directly out the 'port',
bypassing all 'driver' software. The 'driver' software is making a mess
of things.

VG>
VG> Vinod
VG>

\/
Robert Heller ||InterNet: heller@cs.umass.edu
http://vis-www.cs.umass.edu/~heller || heller@deepsoft.com
http://www.deepsoft.com /\FidoNet: 1:321/153

In article <30b8645c.0402281625.562b835@posting.google.com> , Vinod Gupta wrote:

Give the Windows users a pdf file not a postscript file.

Really.

$ ps2pdf foo.ps foo.pdf

Or, better yet (IMO)

$ pdflatex foo.tex

You can do some really cool stuff with pdflatex (links and
whatnot), but designing a LaTeX files that works with both
"normal" LaTeX and pdfLaTeX takes some effort.

NB: There are ways to print PS directly in Windows, but you've
got to install a special app, and the chances of your
average Windows user being able to do it are sufficiently
close to 0 to be ignored.

--
Grant Edwards grante Yow! CHUBBY CHECKER just
at had a CHICKEN SANDWICH in
visi.com downtown DULUTH!

On Sun, 29 Feb 2004 03:04:28 +0000, Grant Edwards wrote:

This is a special app??

C:\> type file.ps > LPT1

But I will certainly agree that the average Winbloze luser is unable to
perform such a task.

In article <404156bc$0$41293$a1866201@newsreader.visi.com>, on Sun, 29 Feb
2004 03:04:28 +0000, Grant Edwards wrote:

Start a Windows "shell". Type

copy filename.ps lpt1:

and substitute the mapped name of the printer for "lpt1:".

Our MCSE denied this would work. It did.

In article <pan.2004.02.29.03.52.10.354020@yahoo.com>, Dave Uhring wrote:
Ya know, I wondered if that would still work. Does it work
with network printers?

--
Grant Edwards grante Yow! An Italian is COMBING
at his hair in suburban DES
visi.com MOINES!

On Sun, 29 Feb 2004 05:51:12 +0000, Grant Edwards wrote:

The only time I used it was with an HP printer attached to the box. The
box was running NT-4 WS. But if 'net use LPT1: <printer>' has been
executed it -should- work with a network printer.

Robert Heller <heller@deepsoft.com> wrote in message news:<80931$4041480d$cb248f0$20082@nf2.news-service.com>...
Thanks a lot for this explaination and I believe you are right. I also
appreciate your tip on howto get around. However, I will be interested
in identifying and possibly fixing the source of the problem.

PostScript is supposed to be a universal language, thousands of PS
printers work on this assumption. If latex/dvips on linux is not
producing the "standard" ps, or more likely gs/driver on Windows is
making mess of it then that need to be fixed. Not using gv/gs is not
an option for us because some times we get huge ps files and we often
need to preview and print only selected pages. pdflatex is good
alternative but only for our own tex docs. Many times, ps files are
coming from different sources on which we have no control. It is not
that all ps files fail to print from gv/ps on Windows. So, I am not
sure if problem is badly created ps by latex/dvips on linux or
gv/gs/print_driver on Windows. Howto identify the source of the
problem?

Vinod

In article <30b8645c.0402291206.5fdf372e@posting.google.com>, Vinod Gupta wrote:

Don't worry, it is.

That fact that Windows is broken is not news to anybody here. Ghostview has
no way to know that the destination printer is postscript. GV has to use
the standard Windows printing API. AFAIK, that API does not accept
Postscript. GV has to convert the Postcript into a pixmap (that's what GV
is designed for), the bitmap is then converted back to Postcript by the
Windows printing system, which sends it to the printer to be converted back
into a pixmap. As you can imagine, this is not an efficient process.

Like I said earlier: convert them to pdf. Acroread doesn't convert text to
pixmaps when it prints, so it's much less "lossy" than the GV route.

$ ps2pdf foo.ps foo.pdf

Life will be far, far simpler for you and your customers if you give them
pdf files.

So convert them to PDF.

Microsoft is the source of the problem. Windows hasn't a clue what to do
with PS files. There's not much you can do about it.

Convert the PS files to PDF.

Really.

--
Grant Edwards grante Yow! -- I have seen the
at FUN --
visi.com

vrak58@yahoo.com (Vinod Gupta),
In a message on 29 Feb 2004 12:06:02 -0800, wrote :

VG> Robert Heller <heller@deepsoft.com> wrote in message news:<80931$4041480d$cb248f0$20082@nf2.news-service.com>...
VG> > vrak58@yahoo.com (Vinod Gupta),
VG> > In a message on 28 Feb 2004 16:25:48 -0800, wrote :
VG> >
VG> > VG> I have created a PS file from TeX document on my Linux RH9 which print
VG> > VG> fine on a networked PS printer. If I send the same PS file to Windows
VG> > VG> users, while they can view the file using ghostview, but printing to
VG> > VG> the same PS printer is painfully slow. It seems gv sends a bit map to
VG> > VG> the printer as the job is shown as 100 times larger than the size of
VG> > VG> the PS file. The document has no images. Any suggestion?
VG> >
VG> > If the printer IS a PostScript printer, the MS-Windows users *probably
VG> > should not* be using ghostview to print it -- they really should be
VG> > sending the file *directly* to the printer. There are some shareware /
VG> > freeware utilities for doing thie.
VG> >
VG> > I suspect that what is happening is that ghostview is using ghostscript to
VG> > 'convert' the PostScript to the MS-Windows print driver API (GDI?),
VG> > which is being turned *back* into PostScript by the MS-Windows
VG> > PostScript 'driver'. To print a *PostScript* file on a *PostScript*
VG> > printer, the file just needs to be sent directly out the 'port',
VG> > bypassing all 'driver' software. The 'driver' software is making a mess
VG> > of things.
VG>
VG> Thanks a lot for this explaination and I believe you are right. I also
VG> appreciate your tip on howto get around. However, I will be interested
VG> in identifying and possibly fixing the source of the problem.
VG>
VG> PostScript is supposed to be a universal language, thousands of PS
VG> printers work on this assumption. If latex/dvips on linux is not
VG> producing the "standard" ps, or more likely gs/driver on Windows is
VG> making mess of it then that need to be fixed. Not using gv/gs is not
VG> an option for us because some times we get huge ps files and we often
VG> need to preview and print only selected pages. pdflatex is good
VG> alternative but only for our own tex docs. Many times, ps files are
VG> coming from different sources on which we have no control. It is not
VG> that all ps files fail to print from gv/ps on Windows. So, I am not
VG> sure if problem is badly created ps by latex/dvips on linux or
VG> gv/gs/print_driver on Windows. Howto identify the source of the
VG> problem?

If you were to visit the Adobe site (www.adobe.com), there is someplace
a page listing all of the companies that have signed with Adobe for a
PostScript license (Adobe is the inventor of PostScript). Conspicuously
missing is Microsoft Corp. MS-Windows has NO native support for generic
PostScript printers.

LaTeX/dvips does produce standard PostScript (there are issues relating
to bitmaped CM fonts, but that is a separate issue). Always has. The
problem is the "gv/gs/print_driver on Windows". The MS-Windows print
interface is the source of your problems. It appears that the way
MS-Windows handles printing does not 'sanely' handle PostScript files
with a PostScript printer -- eg it has this 'silly' "print-driver"
interface API and apparently, gv under MS-Windows has no way of
determining if the printer is a PostScript printer or some random
dot-matrix / ink-jet printer.

VG>
VG> Vinod
VG>

\/
Robert Heller ||InterNet: heller@cs.umass.edu
http://vis-www.cs.umass.edu/~heller || heller@deepsoft.com
http://www.deepsoft.com /\FidoNet: 1:321/153

Grant Edwards <grante@visi.com> wrote in message news:<slrnc45714.jpd.grante@bambi.visi.com>...

You are right, I converted ps to pdf on linux and sent the pdf to
Windows users which displays and prints fine with Acroread.

Thanks a lot.
Vinod

Robert Heller <heller@deepsoft.com> wrote in message news:<9b56f$40432511$cb248f0$20459@nf2.news-service.com>...
You are right, problem lies in print-driver which does a poor job of
bitmap to ps conversion. The Windows users can view any PS file with
GV and print on any non-postscript printer. So, the message is - share
only PDF accross platforms.

Thanks for the help,
Vinod

On 2004-03-02, Vinod Gupta <vrak58@yahoo.com> wrote:

Yup. And that's exactly why the pdf format was developed in the first
place...

--

-John (JohnThompson@new.rr.com)

Hamilcar Barca <hamilcar@never.mind> writes:

This reminds of an incident of losing with windows in years past. I
had matlab running and they have this command (called "meta") to dump
a figure/picture to a named file. I figured I'd be smart to name my
file "lpt1:" so it could use the magic filename and go straight to the
printer.

Well, matlab first squaked about "lpt1:" not being a regular file.
That was stupid, but OK. Then I discovered that matlab had somehow
managed to create a file actually called "lpt1:" in the NT4 NTFS.
That was collosally stupid. It detects something is up with the name,
but manages to do exactly the wrong thing all around. A pox on matlab
too.

Now, with a file called "lpt1:", I couldn't delete it -- in either the
cmd.exe shell or explorer. I couldn't rename it. I couldn't do
anything with it. Finally i deleted the parent directory (and hence
all files in it). Windows crashed and burned hard. After a
"scandisk", the system came up, but I had an unemptiable file in my
wastebasket. Instability grew over the next year or so until I had to
reformat that partition or windows would crash all the time.

--
Johan KULLSTAM

In article <873c8lz4vu.fsf@comcast.net> (Sun, 07 Mar 2004 03:56:19 +0000),
Johan Kullstam wrote:

I don't know how Matlab did that and it isn't supposed to be able to do
it. Since MS-DOS 3.3, at least, if a "filename" is used as the name of a
device driver, the "kernel" maps that name into every directory on the
file system. Once upon a time, I created such a driver (named LPT1 and
it showed up everywhere on the disk I typed DIR.

By design(!)

I believe you found a bug in Windows, hard as that may be to believe.

In MS-DOS, after an hour or so trying to figure out what was wrong with
my system, I finally booted from a floppy disk and removed the "DEVICE="
statement from CONFIG.SYS. I wonder if Windows has such a feature,
although I don't care any more.

--
"Until we had this concept of Web services, software on the
Internet couldn't talk to other software on the Internet."
-- Bill Gates. Chairman, Microsoft. 10/29/2003.