Re: [hylafax-users] DID vs. OCR/Barcode Was: routing received faxes to clients

[Ted Egan <TedEgan@xxxxxxxxx>]

Ted Replied to All Recipients: 

In my case the problem is much more difficult.  The "clients" are directories 
on a web server, and the faxed-in documents have to be routed to the 
appropriate directory.  Further, the document must be stored in pdf format 
and a database table updated with the directory, client, pdf filename and 
document type.  

Since the main application is web-based (apache/php/mySQL on linux, or LAMP if 
you're into buzzwords) I have the luxury of forcing people to download a 
cover sheet before faxing the document.  Since I will be able to control the 
cover sheet fonts, I should be able to come up with a font that gives me a 
recognizable control number.

At least that's the plan.  There is windows-based software that can convert 
PDF to text, but not much available for linux.  If I have to, I'll hang a 
windows comptuer on the network or use Wine to handle the conversion, but 
thinking about makes me want to go hide in the nearest bar.

In response to Bill Binko who wrote on Wednesday 07 July 2004 2:31 am:


> On Tue, 6 Jul 2004, Lee Howard wrote:
> ...
>
> > So, basically for an initial investment of $500 and a monthly recurring
> > fee of less than $100 you can accomplish a very attractive solution:
> > routing faxes solely based on the number that the sender dialed.  The
> > sender can be trusted to do that, because they can dial a number
> > already as a minimum expectation.
>
> Actually, it came out quite a bit higher than that.  He currently has a
> three line hunt group that feeds into three multitech modems in a server
> that also hosts his email, database, etc.  (The additional load on the
> server is essentially zero cost at this point.)
>
> Using your numbers, to replicate that would add $400 per line for the new
> modems, plus a recurring cost of $50 per line for the DID capabilities
> plus $20ish for the block.  So it would be about $3500 the first year plus
> ~$2k each year after that.
>
> The reality (in his case) is that he's using a T1 split for voice and
> data.  When he tried to get a price on the DID, they said they'd have to
> add DID to all the voice/fax channels on the T1 (12 lines).  Now, that may
> be a marketing ploy, but it increases the cost considerably.
>
> The other issue is that he doesn't NEED some of the benefits of DID. Sure
> some of his people would like a dedicated fax number, and it would
> certainly make it easier if it just emailed it to them after the DID was
> detected.
>
> But the real reason he wants routing is to route based on content, not
> destination.  Here's the two main scenarios:
>
> First, there's new business:
>
> 1) A user decides they don't want to apply online and downloads a PDF form
> to fill out.  Ideally, they fill out the form using the PDF forms support,
> but lots of time, they fill them out by hand.
>
> 2) The form has an identifier on it that says which form it is (about 20
> forms map to the 50 states).  That id could be in a barcode form.
>
> 3) The potential customer faxes it to an 800 number that feeds the 3-line
> fax hunt group.
>
> 4) Those applications need to be routed to the people who handle new
> business.  Ideally, they'd be broken out by form or state since the people
> are distributed geographically.
>
> Right now, that sorting is done by a single resource who does it twice a
> day.  If you send that fax at 9:35am, there's a good chance noone will
> look at it until the following day.  That day costs him a great deal of
> business.  He's tweaking the scheduling, but it's a pain, and it's a
> management issue to be watching that.
>
> The second scenario is a bit more subtle: its about losing information.
>
> When he sends out letters through the fax server, we scan the PS files for
> the customer number and attach a PDF of the sent fax his customer in his
> database.  (I'm looking forward to using the built-in support for some of
> this in 4.2.0 :)
>
> When a customer faxes back a response (Usually after simply signing the
> document that was sent out), there's no way to match it to the original,
> or to automatically attach a PDF of the INBOUND fax to the customer.
>
> Embedding a barcode on the sheet they needed to sign might help this.
>
> > ...  Now, I've never used OCR, but it would seem to me that
> > the problem with OCR-based routing would be tightly tied with the
> > limitations of OCR.  (I.e., let's say the sender doesn't have ECM on
> > their fax machine, and the bar code/key routing text on the page gets
> > garbled, but not enough to trigger RTN... then your receiver will
> > respond with an MCF confirmation, and how does the fax then get
> > routed?  Or lets say the sender fed the page in crooked... can the OCR
> > software decode a crooked barcode?)
>
> I've seen some good barcode detection (albeit from Cardiff -- a pricey
> software vendor if there ever was one) that could certainly detect a 128B
> barcode even at fax resolutions (and with a skew).  That doesn't mean the
> open-source alternatives are anywhere near there... but it's not
> impossible.
>
> Also, if even 80% got routed correctly, it would help the new-business
> case considerably.  Others could be hand-routed.
>
> > I'm not trying to say that everyone is wrong for trying to do things
> > economically.  I'm not saying that there isn't a place for non-DID
> > routing mechanisms.  What I am saying is that I suspect that nine of
> > ten inbound routing mechanism needs can be satisfied best with DID, and
> > the investment in it will be well-made.
>
> I know, and it certainly is the most fool-proof solution if it fits!  I'm
> just having a hard time shoe-horning it into this particular application
> (perhaps I'm in that 10% :).
>
> > There seems to be plenty of potential, if that's what you've not been
> > able to find:
> >
> > http://jocr.sourceforge.net/
>
> This is where I think there's the most potential.  GOCR is fairly stable
> and well-deployed.  Now that they have barcode support, perhaps there's a
> solution buried in there.
>
> > http://barcode.sourceforge.net/
>
> This seems to be an invenvtory system using barcode scanners.
>
> Anyway, I'll make sure that if I find a solution, I'll post it back.
>
> Thanks for the thoughts,
>
> Bill

-- 
/*************************
*
*  Ted Egan
*  (239) 593 3677 (voice)
*  (239) 596 4640 (fax)
*
**************************/

____________________ HylaFAX(tm) Users Mailing List _______________________
  To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
 On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
  *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*