Actually if a file contains an EMF or a WMF image, the image is not exported when trying to export it as PNG.
We just added a stub parser for EMF that focuses on text extraction and embedded document extraction (yes, a PDF or a WMF can be embedded in an EMF, yeeha!). Always looking for patches for rendering... If you're having problems with rendering WMF, please open a separate issue. There is support for rendering WMF. Thank you.
I can provide an example of the file I mentioned. Is it a good idea?
Sure, as long as the file is licensed under ASL 2.0 and under 1 MB (bugzilla's file attachment limit, I think), otherwise email it to the dev list or upload it to your github. It might be a while before someone has time and is interested in rendering an EMF or WMF file, but would be a fun exercise.
Merged the hemf branch via r1849040 There are still rendering issues and EMF+ is only very rudimentary implemented, but most cases of the common crawl corpus pass, so I hope it doesn't affect the next release too much. I keep the issue open while still adding functionality.
Add more records for EMF+ via r1858625 Furthermore there are now extractors method (getEmbeddings()) in HwmfPicture and HemfPicture available.
Add a few more records via r1859159
Add some EMF+ drawing methods via r1860732
Thanks to Michael Ford, who provided me a test deck with various *SL*/EMF/WMF rendering errors. Applied via r1861952 This patch contains the following fixes: * changed the EMF/WMF/ImageRenderer API to use Dimension2D instead of Dimension, to cover cases where vector graphic patterns where below 1 pixel unit * reordered image data loading in DrawPaint because EMF lazy loaded the image data and couldn't access it, when the stream was closed * reset graphic context clipping after EMF pictures were processed * inverted the logic for HSLF getForegroundColor()/getBackgroundColor() because of a bit mask handling error * partly implemented WmfDibStretchBlt * initialize the WMF viewport with the inner bounds, because some pictures in ANISOTROPIC mapping mode wouldn't be rendered correctly otherwise, i.e. either upside down or with an offset * empty clippings on WmfTextOut are now ignored * refactored the clipping handling in HwmfGraphics * handled offsets/differences of innerBounds (bounds set via WMF records) to the placeable header * Removed invalid ObjectTable marker of WmfOffsetClipRgn, WmfIntersectClipRect, WmfExcludeClipRect - they are processed immediately * PPTX2PNG output files are now 1-based, so the file index matches the -slide parameter * PPTX2PNG output file names can now be configured via -outfile and -outpat switch * XSLF shapes with a background picture defined as pic element instead of the blip properties are also handled now
fix image dimensions via r1863602
Andi, I recently dumped emf and wmf from a batch of hwp files. If you want Korean-language focused files to work with: http://162.242.228.174/share/hwp_xmfs.zip
Created attachment 36864 [details] EMF freezing Windows OpenJDK 12 The attached EMF is freezing our OpenJDK 12 build. https://builds.apache.org/view/P/view/POI/job/POI-DSL-Windows-1.12/ My first analysis is, that it is due some over-proportional AffineTransformation state (800x width/scale) and the processing of TextLayout at HwmfGraphics:488. This is somehow accepted in Linux, but the Windows font renderer freezes in this request. I think the root source is that the group records (EmfCommentDataBeginGroup/EmfCommentDataEndGroup) aren't processed/rendered at all and their bounds record would need to affect the AffineTransformation state of the graphics context.
Ok, I've fixed it locally - it was a two-liner :) in setting the window size before rendering. Before applying the patch, I need to make sure that my huge emf test set still works - IIRC I've already implemented something similar a while ago and it had side-effects. I'm also extending PPTX2PNG to allow processing files via stdin, e.g. when iterating through compressed archives.
Applied via r1869272 - extract option for embedded element in PPTX2PNG - minor GenericRecordJsonWriter fixes - fix EMF+ world transformations - fix initialization of emf pictures, which were partly unbounded -> excessive memory consumption - change EMF+ brushes to continueable record There are still wrong transformations, so shapes are misplaced ... tbc.
Applied via r1870566 - use Rectangle2D instead of Dimension2D for image bounds - fix shearing transformation - fix rendering of font attributes (bold/italic/...) - emf+: needs its own object table and properties table - emf+: add linear gradient handler - emf+: handle brush data of pens - wmf/emf/emf+: position right aligned text correctly - emf+: use emf+ instead of emf records in dual-mode - emf+: handle region data and operations correctly - emf/+: map font weight to awt font weight correctly
Created attachment 37144 [details] Sample.wmf with wrong text reference A sample wmf (which also affects EMF rendering), which causes rendering errors Applied via r1876136 - fixed WmfExtTextOut dx handling for variable text spacing - fixed WmfExtTextOut text position for (0,0) references based on the current/last path location - fixed WmfExtTextOut handling of symbol/wingdings charset (move ascii to unicode private area, because Java font loader maps the glyphs there) - and use existing workaround if the fonts aren't installed, i.e. use corresponding unicode characters of the logcial font then - provide option in PPTX2PNG to use given file input type, if the file magic is unknown - provide option in PPTX2PNG to render text as shapes in SVG, as dx handling (see above) implemented via TextAttribute.TRACKING is not supported by batik source of the sample.wmf, which I've used: https://stackoverflow.com/questions/58726194/svg-rendering-with-batik-produce-broken-image
I'm closing this issue now - further EMF/WMF rendering bugs will be treated separately.