Fridrich Strba 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 > Thanks for the links. > 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 ;-) > Yes, one of those rejected SoC 2006 applications was mine. :) I applied to do the Apple iWorks filter, but I never heard much about why mine application wasn't accepted. I suppose I should have chose a more "killer" project like the grammar checker.
> >> 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),...). I'll see what I can do. > 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. > So, I will try to avoid breaking the API. >> * I am able to dump plain text from Works 4 and 7/8 formats. Also, I >> have some progress on page and character formats in Works 4, which is >> apparently the most popular of the Works formats. But I don't have any >> source code worth showing. >> > > Even the most ugly code that has some desired functionality is worth > showing. IMHO, technical discussions around an existing, though > imperfect, code are really useful for one's growth ;-) And I know what I > am saying when I speak about imperfect code from my own hacking > experience :-) > I'm attaching some messy, experimental code that mostly just dumps the text area from 3 Works formats. This code isn't integrated into libwps (though you can already see the copy and paste). I'll post more code later. 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
