This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libjbig2-1.6-1 does not implement JBIG2.

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
(, 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

  * 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
      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  Google has sponsored an open-source
JBIG2 encoder, see

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:

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:

libjbig2enc{DLLNUM} XXXX again, scratch that. jbig2enc builds
only a static lib. So again, no
(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. 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.

jbigkit maintainer for cygwin

-- Unsubscribe info: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]