Created attachment 37430 [details] sample1.zip hi, the attached wmf files can't display correctly. thanks.
The rendered results looks good on the trunk on my machine. Actually I think your 2.png contains an error - 2'80 is probably wrong and should be 2x80 (2*h where h = 80). Please follow the instruction link below and comment in this ticket, if it works or not: http://poi.apache.org/components/slideshow/ppt-wmf-emf-renderer.html#Instructions+to+run If it doesn't work, you can dump the wmf with the "-dump <file>" option and check the font records for the font typefaces - those should be available to your Java environment. While doing the above, I noticed that one font name seems to be erroneous read by POI and I'll check how it's read correctly. Apart of that the fonts "Times New Roman", "Symbol", "System" plus the font not correctly interpreted.
Fixed the font typeface string loading via r1881567 The charset of the font is now used to read the typeface name. Apart of that, the 宋体 font (i.e. the simsun font) was the missing font. https://github.com/sonatype/maven-guide-zh/blob/master/content-zh/src/main/resources/fonts/simsun.ttc
Created attachment 37455 [details] sample2.zip thanks every much. i found some other wmf display error. see attachment sample2.zip thanks.
sample1.zip is fixed in the nightly trunk.
Thank you for the sample2 - fixed it via r1881750 the current location is now moved to the end of the rendered string. you need to download the euclid symbol font, for the braces to be displayed proper
Created attachment 37456 [details] sample3_emf.zip
hi, same2.zip now displays ok in the nightly trunk. sample3_emf.zip contains an emf picture which throws exception with the following error: org.apache.poi.util.RecordFormatException: Undefined record of type: 2596720087 at 0 at org.apache.poi.hemf.record.emf.HemfRecordIterator._next(HemfRecordIterator.java:74) at org.apache.poi.hemf.record.emf.HemfRecordIterator.<init>(HemfRecordIterator.java:38) at org.apache.poi.hemf.usermodel.HemfPicture.getRecords(HemfPicture.java:81) at org.apache.poi.hemf.usermodel.HemfPicture.getHeader(HemfPicture.java:72) at org.apache.poi.hemf.usermodel.HemfPicture.getBoundsInPoints(HemfPicture.java:145) at org.apache.poi.hemf.usermodel.HemfPicture.getSize(HemfPicture.java:154) my code: HemfPicture emf = new HemfPicture(fis); Dimension2D dim = emf.getSize(); ... thanks.
(In reply to liming-coder from comment #7) > sample3_emf.zip contains an emf picture which throws exception with the > following error ... Easy fix ... rename it to .wmf. I've replaced the Renderer selection in PPTX2PNG based on the FileMagic via r1881838
Created attachment 37524 [details] sample4.zip hi, i've collected some wmf/emf images which also have some problems. see sample4.zip,sample5.zip. thanks.
Created attachment 37525 [details] sample5.zip sample5.zip
Applied via r1883051 EMF: workaround for invalid EMF header bounds EMF: add option to PPTX2PNG / DrawableHint to fallback to force EMF header bounds EMF: use RGB instead of HSL gradiants Subversion The offset issues in emf1 and emf2 really took me a while to figure out and now its unfortunately just a compromise/workaround which often happens to be ok. For EMFs which make use of inner window / viewport bounds to scale parts completely different to the header bounds this doesn't work and hence I've introduced another rendering hint DrawableHint.EMF_FORCE_HEADER_BOUNDS (boolean) to force the usage of the header bounds, i.e. ignore the inner bounds / records. Apart of that, I've replaced the HSL gradient calculation with RGB gradients. Although HSL looks much better - in my point of view - it looks like Powerpoint use RGB ... There are still other issues, which I hope to fix soon ... you can always test-drive the nightly for the current fix
thanks Andreas. i will try this weekend.
applied via r1883460 - close polygons - reset current path location on emf modifyworldtransform - mirror text if the AffineTransform of the graphics context is negative scaled JDKs > Java 8 don't fallback to one of the builtin fonts, if the font is not installed - *on my machine*. But I've tested on the Apache Jenkins with other environments (Java8-15) and there it seems to be ok. (to be continued ...)
Created attachment 37612 [details] 703 with latest trunk, emf in 703.zip is too small.
(In reply to liming-coder from comment #14) > with latest trunk, emf in 703.zip is too small. This is another case where the bounds inspection fails. I can render it via the flags -emfHeaderBounds or graphics.setRenderingHint(Drawable.EMF_FORCE_HEADER_BOUNDS, true); I still haven't identified a pattern when to use the emf header bounds or the window/view bounds set by the records.
Created attachment 38048 [details] 16.zip the image in 16.zip is rendered too small. poi version is 5.0.0
16.zip or its contents image68.emf is another case for the emfHeaderBounds switch. I haven't yet investigated, if I can find a pattern for deciding which method to choose ... but wanted to post this note about the switch.
add another heuristic - cumulate the bounding box of the shape records and compare it to window, viewport and emfbounds Applied via r1894176