[hylafax-devel] Re: HylaFAX & libtiff

[Dmitry Bely <dbely@mail.ru>]

Robert Colquhoun <rjc@trump.net.au> writes:

> There  are a few of options i can think of:
> 
> 1) Leave patch as is, will require people to upgrade to 3.5.X, this will 
> require the least amount of work.
> 
> 2) Wrapper run length quantities and add some logic to configure to detect 
> different versions of the tiff library.
> 
> 3) Try and separate hylafax and libtiff a little better so that hylafax is 
> not dependent on internal libtiff routines, by far most work but probably 
> best result.

I vote for the last option. IMHO, an application should *not* depend on any
internal library functions/data. Moreover, library should be changed to
make this data inaccessible (static) from the outside to avoid similar
problems in future.

To achieve that, I think we should move G3Encoder/G3Decoder classes or
their equivalents to the TIFF library. In any case, it's wrong that Sam
created MemoryDecoder class (and me after him :-)) from scratch in any
place where he needed it (Tagline.c++, tagtest.c++, faxQueueApp.c++,
choptest.c++, FaxSend.c++, and me in FaxModem.c++ and t4test.c++) -- it
should be defined in one place and then inherited if needed. Also
G3Decoder::setRuns() should be moved to the G3Decoder constructor (see my
patch for example), and G3Decoder::lastRuns() should be private.

BTW, if you decide to apply your patch, please do not forget fo update my
patch also :-)

Hope to hear from you soon,
Dmitry



____________________ HylaFAX(tm) Developers Mailing List ____________________
 To unsub: mail -s unsubscribe hylafax-devel-request@hylafax.org < /dev/null