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."
Andrew ------------------------------------------------------------------------- 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
