Lovely HP Scanner

My dad has some random HP Photosmart scanner and keeps running into problems with it and ReceiptWallet. His messages imply that it is an issue with ReceiptWallet and that very well may be the case. I looked at his ReceiptWallet log today and saw:

               XResolution: 200.0000
               YResolution: 200.0000
        imageInfo:
                ImageWidth: 616
               ImageLength: 1528
           SamplesPerPixel: 3
             BitsPerSample: 5605
              BitsPerPixel: 16815
                    Planar: 0
                 PixelType: 2
               Compression: 0
got the image info 0...
setupMemXfer.MaxBufSize: 16777216
setupMemXfer.Preferred: 1048576
bytesPerRow: 0
Getting image via memory based transfer...
totalMaxDestBytes : 0
rc: 1
Got image via memory based transfer: 1

This means that the scanner says that it has 16815 bits per pixel! Most scanners do 24 bits per pixel. His scanner must be so advanced that it can capture color 800 times better than the average scanner! OK, so the scanner reported an error and somehow ReceiptWallet didn’t properly handle this (I think I fixed this). The better question is why oh why do HP scanners report bogus information? It seems like the HP scanners are the ones that randomly screw up scans the most. I worked on an issue last week with a different HP scanner doing something similar. Did I mention that the scanner logs debug message to the Console? This is very bad form in a shipping app. ReceiptWallet’s debugging information is turned on via a hidden switch and logs it to its own file to make it easier to troubleshoot. I’m hoping that someday the drivers get better.

New features for newer operating systems

I’ve written a number of times (I think) about how long should I support an older OS. I’ve also said that I’m not abandoning Tiger users, quite yet, but I may have mentioned that new features are likely going to be Leopard only as required to make things easier. In the recent past, I’ve implemented 2 Leopard only features; the first is support for Image Capture scanners. Image Capture seems like a broken framework that might be fixed someday. In the meantime, the only way for me to reliably test and get things working is to require Leopard.

The other feature (which I just finished today) is allowing a library to be encrypted. The approach I took was to create an encrypted disc image and shove everything in that. Encrypted disc images are supported on Tiger, but one of the slick features in Leopard is a sparsebundle. What is a sparsebundle? Well, it is a growable disc image that has “bands”. This means that if you modify a few files in the disc image, only the necessary bands are updated. This is absolutely necessary for backups otherwise each time a user touched a ReceiptWallet library, he’d have to backup the entire disc image (backup apps do the right thing; it isn’t a manual process to copy the bands). With one of my libraries approaching 1 GB, that would be a complete waste of time. Time Machine uses sparsebundles for the Time Capsule and if it is good enough for Apple, it’s good enough for me! So, I’ve disabled encryption on Tiger. I’m sure that some people won’t be too happy about this, but doing encryption another way would have taken significantly longer with no true reward.

Everyday, I look at the statistics I collect on what operating systems users run. The large majority run Leopard. In the graph below, you have to make one big assumptions as the data is anonymous so users that check for updates all the time (more than the default once a day) will get recorded more than once, and that is that Tiger and Leopard users check for updates at the same rate. The actual numbers are irrelevant; it is the trends I look at and the ratio of Leopard to Tiger users. The blue and red lines represent the most recent versions of Leopard.

UserData.png

Supporting ancient OS versions?

I had a user today purchase ReceiptWallet and then complain that it doesn’t work on Mac OS X 10.2.8! First off, people should download the demo prior to purchasing as I have a big “agree to this” section when purchasing that tells people to try before they buy and says we don’t offer refunds. (I did give this guy a refund as I don’t want to fight chargebacks because people can’t read.) Second off, 10.2.8 came out in October 2003! This guy said that he stays 2 OS versions back (apparently major versions). How can anyone expect developers to support such old OS versions? Apple stopped providing security updates to 10.2.8 a long time ago!

Based on usage statistics I started gathering a few months back (anonymously, of course, which requires me to make some assumptions), Leopard (10.5) users outnumber Tiger users (10.4) 4 to 1. Since ReceiptWallet uses CoreData, it requires 10.4 as CoreData was introduced in 10.4. Based on these statistics, going forward, I have to really decide if I will continue with 10.4 support. For now, I’ll keep supporting it, but some features will require 10.5 (or even 10.5.3) and higher.

Hacking ICA – NEAT Receipts scanner working with ReceiptWallet

After a lot of work today, I managed to get the NEAT Receipts scanner to work with ReceiptWallet. It wasn’t easy as there are issues with ICA and the driver that NEAT Receipts ships is quite buggy (if I tell it to scan the entire width, it fails; I have to divide by 3 to get it to work). I suspect that they just got the scanner working with their software and called it a day. Some comments in their forums seem to back this up as the scanner works quite poorly in Image Capture. I’m only going to be supporting 10.5.3 (which was just released) and higher for using Image Capture and this scanner. A large number of ReceiptWallet users are using Leopard, so this isn’t a huge problem.

I’ll be posting a beta probably tomorrow with preliminary support for the scanner. I’m sure I’ll have to keep tweaking the support when they fix/change their drivers. If you don’t have a scanner, I wouldn’t recommend their scanner as the drivers still need work; I’d recommend the Pentax DS Mobile 600 or the ScanSnap S300M. If you already have the scanner, now you can use it with a stable, mature product.

EPSON, grumble, grumble, grumble

This weekend I finally had a chance to sit down with the EPSON CX9400 I picked up on Thursday. After hours upon hours of attempting to debug ReceiptWallet and figure out the problem, I finally came up with a workaround. It appears that the EPSON TWAIN data source doesn’t close a few of its resources when the data source is closed. Then when the data source is opened again lots of stuff has taken place since the last scan potentially causing the data source to lose track of its resources (or maybe Carbon doesn’t like trying to open the same resource more than once by the same plugin). In any case, I worked around this by not closing the data source for any EPSON scanner. I really, really dislike this solution, but I went through a lot of my code and tried removing chunks to see if they caused the issue and then eventually discovered that if I started a scan, closed the scan, then showed the thumbnail view (I normally show the list view), it would crash. So all the code I tested to see if it caused the crash really led me no where.

So, this proves to me (beyond a reasonable doubt) that the EPSON scanner driver is a piece of junk and causes lots of problems for ReceiptWallet users.

While I’m beating on EPSON, I decided to grab a screenshot of their latest user interface. This is 2008, not 2000 when I bought my last EPSON scanner. Can we at least get the buttons to be nice OS X buttons and use fonts that don’t look like crap? This UI is completely unacceptable; it’s kind of interesting that the Apple store doesn’t sell any EPSON scanners or all-in-one devices (at least the online Apple store).

I recommend that Mac users stop buying EPSON devices (unfortunately I had to buy one to test) until EPSON decides to spend some money and fix the drivers. They are in such sorry shape, it isn’t even funny.