Bug 42961

Created attachment 20536 [details]
not rendered.wmf

Attaching sample file.

Code used to test:

    File file = new File("not rendered.wmf");
    WMFRecordStore store = new WMFRecordStore();
    store.read(new DataInputStream(new FileInputStream(file)));
    WMFPainter painter = new WMFPainter(store, 1.0f);
    BufferedImage image = new BufferedImage(store.getWidthPixels(),
					    store.getHeightPixels(),
					    BufferedImage.TYPE_INT_ARGB);
    Graphics2D graphics = image.createGraphics();
    painter.paint(graphics);
    graphics.dispose();
    ImageIO.write(image, "png", new File("not rendered.png"));

Result is a PNG which is entirely transparent.

Created attachment 20537 [details]
Patch fixes the issue for this file

Wow, I didn't think it would be this simple.

WMFRecordStore line 82 was exiting the loop when recSize <= 0.	In the WMF file
I attached here, there was a record of size exactly 0.	Changing the condidion
to recSize < 0 fixes the issue.

Created attachment 20538 [details]
Another WMF that still has a problem

Patch solves about 95% of incidents but I found another eight that still fail. 
Here's one.

It seems that the new file's problem is that it contains two unimplemented
functions, META_SETSTRETCHBLTMODE and META_STRETCHDIB.

Implementing these is out of my league... feel free to split this into a
different bug if it makes more sense to do that.  I suspect the remaining files
are similar because when I look at the files, they do all contain similar
characteristics (they all contain a small image scaled to be bigger.)

LOL...

I only just realised this (because I do the diffs relative to our local branch)
that the previous fix is dependent on my fix to Bug 42479 which caused the
problem. :-)

(In reply to comment #4)
> It seems that the new file's problem is that it contains two unimplemented
> functions, META_SETSTRETCHBLTMODE and META_STRETCHDIB.
> 
> Implementing these is out of my league... feel free to split this into a
> different bug if it makes more sense to do that.  I suspect the remaining files
> are similar because when I look at the files, they do all contain similar
> characteristics (they all contain a small image scaled to be bigger.)
> 

Does your last fix fix the problem with the new file ? I understand that no.

No, my fix only solved the issue for the first file (which was in turn due to 
a fix for another bug, funnily enough.)  The second file has unimplemented 
commands in it.

(In reply to comment #7)
> No, my fix only solved the issue for the first file (which was in turn due to 
> a fix for another bug, funnily enough.)  The second file has unimplemented 
> commands in it.

The second example was incorrectly defined as text, so it seems impossible to
retrieve it as a WMF file. I tried to change its type as octet/stream, but it
does not work. Can you resubmit it as stream ? ;-)

Seems to be okay now, if I click on it, it tries to open in Paint.

(In reply to comment #9)
> Seems to be okay now, if I click on it, it tries to open in Paint.
> 

I can't open it with Paint on my PC (contrary to the first example). It says
that it is not a valid file...

Works fine here.  I don't even get a warning, it just opens quietly.  This is on
Vista, so it's possible some versions of Windows treat the file differently.

(In reply to comment #11)
> Works fine here.  I don't even get a warning, it just opens quietly.  This is on
> Vista, so it's possible some versions of Windows treat the file differently.
> 

You're right, I was trying to open it on my old Windows Me, but it works fine
with my other XP box. However, I think this is a little more difficult here:
- It will be easy to cope with the two META_STRETCHDIB and
META_SETSTRETCHBLTMODE functions, because I have already done something like
that (stretching bitmaps) for another existing function before.
- But there is another problem to cope with: the file does not have an Aldus
Header, so it will also be necessary to decode the MAPMODE, which is not done at
the moment in the code (in WMFHeaderProperties and WMFRecordStore). Also the
AbstractWMFReader will need to be slightly modified to take care of this new
case (for the moment, it assumes that the Aldus header was present).

I think I will be able to propose a patch for the end of the month, if someone
has not done it before...

(In reply to comment #12) 
> I think I will be able to propose a patch for the end of the month, if someone
> has not done it before...
> 

End of the month because I'm going to Japan for holidays tomorrow, returning
home the 17th of August ;-) 

You're right, there is no APM header... we handle these by yanking the 
viewport size out and creating a fake APM header, which works for a lot of 
pictures but sometimes produces the wrong scaling. Implementing support for 
doing it properly will certainly add time, although those of us who currently 
work around it in a shoddy way will certainly thank you. :-)

And I envy you.  I had my two weeks in Japan almost a whole year ago, and I'm 
still pining for Akihabara.

(In reply to comment #14)
> You're right, there is no APM header... we handle these by yanking the 
> viewport size out and creating a fake APM header, which works for a lot of 
> pictures but sometimes produces the wrong scaling. Implementing support for 
> doing it properly will certainly add time, although those of us who currently 
> work around it in a shoddy way will certainly thank you. :-)
> 
> And I envy you.  I had my two weeks in Japan almost a whole year ago, and I'm 
> still pining for Akihabara.
> 
OK, returned from japan (that was GREAT !!), and had time since my return a few
days ago to fix this. Since it is in my local copy, I need to sync before
sending the patch (I think it will be done before end of the week-end). I had to
fix 3 things to be able to see the image:
- implement META_STRETCHDIB
- implement META_MAPMODE (the file is in ANISOTROPIC mode)
- allow to read metafiles without APM

I just created a new bug #43194, because i think this is some "big" patch, and
it is a slightly different issue from this one. I reused your second example for
this.

(In reply to comment #16)
> I just created a new bug #43194, because i think this is some "big" patch, and
> it is a slightly different issue from this one. I reused your second example for
> this.

OK, patch uploaded for #43194, this should close this bug and the other.

Patch from bug #43194 applied.