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