Sorting it all Out Michael Kaplan's random stuff of dubious value Be sure to read the disclaimer here first!
It was quite a while ago that I first posted Let's get vertical and talked about how prepending a font name with an @ would signal a font with knowledge of verticality to properly decide when to rotate glyphs 90 degrees.
I have been asked whether those samples from the "Far East Win32 SDK" still existed. It seems that they do not (though the GlobalDev web site still talks about the TATE sample in this article). Mildly disappointing, as it always is when samples seem to go away....
Anyway, a question came up a while back related to GetGlyphOutline. A customer wanted to know how to determine programatically whether a glyph would be rotated or not, in a vertical font.
They noticed that when they passed the text (fo a vertical font in the HDC), they would get back a rotated glyph, but when they passed the glyphid and the GGO_GLYPH_INDEX flag, they would not get a rotated glyph. It was causing them trouble when they were just storing the glyphid values, and seemed a strange thing to depend on for determining whether rotation was happening.
Nobody seemed aware of the reasoning behind the two different behaviors here, though no one has ever expected a whole of explanation about GetGlyphOutline behavior or details; articles like this one from CodeGuru are typical in their explanations about this proc:
A Function from Hell I guess it was the mere challenge that made me design this class. In Windows, simply outputting characters generally isn't exactly fun, with all these complex functions and structs, but it's nothing compared to retrieving basic character data from the system's depths.You have to deal with GetGlyphOutine(), a function from hell, probably made up by the nastiest member of the Windows design team when he was suffering from a really, really bad temper. To use it, you have to struggle with horribly complex nested structs of varying sizes, bearing data in weird formats. The documentation is very dense and sketchy, and only recently more or less free of errors and inconsistencies. Only in some remote, dim corners of the huge MSDN library one or two small, partly outdated articles can be found.No wonder most programmers tend to give this part of Windows GDI a wide berth. It's almost as if Microsoft doesn't want you to play with text. It wouldn't have something to do with the fact that it was Apple, who originally designed the core font technology for Windows, wouldn't it?
I guess it was the mere challenge that made me design this class. In Windows, simply outputting characters generally isn't exactly fun, with all these complex functions and structs, but it's nothing compared to retrieving basic character data from the system's depths.You have to deal with GetGlyphOutine(), a function from hell, probably made up by the nastiest member of the Windows design team when he was suffering from a really, really bad temper. To use it, you have to struggle with horribly complex nested structs of varying sizes, bearing data in weird formats. The documentation is very dense and sketchy, and only recently more or less free of errors and inconsistencies. Only in some remote, dim corners of the huge MSDN library one or two small, partly outdated articles can be found.No wonder most programmers tend to give this part of Windows GDI a wide berth. It's almost as if Microsoft doesn't want you to play with text. It wouldn't have something to do with the fact that it was Apple, who originally designed the core font technology for Windows, wouldn't it?
Anyway, like I said nobody seemed to really understand/recall the reason for the difference (and comments in the code were reported as beung less than helpful in resolving the issue).
Though it does provide an interesting and only slightly kludgey way to determine whether a glyph is rotated without having to dig into the OpenType vert or vrt2 features. It is fair to say that the behavior could not be changed without breaking a ton of people, so even though it is not specifically documented (something true of the bulk of GetGlyphOutline behavior), it is pretty much set in stone.
The one place whether this is pretty unfortunate is when one is dealing with supplementary ideographs in Extension B, since GetGlyphOutline can only take a single WCHAR or a single glyphid. and even using Uniscribe's ScriptGetCMap won't help here in figuring out the rotation issue even when it will help with the Extension B glyphid retrieval....
There seems to be no good way around it -- one needs to dig into the OpenType features if one wants the real answers here!
This post brought to you by ＠ (U+ff20, FULLWIDTH COMMERCIAL AT)
>it was Apple, who originally designed the core font technology for Windows,
Microsoft licensed TrueType from Apple. TueType is a "core font technology" for sure, but how does that explain the annoying APIs? I don't think you can blame Apple in this case.
Well, that was a quote, of someone else's opinion....
But there are a whole lot of GDI functions related to fonts that are pretty nightmarish, and one almost has to believe that it is the hideously complex nature of what is underneasth that makes it so hard on top. :-)
One of the interesting side effects of having comments open all the time is that sometimes a post from
The other day I was chatting by email with a developer on a unique problem -- she was trying to support
The question Craig asked me last December was clear enough: When will Windows support a vertical layout