Complete absence of printer drivers for Win 2003SE (Smartphone not PDA)

[perhagman]

Stockholm, August 21 2006.


Dear Forum:

We have a C# application running on older Smartphone models
(MS Windows 2003SE for Smartphone) where both WM5.0 and PDAs
are "overkill".

The Smartphone gets input data from a barcode scanner via
bluetooth (SPP serial profile), forwards the data via GPRS to
a webserver which validates & replies with a beep + ascii-text.

Now, at the end of a transaction, we need to send ascii-text
not to the Smartphone display but rather to a portable printer
at the remote location - preferably also pushed out from the
Smartphone via bluetooth to the mobile printer.

The REAL snag is that 99% of the market only use PDAs so the
hardware manufacturers themselves have no drivers which can
be used on Win 2003SE Smartphone OS (only PPC/WinCE or WM5.0)
and consequently we need to find a workaround to solve this.


[A] Using FieldSoftware's SmartphonePrint which does allow
for bluetooth printing to some models, but it only can print
PIM elements unfortunately.

In that case, we thought of using the Smartphone PIM task
+ Notes attached to a Task, as the text to print, but this
mean we must create a Task+Notes on-the-fly programmatically
deleting any previous ones in the process, AND launch the
3rd-party SmartphonePrint sequence without user interaction!!

Does anyone now how this could be done simply?

[b] Else, has anyone seen any other Smartphone 2003 print
utility from "way back when" ??

[C] Better yet, would anyone knows of any usable drivers?!?
so we indeed could integrate the printing to our C# application
(deployed from MS Visual Studio 2005 Professional), and bypass
the need for a 3rd-party software, which is harder to control
AND which would lead to resorting to end-user action...

Grateful for any suggestions, albeit in priority C > B > A !

Brgds,
/Per Hagman

==============================================================

PS-1:

There are two-three well-known 3rd-party suppliers of standard
software for printing from an older Smartphone such as Qtek8080
or imate SP3 - aka SPV/Xphone/SDA/SMT5600 etc, namely:

FieldSoftware -- www.fieldsoftware.com/smartphoneprintfull.htm
JetCet -- www.westtek.com/smartphone/jetcet/
PrintBoy -- www.bachmannsoftware.com/pbce.htm (only MS Mobile 5.0?)

Although articles, forums etc. indicate that PrintBoy works on
both PDA and Smartphones, its CAB-file doesn't install on our
MS Win 2003SE Smartphone...

Repligo 2.0 for Smartphones looks like another method, but we
will have to doublecheck if the HP printing is possible for
the portable printers that are available... ???

www.cerience.com/products/smp/index.htm
www.cerience.com/docs/smp/docs/index.htm#Printing

There are a number of small portable mobile printers available
on the market, many conveniently eqipped with a bluetooth
interface -- these printers are ok for field-service printing

For a visual near-complete listing, see again:
www.fieldsoftware.com/PrintersSupported.htm


PS-2:

There is also ActivePrint for PDA printing while docked, and
it might work for Smartphones. However, it doen't really apply
for printing at remote locations (or in a delivery truck) using
small mobile printers,,,

www.activeprint.pocketwatchsoftware.com/news/2006.04.04.htm

Finally at www.print4mobile.com/Engine.htm we found a system
for printing more sophisticated database-driven report prints
which is a clear overkill for us at this stage, and still we
cannot see how they would handle the lacking mobile printer drivers...

Note:
HP has discontinued its Win Smartphone 2003SE package in late 2005:
http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=en&cc=us&prodTypeId=18972&prodSeriesId=242184&prodNameId=235049&swEnvOID=2008&swLang=8&mode=2&taskId=135&swItem=ja-36647-1

However, here's a download link:
www.yse-uk.com/download/details.php?file=37

[Mike Temporale]

I think the lack of print drivers is bigger than just the Windows Mobile arena. There's not much that can be done - PDA print drivers are still lacking.

As a solution, I would suggest sending the data to a remote server some place and have that machine print the document to whatever printer you want. This has a number of advantages, the biggest would be the that the server could buffer and spool a lot more than each device. Thus the device doesn't need to stay connected as long.

[perhagman]

Thanks for your comment Mike,

And yes - I'm sure the problem is fairly widespread, in the sense that quite a few people have posted threads relating to printing problems in diverse fora,,,

However - it goes without saying - anyone developing field-service applications for different industry/service sectors, based on either Smartphone or PDAs, would sooner or later run into the necessity of remote printing (ie. local for the worker sporting the handheld) !

A real simple case is large retailers with showroom salespeople, who might want to give a customer a slip with an article's name, number and storeroom placement -- DIY model of IKEA et al.

Obviously, other WiFi/PDA as well as PC/cash-register solutions to that scenario proliferate, but it is kind of neat to be able to provide 95% of the aspired functionality with a cheap i-Mate Smartphone (€100 or so), coupled possibly if need be with a bluetooth barcode scanner + validating stock over Gprs.

For one, the salesperson wouldn't need to lug a PDA around in addition to the ubiquitous standard cell-phone - the Smartphone fulfills both needs.

So, the webserver printing is out for some scenarios, and for others yet, there is no need for physical printouts - server-originated email or even fax-copies of e.g. passed orders suffice.

So - we must pursue the bluetooth printing idea further - and re. the size of the spooled document, we do not expect this to be a hurdle, as for the most part the portable printers would simply take a few houndred bytes of ascii-text to make up for these kinds of order-slips etc.

Right now, we will test the RepliGo avenue, but both that one and the FieldSoftware option requires a 3rd-party application to run in parallel, which (a) can be difficult to manage from our deployed C# app on the Smartphone; and (b) will at some point require user interaction, which we of course endeavor to minimize (salespeople are no IT-guys usually!)...

So - apart from the lacking Win2003SE printer drivers - if anyone has a solution to (a)+(b) whereby we could integrate the remote bluetooth printouts in our own C#-code -- please advice us !

[or direct us to a forum of specialized developers]

Cheers,
/ Per Hagman

[Mike Temporale]

let's, for a second, forget about what the rest of the world is doing.

Why does your application require that the device talk directly to the printer? Would it not be faster to have the information submitted to a server somewhere in the company and then have that server handle the print out.

In fact, I would call this method the preferred method even if your device was able to talk directly to a printer. Why not unload the processing and spooling to another faster and dedicated machine. Remember, mobile devices are not laptops. They aren't meant to replace all the functionality of a full blown machine.

Let's say your warehouse working is doing his inventory. Once he's done counting all of the Sprockets, he can select Print on his device. This will show him a list on known printers around the warehouse. He selects the one closest to his boss' desk and hits print. The application then takes the data to be printed and the printer he selected and submits that to a local server by means of a web service and the device is now finished it's job. The server then generates the print out and directs it to whatever printer was selected.

I can see numerous advantages with this design.
- doesn't require specific printers with mobile drivers
- mobile device doesn't need special drivers installed on it
- mobile device isn't wasting time connecting to a printer and attempting to spool and print a job (which requires a fair amount of memory and work if I'm not mistaken)
- printers can be updated at any time without any change to the device
- if the printer breaks, the job is spooled on a powerful server and can resume printing as soon as the printer is online. No worries about the device hanging onto the print job and that connection until the printer is fixed
...

Anyway, that's just my opinon. You can continue to spin your wheels looking for a direct printing solution, but I would much rather take this solution and enjoy the improved reliability and easy of deployment. 8)