Hi
Looking for something else I found this in wine/objects/font.c:
GetTextExtentPointA/W: TRACE("not bug compatible.");
As funny as it is it doesn't say that much. Is this referring to a bug in Windows? And in what way not compatible? Maybe there should be some comment explaining it.
Thanks
bye Fabi
On Fri, Feb 06, 2004 at 02:51:10PM +0100, Fabian Cenedese wrote:
Hi
Looking for something else I found this in wine/objects/font.c:
GetTextExtentPointA/W: TRACE("not bug compatible.");
As funny as it is it doesn't say that much. Is this referring to a bug in Windows? And in what way not compatible? Maybe there should be some comment explaining it.
Maybe it refers to the differences between those functions and their GetTextExtentPoint32 counterparts, I don't know. Feel free to remove it.
Huw.
On Sat, 7 Feb 2004 00:51, Fabian Cenedese wrote:
GetTextExtentPointA/W: TRACE("not bug compatible.");
As funny as it is it doesn't say that much. Is this referring to a bug in Windows?
Actually, it does say much.
Bug compatibility is defined in TNHD (or the jargon file as it's often named these days). This means there's a bug in some versions of Windows that has not been translated to Wine. My guess is that the bug referred to here is one that causes GetTextExtent* to sometimes return a width of zero for non-empty strings. The bug has no practical uses, and although plenty of apps no doubt work around it, the work-around is to detect if the width component is zero, and then futz around with the string to try to figure out what the return value really should have been. It is extremely unlikely that the lack of compatibility with this bug would break any Windows app, particularly since the bug is not present in all versions of Windows.
In fact, there would appear to be no sensible way for an app to rely on the presence of a bug in these API calls. In other cases, however, an app might rely on the buggy behaviour of a particular API call, and then bug compatibility can be important.
It seems to me that all this is saying is "this isn't bug compatible, but it wasn't thought that it would be useful to emulate Microsoft bugs here".
On Mon, Feb 09, 2004 at 09:00:45AM +1100, Troy Rollo wrote:
On Sat, 7 Feb 2004 00:51, Fabian Cenedese wrote:
GetTextExtentPointA/W: TRACE("not bug compatible.");
As funny as it is it doesn't say that much. Is this referring to a bug in Windows?
Actually, it does say much.
Bug compatibility is defined in TNHD (or the jargon file as it's often named these days). This means there's a bug in some versions of Windows that has not been translated to Wine. My guess is that the bug referred to here is one that causes GetTextExtent* to sometimes return a width of zero for non-empty strings. The bug has no practical uses, and although plenty of apps no doubt work around it, the work-around is to detect if the width component is zero, and then futz around with the string to try to figure out what the return value really should have been. It is extremely unlikely that the lack of compatibility with this bug would break any Windows app, particularly since the bug is not present in all versions of Windows.
In fact, there would appear to be no sensible way for an app to rely on the presence of a bug in these API calls. In other cases, however, an app might rely on the buggy behaviour of a particular API call, and then bug compatibility can be important.
It seems to me that all this is saying is "this isn't bug compatible, but it wasn't thought that it would be useful to emulate Microsoft bugs here".
Interesting. Any chance of a regression test that shows this behaviour?
Huw.
On Mon, 9 Feb 2004 10:13, Huw D M Davies wrote:
Interesting. Any chance of a regression test that shows this behaviour?
The attached file demonstrates the bug, but it seems I misdescribed the bug. The bug actually entails Windows returning absurdly wide widths for some strings when printing to a postscript printer. A consequence of this is that if you are doing your own word-wrapping you sometimes end up with infinite lines each containing zero characters when printing to a Postscript printer or performing a WYSIWYG preview matched to a Postscript printer unless you detect and compensate for the bug.
The attached example should demonstrate it on Windows 2000 if the default printer is a postscript printer. C file and sample output included.
The attached example should demonstrate it on Windows 2000 if the default printer is a postscript printer. C file and sample output included.
Wrong file - corrected files attached.
-
Fabian Cenedese -
Huw D M Davies -
Troy Rollo