> running all operating systems (including Windows) so I think this
> implies running Samba + CUPS on print servers so nmbd can publish
> printers to Windows clients without installing any additional software

That can be done, but I wouldn't do it unless you find
  you actually need it.
In my experience it actually complicates matters, another
  interdependency, etc.  That said it may help for some
  cases (e.g. autoinstall local windows printer driver).


So long as the CUPS print-server has a fixed IP address
  (and optionally a DNS-name pointing to that), you can
  then find easily the printers' URL like:-

http://198.51.100.162:631/printers/hplaserjet1100/


(Note in debian 6.0 cups there seems to be some weird
  bug with printing that came in via a DNS-pointer,
  the cups server then is unhappy about the request's
  HOST: header.).

In windows-XP and later (I.e. all currently supported!)
  you can setup printing to a printer with URL as above.
  (In windows-XP you say 'local printer' and then say
  'connect to a printer on the internet '...

On windows 2000, I believe it would be silly about
  printing to a http://[ip address] URL.  You could
  workaround this with a local hosts file etc.

On windows 98se it was possible to get a microsoft IPP
  addon, that used to at least work ;-).

On modern Linux (which uses CUPS, like MAC OS X), you
  can print to remote http / CUPS-ipp servers with
  no issues....  So I doubt you need samba.


Windows XP (and likely earlier versions) used to choke
  if setup with an IPP/http printer as the default
  printer and it was not avaliable.  E.g. m$-office
  tools would try to 'query the settings of the default
  printer' and grind to a halt until you set PDFcreator
  or something else as the 'default printer'.
I'm not 100% sure, but I got the impression this was
  improved in windows-7.



On most windows (it likely works equally in windows-7)
  you can use the "Adobe generic postscript printer driver"
  to send printer jobs to CUPS, and CUPS processes them.
You can use the .PPD file copied from a linux system in
  order the driver has all the exact margins/trays/duplex
  etc. options available, but this is not required for
  functional printing.  (note the adobe installer will
  only read the .PPD from a drive-letter'ed C: D: etc
  location and not \\servername\  etc.).


> I think running CUPS implies rendering the jobs?
Well, when all the right bits-and-pieces (drivers) are
  installed (as they tend to be on ubuntu/derivaties
  and easily can be on debian etc...), CUPS itself
  supports the printer.

Then, CUPS, will accept both:-
  * 'Raw' print jobs (e.g. from windows client using the
      printer installed locally, just dumping the raw
      output through CUPS).
  * Postscript/PCL and PDF files and the like, I think.
      In which case CUPS itself 'renders' the job.
      (e.g. adobe generic PS driver, see above).


--Simon
_______________________________________________
openwrt-users mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-users

Reply via email to