[Libwpg-devel] Future plans?

[Fridrich S. <fri...@bl...>]

-----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 committ=
ed
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 th=
at
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 woul=
d
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 consult=
ed
Caol=C3=A1n 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 thes=
e
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, ta=
ble
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-i=
n
would do pretty well with an older libwpd (at least I would assure th=
at
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 hav=
e.

*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 t=
o
release 0.8.5 as soon as possible and implement the tabs and (if agre=
ed
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 no=
t
as bad as to prevent understanding. Please, if it is not clear, you a=
re
free to yeal at me :-)

*An old mac?*

I start to have quite a problem to be converting WP3 file format with=
out
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 a=
n
example is the expectation-document's complex table that took about 1=
2
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, i=
t
would be good, but just for easier network access, so it is not a mus=
t.
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 coul=
d
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, w=
e
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 t=
he
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=C3=A1n (when I asked him) was warning that a basic expo=
rt
filter could become a time sink in terms of maintenance. Moreover,
opening and saving a WP document without even modifying anything woul=
d
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 th=
e
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 pla=
y
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 instan=
ce,
the text strings inside WP Graphics are using WP document formating,
charsets ... OK, this is just my opinion and I as in everything I sai=
d
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 n=
ot
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 opin=
ion?


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=3D
=3D/lne
-----END PGP SIGNATURE-----