[hylafax-devel] Re: CVS update (was: Sendproblem ...)

[Dmitry Bely <dbely@mail.ru>]

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

> > > > It's not just the class 2.0 modems - hylafax has been sending tiff files
> > > > with included RTC to the ordinary class 2 modems as well.
> > >
> > > Only when using buggy Ghostscript. AFAIK Sam Leffler originally used other
> > > Postscript rasterizer (by SGI) which did not append that wrong extra
> > > RTC. And all Class2 modems he tested worked for him. Ask also Harald
> > > Pollack -- he does not append RTC in his fax program, and all
> > > Class2/Class2.0 modems still work (except USR which is the special
> > > case). What else proof do you need?
> >
> >I still have no response from you (just wonder how long are you going to be
> >"nervous" :-) Darren would say "... this is not a productive attitude" :-)))
> 
> Sorry i can only do hylafax in my spare time which i have very little(i 
> just spent most of sunday at work :-( )

I see. I'll try to ask Darren (you know ... :-)))

> >I have many other changes/additions waiting -- e.g. now almost all modems
> >(including USR) should work with default setting even without *any* Modem*
> >and Class* entries in the config.<modem>, and all these "right config file"
> >and "supported modems" talks among newbies may become a history soon
> >(although it's still possible to break anything editing config files :-)).
> >Also some nasty bugs in Class1 driver have been fixed, and maybe something
> >else that I've forgot to mention.
> 
> ...i guess you better send the patches

Will be done soon -- I just have to write "whatsnew" and split changes as
you like.

> >  But if the RTN patch still
> >has not approved ...
> 
> It still has issues - i was looking at the way the tiff file is fixed in 
> correctPhaseCdata(), just after you decode it hylafax runs through the
> data

I don't walk through *all* file -- just 20 bytes in the very end:

[---cut---]
    /*
     * We expect RTC near the end of data and thus
     * do not check all image to save processing time.
     * It's safe because we will resync on the first
     * encountered EOL.
     *
     * NB: We expect G3Decoder::data==0 and
     * G3Decoder::bit==0 (no data in the accumulator).
     * As we cannot explicitly clear the accumulator
     * (bit and data are private), cutExtraRTC()
     * should be called immediately after
     * MemoryDecoder() constructing.
     */
    const u_long CheckArea = 20;
    if( cc > CheckArea ){
        bp += (cc-CheckArea);
        cc = CheckArea;
    }
[---cut---]

So it does not require much time.

> again to fix up the DLE's - it would be nice if there was only one pass 
> through the file. ie start decoding fix up first eol, continue decoding 
> fixing up dle's and finish up by trimming any extra rtc's.

Inserting extra DLE is very easy task and also requires almost no
time. Remember, the whole bitmap is already in the memory buffer when we do 
all this...

> >In the meantime find configure patch attached, which enables CVS Hylafax to
> >build with both libtiff 3.4 and 3.5 (tiff_runlen_t is autodetected).
> >It's essential for me, because I still use libtiff 3.4.
> 
> Darren added this, thanks.

Hope to hear from you soon,
Dmitry



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