My recent error scenario illustrates this: my incorrectly keyed in digit string happened to not trigger a checksum error, hence was accepted by the ebanking system of my bank, but was then rejected by the destination bank because the string did not make sense to them.
In the meantime, I have hacked a kind of tool which both shortens the time I need to prepare my payments and diminuishes errorproneness,
- it selects the area to read and adjusts parameters for xsane,- increases the output of xsane by a factor of 1.5 (amazing how that reduces the errors of OCR conversion),
- submits the result to tesseract, - does some string processing,- displays the corrected and the original strings (see attachment - bad quality to limit the size of this email), ready for copy paste.
Looks very promising (and can be improved, I only spent half an afternoon) - needs now to be assessed by really using it in "production". Talking about generalisation - I see your arguments - does only make sense once that provides positive results.
Generalisation: maybe the concepts I put to work allow to create similar tools / adjust the one I have made. I live part of my time in Austria - Austrian slips should not be too difficult to handle along such lines. And, maybe the mandatory introduction of IBAN input will create an incentive to banks to improve the readability of their slips.
Juergen
<<attachment: convert.jpeg>>
