Re:Restructuring a giant, ancient codebase to make LibreOffi...
by chris_wot on Friday January 19, 2018 @04:47AM
(#16185123)
Can you link to that library?
Re:Restructuring a giant, ancient codebase to make LibreOffi...
by buovjaga on Friday January 19, 2018 @07:58AM
(#16185867)
I found it in his submission history: https://github.com/kakwa/libemf2svg
Re:Restructuring a giant, ancient codebase to make LibreOffi...
by kakwa_ on Friday January 19, 2018 @12:51PM
(#16188176)
thanks ^^
For information, the bits of code that is handling "font index encoding":
https://github.com/kakwa/libemf2svg/blob/master/src/lib/emf2...
To
https://github.com/kakwa/libemf2svg/blob/master/src/lib/emf2...
The article mentions EMF/EMF+. this format is basically a list of calls to GDI.h and is a bitch to map to other graphic stacks when you are not on Windows.
The specification of the format is public (kudos for Microsoft), it helps a lot. But there are a lot of corner cases and the spec can be quite hard to understand some times. Computing correctly the origin is tricky for example (VIEWPORTORGEX, WINDOWORGEX etc).
For some stuff, it's impossible to get it right.
One example that comes to my mind is a text encoding bug I got a year ago (I maintain an emf to svg conversion library). It took me one week to track it down. In most cases the strings are UTF-16. But in weird cases, when the ETO_GLYPH_INDEX flag is set, the "encoding" is directly the index of the glyph inside the selected font.
It's not the most portable way to handle text... If you don't have the exact same font on your computer, there is a good chance the text will not be displayed correctly.
And converting back to a well known encoding is tricky (using the cmap tables of the ttf file, you have to build a reverse cmap, pray there is a 1-1 mapping between glyph and unicode, and convert back to utf-8 or something).
Even Microsoft itself, on the Mac OS, version got it wrong.