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-----