Bug 64716 - wmf display error
Summary: wmf display error
Alias: None
Product: POI
Classification: Unclassified
Component: XSLF (show other bugs)
Version: 4.1.2-FINAL
Hardware: PC Mac OS X 10.1
: P2 normal (vote)
Target Milestone: ---
Assignee: POI Developers List
Depends on:
Reported: 2020-09-08 00:03 UTC by liming-coder
Modified: 2021-10-12 22:31 UTC (History)
0 users

sample1.zip (35.63 KB, application/zip)
2020-09-08 00:03 UTC, liming-coder
sample2.zip (234.99 KB, application/zip)
2020-09-14 22:05 UTC, liming-coder
sample3_emf.zip (43.64 KB, application/zip)
2020-09-17 21:52 UTC, liming-coder
sample4.zip (318.43 KB, application/zip)
2020-10-23 07:15 UTC, liming-coder
sample5.zip (725.36 KB, application/zip)
2020-10-23 07:16 UTC, liming-coder
703 (35.61 KB, application/zip)
2020-12-15 06:29 UTC, liming-coder
16.zip (81.29 KB, application/zip)
2021-09-26 23:59 UTC, liming-coder

Note You need to log in before you can comment on or make changes to this bug.
Description liming-coder 2020-09-08 00:03:16 UTC
Created attachment 37430 [details]

the attached wmf files can't display correctly. 

Comment 1 Andreas Beeker 2020-09-08 21:07:34 UTC
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:


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.
Comment 2 Andreas Beeker 2020-09-08 21:37:49 UTC
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.
Comment 3 liming-coder 2020-09-14 22:05:24 UTC
Created attachment 37455 [details]

thanks every much. i found some other wmf display error. see attachment sample2.zip

Comment 4 liming-coder 2020-09-14 22:11:41 UTC
sample1.zip is fixed in the nightly trunk.
Comment 5 Andreas Beeker 2020-09-15 22:57:35 UTC
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
Comment 6 liming-coder 2020-09-17 21:52:45 UTC
Created attachment 37456 [details]
Comment 7 liming-coder 2020-09-17 21:59:18 UTC

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();

Comment 8 Andreas Beeker 2020-09-19 08:19:35 UTC
(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
Comment 9 liming-coder 2020-10-23 07:15:29 UTC
Created attachment 37524 [details]

i've collected some wmf/emf images which also have some problems. see sample4.zip,sample5.zip.

Comment 10 liming-coder 2020-10-23 07:16:18 UTC
Created attachment 37525 [details]

Comment 11 Andreas Beeker 2020-11-01 15:47:17 UTC
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
Comment 12 liming-coder 2020-11-05 09:27:57 UTC
thanks Andreas. i will try this weekend.
Comment 13 Andreas Beeker 2020-11-15 21:56:40 UTC
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 ...)
Comment 14 liming-coder 2020-12-15 06:29:10 UTC
Created attachment 37612 [details]

with latest trunk, emf in 703.zip is too small.
Comment 15 Andreas Beeker 2020-12-18 21:23:16 UTC
(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.
Comment 16 liming-coder 2021-09-26 23:59:24 UTC
Created attachment 38048 [details]

the image in 16.zip is rendered too small. poi version is 5.0.0
Comment 17 Andreas Beeker 2021-10-11 20:23:57 UTC
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.
Comment 18 Andreas Beeker 2021-10-12 22:31:22 UTC
add another heuristic - cumulate the bounding box of the shape records and compare it to window, viewport and emfbounds

Applied via r1894176