lib{z|gz}. word stores some graphics compressed with lz compression,
some systems name their libz as libgz (suse linux dist) Some systems
have an old useless libz floating around their X dir which shouldn't
be there (redhat 4.2 linux and anyone who installed an old version
of plotutils using its xmkmf -a mechanism). So this will cause some
complaints from users. I have a configure script which will note
these issues for people that are using configure with wv, but that
does not include abiword I believe
later on abi will have to decide on a vector file formats for graphics,
probably something like svg ?. Anyhow word stores some of its graphics in
wmf format. I have a wmf parser and converter which I have to update, and
maybe add svg support to it. This might be something that uses libplot
as a library to convert wmf and emf into other vector formats. Currently
libwmf can only convert to gif, fig and X calls. So I foresee dependancies
on libwmf and hopefully just plotutils, but maybe also libgd. This issue is
really not much of a problem for abi as I can just hand a wmf file to abiword
and let it sort out for itself what to do with it, native mswindows draw calls
for that platform maybe and maybe a future version of libwmf for unix platforms
or something better that comes along.
At some future date I will also be moving the ole2 code over to libole2 which
the gnumeric people have been working on. Some speed increases over my own
ole hacked together nightmare, cleanly seperated Summary and DocumentSummary
access information, and save support as well to support saving word documents
for some mythical future save support.
If theres any requests for a graphic api you can mention them now. Graphics
are special characters. Both 0x01 and 0x08 chars are graphic flags. They differ
slightly but both end up embedded in the obnoxious escher file format which
requires some serious processing to get to the heart of the matter. Most
escher graphics are just jpg/png wmf etc wrapped in a bit of escher fluff,
but there is also word art and drawing primitives in their own right. Escher
is really a vector file formats itself. So eventually I might spin the escher
code off into a seperate library which will attempt to hook up with an existing
vector format implementation and output that instead. Currently I will only
output any embedded bitmat or wmf graphics found in escher (which is the
overwhelming majority of them), but the whole set of primitives will have to be
supported some day.
For now the rough and ready support looks something like this
in the spec handler for the case of a 0x01 graphic you do
case 0x01:
{
FILE *f;
Blip blip;
char *name;
long p = ftell(ps->data); /* save the data location and restore it later*/
fseek(ps->data,achp->fcPic_fcObj_lTagObj,SEEK_SET);/* go to the graphics data */
wvGetPICF(&picf,ps->data); /* get the picture header and data */
f = (FILE *)picf.rgb; /* get a FILE *pointer to the escher data */
wv0x01(&blip,f,picf.lcb-picf.cbHeader);/* parse the escher data into the blip */
name = wvHtmlGraphic(ps,&blip); /* for wvHtml I convert the data into a
fileformat that a webbrowser can see and get a filename for the graphic to
embed into the html output, abi can get a raw handle to the preparsed escher
format and currently get to the raw png/jpg etc etc data, or at a later
stage call a currently non existant wvConvertEscherToSVG(svghandle,&blip); to
suport all the drawing primitives as well as any embedded graphics*/
fseek(ps->data,p,SEEK_SET); /* restore the data stream to its orig location*/
}
The 0x08 graphic will be somewhat similar. The reason that we restore the data
stream to its orig location is because pre word8 files use the same stream for
both data and document text.
C.
Real Life: Caolan McNamara * Doing: MSc in HCI
Work: Caolan.McNamara@ul.ie * Phone: +353-86-8790257
URL: http://www.csn.ul.ie/~caolan * Sig: an oblique strategy
A line has two sides