Subject: Re: wvExporter Draft API
From: Paul Rohr (paul@abisource.com)
Date: Wed Sep 27 2000 - 17:28:53 CDT
Dom,
Thanks for sending this out. Having the APIs to review really helps.
At 02:01 PM 9/27/00 EDT, Dom Lachowicz wrote:
>I plan for the exporting API to be "use-driven" i.e. the types of calls a WP
>such as AW or KWord needs will be found in the API. This is why I'm posting
>this message here instead of the wvWare-devel list.
Cool. I agree with Martin -- a "just-in-time" use-driven approach sounds
entirely appropriate.
>Basically, this means
>that you won't have to deal with all of those nasty word structures such as
>FIB, CHP, FKP, etc...
Could you explain some more about the style of API you intend to replace
these with? From the stuff you're doing with fonts, it looks like you're
thinking of adding lots of little function calls for each formatting
primitive. However, I'm not sure what this gains us.
Currently, our Word importer does expose those "nasty word structures", so
in a quick scan of less than 900 lines of code, it's pretty easy to locate,
say, the mapping between:
AbiWord Word example
------- ---- -------
c props CHP font-weight:bold vs. chp->fBold
p props PAP text-align vs. pap->jc
section props SEP page-margin-left vs. sep->dxaLeft
This means that the API between wv and our importer can be comparatively
narrow, and it doesn't need to evolve for each and every additional property
we want to import -- we just interpret another portion of the structure and
map it to the relevant property.
I guess I was expecting export via wv to allow us to do pretty much the same
thing, only in reverse. (Insert big hand wave here.)
There's clearly plenty of Word-specific and OLE-specific crud that I'd be
more than happy to encapsulate inside wv. (For example, if we don't need to
mess with FIBs on import, we may not need direct access to them on export
either.) However, I suspect that it might be simpler to go ahead and allow
our exporter to just directly set the relevant portions of some structures
and pass them en masse, instead of introducing a whole layer of APIs to do
the same job.
I don't know exactly what the calling sequence should be, since we're
probably better off letting wv instantiate and manage those structures, but
the idea would be that we pass all the relevant properties en masse by
filling out the appropriate word structure. Thus, the job of the wv
exporter would be to produce and assemble those structures in the right
sequence to generate a valid word document.
Does the question make sense?
Paul
This archive was generated by hypermail 2b25 : Wed Sep 27 2000 - 17:22:45 CDT