Re:HTML to Postscript

[Adam <adam@xxxxxxxxxxxxxxxxxx>]

>> >If the print command is already set then they ignore that and just hit ok.
>> >Is the it somehow difficult to make sure the proper "lpr -Ptherightqueue
>> >%s" is setup on the different boxes?  hmmmm.
>> True, but there are roughly 20 laser printers spread across Michigan and
>> Nothern Indiana,  typically they will print to the one closest to them,
>> but not always.
>Ok that clarifies alot, you need a WAN solution, probably on dialup
>bandwidth ;)

Leased 64k to be exact, get about 90k out of them with compression.

>> >>2. The postscript it generates is huge and ugly.
>> >That's just postscript methinks ;)
>> Having written some postscript, I disagree.
>So you think you can write a ps generator to generate postscript as good
>as you can write....
>Please joing the efforts in Mozilla to make that reality ;)

No,  generated will "never" be as good as hand written,  the diffrence in
quality is simply staggering, and I think it could be better.  Also bieng
able to write postscript and writing a program to write postscript are
two entirely difrrent matters,  and I'm a lousy programmer.

>>  A lot can be described in
>> a very compact format,  and with support for included compressed images
>> jobs should be very small.  But printing a 4k gif with netscape can
>> generate over 1Mb of postscript.  That is indicative of a very poor
>> postscript generator.
>No arguments there, but you can't fix it in Netscape, possibly could be
>fixed in Mozilla (may already be fixed) but I don't think Mozilla is prime
>time yet.

Nope.

>> >>I have Optra 
>> >>lasers with 2Mb of RAM, and not to infrequently they can't print
>> >>the page due to the size of the job.  That is ridiculous.  So
>> >>my only option there is to convert every jobs to PCL using 
>> >>ghostscript at the client, which makes the printing SLOWWWW.
>> >Why are you doing it at the client?
>> Because the client is at the other end of a 90kbps connection,  sending
>> 2Mb of postscript to convert it into 200 to 400K of PCL and then sending
>> it back to the printer is simply not going to work.
>I'm confused why you can't dump a 486 at each printer to do this
>conversion AT the printer just using a different box.  I'm also not user
>why you can't put some REAL RAM in the printers(like at least 16M).

We'll I've already re-deployed all my nice old 486's as Linux thin clients 
(hence the not so powerful clients).  And additional RAM for the printers
would come out of each locations budget,  and the managers would have a
fit.  Polotics.

>> >>  Also
>> >> I'd just as soon not configure every printer at every client, not
>> >> to mention installing ghostscript which is an enourmous package.
>> About one printer for every six to eight clients.
>Place a print server each of those cluster and make IT the only one the
>talks to the REAL printer.

I may do that in the future, currently they are hooked to a Cisco 2511
access server.

>> >> can convert the jobs on a nice and fast server and not have a
>> >> problem if I can get PHP to start the print job thiere
>> >Why not just set up a queue on that big print server then setup all the
>> >clients to print remotely to that queue via the normal print queue for
>> >that box, don't even have to change the lpr %s line in netscape if you do
>> >that?
>> Again the bandwidth,  I'd prefer to just send the PCL job from here and
>> never have to try and move that mountain of postscript around.
>It'll take 20 PC's and, etc. and presumes proximate location on the
>clusters, but the above suggestion would dramatically reduce your
>bandwidth through put at what you are claiming to be the bottlenecks.  You
>CAN use one of the cluster PC in each workgroup for this task but it have
>to be pretty beefy to do both Netscape browsing and handle EVERYONE's (in
>probably even have spares PC in stock that could be pressed into service.

Makes sense, but takes time.  I have serveral old boxes working as print
servers scattered here an there,  but certainly not one for every printer.
Usually any site that has a Windows box has it's own print server as they
have problems  with printer queues that take a long time to respond.  But
most branches are strictly linux.

>> >Another option you might have is the CUPS (Common Unix Printing System)
>> >just released GPL.  If you are interested in this (beware it uses
>> >Ghostscript as well) I'll send you a pointer.
>> Maybe.  But I need an interim solution, rather more quickly that I can
>> scrap by good old LPD system and replace it.  I am no fan of how UNIX
>> handles printing (or of how window's does it either).  There simply
>> HAS to be a better way.
>Yet it hasn't been created yet, perhaps in time.  CUPS may be a step in
>that direction, however I've barely touched it's surface at this point.

Maybe you should present about CUPS at an upcoming meeting?

>> >Perhaps you could really describe you problem and a solution will present
>> and I can convert the postscript to PCL on the server.  I just haven't gotten
>> it working yet.  It produces output,  but very confused output.
>> 
>Perhaps html to ps is a little harder to do than you originally thought?

Well I got it working.  Not perfect but acceptable.  They pick a printer
from a drop down list on the web site, and push the print bottom (part of an
HTML form) and the PHP-Webserver fires up the print job generator and creates
a nice clean image of the page (dropping URLS and such things) and sends it
to the printer they requested.  By converting from Postscript to PCL I can
cut the print job size roughly in half, and by lowering the print resolution
to 180x180 it is even smaller.  These documents will be scribbled on my
part's clerks so quality is less important than speed.  It's not ideal, but
I'll keep you posted if you're interested.