[Printing-architecture] PDF workflow, cupsaddsmb, and Windows clients

[Printing-architecture] PDF workflow, cupsaddsmb, and Windows clients

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

Hi all,

Is there any adoption of PDF workflow in the Windows world?
I used to have a setup like this:
PostScript-based printers on CUPS are exported to Windows clients with
cupsaddsmb, and happy Windows clients just point and print easily.

How that I'm trying to switch my PPDs to PDF-based ones (written with PJL
commands), this setup no longer works.

Is there a solution better than uploading a manufacturer-provided driver
for each printer? Ideally, something as automatic as current
cupsui6/cupsps6.dll is, one that could take a PJL-based driver and build a
UI around it to show to a Windows client?

-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 831 bytes --]

Re: [Printing-architecture] PDF workflow, cupsaddsmb, and Windows clients

[Ira McDonald]

[-- Attachment #1: Type: text/plain, Size: 2049 bytes --]

Hi Alex,

I've copied Mike Sweet (Apple, CUPS) and Smith Kennedy (HP, all things
printing-related) on this reply.  I hope they can reply with more detail
about
Windows printing.

But I'd like to point out that CUPS PPD API was deprecated in CUPS 1.6
and PPDs in general are deprecated legacy in CUPS 2.0.  PDF workflow
in Linux, UNIX, and elsewhere is based on generic print clients using direct
printer queries for printer capabilities and current defaults (IPP
Everywhere).

PPD-based printing solutions are destined to disappear in the future.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434


On Mon, Aug 24, 2015 at 10:56 AM, Alex Korobkin <korobkin+op@gmail.com>
wrote:

> Hi all,
>
> Is there any adoption of PDF workflow in the Windows world?
> I used to have a setup like this:
> PostScript-based printers on CUPS are exported to Windows clients with
> cupsaddsmb, and happy Windows clients just point and print easily.
>
> How that I'm trying to switch my PPDs to PDF-based ones (written with PJL
> commands), this setup no longer works.
>
> Is there a solution better than uploading a manufacturer-provided driver
> for each printer? Ideally, something as automatic as current
> cupsui6/cupsps6.dll is, one that could take a PJL-based driver and build a
> UI around it to show to a Windows client?
>
> --
> -Alex
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture
>
>

[-- Attachment #2: Type: text/html, Size: 3457 bytes --]

Re: [Printing-architecture] PDF workflow, cupsaddsmb, and Windows clients

[Michael Sweet]

Alex,

The Windows print system is based on Microsoft's XPS format, which is functionally the same as PDF but requiring different tools/filters.

I know Ghostscript and mupdf have XPS support, but I don't know of anyone that has either written the necessary CUPS filters nor the corresponding Windows drivers (which need to comply with some unfortunately strict Microsoft licensing...)



> On Aug 24, 2015, at 11:36 AM, Ira McDonald <blueroofmusic@gmail.com> wrote:
> 
> Hi Alex,
> 
> I've copied Mike Sweet (Apple, CUPS) and Smith Kennedy (HP, all things
> printing-related) on this reply.  I hope they can reply with more detail about
> Windows printing.
> 
> But I'd like to point out that CUPS PPD API was deprecated in CUPS 1.6
> and PPDs in general are deprecated legacy in CUPS 2.0.  PDF workflow
> in Linux, UNIX, and elsewhere is based on generic print clients using direct
> printer queries for printer capabilities and current defaults (IPP Everywhere).
> 
> PPD-based printing solutions are destined to disappear in the future.
> 
> Cheers,
> - Ira
> 
> 
> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto: blueroofmusic@gmail.com
> Winter  579 Park Place  Saline, MI  48176  734-944-0094
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
> 
> 
> On Mon, Aug 24, 2015 at 10:56 AM, Alex Korobkin <korobkin+op@gmail.com> wrote:
> Hi all, 
> 
> Is there any adoption of PDF workflow in the Windows world? 
> I used to have a setup like this: 
> PostScript-based printers on CUPS are exported to Windows clients with cupsaddsmb, and happy Windows clients just point and print easily. 
> 
> How that I'm trying to switch my PPDs to PDF-based ones (written with PJL commands), this setup no longer works. 
> 
> Is there a solution better than uploading a manufacturer-provided driver for each printer? Ideally, something as automatic as current cupsui6/cupsps6.dll is, one that could take a PJL-based driver and build a UI around it to show to a Windows client?
> 
> -- 
> -Alex
> 
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture
> 
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Re: [Printing-architecture] PDF workflow, cupsaddsmb, and Windows clients

[Till Kamppeter]

On 08/24/2015 12:59 PM, Michael Sweet wrote:
> Alex,
>
> The Windows print system is based on Microsoft's XPS format, which is functionally the same as PDF but requiring different tools/filters.
>
> I know Ghostscript and mupdf have XPS support, but I don't know of anyone that has either written the necessary CUPS filters nor the corresponding Windows drivers (which need to comply with some unfortunately strict Microsoft licensing...)

One should check how well Ghostscript performs as XPS 
interpreter/converter If it does well, the needed CUPS filter would be a 
simple wrapper around Ghostscript, which we would name xpstopdf and 
after that we get the usual pdftopdf and then pdfto<whatever the printer 
needs>.

    Till

Re: [Printing-architecture] PDF workflow, cupsaddsmb, and Windows clients

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

On Mon, Aug 24, 2015 at 1:28 PM, Till Kamppeter <till.kamppeter@gmail.com>
wrote:

> On 08/24/2015 12:59 PM, Michael Sweet wrote:
>
>> Alex,
>>
>> The Windows print system is based on Microsoft's XPS format, which is
>> functionally the same as PDF but requiring different tools/filters.
>>
>> I know Ghostscript and mupdf have XPS support, but I don't know of anyone
>> that has either written the necessary CUPS filters nor the corresponding
>> Windows drivers (which need to comply with some unfortunately strict
>> Microsoft licensing...)
>>
>
> One should check how well Ghostscript performs as XPS
> interpreter/converter If it does well, the needed CUPS filter would be a
> simple wrapper around Ghostscript, which we would name xpstopdf and after
> that we get the usual pdftopdf and then pdfto<whatever the printer needs>.
>
>
GhostScript 9.16 is great at XPS to PDF conversion. Older versions had some
bugs, but more recent ones are good at it.

I don't see how we could integrate that with printer options, though. Let's
say I want a user to be able to select a stapling option. One cannot inject
PJL commands into an XPS job I suppose?


-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 1813 bytes --]

Re: [Printing-architecture] PDF workflow, cupsaddsmb, and Windows clients

[Michael Sweet]

Alex,

> On Aug 24, 2015, at 2:11 PM, Alex Korobkin <korobkin+op@gmail.com> wrote:
> ...
> I don't see how we could integrate that with printer options, though. Let's say I want a user to be able to select a stapling option. One cannot inject PJL commands into an XPS job I suppose?

That's why you put the options in a job ticket that is transmitted in parallel with the document data...

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Re: [Printing-architecture] PDF workflow, cupsaddsmb, and Windows clients

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 919 bytes --]

On Mon, Aug 24, 2015 at 2:47 PM, Michael Sweet <msweet@apple.com> wrote:

> Alex,
>
> > On Aug 24, 2015, at 2:11 PM, Alex Korobkin <korobkin+op@gmail.com>
> wrote:
> > ...
> > I don't see how we could integrate that with printer options, though.
> Let's say I want a user to be able to select a stapling option. One cannot
> inject PJL commands into an XPS job I suppose?
>
> That's why you put the options in a job ticket that is transmitted in
> parallel with the document data...
>
>
Right, this is the case when you connect to the printer via IPP. However,
when one adds a printer via IPP in Windows, it cannot select a driver
automatically (or I couldn't figure out that step). That's why I'd prefer
to connect to it via Samba, but with Samba the job options do not work.



> _________________________________
>
________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>


-- 
-Alex

[-- Attachment #2: Type: text/html, Size: 1902 bytes --]

Re: [Printing-architecture] PDF workflow, cupsaddsmb, and Windows clients

[Till Kamppeter]

On 08/25/2015 03:44 PM, Alex Korobkin wrote:
> Right, this is the case when you connect to the printer via IPP.
> However, when one adds a printer via IPP in Windows, it cannot select a
> driver automatically (or I couldn't figure out that step). That's why
> I'd prefer to connect to it via Samba, but with Samba the job options do
> not work.
>

Windows seems to be missing IPP Everywhere (ask printer/CUPS server for 
PDLs and options via IPP and then present the options in print dialog 
and send the job in one of the PDLs with the users settings as IPP 
attributes) support.

    Till