libwpg-devel

[Libwpg-devel] some problems with bitmaps

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

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

Hello, Ariya,

I was trying to handle the color_formats 1, 2 and 3 in WPG2. Although, I
managed to get something, I am asking whether the run length encoding
does not assume something that is true only for color format 4. Do you
think you will have some little time to look towards these two
documents? I tried, but since you coded it, you might see the solution
faster then me. Maybe the size of the white and the black runs???

Cheers

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

iD8DBQFGiZRxu9a1imXPdA8RAl96AJ9RSFpTrvMMAre8ZsPGs3ReNluVIQCcCIdL
m+Sz+JFSogKMEqM6omF3jZw=
=NO7u
-----END PGP SIGNATURE-----

Re: [Libwpg-devel] some problems with bitmaps

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

> I was trying to handle the color_formats 1, 2 and 3 in WPG2. Although, I
> managed to get something, I am asking whether the run length encoding
> does not assume something that is true only for color format 4. Do you
> think you will have some little time to look towards these two
> documents? I tried, but since you coded it, you might see the solution
> faster then me. Maybe the size of the white and the black runs???

OK. I'll have  a look, although likely I'm going to do something
useful only on the weekend. Also, if you have more variants of the
bitmaps, just send them to me. I found out with X3, it's almost
possible (or I simply miss it) to create less-than-8-bit bitmaps.

And thanks for integrating libwpd2+libwpg, that's simply awesome !


Regards,

Ariya

Re: [Libwpg-devel] some problems with bitmaps

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

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

Hi, Ariya,

Ariya Hidayat wrote:
> OK. I'll have  a look, although likely I'm going to do something
> useful only on the weekend. Also, if you have more variants of the
> bitmaps, just send them to me. I found out with X3, it's almost
> possible (or I simply miss it) to create less-than-8-bit bitmaps.

Yeah, these pictures are extracted from documents that we have in our
libwpd regression suite using an if zero-ed debug code. Now, there is
something with the line length or so in the RLE. I was just thinking
whether one could not be safer to use internally a std::vector <
std::vector < char > > to do the RLE decoding instead of having a flat
array of the size of data_size*width*height. Like this, we would even
avoid a possibility of the kind of security problems we had some times
ago in libwpd. And for std::vector < T > t, it is mandated by the
standard that if it is not empty, &t[0] points to the beginning of the
wrapped array and that this one is stored in contiguous memory space.

I would try to do something, but I guess that it would take me much more
time to go through the RLE decoding logic then it would take you :-)

Take your time, I am not rushing anything, although the Debian OOo
maintainer is breathing fire on my neck for a release of libwpg, but who
cares pushy Debian maintainers :-P

Cheers

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

iD8DBQFGi2M8u9a1imXPdA8RAhKvAJ4oYtyyM/pTgMoRq2gYOCOdyKzRxACfW/hY
lMdqVBysahLlJizgCdW65AI=
=RROi
-----END PGP SIGNATURE-----

Re: [Libwpg-devel] some problems with bitmaps

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

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

OK, I had a look today, and the problem was twofold:

1) raster length for color_depth < 4 is the width of the image in pixels
divided by the number of pixels per byte. The last incomplete byte is
padded by 0 bits.

2) depending on this, when filling the WPGBitmap class with points, we
have to keep in mind that a new scanline will start with a new byte, so
skipping anything in the previous unfinished byte is a must before we
start a new line.

In the same run, there was a problem with some of these images where we
were trying to read more bytes than the file contained because of the
fact that we were trying to read the same number of bytes as pixels in
the image, even though, several pixels do share the same byte.

This things look solved now.

Also, just for your information, a fabulous QA guy, our own AbiWord's
sum1 took hold of the new wpd2odt tool that is also calling libwpg for
the embedded graphics. This is a good news, since it can help us to have
a great quality of the library, but also a bad news, since he is able to
find a bug if it exists, so a load of work might wait for us.

Cheers

Fridrich

Ariya Hidayat wrote:
>> I was trying to handle the color_formats 1, 2 and 3 in WPG2. Although, I
>> managed to get something, I am asking whether the run length encoding
>> does not assume something that is true only for color format 4. Do you
>> think you will have some little time to look towards these two
>> documents? I tried, but since you coded it, you might see the solution
>> faster then me. Maybe the size of the white and the black runs???
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD4DBQFGkjgEu9a1imXPdA8RAijxAJiZyLZSRnuvoA0/ZZu5TheJX62jAJ9EinMW
I5HYQfXTX6BtUsjHKbh5RQ==
=8BU7
-----END PGP SIGNATURE-----

Re: [Libwpg-devel] some problems with bitmaps

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

> OK, I had a look today, and the problem was twofold:
>
> 1) raster length for color_depth < 4 is the width of the image in pixels
> divided by the number of pixels per byte. The last incomplete byte is
> padded by 0 bits.
>
> 2) depending on this, when filling the WPGBitmap class with points, we
> have to keep in mind that a new scanline will start with a new byte, so
> skipping anything in the previous unfinished byte is a must before we
> start a new line.
>
> In the same run, there was a problem with some of these images where we
> were trying to read more bytes than the file contained because of the
> fact that we were trying to read the same number of bytes as pixels in
> the image, even though, several pixels do share the same byte.
>
> This things look solved now.

Great news! I'm sorry that I didn't have time at all to look into this.

> Also, just for your information, a fabulous QA guy, our own AbiWord's
> sum1 took hold of the new wpd2odt tool that is also calling libwpg for
> the embedded graphics. This is a good news, since it can help us to have
> a great quality of the library, but also a bad news, since he is able to
> find a bug if it exists, so a load of work might wait for us.

Well, that's hardly a bad news. Fixing bugs during development is
still many times better than after it is made public.


Regards,

Ariya



>
> Cheers
>
> Fridrich
>
> Ariya Hidayat wrote:
> >> I was trying to handle the color_formats 1, 2 and 3 in WPG2. Although, I
> >> managed to get something, I am asking whether the run length encoding
> >> does not assume something that is true only for color format 4. Do you
> >> think you will have some little time to look towards these two
> >> documents? I tried, but since you coded it, you might see the solution
> >> faster then me. Maybe the size of the white and the black runs???
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
>
> iD4DBQFGkjgEu9a1imXPdA8RAijxAJiZyLZSRnuvoA0/ZZu5TheJX62jAJ9EinMW
> I5HYQfXTX6BtUsjHKbh5RQ==
> =8BU7
> -----END PGP SIGNATURE-----
>


-- 
http://www.linkedin.com/in/ariyahidayat
http://www.google.com/search?q=ariya+hidayat&btnI