libwpg-devel — libwpg development

Re: [Libwpg-devel] web pages for libwpg

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

Nice to hear you again, Smokey. You cannot imagine how much we miss you :-)

Smokey Ardisson wrote:
> Aside from stuff about creating a Universal Binary and/or targeting 
> 10.3.9 as well as 10.4, the Linux stuff should be fine for Mac OS X 
> as well; building libwpd and its dependencies is the "hard" part ;-)

This will disappear with 0.9.x, since libgsf will not be dependency 
anymore; but it is possible that libwpd will be not the same thing 
anymore either. Let's see.

> Real Mac hackers probably know those bits, too; likely even Fridrich 
> can fill in the details.

My Mac Mini is now having a break resting somewhere in a box :-)

> As I'm still on 10.3.9 and only 10.4 can build Universal Binaries, I 
> can't say with certainty, of course, but at least I can build libwpg 
> and wpg2odg (again--after some changes that went in cvs in the past 
> few days) on 10.3.9 with gcc 3.3 (despite the purported gcc 4 
> requirement), at least as a shared libs/binaries.

Actually, it builds on win32 with gcc 3.4.5 and on CentOS4 with gcc 
3.4.6, so lowering requirements could be a solution. Moreover, MSVC 6 
and higher on win32 do the job too.

> Some of the files I throw at it seem to have minor issues, but I feel 
> comfortable saying libwpg and friends build and work on Mac OS X.
> And the site looks very nice :)

Very true, indeed!

> Smokey
> (still around, just rather busy)

The introductory sentence still applies :-)

Cheers

Fridrich

Re: [Libwpg-devel] the website is live

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

Great, thanks a lot. Let me try to find a moment to blog about it. Maybe 
  some planets could relay the information.

Cheers

Fridrich

Ariya Hidayat wrote:
> Hi folks,
> 
> Since we have enough content already (some parts are missing, but we
> can fill it progressively), finally I put the website online:
> http://libwpg.sf.net.
> 
> So go and spread the words!
> 
> 
> Regards,
> 
> 
> --
> Ariya
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Libwpg-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libwpg-devel
> 

Re: [Libwpg-devel] Proposal: input stream simplification

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

Ok, so this is what I did. I declared the bitmap having 32-bit colours. 
If OOo gets such a bitmap, it expects to receive a bgra (or argb in 
little endian) colour. This means, that we are giving it all the 
information including the alpha channel in this way. Other applications, 
since the fourth byte is specified as reserved, will simply ignore the 
information. IMHO, it is OK for the while.

I implemented the embedded bitmaps in the WPGSVGGenerator class too. As 
well as in the wpg2odg's OdfExporter. I committed such a change also 
into ooo-build main trunk. And it looks like working very well :-)

On other note, I built the other day a static Qt on win32 and I built a 
completely statical perfectspot.exe (including the jpeg plugin :-) ). It 
can be tried here: http://hei.unige.ch/~strba5/ariya/perfectspot.exe

Concerning the compilation on Mac, I have a little problem, because when 
I was changing jobs, I had to bring many of my test machines (that I 
own) from my office (where there was a lot of place) to my home. Doing 
that, I had to pack out some things and it looks like I packed out also 
my KVM switch, so I am currently not able to use the Mac Mini. When I 
find the switch somewhere in a box in my cellar, I will give it a try.

Cheers

Fridrich

Ariya Hidayat wrote:
>> Stop the presses. Is WPG raster containing alpha channel, if not, it is
>> much easier to generate a normal *.bmp. I an almost having a bmp
>> generator ready :-)
> Yes, there is a possibility of alpha channel. 
> But having a BMP generator is also cool.

Re: [Libwpg-devel] Proposal: input stream simplification

[Ariya H. <ari...@gm...>]

> Stop the presses. Is WPG raster containing alpha channel, if not, it is
> much easier to generate a normal *.bmp. I an almost having a bmp
> generator ready :-)

Yes, there is a possibility of alpha channel.

But having a BMP generator is also cool.

Regards,

Ariya

Re: [Libwpg-devel] Proposal: input stream simplification

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

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

Ariya Hidayat wrote:
>> Yeah, I would still be happy if the wpg2svg was able to create a SVG
>> with embedded rasters in it (using the data uri)...
> I'm working on that. Normally we need libpng to generate the highly
> compressed PNG output, but let me try with my quick-and-dirty
> non-compressed PNG generator. I'd like also to keep the dependency
> minimum.

Stop the presses. Is WPG raster containing alpha channel, if not, it is
much easier to generate a normal *.bmp. I an almost having a bmp
generator ready :-)

Cheers

F.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGaDzYu9a1imXPdA8RAk2NAJ0e268biBDM+BDPGMUgWKpuR1ia3QCdHkzL
Hqrp+ilK84hMJ7ymDw2GwzE=
=8g3G
-----END PGP SIGNATURE-----

[Libwpg-devel] the website is live

[Ariya H. <ari...@gm...>]

Hi folks,

Since we have enough content already (some parts are missing, but we
can fill it progressively), finally I put the website online:
http://libwpg.sf.net.

So go and spread the words!


Regards,


--
Ariya

Re: [Libwpg-devel] web pages for libwpg

[Ariya H. <ari...@gm...>]

> Aside from stuff about creating a Universal Binary and/or targeting
> 10.3.9 as well as 10.4, the Linux stuff should be fine for Mac OS X
> as well; building libwpd and its dependencies is the "hard" part ;-)
> Real Mac hackers probably know those bits, too; likely even Fridrich
> can fill in the details.
>
> As I'm still on 10.3.9 and only 10.4 can build Universal Binaries, I
> can't say with certainty, of course, but at least I can build libwpg
> and wpg2odg (again--after some changes that went in cvs in the past
> few days) on 10.3.9 with gcc 3.3 (despite the purported gcc 4
> requirement), at least as a shared libs/binaries.

Thanks, Smokey. That's certainly an important information.

> Some of the files I throw at it seem to have minor issues, but I feel
> comfortable saying libwpg and friends build and work on Mac OS X.

Would it be good if you can write the details in a separate web page,
e.g. "Building for Mac OS X"? I can prepare the template and fill it
with some info from the linux page.
What do you think?

Regards,

Ariya

Re: [Libwpg-devel] web pages for libwpg

[Smokey A. <alq...@ar...>]

At 2:15 PM +0200 on 5/23/07, Ariya Hidayat wrote:

>I reckon we may need similar information for Mac OS X but then
>again, I don't have access to any Mac machine.

Aside from stuff about creating a Universal Binary and/or targeting 
10.3.9 as well as 10.4, the Linux stuff should be fine for Mac OS X 
as well; building libwpd and its dependencies is the "hard" part ;-) 
Real Mac hackers probably know those bits, too; likely even Fridrich 
can fill in the details.

As I'm still on 10.3.9 and only 10.4 can build Universal Binaries, I 
can't say with certainty, of course, but at least I can build libwpg 
and wpg2odg (again--after some changes that went in cvs in the past 
few days) on 10.3.9 with gcc 3.3 (despite the purported gcc 4 
requirement), at least as a shared libs/binaries.

Some of the files I throw at it seem to have minor issues, but I feel 
comfortable saying libwpg and friends build and work on Mac OS X.

And the site looks very nice :)

Smokey
(still around, just rather busy)
-- 
Smokey Ardisson
alq...@ar...
http://www.ardisson.org/
------------------------------------------
"He is a fool who has forgotten what became of his ancestry
seven generations before him and who does not care what will
become of his progeny seven generations after him."
           --Kazakh Proverb

Re: [Libwpg-devel] Proposal: input stream simplification

[Ariya H. <ari...@gm...>]

> > - parse from a file
> Nah, let's leave this one out, the following buffer should be enough as
> you proposed, people can read the file into memory and then use the
> buffer stuff. What we really do not want is to bloat the core libwpg
> with a lot of stream code.

OK. I'm fine if we drop this one.

> > Also, we agree that there should not be any stream implementation
> > inside libwpg. Thus, no more libwpg-stream stuff. All related stream
> > code will be placed in a separate library, which hopefully someday
> > projects like libwpd/libwps/libwhatever will (re)use. Thus, we share
> > more code and simplify matters.
>
> I don't think that I agree with this wording exactly. I would still
> leave the separation of libwpg-stream and libwpg, it would nevertheless
> be not necessary to have the libwpg-stream or even the WPXStream.h
> header to build against the libwpd.so. I committed something in this sense.

Here I was referring to the future "ideal" case (e.g. libwpg 0.2),
where you already build the separate stream library (which will be a
dependency for libwpg, perhaps also libwpd and libwps). I'm sure we
don't want to duplicate all that stream code again in libwpg
internally.

> Yeah, I would still be happy if the wpg2svg was able to create a SVG
> with embedded rasters in it (using the data uri)...

I'm working on that. Normally we need libpng to generate the highly
compressed PNG output, but let me try with my quick-and-dirty
non-compressed PNG generator. I'd like also to keep the dependency
minimum.

> I agree that we should release ASAP. Why not to go with this option:
> let us release what we have with the libwpg-stream.so and libwpg.so
> separation. It is anyway purely semantical one since it is basically the
> same whether you link against one bloated library or two smaller ones,
> with the additional benefit of having the possibility to disregard the
> stream one whenever it is not needed.

Because one good reason (IMHO): this libwpg-stream will soon disappear
tentatively for libwpg 0.2 (because by then we need your stream
library). There is no point offering some code which won't be
supported at all in the next version, nevermind that the stuff in
libwpg-stream has no direct relation to WPG format.

Granted, perhaps the application developer only needs to do simple
search-and-replace when switching from libwpg 0.1 to 0.2, but still
that's extra work.

> I really really do not like the stream internalization :-(

I know. But what I proposed is not stream internalization per se,
because there won't be any stream code inside libwpg.

> Why not? If they want to use it, it can be at their disposal.

See the above.

Side note: I'm fine if for now (version 0.1) there is no direct
support for OLE stream because Abiword uses its own stream hook (to
libgsf) and OpenOffice.org IIRC uses also its own stream code. For
others (i.e only Inkscape now), well, it's not that there is a ton of
OLE-ed WPG clip arts. And still, they can wait for 0.2.

> Concerning the stream library, I am awaiting input in terms of feature-requests. I
> think, the WPSStreamImplementation stuff can be very well put into a
> library. But there was an idea of doing an output stream interface too...

For output, perhaps:
- stream to file
- temporary file ("scratch")
- zip container

Would be fantastic if we can create ODF container using this library
(useful for stand-alone command-line tools, not for e.g.
OpenOffice.org filter)

As I wrote earlier, seems we're going to create the more-portable, C++
version of libgsf.

> This dependency is really really not a problem. Koffice already uses
> libwpd. And there is hardly any linux distro that does not have
> libwpd-0.8.x.
> If Inkscape takes a precompiled win32 binaries that we provide and uses
> the buffer approach, it will simply have no problem with any
> dependencies at all, since the WPXInputStream class is forward declared
> in the header and the buffer function will not have it in their signature.

Fair enough.

Note 1: do we still need libwpd_types.h?
Note 2: how about building on Mac OS X? any attempt yet?

> It is brain-dead easy now already, I spent some time on it to make it
> so. And that is a sacrifice, because I really hate developing on win32.

Good points. I have mingw now so I'm going to give it a try.
I know how terrible it is to hack on Win32, so thank you for that work!


Regards,

Ariya


PS: I'm not adamant to get rid of libwpg-stream. I know you must have
a very good reason to do this separation. Just please consider my
rationale above. I have no problem if we decide not to drop it, I just
want to make sure we all know the consequences.

Re: [Libwpg-devel] Proposal: input stream simplification

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

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

Ariya,

Ariya Hidayat wrote:
> The libwpg main parsing API will consist of the following three:
> - parse from an input stream
This has never been controversial anyway
> - parse from a file
Nah, let's leave this one out, the following buffer should be enough as
you proposed, people can read the file into memory and then use the
buffer stuff. What we really do not want is to bloat the core libwpg
with a lot of stream code.
> - parse from memory buffer
Yeah, this is already done.

> Also, we agree that there should not be any stream implementation
> inside libwpg. Thus, no more libwpg-stream stuff. All related stream
> code will be placed in a separate library, which hopefully someday
> projects like libwpd/libwps/libwhatever will (re)use. Thus, we share
> more code and simplify matters.

I don't think that I agree with this wording exactly. I would still
leave the separation of libwpg-stream and libwpg, it would nevertheless
be not necessary to have the libwpg-stream or even the WPXStream.h
header to build against the libwpd.so. I committed something in this sense.

> Since we desperately need a release (otherwise, more and more projects
> will have a copy of libwpd in their own tree [2]), I reckon if I
> finish implementing and testing support for raster image, we could
> call it a 0.1. It won't be perfect (no pun intended). In addition, the

Yeah, I would still be happy if the wpg2svg was able to create a SVG
with embedded rasters in it (using the data uri)...

> next version likely would break the binary compatibility because IMHO
> it's difficult to keep it as long as we want to add features (text
> support comes into mind). The API in 0.1 will not be stable anyway, we
> still don't know what others want and/or what we could squeeze more
> from the WPG format.

I agree that we should release ASAP. Why not to go with this option:
let us release what we have with the libwpg-stream.so and libwpg.so
separation. It is anyway purely semantical one since it is basically the
same whether you link against one bloated library or two smaller ones,
with the additional benefit of having the possibility to disregard the
stream one whenever it is not needed.

I really really do not like the stream internalization :-(

> So if this stream library is not available rather soon, and since
> libwpg 0.2 is going to break some things anyway, let's just make
> libwpg 0.1 very simple: no public API for stream code. The users (or
> rather, developers) that want to use libwpg must use one of three
> parsing functions above. But s/he would not get all the fancy stuff
> like WPGFileStream at his/her disposal, it's internal stuff only.

Why not? If they want to use it, it can be at their disposal. Concerning
the stream library, I am awaiting input in terms of feature-requests. I
think, the WPSStreamImplementation stuff can be very well put into a
library. But there was an idea of doing an output stream interface too...

> Designated result for 0.1:
> - no dependency on libwpd, we'll have a local copy of the abstract
> WPXInputStream

This dependency is really really not a problem. Koffice already uses
libwpd. And there is hardly any linux distro that does not have
libwpd-0.8.x.
If Inkscape takes a precompiled win32 binaries that we provide and uses
the buffer approach, it will simply have no problem with any
dependencies at all, since the WPXInputStream class is forward declared
in the header and the buffer function will not have it in their signature.

> - no public class of any stream implementations
> - building is (hopefully) very easy on Win32

It is brain-dead easy now already, I spent some time on it to make it
so. And that is a sacrifice, because I really hate developing on win32.

> Then in libwpg 0.2 we start to introduce the *dependency* to your
> stream library. This won't change the API at all (w.r.t to parsing),
> except:
> - we won't have any WPXInputStream anymore, we depend on what abstract
> class the stream library provides
> - applications (e.g. Abiword, Karbon, etc) depend on the stream
> library include file only, but they don't have to link

Here we agree completely :-)

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

iD8DBQFGVaOPu9a1imXPdA8RAop9AJwJhfFUsScQoFdpoWeMwqKfch5TVwCfV08f
/5HBUHbv2gTjSaj8py5V8EQ=
=wmPT
-----END PGP SIGNATURE-----

Re: [Libwpg-devel] Proposal: input stream simplification

[Ariya H. <ari...@gm...>]

Fridrich, regarding the stream stuff, I hope we agree on the following:

The libwpg main parsing API will consist of the following three:
- parse from an input stream
- parse from a file
- parse from memory buffer

They are of the same importance, the last two are provided only for
convenience (useful for developers who won't deal with stream
concept).

Also, we agree that there should not be any stream implementation
inside libwpg. Thus, no more libwpg-stream stuff. All related stream
code will be placed in a separate library, which hopefully someday
projects like libwpd/libwps/libwhatever will (re)use. Thus, we share
more code and simplify matters.

Now, on to the pragmatic thing. When are you going to spin off the
stream code and put it in a separate library ? [1] If this is not
going to happen soon, then I propose the following.

Since we desperately need a release (otherwise, more and more projects
will have a copy of libwpd in their own tree [2]), I reckon if I
finish implementing and testing support for raster image, we could
call it a 0.1. It won't be perfect (no pun intended). In addition, the
next version likely would break the binary compatibility because IMHO
it's difficult to keep it as long as we want to add features (text
support comes into mind). The API in 0.1 will not be stable anyway, we
still don't know what others want and/or what we could squeeze more
from the WPG format.

So if this stream library is not available rather soon, and since
libwpg 0.2 is going to break some things anyway, let's just make
libwpg 0.1 very simple: no public API for stream code. The users (or
rather, developers) that want to use libwpg must use one of three
parsing functions above. But s/he would not get all the fancy stuff
like WPGFileStream at his/her disposal, it's internal stuff only [3].
This is just fine because Abiword uses its own stream code to hook
into the parse function, so does OpenOffice.org. For others (Karbon,
Inkscape), they can choose to parse from file and/or from memory
buffer.

Designated result for 0.1:
- no dependency on libwpd, we'll have a local copy of the abstract
WPXInputStream
- no public class of any stream implementations
- building is (hopefully) very easy on Win32


Then in libwpg 0.2 we start to introduce the *dependency* to your
stream library. This won't change the API at all (w.r.t to parsing),
except:
- we won't have any WPXInputStream anymore, we depend on what abstract
class the stream library provides
- applications (e.g. Abiword, Karbon, etc) depend on the stream
library include file only, but they don't have to link

Comments? Flames? Ideas?


--

[1] Consider using Google project hosting rather than SF. Google's
infrastructure is simply faster, better, and uncluttered.
[2] And personally, I don't like KOffice 2.0 (alpha1 to be scheduled
in June) to have a local copy of libwpg at all
[3] Perhaps "stream internalization" that you don't like, but this is
temporary until the stream library is ready

Re: [Libwpg-devel] web pages for libwpg

[Ariya H. <ari...@gm...>]

> I just committed some fixes for the win32 build.

Very good. Thanks.

> MS Visual Studio:
> MinGW:

Is it possible for you to add this information to the
build_windows.htm web page? Unless I do it by myself (which I can't,
in the mean time), I don't have full confidence to write down all
these steps.

> Ariya, I would still insist on the fact that we should treat the stream
> and buffer version of WPGraphics::parse and WPGraphics::generateSVG at
> the same level of importance ;-)

I'll continue this on the original stream thread...

> And yay for hosting the api
> documentation, that is normally built if doxygen is in the path,
> somewhere. Uwog, can you try to help us with it. Moreover, once the
> regression suite exists, would be nice to have some results publicly
> accessible :-)

Fine with me.


Regards,

Ariya

Re: [Libwpg-devel] web pages for libwpg

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

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

Ariya Hidayat wrote:
> The information is mostly complete, except for building_windows.htm,
> which is about building libwpg under Windows. I hope Fridrich can fill
> some holes there, as I have no experience nor knowledge on how to do
> that. I reckon we may need similar information for Mac OS X but then
> again, I don't have access to any Mac machine.

I just committed some fixes for the win32 build.

MS Visual Studio:

Now it can build a static library and statically linked multithread (do
not ask me why, but the free as beer VS8 does not have anymore single
thread C runtimes, so multithread is a must) binaries. They build with
MSVC6 and with VS8. Their only runtime dependency is a kernel32.dll, so
they should run basically on any win32. The build is simple: use the
libwpg.dsw project file located in build/win32 and to have somewhere in
the include path <libwpd/WPXStream.h> and <libwpd/libwpd_types.h>
headers. Libwpd is not needed in the link process, so one does not
really need to build it.
The only difficulty can be that when one is building a cvs checkout, the
libwpg.h file is not existing (normally generated by the autofoo build
process at configure time). The solution is to copy the libwpg.h.in into
libwpg.h and replace the occurences of @WPG_MAJOR_VERSION@,
@WPG_MINOR_VERSION@ and @WPG_MICRO_VERSION@ with the values found in
configure.in file.

MinGW:

A static library, a DLL and statically or dynamically built wpg2raw.exe
and wpg2svg.exe can be build on win32 using gcc (MinGW). There is also
need to have pkgconfig for win32 and the above-mentioned headers. Again,
libwpd is not a dependency needed at runtime and nothing links with it,
so if one does not want to build it, it is completely ok to put the
headers and the *.pc files to a location where pkgconfig and g++ will
find them.

> I also suggest we put the API documentation online, at least for
> documentation of public classes. But we can do this later on.

Ariya, I would still insist on the fact that we should treat the stream
and buffer version of WPGraphics::parse and WPGraphics::generateSVG at
the same level of importance ;-) And yay for hosting the api
documentation, that is normally built if doxygen is in the path,
somewhere. Uwog, can you try to help us with it. Moreover, once the
regression suite exists, would be nice to have some results publicly
accessible :-)

Cheers

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

iD8DBQFGVW5iu9a1imXPdA8RAjNHAJ9z6EY0bufYRa+IoLsWMZQZ5Ry+fQCfUHFV
Irh9CFO21NzufyeTXA+aOgM=
=l4JZ
-----END PGP SIGNATURE-----

[Libwpg-devel] web pages for libwpg

[Ariya H. <ari...@gm...>]

Hi folks,

For the past few days, I have created a draft or our web pages. I put
in our CVS repository under the module libwpg-www. If everything looks
fine, we should put the pages on-line as soon as possible.

The information is mostly complete, except for building_windows.htm,
which is about building libwpg under Windows. I hope Fridrich can fill
some holes there, as I have no experience nor knowledge on how to do
that. I reckon we may need similar information for Mac OS X but then
again, I don't have access to any Mac machine.

I also suggest we put the API documentation online, at least for
documentation of public classes. But we can do this later on.

So first, please have a look at the pages. Comments and suggestions
are welcomed.

Thank you!

Regards,

Ariya

Re: [Libwpg-devel] Proposal: input stream simplification

[Ariya H. <ari...@gm...>]

Hi Fridrich,

> First of all, thanks a lot for the nice work on perfectspot. It was  a
> great experience to see commits raining into the CVS.

It's long due. Beside, I would soon need proper complex gradient
support in Qt, which is available only in Qt 4.3 (already in Beta
now), to reproduce many WPG graphics faithfully in Perfectspot.

> Now, concerning the stream implementations, I really hate to look likeld n
> an enemy of progress, but I have to expose my take on it:

On the contrary, your input is very appreciated. I doubt that someone
else has better knowledge and insights to our WPX code :-)

> 1. The reason why I made libwpg to use the WPXInputStream interface was
> that sometimes in a next feature, I would like to branch libwpd and add
> some possibility of parsing embedded pictures. This would just allow me
> to extract the subdocument as a WPXMemoryInput stream and pass the
> pointer to libwpg and grab whatever it outputs and process internally.

> 2. The other reason is that three libraries actually use something that
> could be really really the same thing: libwps uses WPSInputStream that
> is derived from WPXInputStream. I made the libwpg use the WPXInputStream
> also for maintenance reasons. In the future, I would like to have only
> one WPXInputStream implementation library for free use, so that I do not
> have to commit the same change into 2 different cvs repositories and one
> svn too :-). To have the stream the same in all three made it very very
> simply for me to integrate the wpg importer into ooo-build some two
> weeks ago and allowed me to reuse in a considerable way the
> writerperfect infrastructure.

The difference in our opinion perhaps stems from the fact that we do
not agree whether libwpg needs an input stream at all. IMHO libwpg
does _not_ necessarily need any input stream. Arguably, clip arts in
WPG format are typically quite small in size [1] and hence it is quite
sensible to load the content directly in memory and work from there.
This is different than libwpd/libwps, because a text document can be
very large and it is quite not efficient to first load everything to
memory.

As another example, in case of libwpd with embedded picture support
[2], the relevant code needs to read the block corresponds to WPG data
into memory and pass it to libwpg. IMHO it's simpler than constructing
yet another memory stream.

But even if we want to be flexible and allow input stream for libwpg,
the stream implementation itself does not need to exist in libwpg.
This is similar e.g. to zlib. It does offer API for
compression/decompression in memory and through in-out stream. But the
actual stream code is left to the application that wants to use it.

> 3. To keep the stream abstract showed itself a very good solution with
> libwpd and allowed us to have a stable libwpd API and ABI for more then
> 2 years already. I really would like to have the library itself free of
> the stream implementation if it was possible.

I guess the best choice is then to create a separate stream library
for that [3], something called FGIOSL (Fridrich's Generalized Input
Ouput Stream Library), which is quite a cool name :-)

That way, libwpg/libwpd/libwps share most of the stream code and it is
easier to handle. And while we're at that, we might want to put our
output stream related-code there as well, e.g. something for
outputting the OpenDocument container, or even just to stdout and
plain file [4].

> 4. The dependency of libwpd is true, but it is actually a dependency on
> one only header file <libwpd/WPXStream.h>. I have to fiddle more with
> the build system, because libwpd should not be necessary for the binary
> libwpd and libwpg-stream, neither should it be necessary for linking the
> libwpg and libwpg-stream. For applications that use libwpg and do not
> use libwpd (very few of them actually), putting the WPXStream.h header
> somewhere should be enough.

That is a bit hackish, though. Since libwpd (at the moment) is needed
anyway when building libwpg, application which wants to use libwpg
(e.g. Perfectspot) is likely going to just use libwpd's header.

At least, from a packager's point-of-view, it will be:
  Perfectspot depends on libwpg + libwpd
  libwpg depends on libwpd

> 5. The convenience functions can be achieved this way:
>
> parseFile(filename, &exporter) -> parse(&WPGFileStream(filename),
> &exporter);
>
> parseBuffer(buffer, length, &exporter) -> parse(&WPGMemoryStream(buffer,
> length), &exporter);
>
> Since the temporary as a parameter of the function should survive during
> the life of the function, right?

True, but that's just semantics. See my take on (1) and (2) above.

> This is my take, and as I already said, I hate to be an enemy of
> progress :-( Nevertheless, the stream internalization does not look like
> a good idea for me at this stage.

I agree with you. In case I didn't express it clearly, my proposal was
more to entirely decouple the stream implementation from libwpg, which
is along the line with what you want to achieve if we have the
specialized separate stream library.

>From here, I see the following path:

(A) Make libwpg mainly works with memory buffer. Thus, the main API will be:
        libwpg::WPGraphics::parseBuffer(const char* buffer, int
length, WPGListener*)


(B) Make it possible to use input stream, i.e. libwpg depends on
FGIOSL and offer the following.
      libwpg::WPGraphics::parseInput(const WPXInputStream* input, WPGListener*)

Point (A) covers 90% of the use of libwpg (I hope). Point (B) is for
those who want the full flexibility.

Since you might want to start branching libwpd (for libwpd 0.9?),
libwpg has no release yet, and so does libwps, wouldn't it be a good
time now to start implementing FGIOSL?


Regards,


Ariya


[1] Unless you place 5 megapixels vacation pictures inside the file,
but that'll probably only 0.01% of the case.

[2] Feel free to start the discussion in libwpd-devel about this. I'll
be happy to help. Also, perhaps we can start wpd2odt subproject as
well there?

[3] Suppose we start sharing more code between KWord/Abiword/OO, say I
split the KWord's Ami Pro filter code into libami, or we collaborate
on Ultimate RTF library, then such stream abstraction library will be
also very useful.

[4] Somehow I feel we duplicate iostream and/or libgsf here, although
it's true that both do not really fulfill such stream's library
requirements (no hard STL dependency, easy to build on Win32, ...)

Re: [Libwpg-devel] Proposal: input stream simplification

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

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

Hi Ariya,

First of all, thanks a lot for the nice work on perfectspot. It was  a
great experience to see commits raining into the CVS.

Now, concerning the stream implementations, I really hate to look like
an enemy of progress, but I have to expose my take on it:

1. The reason why I made libwpg to use the WPXInputStream interface was
that sometimes in a next feature, I would like to branch libwpd and add
some possibility of parsing embedded pictures. This would just allow me
to extract the subdocument as a WPXMemoryInput stream and pass the
pointer to libwpg and grab whatever it outputs and process internally.

2. The other reason is that three libraries actually use something that
could be really really the same thing: libwps uses WPSInputStream that
is derived from WPXInputStream. I made the libwpg use the WPXInputStream
also for maintenance reasons. In the future, I would like to have only
one WPXInputStream implementation library for free use, so that I do not
have to commit the same change into 2 different cvs repositories and one
svn too :-). To have the stream the same in all three made it very very
simply for me to integrate the wpg importer into ooo-build some two
weeks ago and allowed me to reuse in a considerable way the
writerperfect infrastructure.

3. To keep the stream abstract showed itself a very good solution with
libwpd and allowed us to have a stable libwpd API and ABI for more then
2 years already. I really would like to have the library itself free of
the stream implementation if it was possible.

4. The dependency of libwpd is true, but it is actually a dependency on
one only header file <libwpd/WPXStream.h>. I have to fiddle more with
the build system, because libwpd should not be necessary for the binary
libwpd and libwpg-stream, neither should it be necessary for linking the
libwpg and libwpg-stream. For applications that use libwpg and do not
use libwpd (very few of them actually), putting the WPXStream.h header
somewhere should be enough.

5. The convenience functions can be achieved this way:

parseFile(filename, &exporter) -> parse(&WPGFileStream(filename),
&exporter);

parseBuffer(buffer, length, &exporter) -> parse(&WPGMemoryStream(buffer,
length), &exporter);

Since the temporary as a parameter of the function should survive during
the life of the function, right?

This is my take, and as I already said, I hate to be an enemy of
progress :-( Nevertheless, the stream internalization does not look like
a good idea for me at this stage.

Cheers

Fridrich

P.S.: Ariya, I really like your work and have a high esteem of your
coding capacities (as opposed to mine). I was turning this stream issue
in my head since before the start of last year's GSoC, and have really
impression that abstracting the stream is a good solution.

Ariya Hidayat wrote:
> Hi folks,
> 
> After giving some though about input stream handling, here is my
> proposal to simplify the implementation. The objectives:
> 
> - make it very easy for developer that just wants to parse from file
> or memory buffer
> - make it possible for developer who has its own input stream implementation
> 
> The first applies to the use case to create WPG to Foo converter, e.g.
> our very own command-line converter wpg2odg. In this case, wpg2odg
> does the following:
> 
> 		OdgExporter exporter(&tmpHandler);
> 		libwpg::WPGraphics::parse(input, &exporter);
> 
> where input is an instance of FileStream (or MemoryStream, if it would
> have loaded the content first to memory), which I think could be
> simplified as:
> 
> 		OdgExporter exporter(&tmpHandler);
> 		libwpg::WPGraphics::parseFile(filename, &exporter);
> 
> or
> 
> 		OdgExporter exporter(&tmpHandler);
> 		libwpg::WPGraphics::parseBuffer(buffer, length, &exporter);
> 
> where filename specifies the filename and buffer+length specifiy the
> memory buffer.
> 
> Of course, the standard WPGraphics::parse can be still useful,
> especially for the second use case: applications which have its own
> stream handling.
> 
> In particular, for example if the next version of libwpd would support
> embedded picture in WP document, then it needs to depend to libwpg and
> should allow the listener to "capture" WPG events. However, WP
> graphics are different than WP documents. It is unlikely that the size
> of the graphics would reach e.g. 10 MB or larger. Thus, input class
> which really "streams" the data might not be needed. In short, libwpd
> can just read and load the whole picture data first, then use the
> WPGraphics::parseBuffer() above.
> 
> To clarify, here are the steps that I would like to undertake (if we
> agree on this):
> 
> (1) Integrate the stream code completely into the main parsing code.
> Thus, there is no libwpg-stream module anymore and libwpg won't depend
> on libwpd anymore.
> 
> (2) Create parseFile() and parseBuffer() convenient functions, they
> create the necessary file stream and memory stream and then call the
> standard parse() function. Thus, for those who just want to parse from
> file/memory, no need to deal with stream concept.
> 
> (3) Only make WPGInputStream public, the other stream classes
> (WPGMemoryStream/FileStream/OLEStream) are internal only because they
> are unlikely useful for others, e.g. libwpd has its own, as does OO.o.
> 
> The implications:
> 
> * there is only libwpg shared library, no more libwpg-stream
> * libwpd does not depend on any other library, including libwpd
> * filter code in OO.o/Karbon/Inkscape typically uses either
> parseFile() or parseBuffer() function
> * parse() is offered only for those who really really absolutely wants
> to handle the input stream by itself
> 
> Comments? Objections? Ideas?
> 
> 
> Regards,
> 
> Ariya
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Libwpg-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libwpg-devel

- --
Please avoid sending me Word, Excel or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGUFHgu9a1imXPdA8RAt5GAJ96zFCSP997n/T1vR5Is4kLGiJ/4QCeNCtc
RBSzr48mHOcPsqs/RDgsiZo=
=7HGo
-----END PGP SIGNATURE-----

[Libwpg-devel] Proposal: input stream simplification

[Ariya H. <ari...@gm...>]

Hi folks,

After giving some though about input stream handling, here is my
proposal to simplify the implementation. The objectives:

- make it very easy for developer that just wants to parse from file
or memory buffer
- make it possible for developer who has its own input stream implementation

The first applies to the use case to create WPG to Foo converter, e.g.
our very own command-line converter wpg2odg. In this case, wpg2odg
does the following:

		OdgExporter exporter(&tmpHandler);
		libwpg::WPGraphics::parse(input, &exporter);

where input is an instance of FileStream (or MemoryStream, if it would
have loaded the content first to memory), which I think could be
simplified as:

		OdgExporter exporter(&tmpHandler);
		libwpg::WPGraphics::parseFile(filename, &exporter);

or

		OdgExporter exporter(&tmpHandler);
		libwpg::WPGraphics::parseBuffer(buffer, length, &exporter);

where filename specifies the filename and buffer+length specifiy the
memory buffer.

Of course, the standard WPGraphics::parse can be still useful,
especially for the second use case: applications which have its own
stream handling.

In particular, for example if the next version of libwpd would support
embedded picture in WP document, then it needs to depend to libwpg and
should allow the listener to "capture" WPG events. However, WP
graphics are different than WP documents. It is unlikely that the size
of the graphics would reach e.g. 10 MB or larger. Thus, input class
which really "streams" the data might not be needed. In short, libwpd
can just read and load the whole picture data first, then use the
WPGraphics::parseBuffer() above.

To clarify, here are the steps that I would like to undertake (if we
agree on this):

(1) Integrate the stream code completely into the main parsing code.
Thus, there is no libwpg-stream module anymore and libwpg won't depend
on libwpd anymore.

(2) Create parseFile() and parseBuffer() convenient functions, they
create the necessary file stream and memory stream and then call the
standard parse() function. Thus, for those who just want to parse from
file/memory, no need to deal with stream concept.

(3) Only make WPGInputStream public, the other stream classes
(WPGMemoryStream/FileStream/OLEStream) are internal only because they
are unlikely useful for others, e.g. libwpd has its own, as does OO.o.

The implications:

* there is only libwpg shared library, no more libwpg-stream
* libwpd does not depend on any other library, including libwpd
* filter code in OO.o/Karbon/Inkscape typically uses either
parseFile() or parseBuffer() function
* parse() is offered only for those who really really absolutely wants
to handle the input stream by itself

Comments? Objections? Ideas?


Regards,

Ariya

Re: [Libwpg-devel] unit tests for WPSInputStream()

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

Andrew Ziem wrote:
> With minor changes, you can use these tests for WPSInputStream().  The 
> commented-out parts fail.   I hope the attachment works.
Hmm, my other message didn't get through.  I am writing a Works import 
filter libwps (libwps.sf.net) based on libwpd, and Fridrich Strba 
suggested I use libwpg's stream and OLE classes.   I noticed there may 
be some bugs (or, at least, strange behavior), so I wrote some tests.

Andrew

[Libwpg-devel] unit tests for WPSInputStream()

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

Hi,

With minor changes, you can use these tests for WPSInputStream().  The 
commented-out parts fail.   I hope the attachment works.


Andrew

[Libwpg-devel] grouped objects and wpg2odg

[Ariya H. <ari...@gm...>]

Hi folks,

Since the my last status report, I work on couple of things.

I managed to correctly implement support for compound polygon, which
is used when some objects are grouped together. Without proper
compound polygon support, some polygons are often placed in wrong
position.

I also started wpg2odg, i.e. the command-line tool to convert WPG
files into SVG format. So far it works for simple pictures, I'll make
sure it reaches the same level as wpg2svg. Once this wpg2odg starts to
mature, I'll implement the UNO service so importing WPG within
OpenOffice.org will be seamless.

Bitmap decoding and hopefully also text support are also in my radar.

A glance look at Microsoft Office also showed that likely libwpg can
bring better support for WPG than Microsoft Office.

For some more details and fancy screenshots, see:
http://ariya.blogspot.com/2006/07/wpg2odg-now-with-colors.html
http://ariya.blogspot.com/2006/07/wpg2odg-wpg-viewer-vs-microsoft.html
http://ariya.blogspot.com/2006/07/eiffel-in-perfection.html

As a side note, Inkscape has picked also libwpg for its WPG support. See
http://ariya.blogspot.com/2006/08/inkscape-wpg.html

Another side effect for this libwpg hacking is Perfectspot, a
Qt4-based stand-alone WPG viewer (runs both in Linux and Win32). I'll
release it later when it becomes more stable. I believe such tool can
be useful, e.g. for typical Windows user have WPG collection and would
like to contribute testing libwpg without the hassle of compiling and
building everything.

Regards,

Ariya Hidayat

[Libwpg-devel] SoC WPG: transformation and gradient

[Ariya H. <ari...@gm...>]

Hi folks,

As of today, I have already implemented support for transformed
objects and gradient fills. More information and the obligatory
screenshot can be read at:
http://ariya.blogspot.com/2006/07/beauty-is-in-smoothness-of-colors.html

Regards,

Ariya

[Libwpg-devel] SoC WPG conversion: status as of June 19, 2006

[Ariya H. <ari...@gm...>]

Hi folks,

Here's the status so far with my Summer of Code (WPG conversion filter).

I have converted all WPG1 parsing code to match the new painting
interface model. As I have written in previous progress report, the
model closely follows that of PostScript. There are two types of
functions, to change the state and to draw something. The state
functions don't draw anything and the draw functions don't change any
state.

With this, I have also merged all parsing code and committed
everything to libwpg CVS (from now on, I will not work off the CVS
anymore). My mentor, Fridrich Strba, is also continuing his work on
correcting the color palette by reverse-engineering (as the
documentation is not complete).

I'm trying to complete the object transformation (translation,
rotation, etc). I hope I can finish it (or least, part of it) within
this week. In this area, unfortunately the documentation is also
rather brief.


Thank you !

Regards,

Ariya Hidayat

PS: No screenshot this time...

Re: [Libwpg-devel] SoC WPG conversion: progress as of June 12, 2006

[Ariya H. <ari...@gm...>]

Hi Smokey,

> I just checked my WP 3.5 CD, and it seems to have 5929 WPG2 files on
> it, if nothing is lying.  They all date from 1996, so they're not
> terribly complex (in my spot-checks).

This is a very interesting collection, I must say.

> More discouragingly, though, these files were never distributed in
> the free WP-Mac download or elsewhere, so I suspect they were
> licensed to Corel and that there are restrictions on my dissemination
> of them in electronic format :-(  (And I'm not ready to part with my
> WP 3.5 license yet, nor bring the wrath of Corel on myself or
> libwp*...)

I tried to find WP 3.5 Mac on European ebays, but hardly found
anything. Beside I also don't own any Macs.

So, unless somebody else who has that WP (and does not need anymore)
gives it to me, I guess I must stay with my limited test cases so far.
Of course, when libwpg reaches a usable state, you can always
'torture' it with your collections.

Thank you.

Regards,

Ariya

Re: [Libwpg-devel] SoC WPG conversion: progress as of June 12, 2006

[Smokey A. <alq...@mi...>]

At 11:32 AM +0200 on 6/12/06, Ariya Hidayat wrote:

>Also, if someone has good collections of WPG2 files, I'll be very
>happy if I can have a look and use them for testing. WordPerfect
>Office's clipart does not contain many files and what we have in
>libwpg CVS are mostly WPG1.

I have some good news and bad news on this front.

I just checked my WP 3.5 CD, and it seems to have 5929 WPG2 files on 
it, if nothing is lying.  They all date from 1996, so they're not 
terribly complex (in my spot-checks).

More discouragingly, though, these files were never distributed in 
the free WP-Mac download or elsewhere, so I suspect they were 
licensed to Corel and that there are restrictions on my dissemination 
of them in electronic format :-(  (And I'm not ready to part with my 
WP 3.5 license yet, nor bring the wrath of Corel on myself or 
libwp*...)

Smokey
-- 
Smokey Ardisson
alq...@mi...
http://www.geocities.com/sardisson/

[Libwpg-devel] SoC WPG conversion: progress as of June 12, 2006

[Ariya H. <ari...@gm...>]

Hi folks,

Here's the status so far with my Summer of Code (WPG conversion filter).

Last week I managed to understand how to construct the cubic Bezier
curve, from the polycurve record. This was not so easy but finally I
could find that out. With support for curve, I was able to convert and
view many WPGs in the WordPerfect's clipart folder. See the result
here e.g:
http://ariya.blogspot.com/2006/06/curvey-landscape.html

I also took some time to adjust WPG1 parsing code to match the new
painting model. This is going well, so hopefully I can commit
everything that I work on so far to libwpg CVS in the next days. I
just want to complete first the handling of Bezier curve also in the
WPG1 version.

When this is done, I'll tackle again the issue with transformation
(only for WPG2) and the move on to the WPG-to-ODG task.

Also, if someone has good collections of WPG2 files, I'll be very
happy if I can have a look and use them for testing. WordPerfect
Office's clipart does not contain many files and what we have in
libwpg CVS are mostly WPG1.


Regards,

Ariya Hidayat