FYI. Perhaps someone with some more technical background than I (in C/C++) might take a look at Chris' ideas on making Bibutils into a library? This could be quite important to the both OOoBib, and the evolution of free bib software.

Bruce
--- Begin Message ---
A new 3.14 release of bibutils is available:

http://www.scripps.edu/~cdputnam/software/bibutils


New from 3.12  (see 
http://www.scripps.edu/~cdputnam/software/bibutils/v3hist.html)

1.  The programs have a change in their default behavior.  I had, at
Bruce D'Arcus's request, added a default mangling of id based on which
reference it was.  However, many people, including myself, didn't
like the change.  This is now optional and needs to be turned on with
"-a" or "--add-refcount" command line option.  Additionally, with this
option on, files written by "-s" or "--single-refperfile" are properly named.

1.  copac2xml was written to convert copac format references.

2.  isi2xml has bug fixes to handle multi-author references and multi-keyword
references.

3.  end2xml has various bug fixes, including an important one where the 
reference type information was being lost (this was occuring at least from 
3.12 and possibly earlier).

4.  bib2xml now handles url entries 

5.  Some internal code reorganization that reduced code duplication
will aid in my library development (see below) and adding new formats 
for input/output.


Future:

The big change that's coming (and 3.14 is a small step towards it) is
reorganizing the code into libraries to help people plug this code into
their programs.  And as this always seems to happen, this code was
never written with this in mind, so I have a little bit of work to get there.

The core functions people will use will be like:

The bibliography being passed around is essentially a list of all references
broken down into tag/data/level triplets appropriate for my output services.
(The level bit allows for the recursive nesting of MODS XML.)  This
C struct needs to be initialized (as I'm not programming in C++ and can't
use a constructor):

void bibl_init( bibl *bin );

There will be a single function to call to read in the references.  This
function will handle which functions to use for reading/processing the
raw data.  (Internally done with function pointers--this is one of the major
steps done in 3.14 in preparation for the library generation.  There are
a couple of twists/optimizations to add to 3.14 that are clear now that
I've converted things this far.)  The mode will be one of BIBL_MODSIN,
BIBL_BIBTEXIN, BIBL_COPACIN, BIBL_ENDNOTEIN, BIBL_ISIIN, 
BIBL_RISIN, BIBL_MEDIN (for the moment).  The bibliography that
is outputted will always be in UTF8-encoded Unicode with all 
appropriate cleanups (e.g. LaTeX stuff in BibTeX) performed. 
Passed parameters are essentially giving command line information
regarding character sets and the like.  Setting to NULL will let
everything be returned in a default mode.  (I'm also considering a
flag to allow the raw tag/data from the file to be returned...the 3.14
code actually builds these things, and someone could use this
library to directly read BibTeX or RIS or the like if they wanted...they
just won't be able to nicely output it using my writing code, however...)

int bibl_read( bibl *b, FILE *fp, int mode, bibl_param *p ); 

The output will be just as simple, with modes of BIBL_MODSOUT,
BIBL_BIBTEXOUT, BIBL_ENDNOTEOUT, BIBL_RISOUT (currently).

int bibl_write( bibl *b, FILE *fp, int mode, bibl_param *p );

And of course, the C-version of a destructor to clean up memory
usage:

void bibl_free( bibl *b );

So bib2xml will look something like:

int
main( int argc, char *argv[] )
{
 bibl_param p;
 bibl b;
 int err;
 bibl_init( &b );
 bibl_initparams( &p, &argc, &argv );
 for ( i=1; i<argc; ++i ) {
  fp = fopen( argv[i], "r" );
  if ( fp ) {
   err = bibl_read( b, fp, BIBL_BIBTEXIN, &p );
   if ( err ) bibl_reporterr( err );
   fclose( fp );
  } 
 }
 bibl_write( &b, stdout, BIBL_MODSOUT, &p );
 bibl_free( &b );
}


The big issue in using the library in other projects, such as OOoBib, is
to write the glue between what I'm generating/expecting and how
bibliography information is being dealt with internally in those projects.
For this, these other projects will have to talk with me directly/write their
own stuff/etc.  Note that I'm happy to work with them to some extent
to keep my libraries from diverging from their versions of my libraries
(so we can share bug fixes, etc.).

Oh, and of course the library name will be libbibutils.a.  ;)

Have fun with the current release.

Chris.


--- End Message ---
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to