You are not logged in.

#1 2018-02-24 13:55:27

jbssm
Member
Registered: 2017-10-28
Posts: 21

How to create a postscript printing server in arch?

Hi all,

I have a somewhat oldish Canon printer and it is giving quite an hassle to setup in linux.

Since I don't want to set it up for all my machines, I would like to share it inside my home network with my other Linux boxes *not* as a simple RAW printer (where I would have to install the drivers in all the other machines) but as a postscript printer. Is this possible?

I've already setup the printer in my server machine and I can share it with the other boxes. In one of those boxes I installed the needed Canon drivers (and other quirks) and it prints to the printer connected to my server machine.

Now, how do I make the other devices print without drivers simply using postscript?

Last edited by jbssm (2018-02-24 13:56:05)

Offline

#2 2018-02-24 14:48:27

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 21,660

Re: How to create a postscript printing server in arch?

Offline

#3 2018-02-24 15:01:25

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,544

Re: How to create a postscript printing server in arch?

What part specifically, V1del? I don't see anything there that pertains to the OP's question.

Online

#4 2018-02-24 15:28:34

seth
Member
Registered: 2012-09-03
Posts: 51,037

Re: How to create a postscript printing server in arch?

Is your "somewhat oldish Canon printer" PS capable at all? (Hint: the exact model would likely be of help)
If it's a pure GDI printer: forget about it. You could still add a printserver (raspberry pi?) as proxy.

Offline

#5 2018-02-24 19:56:13

paulkerry
Member
From: Sheffield, UK
Registered: 2014-10-02
Posts: 611

Re: How to create a postscript printing server in arch?

jbssm wrote:

Now, how do I make the other devices print without drivers simply using postscript?

Isn't this just a case of setting up your server with a postscript driver and then setup your clients to use raw?

Offline

#6 2018-02-24 20:32:32

loqs
Member
Registered: 2014-03-06
Posts: 17,323

Re: How to create a postscript printing server in arch?

Offline

#7 2018-02-25 08:55:04

jbssm
Member
Registered: 2017-10-28
Posts: 21

Re: How to create a postscript printing server in arch?

Hi, I have but I don't see anything there pertaining the question.

Offline

#8 2018-02-25 08:56:42

jbssm
Member
Registered: 2017-10-28
Posts: 21

Re: How to create a postscript printing server in arch?

seth wrote:

Is your "somewhat oldish Canon printer" PS capable at all? (Hint: the exact model would likely be of help)
If it's a pure GDI printer: forget about it. You could still add a printserver (raspberry pi?) as proxy.

No it is not PS capable that's the all question. I want my server to share the printer like if it was a PS capable printer and then use the proper (non PS) Canon drivers in the server to actually print the documents I "print" to the server in PS format from other machines.

Last edited by jbssm (2018-02-25 09:00:37)

Offline

#9 2018-02-25 08:59:37

jbssm
Member
Registered: 2017-10-28
Posts: 21

Re: How to create a postscript printing server in arch?

loqs wrote:

I see a lot of info there but sincerely it becomes quite complex after a while and what I get from that is that they are trying to do what I have already done: share the printer in raw in CUPS and then install the proper drivers for that specific printer in evety machine.

Offline

#10 2018-02-25 10:56:12

loqs
Member
Registered: 2014-03-06
Posts: 17,323

Re: How to create a postscript printing server in arch?

I was referring to this section

NOTE,  please, that the editing in the "mime.convs" and the
-----  "mime.types" file does not *enforce* "raw" printing, it
        only *allows* it. Any file arriving from Windows is
"auto-typed" by CUPS, which might consecutively lead to its
treatment by various filters automatically (depending on the
actual outcome of the auto-typing and the configuration of the
printqueue in question):

     --> Files generated by PCL drivers and destined to PCL
         printers get auto-typed "application/octet-stream"
         and are indeed printed "raw". Also, unknown file
         types are getting tagged as "application/octet-stream".

     --> Files generated by a PostScript driver (and destined
         for any target printer type) are auto-typed. Depending
         on the driver, the discovered MIME type may be

           * application/postscript or
           * application/vnd.cups-postscript

"application/postscript" goes first thru the "pstops" filter
    (where also the page counting and accounting takes place
    currently), and the outcome will be of MIME type
    "application/vnd.cups-postscript". The pstopsfilter reads and
    uses information from the PPD and inserts user-provided options
    into the PostScript file. As a consequence, the filtered file
    will possibly have the PJL header you don't want.

"application/postscript" will be all files with a ".ps", ".ai",
    ".eps" suffix or which have as their first character string one
    of "%!" or "<04>%".

"application/vnd.cups-postscript" will be those files which do both,
    first...
    ...carry a string "LANGUAGE=POSTSCRIPT" (or similar variations
       with different capitalization) amongst the first 512 bytes,
       *plus*...
    ...contain the "PJL super escape code" amongst the first 128
       bytes ("<1B>%-12345X"). Very likely, most PostScript files
       generated on Windows using a CUPS- or other PPD, will have
       to be auto-typed as "vnd.cups-postscript".
    Probably a file produced with a "Generic PostScript driver"
    will be just "application/postscript" (have not checked).

Once the file is in "application/vnd.cups-postscript" format,
either "pstoraster" or "cupsomatic" will take over (depending
on the printer configuration, as determined by the PPD in use).

NOTE:  a printer queue with *no* PPD associated to it is a "raw"
-----  printer and all files will go directly there as received
        by the spooler; the exeption are file types
"application/octet-stream" which need the mentioned "passthrough
feature" enabled. "Raw" queues don't do any filtering at all, they
hand the file directly to the CUPS backend. This backend is
responsible for the sending of the data to the device (as visible
in the "device URI" notation as lpd://, socket://, smb://, ipp://,
http://, parallel:/, serial:/, usb:/ etc.)

The queue on the cups server would not be raw but would have the correct ppd so that it can convert PS to printers native raster format.
As in this section

#########################################################################
#
# CUPS in and of itself has this (general) filter chain (CAPITAL
# letters are FILE-FORMATS or MIME types, other are filters (this is
# true for pre-1.1.15 of pre-4.3 versions of CUPS and ESP PrintPro):
#
# <SOMETHNG>-FILEFORMAT
#      |
#      |
#      V
#     <something>tops
#      |
#      |
#      V
# APPLICATION/POSTSCRIPT
#      |
#      |
#      V
#     pstops
#      |
#      |
#      V
# APPLICATION/VND.CUPS-POSTSCRIPT
#      |
#      |
#      V
#     pstoraster   # as shipped with CUPS, independent from any Ghostscipt
#      |           # installation on the system
#      |  (= "postscipt interpreter")
#      |
#      V
# APPLICATION/VND.CUPS-RASTER
#      |
#      |
#      V
#     rasterto<something>  (f.e. Gimp-Print filters may be plugged in here)
#      |   (= "raster driver")
#      |
#      V
# SOMETHING-DEVICE-SPECIFIC
#      |
#      |
#      V
#     backend
#
#
# ESP PrintPro has some enhanced "rasterto<something>" filters as compared to
# CUPS, and also a somewhat improved "pstoraster" filter.
#
# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
#       CUPS and ESP PrintPro plug-in where rasterto<something> is noted.
#
#
#########################################################################

Offline

Board footer

Powered by FluxBB