-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, good people!
I hope everybody is doing fine and looking forward to a new seasonal festivals. I am writing to you this e-mail in order to let you know what my own plans are for the next feature of libwpd and ask for your plans too. *Headers/footers* Last week as soon as SF.net graciously allowed me to do so, I committed the implementation of headers and footers for WP5 and WP3 parsers. I would like to ask kindly those that have the possibility to generate documents in the above mentioned file formats to test this feature thoroughly and report any significant problems to this list. Given that we do not know when the anonymous cvs server of SourceForge.net will again be in sync with the developer one, I created for those who would be eager to test a tarball that is at http://hei.unige.ch/~strba5/libwpd-0.8.4a/libwpd-0.8.4a.tar.gz It will work OK with a vanilla wpd2sxw 0.7.1 *Page and section margins* As I wrote in November, I have been trying to break my head and come up with an elegant way to handle page margins in WP documents. I consulted Caolán and he pointed me to some of his code in MSWord converter for OOo. The solution that I would like to propose is following: 1) Decompose the WP page margins into libwpd page margins (constant between two hard page breaks and equal to minimum margin between these two breaks) and libwpd section margins. 2) Lay out every section (single or multiple column one) as a section. This is perfectly legal in both ODT and abw file formats. The benefits would be: a) Possibility to convert correctly formatting (paragraph indents, table positions...) in multi column sections. b) Allow to implement flush right, centered on margins and other hard tabs correctly in the above mentioned multi column sections. Cons: i) Although this would not break the API, an older wpd2sxw and AbiWordperfect plugins using a new libwpd could have some margins incorrect. On the other hand, a new wpd2sxw and AbiWordperfect plug-in would do pretty well with an older libwpd (at least I would assure that the code is exactly doing this). There is a minimum version of the modification that does not require the section margins part. Simply make the libwpd page margin as mentioned above and instead the section margin, handle the second component as we do now (paragraph margins by page margin change). The only benefit of this approach would be that the "ugly line" marking the page borders would not run in the middle of the text and that the wpd2sxw and AbiWordperfect would not have to change. The other benefits would be not there and implementation of the hard tabs and other foo would be hard if not impossible in that setting (as it is hard/impossible now). So, I would like to have your input on this. I do not plan to include it in libwpd 0.8.5, but in the following version it would be nice to have. *Tabulators* Originally, I was thinking that the implementation of tabulators in libwpd 0.8.5 would be a nice thing to have, but I realize that it is about 4 months since we released libwpd 0.8.4 and thus I would like to release 0.8.5 as soon as possible and implement the tabs and (if agreed upon) the above-mentioned page/section margin split. This would allow to release in the same token wpd2sxw 0.7.2 and new AbiWordperfect that would be page/section margin ready and diminish the probability of breakages in the moment of the split. /me hopes that my English is not as bad as to prevent understanding. Please, if it is not clear, you are free to yeal at me :-) *An old mac?* I start to have quite a problem to be converting WP3 file format without being able to see the document. This file format with its "old codes" and "new codes" section in variable length functions means about two A4 sheets of hexadecimal garbage for two or three meaningful codes. As an example is the expectation-document's complex table that took about 12 A4 sheets of hexadecimal output and it was quite a pain to understand the logic. So, if you know someone who has a PPC Macintosh somewhere in his basement and wants to get rid of it, I would gladly accept the donation. It is enough to be able to run the classic environment with the different existing WP3.0-3.5e versions. If one can load MacOSX, it would be good, but just for easier network access, so it is not a must. I tried to buy a MacMini, but since they releases the Intel versions, I cannot get hold of any cheap PPC anymore. And emulators like Qemu can emulate PPC (and run a PPC linux on it), but installing MacOS is a different story. *0.9.x branch when?* I do not know when it should be, but I was just thinking that we could start to think about possible new functions in our interface classes that would break the API. Like that, once the 0.9.x branch created, we would know what to implement ;-) As for me, I have two candidates "virtual void WPXHLListenerImpl::insertField(...)" for page numbers, page counts, etc... and "virtual void WPXHLListenerImpl::insertHyperLink(...)". *Export and pictures* Since a good while, there is an issue (request for feature) filed in the OOo IssueZilla requesting a Save As WordPerfect Document feature. The discussions may appear from time to time on the #openoffice.org irc.freenode.net channel. My personal position has always been that the priority is to have a nearly perfect import and than we can start exporting. Although people argue that a basic export is better than nothing, Caolán (when I asked him) was warning that a basic export filter could become a time sink in terms of maintenance. Moreover, opening and saving a WP document without even modifying anything would result in loss of all codes that are not both in the importer AND in the exporter feature list. I can already see people who are shouting loud that the filter deleted their images, positioned boxes... I do not know what you think about it. But, I would like to know ;-) Concerning pictures, I would like to spend some time in finalizing the basic conversion of vector graphics in WPG2 and try to ask Marc I or Marc II to release an initial version so that people can start to play with it. On the other hand, more I think about it, more I think that a redesign of libwpd to include libwpg would be quite handy. For instance, the text strings inside WP Graphics are using WP document formating, charsets ... OK, this is just my opinion and I as in everything I said untill now, I might be wrong. I am copying this e-mail to the libwpg-devel list too in order to have some feedback. In a very short term, since according to the specifications, WPG is not to be embedded in an OLE stream, I was thinking to port the input and output of the libwpg from libgsf to the C++ standard library istream and ostream classes. This would diminish a set of dependencies. Your opinion? OK, I wrote more than enough. Hear from you soon Fridrich -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEO4M6u9a1imXPdA8RAkn2AJ4/V5WmNZK8TZZyFPasfWWG+7wwrACeIRsr 4O1t/ZOMOBpzSPQbG14oa9U= =/lne -----END PGP SIGNATURE----- ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Libwpd-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libwpd-devel
