libjbig2-1.6-1 does not implement JBIG2.

[Charles Wilson]

LIM Fung-Chai wrote:
> In a way, this is a bug report of sort, for the cygwin jbigkit maintainer.

Not a bug.

> The libjbig2 cygwin package is built from the upstream jbigkit package
> (http://www.cl.cam.ac.uk/~mgk25/jbigkit/), which implements a codec
> adhering to the JBIG1 standard.  The "2" in libjbig2 gives the
> impression that it supports the JBIG2 format, 

You infer where I did not imply.

> which, being newer than
> JBIG1, gives better compression than JBIG1.  It should have retained
> the older moniker "libjbig1".

No, it should not have retained the old number; your impression is 
wrong: the "2" is a DLL API version number, not a format version number. 
  If I didn't change the DLL API version number when the API was, in 
fact, changed in a backwards-incompatible way, then existing 
applications would break.  The API change was described in the release 
announcement

http://cygwin.com/ml/cygwin-announce/2006-11/msg00048.html

   * Bump DLL number because upstream API changed:
      "minor API modification in jbg_enc_options(): parameter l0 changed
      from type long to unsigned long; previous value now remains
      unchanged when l0 == 0 (was: l0 < 0)"

Existing client code MAY have, in the past, tried to pass negative 
values in position #10 to jbg_enc_options() since that was a "change the 
other encoding options but do not change #10".  However, with this API 
change those existing calls with parameter #10 < 0 would get silently 
reinterpreted as "parameter #10 is a really big number" and WOULD cause 
the corresponding jbg_enc_option to be changed.

Therefore, old code should not use the new DLL without recompiling -- 
and the only way to force that to happen is to change the DLL name. 
(And, old client code that relied on the "negative value means don't 
modify" behavior would elicit a warning message during the recompile, so 
that's good too).

So, we've established that:
   (1) this is an incompatible API change

   (2) on windows, we change the DLL name when the API changes, by 
incrementing the API version number.

     cygjbig1.dll -> cygjbig-2.dll

(The hyphen was because jbig-1.6's build process now uses libtool, and 
the libfoo-${DLLNUM}.dll pattern is libtool's naming convention.  I 
trust you're not going to try to argue that
    cygjbig1.dll -> cygjbig-1.dll
is somehow *less* confusing?  And if so, then how would the two cygwin 
packages containing those DLLs be named?  And what of the NEXT 
incompatible API change in jbigkit -- what should THAT dll and package 
be named?)

   (3) the cygwin packaging scheme requires that, for a DLL named
         'cyg{PKG}-{DLLNUM}.dll' or 'cyg{PKG}{DLLNUM}.dll'
       the package containing that DLL should be named
         'lib{PKG}{DLLNUM}'
       which, in this case, is libjbig2.

       (Now you see the problem with cygjbig1.dll -> cygjbig-1.dll.
       Both DLLs *should* go into a package named "libjbig1".  That's
       a problem.)

If that conflicts with some other package NOT currently part of the 
cygwin official distribution, nor even proposed for official inclusion, 
and whose source code has been downloaded from sourceforge by all of 250 
people in the entire world, and perhaps confuses someone who didn't read 
the release announcement first...

well, that's not a problem I can solve.

> FYI: An open-source implementation of a JBIG2 decoder is part of the
> ghostscript project and is described in
> http://jbig2dec.sourceforge.net/.  Google has sponsored an open-source
> JBIG2 encoder, see http://www.imperialviolet.org/jbig2.html.

If someone were to propose a JBIG2 package for official inclusion, I 
would suggest the following naming scheme for the packages:

The jbig2dec package builds a library named "libjbig2dec" not 
"libjbig*", so:

    jbig2dec
    libjbig2dec-devel
    libjbig2dec{DLLNUM}    XXXX scratch that, jbig2dec doesn't build
                                as a shared library anyway; it's static
                                only.  So there's no conflict here.
(And, even if jbig2dec DID build a shared library, package name 
"libjbig2decX" doesn't conflict with package name "libjbig2" anyway.)


The jbig2enc package builds a library named "libjbig2enc" not 
"libjbig*", so:

    jbig2enc
    libjbig2enc-devel
    libjbig2enc{DLLNUM}    XXXX again, scratch that.  jbig2enc builds
                                only a static lib.  So again, no
                                conflict.
(And, even if jbig2enc DID build a shared library, package name 
"libjbig2encX" doesn't conflict with package name "libjbig2" anyway.)



So, as there is no technical conflict nor any true packaging conflict, 
the ONLY concern here is that some people might be confused by the name 
of the package containing cygjbig-2.dll, libjbig2-1.6-1.

Uhmmm...how shall I put this?  Solving that "problem" rates lower on my 
priority list than organizing my collection of pocket lint.  I've 
already spent all the time I'm willing to devote to that issue, 
composing this email.

--
Chuck
jbigkit maintainer for cygwin


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/