On Tuesday 02 January 2007 19:42, * * wrote:
StringAnalysis should have a cache object, not save the HDC directly.
I agree, although you shouldn't free the cache in ScriptStringFree, the caller is responsible for that.
One of the important things about the cache, which wine currently doesn't do, is that the caller is free to select a different font into the HDC after calling ScriptStringAnalyse and Uniscribe is supposed to use the right one.
Yes, cache handling is still very basic. If the font changes the cache should be invalidated. It also needs to be ref counted and locked.
-Hans
On 1/2/07, Hans Leidekker hans@it.vu.nl wrote:
On Tuesday 02 January 2007 19:42, * * wrote:
StringAnalysis should have a cache object, not save the HDC directly.
I agree, although you shouldn't free the cache in ScriptStringFree, the caller is responsible for that.
One of the important things about the cache, which wine currently doesn't do, is that the caller is free to select a different font into the HDC after calling ScriptStringAnalyse and Uniscribe is supposed to use the right one.
Yes, cache handling is still very basic. If the font changes the cache should be invalidated. It also needs to be ref counted and locked.
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.
{{ Seems with wine-devel the default action isn't reply to list, I've got to be more careful when replying }}
-- Richard Voigt
-Hans
* * 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.
Jeff Latimer
On 1/2/07, Jeff L lats@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: 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
* * wrote:
"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.
I have checked how this works by not selecting a font before the first ScriptShape. The test run works as as specified and Windows did not return E_PENDING in this case. My reading of uniscribe is that its not too fussy about what fonts you use and accepts what ever the default is in the HDC. The key thing is that once you have initialised a Script_Cache from a HDC then the font can't be changed cache.
Jeff
-
* * -
Hans Leidekker -
Jeff L