Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Printing...

635 views
Skip to first unread message

Les Stroud

unread,
Aug 2, 2011, 4:25:50 PM8/2/11
to dev-p...@lists.mozilla.org
I don’t know if anyone is monitoring this list still….but I have an extension to pdf.js that might be interesting.

In a recent app that I’ve developed, I had to implement printing from javascript, via XHR, without drivers direct to the printer using IPP. If you don’t know, IPP is just HTTP with some utf-8 header information prepended to a POST body.  In my case, it was pretty simple because I have a known set of templates that get printed.  So, I can store pre-formatted printer language and token replace the variables.  

For you guys, if you can render a pdf in javascript/html5, without needing native components, then it would not be a very long step to render postscript (or, even PCL).  If you can render postscript and pcl you would cover 90% of the printers out there.  With that, you could use the same mechanism to print from the browser without having to use native divers.  Not only would it be kewl, but it would keep the entire printing process within the browser process sandbox.  This would have the following advantages:

  - Make firefox significantly more secure
  - Open up the possibility of http accessible print “drivers” (javascript renders for the printer control language)...simpler installs by simply parsing an http/ipp response from an ip address for printer model, querying a central service on the web, downloading the javascript renderer live for that printer, and printing.  This would make rollouts and updates of print drivers a snap by taking advantage of browser caching.
  - Reduced native code footprint that has to be maintained across platforms.

With you guys headed toward becoming an operating system, this might be a really good fit…and it is a better answer than what google, apple, and hp have come up with….given you can render fairly quickly.

Thoughts?

LES
--
Les Stroud Developer, Architect, Creative Thinker
web: lesstroud.com email: l...@lesstroud.comlinked in | twitter | facebook




Chris Jones

unread,
Aug 2, 2011, 9:06:48 PM8/2/11
to Les Stroud, dev-p...@lists.mozilla.org
Hi Les,

This is a pretty interesting idea. I'm not much of an expert here, but some comments follow.

----- Original Message -----
> From: "Les Stroud" <l...@lesstroud.com>
> To: dev-p...@lists.mozilla.org
> Sent: Tuesday, August 2, 2011 1:25:50 PM
> Subject: Printing...
> I don’t know if anyone is monitoring this list still….but I have an
> extension to pdf.js that might be interesting.
>

> For you guys, if you can render a pdf in javascript/html5, without
> needing native components, then it would not be a very long step to
> render postscript (or, even PCL).

PostScript output isn't trivial but it's doable. I don't know PCL at all.

> If you can render postscript and pcl
> you would cover 90% of the printers out there. With that, you could
> use the same mechanism to print from the browser without having to use
> native divers. Not only would it be kewl, but it would keep the entire
> printing process within the browser process sandbox.

It depends on what you mean by "browser process sandbox". The problem here is that web content by default can't do cross-origin HTTP requests, so since (presumably) pdf.js would be in a different origin from a discovered IPP printer, pdf.js wouldn't be able to talk to the printer by default. We could get around that problem by upping pdf.js's trust level to that of an "extension", but then we'd hit another issue: need to detect IPP printers, which can't be done with current web APIs. That's not an insurmountable problem either, but it would require adding a new web API for printer detection.

If you mean "browser process sandbox" as in the low-rights renderer processes like Chrome has (and Firefox will get eventually), then this scheme won't quite work because low-rights process can't do arbitrary networking, as would be required for IPP printer discovery. Low-rights renderers would need to use an IPP-discovery API implemented by a higher-rights process.

Another issue is that the PS (or PCL) we send to the printer, whether pdf.js is untrusted or not, needs to be validated to prevent maliciously-crafted PDFs from pwning a local IPP printer. This is new code someone would need to write, or we'd need to grab it from somewhere.

> This would have
> the following advantages:
>
> - Make firefox significantly more secure

This assumes that native printing code is insecure. Let's just fold this into "reduce native code" footprint and the statement won't be controversial.

> - Open up the possibility of http accessible print “drivers”
> (javascript renders for the printer control language)...simpler
> installs by simply parsing an http/ipp response from an ip address for
> printer model, querying a central service on the web, downloading the
> javascript renderer live for that printer, and printing. This would
> make rollouts and updates of print drivers a snap by taking advantage
> of browser caching.

It's not clear to me how much printer-specific "driver" code would be needed. Do you have a guess? But yes, "instant" updates to printing code by web-app-ifying it is very attractive.

> - Reduced native code footprint that has to be maintained across
> platforms.

Yes.

> With you guys headed toward becoming an operating system, this might
> be a really good fit…and it is a better answer than what google,
> apple, and hp have come up with….given you can render fairly quickly.

Possibly. Another problem though is that if the majority of printers nowadays aren't IPP-enabled (do you have numbers?), which is what I would guess, then using an IPP printing interface for all printers would require a translating proxy. Such a proxy would need to take the IPP and translate it into calls to native printing code, which wouldn't really improve overall system security, just move the problem out of firefox.exe.

Anyway, this is an interesting idea. I'll make sure to forward it along to people who know more about printing than I do.

Cheers,
Chris

Les Stroud

unread,
Aug 3, 2011, 4:36:56 PM8/3/11
to Chris Jones, dev-p...@lists.mozilla.org
Let me bore you with a little background on how I ended up here…and then I’ll answer your questions inline.

We are implementing iPads in a manufacturing plant for some production critical operations.  One of the requirements, is that the local site be able to continue running even if the WAN (where the originating web server is located) is inaccessible.  We decided to do this as an html5 application utilizing local storage, app cache, etc.  Fundamentally, we didn’t want to tie our applications tightly to a platform (didn’t want to pick a winner :)).  So, html5 was the best solution in our mind.  The application, however, must also be able to print product labels.  Obviously, being in a browser, on a locked down device like the iPad, makes this a little challenging.  Each tablet has it’s own printer.  So, for this particular application, going straight from the device to the printer is architecturally optimal. Since I was able to specify IPP printers/usb-wifi printer servers and I have a known set of printable things, my particular problem was easier to solve.  Unfortunately, those advantages don’t get me around same origin policies.  So, if you don’t mind, let me digress for a moment to share an opinion around that.

[digress]
CORS is now an industry standard/working draft for enabling cross origin requests.  I’m not a great fan of it, because it requires the secondary origins to declare their support.  I would argue that the browser/user should be in control of what public data it can access (after all the server put it out there, that should be interpreted as intent to share). With that said, not having been in on those discussion, I’m certain there were some sound security reasons for the model that was chosen.  The problem is that CORS didn’t define a model that would work for hardware based, http accessible, restful services (unless the hardware implements CORS). One of these days I’ll have to filter through that email list to get an understanding of why they went with the server side. 
[/digress]

For my particular use case, I had to work with safari (iPad).  I looked at all of the workarounds, but all of them require a means to modify the server configuration or a web page on the device.  So, I started reading webkits code (haven’t looked at FF code yet).  Lo and behold, they have a built in mechanism for whitelisting hosts for cross origin XHR requests.  None of the webkit browser’s expose it, but it is there (WebSecurityPolicy.h).  The more I started thinking about it, having a mechanism that can securely store same origin exemptions would be really useful for both consumer and enterprise web applications.  Especially if that mechanism can be managed both by the user and managed in the enterprise.  Of course, securing that mechanism would be critical.  In fact, I liked the one you guys just deprecated (PrivilegeManager?). :)

I said all of that to provide some context.  As I implemented this project, I was reading about your work on pdf.js and... well…you can see the direction my mind went. :) 

See below ⬇

Thanx for taking the time to forward it around and give it some thought,
LES

On Aug 2, 2011, at 9:06 PM, Chris Jones wrote:

Hi Les,

This is a pretty interesting idea.  I'm not much of an expert here, but some comments follow.

----- Original Message -----
From: "Les Stroud" <l...@lesstroud.com>
To: dev-p...@lists.mozilla.org
Sent: Tuesday, August 2, 2011 1:25:50 PM
Subject: Printing...
I don’t know if anyone is monitoring this list still….but I have an
extension to pdf.js that might be interesting.

For you guys, if you can render a pdf in javascript/html5, without
needing native components, then it would not be a very long step to
render postscript (or, even PCL).

PostScript output isn't trivial but it's doable.  I don't know PCL at all.

Postscript is definitely not simple.  I figure if you can parse and render pdf that you can render ps :).  I’m actually thinking that pcl may not be necessary.  IPP should have all of the printer control attributes that you would need. The advent of hp’s eprint (and apple’s AirPrint) are pushing more printer manufacturers to implement document formats internally.  So, I wouldn’t be surprised if pdf was supported as a printer format soon.  That combined with IPP’s mime type support would make this pretty easy.  For the time being, postscript is probably a good compromise.


If you can render postscript and pcl
you would cover 90% of the printers out there. With that, you could
use the same mechanism to print from the browser without having to use
native divers. Not only would it be kewl, but it would keep the entire
printing process within the browser process sandbox.

It depends on what you mean by "browser process sandbox".  The problem here is that web content by default can't do cross-origin HTTP requests, so since (presumably) pdf.js would be in a different origin from a discovered IPP printer, pdf.js wouldn't be able to talk to the printer by default.  We could get around that problem by upping pdf.js's trust level to that of an "extension", but then we'd hit another issue: need to detect IPP printers, which can't be done with current web APIs.  That's not an insurmountable problem either, but it would require adding a new web API for printer detection.

If you mean "browser process sandbox" as in the low-rights renderer processes like Chrome has (and Firefox will get eventually), then this scheme won't quite work because low-rights process can't do arbitrary networking, as would be required for IPP printer discovery.  Low-rights renderers would need to use an IPP-discovery API implemented by a higher-rights process.

Another issue is that the PS (or PCL) we send to the printer, whether pdf.js is untrusted or not, needs to be validated to prevent maliciously-crafted PDFs from pwning a local IPP printer.  This is new code someone would need to write, or we'd need to grab it from somewhere.

Cross origin - seem my treatise above :).  Elevation to extension is a good idea.  That certainly simplifies things.  I just wish the standard mechanism allowed for this….sigh. :)  

Printer detection is harder.  It would be nice if the XHR had a multicast mechanism so that you could take advantage of the bonjour/zerconf stuff.  Since that isn’t there, it may make sense to spawn a pool of web workers to iterate through the machine's class C address space with an IPP get-printer-attributes request?  It’s a little spammy, but with the amount of multicast traffic around these days, it might not be too bad.  The web workers should drake it performant and the response, if one received will give it all the data it needs for a listing.


This would have
the following advantages:

- Make firefox significantly more secure

This assumes that native printing code is insecure.  Let's just fold this into "reduce native code" footprint and the statement won't be controversial.

Yeah, sorry.  I was not try to imply that the native printing code is insecure.  I am in no way a security expert (does staying at a holiday inn express not qualify? :)) .  I was probably making a faulty assumption that it would be easier to fall back on the existing security around the renderer and javascript engine than it would be to have to manage it separately (frankly, since i have never read the FF code, i don’t even know that they are separate..they used to be, but that was way back in the netscape days :)).  So,  ‘reduce native code’ is a better description.


- Open up the possibility of http accessible print “drivers”
(javascript renders for the printer control language)...simpler
installs by simply parsing an http/ipp response from an ip address for
printer model, querying a central service on the web, downloading the
javascript renderer live for that printer, and printing. This would
make rollouts and updates of print drivers a snap by taking advantage
of browser caching.

It's not clear to me how much printer-specific "driver" code would be needed.  Do you have a guess?  But yes, "instant" updates to printing code by web-app-ifying it is very attractive.

Now that you mention this, I’m not sure what the requirements would be either.  Print drivers generally deal with printer control language.  However, IPP would standardize that in this case.  The types of documents are likely to be limited to pdf or html (graphics, canvas, etc).  So, I can’t imagine that there would be too many printer specific things that you would care about. The attributes that would be different should come back on the ipp attributes request (orientation, duplex, default margin?).  I’ll have to think about that a little more, but this would certainly make that simpler.


- Reduced native code footprint that has to be maintained across
platforms.

Yes.

With you guys headed toward becoming an operating system, this might
be a really good fit…and it is a better answer than what google,
apple, and hp have come up with….given you can render fairly quickly.

Possibly.  Another problem though is that if the majority of printers nowadays aren't IPP-enabled (do you have numbers?), which is what I would guess, then using an IPP printing interface for all printers would require a translating proxy.  Such a proxy would need to take the IPP and translate it into calls to native printing code, which wouldn't really improve overall system security, just move the problem out of firefox.exe.

I’ll have to do a little research on numbers.  Certainly that would make a big difference.  I ran across http://pwg-wiki.wikispaces.com/IPP+Everywhere while I was looking into your question.  It is an IPP 2.0 working group that was formed late last year.  It looks like the entire printing community is involved in trying to create “driverless” printing.  There are some notable members and some notable absences.  Their work might dovetail into this a bit. It appears to be driven by the printer companies, but that doesn’t speak to a commitment level.  I can say that many of the newer, network enabled, printers that I have personally seen have it (though it is not always enabled by default).  Usb printers would not be candidates, however.  So, the right breakdown may be that of ip enabled versus usb.


Anyway, this is an interesting idea.  I'll make sure to forward it along to people who know more about printing than I do.

Kewl.  Like I said, it was interesting.  I don’t know if the details will bear out.  However, I found, in my recent project, that there were not a lot of web folks that realized that you could print with an HTTP POST. Given that, and your work, I wanted to at least pass it along to see if you thought it would have value to you or mozilla in general.


Cheers,
Chris
0 new messages