Hi,
I don't think the main use case here is to be able to submit IPP
requests directly to a printer. As you said, that can probably be
better handled by the existing platform print system. Similarly, for
the typical sites that don't care too much about the details of how
they're rendered for printing, the existing window.print API is
probably good enough.
The use case here is for more specialized browser-based apps that want
to take more control over how they print. Imagine a kiosk app that
needs to print some exact content with particular settings without
worrying about the user getting print preview settings right. Or
imagine a VDI app that wants to tell the remote system what printers
are available and submit jobs directly on behalf of the remote system.
These kind of apps need to do more specific things than the
window.print API allows, like:
* Enumerate available printers
* Get printer capabilities and status
* Submit a job with specific options
* Monitor the status of a submitted job
IPP already has tons of attributes with standardized names and
well-defined semantics that cover exactly those types of situations,
so it seems to make sense to reuse that rather than coming up with
another way to describe the same objects. There will be a lot of
other issues the browser has to deal with in terms of permissions, UI
integrations, translating to the native print system on the platform,
etc, but those should be independent of the data representation.
Thanks,
Benjamin
On Thu, Apr 27, 2023 at 3:38 PM Kennedy, Smith Wireless & IPP
Standards <smith.kennedy at hp.com> wrote:
>> HI Benjamin,
>> Just to satisfy my own curiosity, can you describe use cases where it is necessary for JavaScript scripts executing in a web page would want to formulate their own IPP requests? What value does that provide, and why is calling out to the browser's native print system inadequate?
>> Smith
>> /**
> Smith Kennedy
> HP Inc.
> */
>> On Apr 27, 2023, at 2:49 PM, Benjamin Gordon <bmgordon at chromium.org> wrote:
>> CAUTION: External Email
> Resending since it seems that the original email got dropped
> somewhere. From today's call, it sounded like the JS library at
>https://github.com/williamkapke/ipp and/or
>https://github.com/sealsystems/node-ipp has a representation that's
> already along the right lines, but there might be some cases that they
> don't address. What do people think about formalizing something based
> on those?
>> Thanks,
> Benjamin
>> On Thu, Mar 23, 2023 at 4:33 AM Benjamin Gordon <bmgordon at chromium.org> wrote:
> >
> > Hi all,
> >
> > We have recently started some discussions internally about what a web-based printing API might look like. Rather than inventing yet another new way to describe printers and states and jobs and so on, I've been advocating for building on all the PWG's hard work with IPP. The sticking point is that binary IPP frames aren't very ergonomic to work with in Javascript. Has there ever been any consideration of defining a canonical JSON encoding? If we brought forward a proposal for such a thing in the next couple of months, would there be interest in moving it through the whole standardization process?
> >
> > Thanks,
> > Benjamin
>>