Bug 137440 - [EMF] FILEOPEN: Wrong text due to missing ETO_GLYPH_INDEX option from EMR_EXTTEXTOUTW record
Summary: [EMF] FILEOPEN: Wrong text due to missing ETO_GLYPH_INDEX option from EMR_EXT...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.6.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:emf
Depends on:
Blocks: EMF-WMF
  Show dependency tree / graph
 
Reported: 2020-10-13 08:40 UTC by Timur
Modified: 2022-05-26 00:19 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Attachments
EMF (1.39 KB, image/emf)
2020-11-09 14:58 UTC, Timur 		Details
Logs from importing emf file (20.02 KB, text/plain)
2020-11-10 16:32 UTC, Bartosz 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Timur 2020-10-13 08:40:17 UTC 
MSO created DOCX attachment 165503 [details] from (dumpyard) bug 131381 opens EMF image with wrong text, as compared with MSO in attachment 165504 [details] .

DOCX is old format, but similar if resaved in MSO. Didn't open in LO 3.5. Similar from 3.6 to 7.1+ for me. Test in Windows 7 OpenGL and GDI (with and without OpenGL) for older LO 6.4 and Skia and GDI in LO 7.1+.

Reported added different comparison with MSO as attachment 166332 [details]. I don't know how he gets that.
Comment 1 Xisco Faulí 2020-10-13 08:51:09 UTC 
Reproduced in

Version: 7.1.0.0.alpha0+
Build ID: a9976a958b2857e308c6598532151878615bfd9f
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 2 Timur 2020-11-09 14:58:33 UTC 
Created attachment 167142 [details]
EMF

Fileopen DOCX is not important. Also if EMF inserted in new Writer.
Comment 3 Bartosz 2020-11-10 16:32:17 UTC 
Created attachment 167176 [details]
Logs from importing emf file
Comment 4 Bartosz 2020-11-10 19:06:08 UTC 
The root cause of wrongly displayed text is lack of implementation of ETO_GLYPH_INDEX option from EMR_EXTTEXTOUTW record.

ETO_GLYPH_INDEX bit indicates that the codes for characters in an output text string are
actually indexes of the character glyphs in a TrueType font. Glyph indexes are font-specific, so to
display the correct characters on playback, the font that is used MUST be identical to the font used
to generate the indexes.

Generally it is not possible to get right character from Unicode, and it should be taken directly from TrueType font index. More information:
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/5c88ddaf-5dbe-4f81-9c0d-83785798d500/how-to-get-right-unicode-character-when-exttextoutw-called-with-etoglyphindex-set-in-fuoptions?forum=windowssdk

I found also some useful implementation on Qt side, which could be helpful:
https://bugreports.qt.io/browse/QTBUG-40683
Comment 5 Julien Nabet 2022-04-23 13:49:47 UTC 
Just for the record, on pc Debian x86-64 with master sources updated today, I noticed these logs:
warn:emfio:8686:8686:emfio/source/reader/emfreader.cxx:1927: SJ: ETO_PDY || ETO_GLYPH_INDEX in EMF
warn:drawinglayer.emf:8686:8686:drawinglayer/source/tools/emfphelperdata.cxx:1773: EMF+	 TODO SetPixelOffsetMode
warn:drawinglayer.emf:8686:8686:drawinglayer/source/tools/emfphelperdata.cxx:1760: EMF+	 TODO SetAntiAliasMode
warn:drawinglayer.emf:8686:8686:drawinglayer/source/tools/emfphelperdata.cxx:1767: EMF+	 TODO InterpolationMode
Comment 6 Bartosz 2022-05-26 00:19:07 UTC 
More information: https://docs.microsoft.com/en-us/typography/opentype/spec/cmap