I have looked at the coding and don't see any obvious error.  Could 
you give a little more detail on the steps you have gone through 
when you encounter the problem?  The value -1 is normally returned 
in only two instances - either the document compression mode has not 
been initialized by the user, or the document argument in the call 
to xmlGetDocCompressMode is NULL.

Bill

This happens during the loading of a diagram.  These are the stages
that lead up to it:

  doc = xmlDiaParseFile(filename);

  if (doc == NULL){
    message_error(_("Error loading diagram %s.\nUnknown file
type."),filename);
    return FALSE;
  }
  
[...parse doc...]

At this point, xmlGetDocCompressMode(doc) returns -1.

Do you not set the compress mode when loading a document?  If not, the
docs should reflect this.

When I 'grep' through the source, the compression mode is actually 
contained in element "compression" within the context structure.  
This element is set by xmlSetDocCompression() and checked by 
xmlGetDocCompression().  There is no call to xmlSetDocCompression 
within the library, so I would conclude it is up to the user to take 
care of it.

If you would like to suggest an enhancement, I am sure it can be 
considered, else if you would suggest some particular document 
should be changed that can certainly be done.

Bill

Either

a) The docs (http://xmlsoft.org/library.html) should be updated to
clarify that the compression state is not set automatically when a
diagram is loaded (currently, it implies otherwise), or

b) (Better) The loader should call xmlSetDocCompression when it knows
whether the document is compressed or not.  I see in a comment in
xmlIO.c:xmlRegisterDefaultOutputCallbacks already thought a bit about
the problem of determining whether to write with compression or not. 
Instead of having to open an existing file, it'd be easier to keep the
info from loading.

Currently, it's throwing away a bit of information that's fairly
crucial to keeping the document similar to previously (important
especially for CVS users).

OK, I think I now fully understand the problem.  I'll have to do 
some further studying to find out whether (or how) the library can 
determine the compression mode of the input; if it's possible, then 
set the compression mode of the corresponding document (I'm not yet 
sure what to do with the "global" compression mode).  I'm going to 
change the severity of this bug to be a request for enhancement, 
since clearly the library does not do this at the moment.  I'll 
leave the documentation alone until this is resolved.  Thanks for 
your patience.

I have implemented some code in CVS which (I hope) will detect a 
compressed document and set doc->compression to be 9 if compressed, 
0 if not compressed, and -1 if not determined.  I tested it with 
some trivial cases, but would appreciate it if you could give it a 
more thorough test and let me know the results.

Seems fixed, if no the requested will have to report back,

Daniel

Should be fixed in libxml2-2.6.2,

  thanks,

Daniel