Menu
▾
▴
libwpg-devel
|
From: Ariya H. <ari...@gm...> - 2007-05-20 11:54:57
|
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 |
|
From: Fridrich S. <fri...@bl...> - 2007-05-20 13:49:44
|
-----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----- |
|
From: Ariya H. <ari...@gm...> - 2007-05-21 10:50:19
|
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, ...)
|
|
From: Ariya H. <ari...@gm...> - 2007-05-24 13:47:48
|
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 |
|
From: Fridrich S. <fri...@bl...> - 2007-05-24 14:37:38
|
-----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----- |
|
From: Ariya H. <ari...@gm...> - 2007-05-25 07:37:40
|
> > - 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. |
|
From: Fridrich S. <fri...@bl...> - 2007-06-07 17:11:09
|
-----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----- |
|
From: Ariya H. <ari...@gm...> - 2007-06-07 23:41:12
|
> 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 |
|
From: Fridrich S. <fri...@bl...> - 2007-06-09 13:31:00
|
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. |
|
From: Fridrich S. <fri...@bl...> - 2007-06-09 14:00:08
|
Ariya,
Ariya Hidayat wrote:
> 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.
I am turning this since two weeks in my head, and really understand your
concerns. On my side, I would like to have the wpg2foo tools support
also the OLE2 embedded documents. Believe me, the wpg importer
integrated into stock OOo is not for tomorrow because there is a lot of
bureaucracy about including new libraries (libwps approval by Sun legal
took 6 months and I was bugging the people litterally every day) and new
features. And the add-on converter built against the SDK is using those
stream classes. And I cannot change it, because all the resources that I
use for the integrated filter stream class are not exported in the
public API :-(
There would be possibility to remove the stream abstraction in libwpg
and keep the OLE2 stuff in wpg2foo tools: make them depend on
libwpd-stream-0.8 and make them use the GSFStream class. That is the
stream class that is there for whole 0.8.x release series, but this
would mean a gsf dependency and I really feel uneasy about it.
So, if you could make me a favour and live with this situation, I would
really prefer to have in the libwpg sources a WPXInputStream
implementation that supports OLE2 embedded WPG files. It is really dead
easy to build and link with. The statical perfectspot.exe is the witness.
> 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.
Honestly, when I am turning this in my head, let us start with the input
stream class and not to focus on big constructions. An approach of 1
interface class + 1 sample fully functional implementation (with as
little dependencies as possible) would be a good start. I do not think
that I will have enough free time (and surely not the official blessing
of my employer to do it in company time) to replace libgsf :-(
> Note 1: do we still need libwpd_types.h?
Kind of. it is because of the uint8_t * output of the read function.
Since the return values are not part of a function signature, an
unsigned char * could work as well. But again, this would mean to
require a very recent version of libwpd for the WPXStream.h header
without libwpd_types.h (which is really little). I am also thinking
about removing the use of uintXY_t and intXY_t from libwpd for next
release cycle (as we do not use it in libwpg), nevertheless, given that
I spent >a month auditing libwpd code for different potential integer
issues, I really don't want to do this very quickly, because having an
advisory agains your library is quite tiring stuff, especially if many
many many people use it.
> Note 2: how about building on Mac OS X? any attempt yet?
Not yet, sorry
> 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.
I would really really like to keep it there for 0.1.x and drop it for
0.2.x. Can you live with my stubborneness?
Cheers
Fridrich
|
|
From: Ariya H. <ari...@gm...> - 2007-06-12 15:16:28
|
> Honestly, when I am turning this in my head, let us start with the input > stream class and not to focus on big constructions. An approach of 1 > interface class + 1 sample fully functional implementation (with as > little dependencies as possible) would be a good start. I do not think > that I will have enough free time (and surely not the official blessing > of my employer to do it in company time) to replace libgsf :-( I guess as a start that's already good. Feel free to create a project for that (preferably in Google Code), then I'll see what I can help to populate the implementation. > I would really really like to keep it there for 0.1.x and drop it for > 0.2.x. Can you live with my stubborneness? Yes, I believe it's fair enough. Best regards, Ariya |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X