Created attachment 21747 [details] This attachment contains a WMF witha viewport width of 0 and the resulting svg images after it has been processed by a modified & unmodifed WMFTranscoder Line 118 on WMFPainter.java resets the scale based on a calculation of scale * the width in pixels / the viewport width. In the event that the viewport width is zero, division by zero occurs and a the scale is set as "Infinity." This causes lots of issues downstream and eventually the SVG file is written out with "?" in place of numbers in the <path> tags, and the SVG renders completely blank. If this line is commented out, then the SVG resembles the original WMF, except that only about half of the original content is rendered in the view port. See the attachment for the original WMF image and the resulting two SVG files.
The problem is in the big readRecords method, with the META_SETWINDOWEXT switch. A variable _bext is used to be sure that the viewPort is set only the first time. In this example, the first META_SETWINDOWEXT records all have 0 width and height. The solution is to allow to reset the viewPort after it has been set before. It is wise to also not allow to set viewPort if width or height are 0, as this is an error in the WMF File. I have applied this solution in my working copy of Batik, and it works. I will propose the (small) patch soon.
I will send a patch as soon as I can, but these lines in WMFRecordStore: if (_bext && functionId == WMFConstants.META_SETWINDOWEXT) { vpW = width; vpH = height; if (! isotropic) scaleXY = (float)vpW / (float)vpH; vpW = (int)(vpW * scaleXY); _bext = false; } should be changed to: if (functionId == WMFConstants.META_SETWINDOWEXT) { if ((width > 0) && (height > 0)) { vpW = width; vpH = height; if (! isotropic) scaleXY = (float)vpW / (float)vpH; vpW = (int)(vpW * scaleXY); } } Of course, _bext is not useful anymore. The check for width and height being greater than 0 is "just in case". There are so many faulty WMF files in the wild ;)