libwps-devel — libwps development

Re: [libwps-devel] Generalizing WPXInputStream::getDocumentOLEStream()

[Andrew Z. <ah...@ma...>]

> Along the lines of making it ready for consumption, I added plain text 
> support for Works 8 format, so the code should generally be ready for 
> users.  One exception is it doesn't handle Works 2000 (v5) which, unlike 
> other Works format, appears to be using encapsulated RTF.
>   
After another look, the RTF appears to be junk that should not be in the 
file, so a Works 2000 should not need to understand the RTF.  Actually, 
the Works 2000 format looks a lot like Works 8 format.


Andrew

Re: [libwps-devel] Generalizing WPXInputStream::getDocumentOLEStream()

[Andrew Z. <ah...@ma...>]

Fridrich Strba wrote:
>> If you don't like that, how about keeping the old method, adding a new
>> method, and the old one calls the new method?
>> WPXInputStream * GSFInputStream::getDocumentOLEStream()
>> +WPXInputStream * GSFInputStream::getDocumentOLEStream(char * streamName)
>>     
>
> This looks a bit more feasible and if there is no other way, I could be
> convinced by some boxes of coca light lemon to do it (I do not drink
> alcohol :-) ).
:)

> Nevertheless, I would advice you to inspire yourself as
> well from the stream class in libwpG
> (http://sourceforge.net/projects/libwpg/). It uses for getting the ole
> stream a nice neat (OK, it was neat before I hacked it a bit) C++
> library POLE written by hacker extraordinaire Ariya Hidayat :-). The
> advantage of this OLE implementation is that you do not need more than
> the C++ STL library to compile and to run. It means that the dependency
> on libgsf, glib & Co. is not there anymore. Believe me, this is making
> the things much easier on Win32.
> I am even contemplating to ditch out the gsf dependency from the stock
> libwpd for 0.9.x. Moreover, AbiWord CVS HEAD has the stream class
> implemented internally and does not use libwpd-stream, because of some
> problems on win32.
>   
For now, I'd like to keep basic code in sync with libwpd, so I'll wait 
for libwpd to make any stream changes and then copy them.

Along those lines, I introduced a dependency on iconv to translate 
UTF-16 to UTF-8 for the Works 8 format.  (I'm guessing that Works 8 uses 
UTF-16.  I haven't tested it much yet, but it is double byte.)  Do you 
think that would be a porting problem?
>> In this phase, libwps is still a patch on libwpd.   It makes it easy to
>> test libwps by just patching the libwpd.so and then running
>> OpenOffice.org, Abiword, and KWord.   Actually with this small change,
>> Abiword accepts .wps documents (if they are renamed to .wpd).  However,
>> OpenOffice.org would need the equivalent change to its
>> getDocumentOleStream() here, and then it could use that code for both
>> libwps and libwpd.
>>     
>
> This is a good scenario for the beginning. Nevertheless, it is
> preferable to make a separate library even if it depends for certain
> things on libwpd's public API. 
I'm working towards that.  Per your comment below, I did remove the 
WP[0-9]*{cpp,h} files which were specific to WordPerfect.  Next, I'm 
going to just rename the compiled library.   Is there a rule or 
convention for the .so numbers?  If I make the release libwps 0.1, the 
library is libwpd-0.1.so.1.0, and I change the .so number with API changes?
> This could allow you to build your own
> wps2raw, wps2html and wps2text for testing. This would also allow you to
> use the writerperfect code to make your standalone wps2sxw and
> wpsimporter UNO component for OOo 2.x. Again, here, you might get
> inspired from wpg2odg from libwpg's web-site that uses a lightweight
> femtozip library to write the zipped odg files. This would allow you to
> have it all compiled using only the standard library.
>   
I'll look.
>> BTW, the Works 3/4 format file filter is coming along and understands a
>> good amount of formatting.   It's available from SVN at
>> http://libwpd.sourceforge.net .  If you don't mind, I might release a
>> modified libwpd RPM for people to try.  (It would be labeled unofficial
>> and experimental.)
>>     
>
> Please, do _not_ do that. To have different unofficial libraries in the
> wild would just not be the best idea. 
OK.
> Just follow the advice above and
> we will get really soon some publicity. I promis to blog about it so
> that OOo and AbiWord hackers/users (does AbiWord have users? :-P) can
> test it thoroughly. This way we might have usable GNU/Linux and Win32
> binaries quite quickly.
>   
Thanks for the help.   I would not suggest it to users until there are 
easy-to-install binaries for Windows and probably Linux too, but I am 
looking forward to exposing it to hackers, then getting some binaries 
(probably AbiWord), and finally showing the users. 

Along the lines of making it ready for consumption, I added plain text 
support for Works 8 format, so the code should generally be ready for 
users.  One exception is it doesn't handle Works 2000 (v5) which, unlike 
other Works format, appears to be using encapsulated RTF.

By the way, I thought a web-based conversion service would be nice.  It 
could use the command line tools to make HTML or SXW.   But I may not 
have time to develop it and maintain it. 
> BTW, you really do not need all the WP1 WP3 WP42 WP5 and WP6 parsing
> code in your SVN ;-)
One step at a time.  :)



Andrew

Re: [libwps-devel] [Libwpd-devel] Generalizing WPXInputStream::getDocumentOLEStream()

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello, Andrew,

Excited to see the advance in your coding.

Andrew Ziem wrote:
> Would it be possible to make a change to
> WPXInputStream::getDocumentOLEStream() to include a parameter for the
> name of the stream?   It would make the class more generic.  As far as I
> can tell, this is the only change that libwps requires to share basic
> code with libwpd.  The change is basically (full patch attached):
> -WPXInputStream * GSFInputStream::getDocumentOLEStream()
> +WPXInputStream * GSFInputStream::getDocumentOLEStream(char * streamName)

As you rightly assume lower, this is not possible. Adding the parameter
to this function would simply break the ABI and that is what we do not
want to do at all at this stage.

> If you don't like that, how about keeping the old method, adding a new
> method, and the old one calls the new method?
> WPXInputStream * GSFInputStream::getDocumentOLEStream()
> +WPXInputStream * GSFInputStream::getDocumentOLEStream(char * streamName)

This looks a bit more feasible and if there is no other way, I could be
convinced by some boxes of coca light lemon to do it (I do not drink
alcohol :-) ). Nevertheless, I would advice you to inspire yourself as
well from the stream class in libwpG
(http://sourceforge.net/projects/libwpg/). It uses for getting the ole
stream a nice neat (OK, it was neat before I hacked it a bit) C++
library POLE written by hacker extraordinaire Ariya Hidayat :-). The
advantage of this OLE implementation is that you do not need more than
the C++ STL library to compile and to run. It means that the dependency
on libgsf, glib & Co. is not there anymore. Believe me, this is making
the things much easier on Win32.
I am even contemplating to ditch out the gsf dependency from the stock
libwpd for 0.9.x. Moreover, AbiWord CVS HEAD has the stream class
implemented internally and does not use libwpd-stream, because of some
problems on win32.

> In this phase, libwps is still a patch on libwpd.   It makes it easy to
> test libwps by just patching the libwpd.so and then running
> OpenOffice.org, Abiword, and KWord.   Actually with this small change,
> Abiword accepts .wps documents (if they are renamed to .wpd).  However,
> OpenOffice.org would need the equivalent change to its
> getDocumentOleStream() here, and then it could use that code for both
> libwps and libwpd.

This is a good scenario for the beginning. Nevertheless, it is
preferable to make a separate library even if it depends for certain
things on libwpd's public API. This could allow you to build your own
wps2raw, wps2html and wps2text for testing. This would also allow you to
use the writerperfect code to make your standalone wps2sxw and
wpsimporter UNO component for OOo 2.x. Again, here, you might get
inspired from wpg2odg from libwpg's web-site that uses a lightweight
femtozip library to write the zipped odg files. This would allow you to
have it all compiled using only the standard library.
I subscribed the lib...@li... and promis to even
with a standalone wpsimporter for OOo 2.x

> BTW, the Works 3/4 format file filter is coming along and understands a
> good amount of formatting.   It's available from SVN at
> http://libwpd.sourceforge.net .  If you don't mind, I might release a
> modified libwpd RPM for people to try.  (It would be labeled unofficial
> and experimental.)

Please, do _not_ do that. To have different unofficial libraries in the
wild would just not be the best idea. Just follow the advice above and
we will get really soon some publicity. I promis to blog about it so
that OOo and AbiWord hackers/users (does AbiWord have users? :-P) can
test it thoroughly. This way we might have usable GNU/Linux and Win32
binaries quite quickly.
BTW, you really do not need all the WP1 WP3 WP42 WP5 and WP6 parsing
code in your SVN ;-)

Cheers

Fridrich
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org

iD8DBQFE++jzu9a1imXPdA8RAr6BAJ4sRaXBEuWsCFlLJN+IhaAd4GKQJACeKYE+
CTQys4q+HrMya/MPosjLUi8=
=HJUK
-----END PGP SIGNATURE-----