GPOS w/o GSUB in a TTF on XP SP2 can be FUBAR

by Michael S. Kaplan, published on 2007/03/27 08:31 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/03/27/1963148.aspx


(This post might win an award for strangest title, unless you deal with OpenType!) 

The GetCharacterPlacement function in GDI has been around since Windows 95/NT 4.0, and the truth is that the number of people who use it probably outnumber the number of people who have read my Stick a fork in GetCharacterPlacement post from the Fall of 2005.

In fact, it is likely that the number of people who use it probably also outnumber the number of people who bothered to read the Platform SDK topic thast points out:

Although this function was once adequate for working with character strings, a need to work with an increasing number of languages and scripts has rendered it obsolete. It has been superseded by the functionality of the Uniscribe module. For more information, see Uniscribe.

and

Note that GetCharacterPlacement does not produce the same results for Kashida and justification on Windows 98/Me as it does on Windows NT/2000/XP. To achieve consistency across all operating systems, use Uniscribe.

So even though it is mostly superceded and it cab often return less than ideal results, people still use it, and people still want to use it.

Why just the other day, Dave asked a question to the UniScribe gurus:

Hi all,

We have a customer reporting that GetCharacterPlacementW started failing when he upgraded to XPSP2 (from XPSP1) when it was used with certain fonts.  Further examination shows the failing fonts to contain Postscript outlines, but I’m not sure if that’s the cause.

GetCharacterPlacement works with these fonts fine in Vista and, as noted above, worked fine in XPSP1.

GetLastError doesn’t report anything, but the problem looks to be in USP10!ScriptStringAnalyse…

0:000> kb

ChildEBP RetAddr  Args to Child             
0012fb90 629c48f2 be010a7e 0044526c 00000006 USP10!ScriptStringAnalyse+0x264 [d:\xpsprtm\windows\core\cslpk\usp\api.cxx @ 3556]
0012fbdc 629c3a41 be010a7e 0044526c 00000006 LPK!LpkStringAnalyse+0xfd [d:\xpsprtm\windows\core\cslpk\lpk\lpk_usp.cxx @ 168]
0012fc4c 77f3dd0f be010a7e 0044526c 00000006 LPK!LpkGetCharacterPlacement+0x1c7 [d:\xpsprtm\windows\core\cslpk\lpk\lpk_gdi.cxx @ 980]
0012fc80 004012b4 be010a7e 0044526c 00000006 GDI32!GetCharacterPlacementW+0x76 [d:\nt\windows\core\ntgdi\client\dcquery.c @ 1334]
0012ff54 00405213 00000001 008c35f8 008c3680 GetCharacterPlacement!main+0x1f4 [c:\repro\getcharacterplacement\getcharacterplacement.c @ 109]
0012ffb8 00404fdd 0012fff0 7c816fd7 0121f6f2 GetCharacterPlacement!__tmainCRTStartup+0x233 [f:\sp\vctools\crt_bld\self_x86\crt\src\crt0.c @ 327]
0012ffc0 7c816fd7 0121f6f2 0121f78a 7ffdc000 GetCharacterPlacement!mainCRTStartup+0xd [f:\sp\vctools\crt_bld\self_x86\crt\src\crt0.c @ 196]
0012fff0 00000000 00404fd0 00000000 78746341 kernel32!BaseProcessStart+0x23 [d:\nt\base\win32\client\support.c @ 576]

0:000> r
eax=80004005 (E_FAIL) ebx=00000200 ecx=74dd5030 edx=00000001 esi=80004005 edi=be010a7e
eip=74da42b7 esp=0012fb84 ebp=0012fb90 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
USP10!ScriptStringAnalyse+0x264:
74da42b7 5b              pop     ebx

Is anybody familiar with what may have changed around SP2 to effect this (a security fix perhaps)?     Is this our bug (i.e. should this always return success with Postscript fonts if the fonts/parameters are valid)?

Thanks!

Dave

Well, both Dave and the customer are correct, there was a change here. Sergey was quick to point out the issue:

In XPSP2 we started applying standard OpenType features in Uniscribe. There is known problem with fonts that have GPOS table, but not GSUB. This has nothing to do with font outline type. If this is their own font or they can work with font vendor, this is enough to add dummy GSUB table with Latin script without any features.

This bug is fixed in Vista.

Now this is not just a GetCharacterPlacement issue, but just like a person with a busted tail light is more likely to be someone without a license or other problems (a fact vlidated by police officers every day!), it is someone who is not using the latest rendering technologies is more likely to be using a font without all of the OpenType tables in it. :-)

(I apologize for that truly ridiculous analogy, it really was beneath me!)

For some, the moral of the story is that if you are using XP, SP2 or later, then be careful about having a GPOS (Glyph Positioning) table without a GSUB (Glyph Substitution) table!

Maybe for others the moral of the story is to upgrade to Vista? :-)

But for me, the moral of the story is simple -- please move on past GetCharacterPlacement. As much as can be done to try to keep it up to date a more work is done in text rendering, it will still have problems doing everything. And the gap is onloy going to get wider....

 

This post brought to you by(U+4df2, a.k.a. HEXAGRAM FOR THE AROUSING THUNDER)


no comments

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

go to newer or older post, or back to index or month or day