richardvoigt at gmail.com
Tue Jan 2 19:26:59 CST 2007
On 1/2/07, Jeff L <lats at yless4u.com.au> 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:
"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
More information about the wine-devel