Re: Proposed package DjVuLibre

[<sourceforge at docbill dot emailuser dot net>]

> 1) The links above aren't directly to the files, they're to SF download
pages.
> I know this and you know this, but other people might not know this.

I could do that.  However, I do not know how often SF changes it's links.
It might be better to just copy them to my personal website, if you want
direct links.

> 2) The binaries do not have a ".exe" extension. This is necessary for them
> to work on Win95/98/ME so unfortunately a showstopper. :(
> (BTW, have you or anyone tested building on Win9X?) I don't want to get
you
> down, though--I definitely vote for this if the packaging issue is fixed.
> (After 3 votes you win!)

Hmm...  That seems to be the way the standard packaging scripts work.  I was
under the assumption the cygwin version of tar handled adding *.exe
extensions as necessary.  I can definitely modify the packaging script to
handle this change.  To my knowledge nobody has tried these executables
under Win9X.  However, there are several volunteers testing the executables.
I believe they are actually not using Cygwin at all.  They are just
installing the cygwin.dll and cygjpeg6b.dll's and testing directly under
Windows.

> 3) Does the GUI stuff build if the user has QT installed, or just fail, or
fail
> horribly? You might see if anyone with kde-cygwin installed can build/use
it:
> <http://kde-cygwin.sourceforge.net/> This is probably not necessary just
to
> do a Cygwin release, but it would be nice to know (maybe in README).

Actually, if both pthreads and qt options are enabled, the build succeeds
without error.  However, at runtime the executables always fail.  All
command lines fail in the pthreads library.  Based on the stack dump, it
seems like libpthread uses uname with a non-threadsafe or invalid pointer...
I haven't downloaded the pthreads source to trace the problem further.
Whether the viewer works once that problem is resolved, is an un-answered
question.  If I do at some point try and get the viewer to work, I'll
probably make that a separate binary package, so the command line utilities
can be installed without an X11 dependency.

> 4) (Also unnecesary) You might put a QUICK START on using the tools in
your
> README. Totally optional, but that's something I really like to see.

Hmmm.

> 5) I found this (in tools/*.cpp) interesting:

The licensing for DjVuLibre has been discussed a great deal.  In fact the
original statement from LT was so weak, that Richard Stallman said he
couldn't consider it open source.  However, LT's current statement is
sufficient to satisfy Richard Stallman, and Desbian.   However, when push
comes to shove developers always have to be careful about patents.  For
example the "bzz" program is a great standalone compression program, just as
good as "bzip2".  But LizardTech doesn't even own the patent, AT&T does.
And AT&T only grants rights to use the patent when it is in conjunction with
a DjVu application.   However, there isn't a single "free" binary compressor
available.  Every binary compression algorithm available has a patent, and
every patent hold places restrictions.  In the case of "bzip2" and "gzip"
the restriction is you can only use them in GPL applications.  In the case
of "bzz" the restriction is it can only be used with a "DjVu" application.

> One last thing: if I read correctly, there is currently no Free version of
> the encoder that runs on a Microsoft OS, so I definitely support making
this
> little bit of Free Software available.

That is correct.  Either Cygwin or an emulator like VMWARE is needed.  It
wouldn't take a huge effort to make a Windows version, but most of the
developers interested in doing so have their hands tied with NDA's.

                                     Bill