William Lachance wrote:
> On 8/18/06, Fridrich Strba <[EMAIL PROTECTED]> wrote:
>> Andrew Ziem wrote:
>> > I have started* a Microsoft Works (.wps) document importer.  Since
>> > libwpd has been incorporated into three word processors, I thought I'd
>> > emulate the libwpd API to make it easy to implement support for Works.
>> Very wise approach :-) It goes in line with Will's vision from this
>> e-mail
>> http://lists.ximian.com/pipermail/openoffice/2004-October/000556.html
>> and with an approach that I was trying to urge the OOo Google SoC
>> mentors to consider
>> http://sw.openoffice.org/servlets/ReadMsg?list=dev&msgNo=1241
>> Unfortunatelly, due to a low number of slots allocated to OOo, none of
>> the "Text importer" projects went through for SoC 2006, as you may know
>> :-( So, I am glad to see you in the "Text importer" universe again ;-)
>> > Then, it was necessary or convenient to copy and paste libwpd's source
>> > code.  Now, I'm seeing there is a lot of copying, pasting, and 
>> renaming
>> > strings like "WP" to "WPS."  To avoid forking what has turned out 
>> to be
>> > an increasing amount of  code, any thoughts on consolidating efforts?
>> Yes, copy&paste == evil. Andrew, quick look at our API would suggest
>> following: Do not copy anything. Just for the time being make depend the
>> libwps on classes from libwpd public headers (WPXProperty* family
>> classes, WPXString, WPXHLListenerImpl (and eventually WPXInputStream)
>> interface class(es),...). It is quite possible that one could extract
>> the framework for the next ABI breakage from the libwpd-0.8.so into a
>> separage libwpd-framework-0.9.so, but as far as I am concerned, my todo
>> list is still long enough and the libwpd API is written in written in
>> stone for at least 1 year more. I have some ideas for API changes for
>> next release cycle of libwpd (like removing completely the libgsf
>> dependency from the provided stream implementation, some changes
>> concerning the page spans and adding callbacks for embedded objects...)
>> but I do not want to touch the API as long as I have still non-breaking
>> changes in my todo list.
> I think Fridrich is on the right track here. Basing a filter off of
> the WPX* framework would allow you to abstract away much of the
> low-level ugliness of the .OOT format, and would potentially pave the
> way towards sharing the work with KWord and AbiWord as well.
> Being able to create a document as follows:
> m_listenerImpl->startDocument();
> m_listenerImpl->openPageSpan(..);
> m_listenerImpl->openSection(..);
> m_listenerImpl->openParagaph(..);
> m_listenerImpl->openSpan(..);
> m_listenerImpl->insertText(..);
> ..
> .. beats writing out a whole bunch of XML by hand, IMO. 
Yes.  It would save me and others effort to use the existing framework.
> Of course,
> there is the problem of figuring out how to properly factor all this
> into a seperate library (libtextdocumentfilter?), which I don't really
> have time to describe in detail right now. If people are really
> interested in going in this direction, I could write a specification
> on how I envision this working. Be warned: implementing the
> specification would probably be a fair amount of work. :)
Is this labor-intensive factoring actually required to start the Works 
filter?  By building Works on top of libwpd, my goal was to save "a fair 
amount of work." :)  Also, you could keep the existing name "libwpd" by 
just redefining "wpd" to mean "word processor document." 


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
Libwpd-devel mailing list

Reply via email to