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. 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. :) -- William Lachance [EMAIL PROTECTED] ------------------------------------------------------------------------- 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 http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Libwpd-devel mailing list Libwpd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libwpd-devel
