Tag Archives: ReceiptWallet

Paperless in MacUpdate Promo!

Another bundle deal, another set of great apps! This time, however, Paperless (formerly ReceiptWallet), is part of the bundle. MacUpdate is offering a bunch of great apps. You’ve probably heard of most of them. This is the first time that one of my applications has been offered as part of a bundle.

I have a strange hobby of collecting software, so I’ll probably bite on this deal despite owning a few in the collection. It’s hard to go wrong for the price. If you decide to buy the bundle, click on the link on the right side of the page advertising the bundle to support my blog (running this blog isn’t free :-)).

Paperless 1.0 Shipped

Mariner Paperless (the new name for ReceiptWallet) 1.0 shipped last week! I’m quite happy to see ReceiptWallet moving forward. While this 1.0 version of Paperless has mostly cosmetic changes, I’m sure that more changes will be coming soon.

There is so much that can be done, I just didn’t have enough time to dedicate to it.

Congratulations, Mariner!

Bye, Bye ReceiptWallet

Today brings to an end my active involvement in ReceiptWallet. As readers of my blog know, Mariner Software bought ReceiptWallet. Today was the official passing of the baton. We initiated the domain transfer that could have taken up to 6 days, but within an hour, receiptwallet.com was in the hands of Mariner Software. All email, support, sales, etc. is now handled by Mariner. I’m not going away and will be available to Mariner as needed and I hope that they tap into my wealth of knowledge every now and again (I have learned something in the last 2 1/2 years of doing receipt/document management).

Now it’s time for me to close my PayPal account associated with ReceiptWallet, purge stuff off my virtual private server, and do some more housekeeping.

I’m not sure if I’m happy or sad. I have very mixed emotions; ReceiptWallet has been part of my everyday life for a long time now. I’ll no longer be answering support tickets everyday and won’t be getting the “I love your software” email messages. However, I won’t be doing support which will be a big relief. Now I have to figure out what to do with my newly found free time.

The end of an idea

Ever since the iPhone SDK came out, I had planned to write ReceiptWallet for iPhone as it seemed like a logical thing to do. A few users asked for it, so I thought it was a good idea. However, today is the day that ReceiptWallet for iPhone ends. I’ve toyed with it for the last few months, but just don’t have my heart into it as it isn’t something that I see myself using. As much as I wanted to do this product to answer the needs of the public, it just isn’t going to happen. I was going to finish it to get it out the door, but then I’d have a crappy product that wasn’t my best work.

In addition, there are some serious issues that have to be overcome before it could become usable.

First off, the camera on the iPhone can’t focus close enough to get quality images. As you can see, these pictures are awful. I’m not sure they would be acceptable for any form of documentation. (Who knows, maybe the IRS would accept something that can’t be read.)


Second off, the synchronization mechanism with the desktop would not be seamless; you would have to launch ReceiptWallet on the iPhone, click on sync and run ReceiptWallet on the desktop. Apple has not provided a plugin mechanism (like Palm did with HotSync Manager) for third parties to sync data.

Third, I’m not happy with the data entry mechanism. ReceiptWallet on the desktop uses combo boxes to allow you to type a few characters and then a dropdown menu shows everything close; nothing like this exists on the iPhone.

The future may change things with ReceiptWallet for iPhone, but ending this today takes a huge weight off my chest and will let me move on.

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
                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.