Bug 64716

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