JKolstad
05-11-2007, 02:18 AM
For those of you who don't know, printing from Windows Mobile devices is in not that dissimilar to printing from an N800: Windows Mobile doesn't contain the regular full-blown Win32 printing subsytem, so most applications simply don't have a print option... with the exception that you can still dump text and pictures -- to PictBridge compliant printers -- via IrDA.
Some of the solutions people found to these printing limitations in the Windows Mobile world might apply to the N800 as well. There are a couple of commercial products for Windows Mobile, for instance, that address this: PrintPocketCE (http://www.fieldsoftware.com/), which prints Pocket Word, Pocket Excel, and e-mail to numerous printers, and PrintBoy (http://www.bachmannsoftware.com/pbce.htm) which prints "real" (full version) Word and PDF documents. (Interestingly, PrintBoy is also available for the Palm and Symbian OSes.)
Both of these programs render the documents themselves, after which they contain print drivers for a "very large handful" (some dozens) of popular printers that cover most printers you'd be likely to encounter on the road -- at least in a commercial settings. If you look at PrintBoy's printer capatibility list (http://www.bachmannsoftware.com/PrinterMatrixWEB.pdf), it's clear that about the only printers sold in volume that aren't supported are the really low-end "host driven" printers such as the HP 3520 -- a $29 printer, that would hopefully never find its way onto a network. :-)
Anyway, it seems as though something like this could be done for the N800 as well. Does GTK+ have anything of a printing subsytem built-in (as, say, wxWidgets does)? Or is it "every application for itself" when it comes to printing? The former would certainly make it a lot easier to convince people to add printing support to their applications, I would think. I'm sure we could round up enough programmers to write "back ends" for various popular printers (starting with PCL3 and whatever-format-Canon-typically-uses would immediately cover a lot of printers).
Another obvious option would be to send print jobs to a "proxy" machine somewhere on the Internet that would render the job and just send back the raw data for the printer in question. Of course the obvious downside here is that you need a high-speed Internet connection to make this happen -- this probably isn't a viable option for the "travelings salesman" scenario.
Thoughts?
---Joel
Some of the solutions people found to these printing limitations in the Windows Mobile world might apply to the N800 as well. There are a couple of commercial products for Windows Mobile, for instance, that address this: PrintPocketCE (http://www.fieldsoftware.com/), which prints Pocket Word, Pocket Excel, and e-mail to numerous printers, and PrintBoy (http://www.bachmannsoftware.com/pbce.htm) which prints "real" (full version) Word and PDF documents. (Interestingly, PrintBoy is also available for the Palm and Symbian OSes.)
Both of these programs render the documents themselves, after which they contain print drivers for a "very large handful" (some dozens) of popular printers that cover most printers you'd be likely to encounter on the road -- at least in a commercial settings. If you look at PrintBoy's printer capatibility list (http://www.bachmannsoftware.com/PrinterMatrixWEB.pdf), it's clear that about the only printers sold in volume that aren't supported are the really low-end "host driven" printers such as the HP 3520 -- a $29 printer, that would hopefully never find its way onto a network. :-)
Anyway, it seems as though something like this could be done for the N800 as well. Does GTK+ have anything of a printing subsytem built-in (as, say, wxWidgets does)? Or is it "every application for itself" when it comes to printing? The former would certainly make it a lot easier to convince people to add printing support to their applications, I would think. I'm sure we could round up enough programmers to write "back ends" for various popular printers (starting with PCL3 and whatever-format-Canon-typically-uses would immediately cover a lot of printers).
Another obvious option would be to send print jobs to a "proxy" machine somewhere on the Internet that would render the job and just send back the raw data for the printer in question. Of course the obvious downside here is that you need a high-speed Internet connection to make this happen -- this probably isn't a viable option for the "travelings salesman" scenario.
Thoughts?
---Joel