On 1/2/07, Jeff L <[EMAIL PROTECTED]> wrote:
* * wrote: > > According to MSDN, the "pending" error is to give the calling app a > chance to select the matching font back into the DC if the information > wasn't cached. I think that the get_script_cache function is broken, > in that it should return the pending error if the HDC isn't provided, > since the HDC in the cache might no longer have the same font > selected. However maybe some applications don't deal with the pending > case properly. The functionality tests ok in Windows the way it is implemented. What you are asking for is not the way it actually works. Having tested a few applications, they all seem to handle the E_PENDING ok. In Windows the cache contains font info to speed up the uniscribe processing so many apps only pass the psc and not the HDC. There is a rule that once you have an script_cache the caller can't change the font. If he does it is his fault and he can fix it. In our case we currently only seek conformance with Windows.
That's distinctly not what MSDN documentation and the associated example code reads: http://www.microsoft.com/typography/developers/uniscribe/uniscribe.htm http://msdn2.microsoft.com/en-gb/library/ms776467.aspx "If the device context is passed as NULL and Uniscribe needs to access it for any reason, Uniscribe returns the error code E_PENDING. This code is returned quickly, allowing the application to avoid time-consuming SelectObject calls." Whereas the current implementation will silently access an HDC even if the application passed NULL, which means the application doesn't get a chance to SelectObject the right font.
Jeff Latimer
