We now have at least three bugs[1] where the program will not accept the all the characters that are required if we do not use native fonts. The latest bug report was reported just today and the reporter resolved the bug as FIXED when he used Native fonts.
So I have a couple of questions.
Should we consider using native fonts a "FIX" or is it just a workaround? Or in other words can we fix our built in fonts to fix this.
Should These bugs marked a duplicates?
[1] http://bugs.winehq.org/show_bug.cgi?id=2389 http://bugs.winehq.org/show_bug.cgi?id=4162 http://bugs.winehq.org/show_bug.cgi?id=5052
--
Tony Lambregts
On 4/11/06, Tony Lambregts tony.lambregts@gmail.com wrote:
Should These bugs marked a duplicates?
These reports should all be pending the same bug. We really need a proper font replacement.
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Tony Lambregts wrote:
We now have at least three bugs[1] where the program will not accept the all the characters that are required if we do not use native fonts. The latest bug report was reported just today and the reporter resolved the bug as FIXED when he used Native fonts.
So I have a couple of questions.
Should we consider using native fonts a "FIX" or is it just a workaround? Or in other words can we fix our built in fonts to fix this.
I also have an installer (for Xilinx) that exhibits this problem. I created a small application that creates a single line edit control (which is what the Xilinx installer uses). I notice that on Win2k the EM_GETMARGINS message returns zero for left and right messages, but on Wine it returns 2 for both margins.
From a trace, the margins are getting set to 2 in EDIT_WM_SetFont(), with the call: EDIT_EM_SetMargins(es, EC_LEFTMARGIN | EC_RIGHTMARGIN, EC_USEFONTINFO, EC_USEFONTINFO, FALSE); Commenting out that single line makes the Xilinx installer work fine. Not that it is the correct fix ;)
On Tue, Apr 11, 2006 at 04:53:20PM -0700, Duane Clark wrote:
Tony Lambregts wrote:
We now have at least three bugs[1] where the program will not accept the all the characters that are required if we do not use native fonts. The latest bug report was reported just today and the reporter resolved the bug as FIXED when he used Native fonts.
So I have a couple of questions.
Should we consider using native fonts a "FIX" or is it just a workaround? Or in other words can we fix our built in fonts to fix this.
I also have an installer (for Xilinx) that exhibits this problem. I created a small application that creates a single line edit control (which is what the Xilinx installer uses). I notice that on Win2k the EM_GETMARGINS message returns zero for left and right messages, but on Wine it returns 2 for both margins.
From a trace, the margins are getting set to 2 in EDIT_WM_SetFont(), with the call: EDIT_EM_SetMargins(es, EC_LEFTMARGIN | EC_RIGHTMARGIN, EC_USEFONTINFO, EC_USEFONTINFO, FALSE); Commenting out that single line makes the Xilinx installer work fine. Not that it is the correct fix ;)
I had some fun with this a month or two ago. See the test_margins_font_change test and calc_min_margin_size in the actual code. The deal seems to be that for 'small' edit controls EC_USEFONTINFO results in no margin. 'Small' is currently defined to be smaller than the extents of the (four character) string "'**'", that's close but not quite how Windows does it.
Another interesting thing is that when it does set margins they are often not symmetric left/right (although you tend to have to use larger font sizes to see this) - it's presumably using some pair of font metrics to set these and despite spending quite a while hunting I drew a blank.
Now your problem could simply be that you don't have the font that the app wants to use in this edit control. It'll create the edit control with a size that would work with that font under Windows (and probably also under Wine), however if you don't have that font and Wine picks one which ends up being slightly larger then you've got a problem. It's difficult to know how to fix this. The other possibility is that you have the correct font but the '**' algorithm is slightly wrong (it is) and that you're right on the edge of it kicking in.
Huw.
Huw D M Davies wrote:
I had some fun with this a month or two ago. See the test_margins_font_change test and calc_min_margin_size in the actual code. The deal seems to be that for 'small' edit controls EC_USEFONTINFO results in no margin. 'Small' is currently defined to be smaller than the extents of the (four character) string "'**'", that's close but not quite how Windows does it.
Does GdiGetCharDimensions give you a better result?
That is the algorithm used by other user32 controls to work out the "size" of a font.
Huw D M Davies wrote:
I had some fun with this a month or two ago. See the test_margins_font_change test and calc_min_margin_size in the actual code. The deal seems to be that for 'small' edit controls EC_USEFONTINFO results in no margin. 'Small' is currently defined to be smaller than the extents of the (four character) string "'**'", that's close but not quite how Windows does it.
The fields in my case are 4 numbers.
Another interesting thing is that when it does set margins they are often not symmetric left/right (although you tend to have to use larger font sizes to see this) - it's presumably using some pair of font metrics to set these and despite spending quite a while hunting I drew a blank.
Now your problem could simply be that you don't have the font that the app wants to use in this edit control...
What the "right" font should be is a bit of a mystery to me. From traces with the font and edit debug channels turned on, it appears to me the application was selecting "MS Shell Dlg". So in my test app, I duplicated the selected font:
afont = CreateFont(-11, 0, 0, 0, 400, 0, 0, 0, DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, PROOF_QUALITY, DEFAULT_PITCH, "MS Shell Dlg"); SendMessage(g_hControl,WM_SETFONT,(WPARAM)afont,0);
And indeed on Win2k, that produces an identical result to the Xilinx app. On Wine, the font appears to be similar but not identical. As far as the characters go, I can see that the '1' has an extra pixel to the right at the bottom. Most of the other characters appear to be pixel identical (though the '7' is rendered one pixel to the right of where it is on Win2k). The biggest difference though, is that the numbers are aliased on Wine, and not on Win2k. I'll see if I can figure out what fonts are actually being used; I don't really know offhand how to go about doing that.
On Wed, Apr 12, 2006 at 08:55:09AM -0700, Duane Clark wrote:
Huw D M Davies wrote:
I had some fun with this a month or two ago. See the test_margins_font_change test and calc_min_margin_size in the actual code. The deal seems to be that for 'small' edit controls EC_USEFONTINFO results in no margin. 'Small' is currently defined to be smaller than the extents of the (four character) string "'**'", that's close but not quite how Windows does it.
The fields in my case are 4 numbers.
Note that this size has nothing to do with what's in the control. The '**' thing is just something the scales with font size that seems to be close to the 'magic' size in Windows.
Now your problem could simply be that you don't have the font that the app wants to use in this edit control...
What the "right" font should be is a bit of a mystery to me. From traces with the font and edit debug channels turned on, it appears to me the application was selecting "MS Shell Dlg". So in my test app, I duplicated the selected font:
afont = CreateFont(-11, 0, 0, 0, 400, 0, 0, 0, DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, PROOF_QUALITY, DEFAULT_PITCH, "MS Shell Dlg"); SendMessage(g_hControl,WM_SETFONT,(WPARAM)afont,0);
MS Shell Dlg maps to either Microsoft Sans Serif or Tahoma depending on Windows version; the default wine.inf maps it to Tahoma so you should check whether you have tahoma.ttf installed. If in doubt a +font log will tell you what Wine picks for this font.
Huw.
Huw D M Davies wrote:
MS Shell Dlg maps to either Microsoft Sans Serif or Tahoma depending on Windows version; the default wine.inf maps it to Tahoma so you should check whether you have tahoma.ttf installed. If in doubt a +font log will tell you what Wine picks for this font.
In Win2k, it is picking "MS Sans Serif", but in Wine configured for "Windows 2000" it is picking Tahoma. And indeed, using my small test app, in Win2k with the Tahoma font, I can no longer type 4 numbers in the field, and the margins are both set to '3'.
On the other hand, in both Win2k and WinXP, "MS Shell Dlg" seems to be mapping to "MS Sans Serif". So is having Tahoma the default really the right thing to do?
Duane Clark wrote:
On the other hand, in both Win2k and WinXP, "MS Shell Dlg" seems to be mapping to "MS Sans Serif". So is having Tahoma the default really the right thing to do?
And to respond to myself once again, according to: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/nls_4q...
"On Windows NT 4.0/2000/XP/Server 2003/Vista, both map to Unicode-based TrueType fonts. MS Shell Dlg uses Microsoft Sans Serif (which is distinct from MS Sans Serif)... MS Shell Dlg 2 simply uses the Tahoma font"
So perhaps we should be doing that?
On Wed, Apr 12, 2006 at 10:14:58AM -0700, Duane Clark wrote:
Huw D M Davies wrote:
MS Shell Dlg maps to either Microsoft Sans Serif or Tahoma depending on Windows version; the default wine.inf maps it to Tahoma so you should check whether you have tahoma.ttf installed. If in doubt a +font log will tell you what Wine picks for this font.
In Win2k, it is picking "MS Sans Serif", but in Wine configured for "Windows 2000" it is picking Tahoma. And indeed, using my small test app, in Win2k with the Tahoma font, I can no longer type 4 numbers in the field, and the margins are both set to '3'.
On the other hand, in both Win2k and WinXP, "MS Shell Dlg" seems to be mapping to "MS Sans Serif". So is having Tahoma the default really the right thing to do?
I assume you mean Microsoft Sans Serif not MS Sans Serif. The former is a TrueType font (micross.ttf) the latter is a bitmap font (sserife.fon).
Indeed it does look like[1] we should be using Microsoft Sans Serif for MS Shell Dlg at least for non-CJK locales.
Huw. [1] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/nls_4q...
Huw Davies wrote:
I assume you mean Microsoft Sans Serif not MS Sans Serif. The former is a TrueType font (micross.ttf) the latter is a bitmap font (sserife.fon).
Indeed it does look like[1] we should be using Microsoft Sans Serif for MS Shell Dlg at least for non-CJK locales.
You are right, it is Microsoft Sans Serif. Testing more on Win2k shows that with Tahoma, the edit field sets margins that depend on the font size. Explicitely setting "Microsoft Sans Serif" gives me the correct font, and it is indeed True Type, but both margins remain zero regardless of the font size.
On Wed, Apr 12, 2006 at 11:28:21AM -0700, Duane Clark wrote:
Testing more on Win2k shows that with Tahoma, the edit field sets margins that depend on the font size. Explicitely setting "Microsoft Sans Serif" gives me the correct font, and it is indeed True Type, but both margins remain zero regardless of the font size.
Interesting, so to clarify, even a large edit control and a small Microsoft Sans Serif has a zero margin?
Huw.
Huw Davies wrote:
On Wed, Apr 12, 2006 at 11:28:21AM -0700, Duane Clark wrote:
Testing more on Win2k shows that with Tahoma, the edit field sets margins that depend on the font size. Explicitely setting "Microsoft Sans Serif" gives me the correct font, and it is indeed True Type, but both margins remain zero regardless of the font size.
Interesting, so to clarify, even a large edit control and a small Microsoft Sans Serif has a zero margin?
Yep.
On Wed, Apr 12, 2006 at 12:26:07PM -0700, Duane Clark wrote:
Huw Davies wrote:
Interesting, so to clarify, even a large edit control and a small Microsoft Sans Serif has a zero margin?
Yep.
Fascinating. This will probably be a huge clue in working out exactly what Windows does here - unfortunately, at the moment, I have no idea what it means :-(
Huw.
Huw Davies wrote:
On Wed, Apr 12, 2006 at 12:26:07PM -0700, Duane Clark wrote:
Huw Davies wrote:
Interesting, so to clarify, even a large edit control and a small Microsoft Sans Serif has a zero margin?
Yep.
Fascinating. This will probably be a huge clue in working out exactly what Windows does here - unfortunately, at the moment, I have no idea what it means :-(
Hmmm, well I found this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pla...
where is says "By default, the edit control margins are set just wide enough to accommodate the largest character horizontal overhang (negative ABC widths) for the current font being used in the edit control."
I haven't quite figured out what that means, yet ;)
Duane Clark wrote:
Hmmm, well I found this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pla...
where is says "By default, the edit control margins are set just wide enough to accommodate the largest character horizontal overhang (negative ABC widths) for the current font being used in the edit control."
I haven't quite figured out what that means, yet ;)
I made the attached changes to the edit test. The results when run on Win2k are a bit strange (note that I only looked for the min in the first 1024 glyphs):
edit.c:807:Font Verdana first char=32, last=64258 edit.c:817:MinA=-1, minC=-7 edit.c:824:Left=1, right=4
edit.c:807:Font Arial first char=32, last=65532 edit.c:817:MinA=-7, minC=-2 edit.c:824:Left=3, right=3
edit.c:807:Font Tahoma first char=32, last=65532 edit.c:817:MinA=-6, minC=-1 edit.c:824:Left=3, right=3
edit.c:807:Font Microsoft Sans Serif first char=32, last=65532 edit.c:817:MinA=0, minC=0 edit.c:824:Left=0, right=0
On Wed, Apr 12, 2006 at 03:13:43PM -0700, Duane Clark wrote:
Fascinating. This will probably be a huge clue in working out exactly what Windows does here - unfortunately, at the moment, I have no idea what it means :-(
Hmmm, well I found this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pla...
where is says "By default, the edit control margins are set just wide enough to accommodate the largest character horizontal overhang (negative ABC widths) for the current font being used in the edit control."
I haven't quite figured out what that means, yet ;)
Yeah I found that too, but also couldn't making much sense of the numbers I got from the ABC widths (or by reading the BBox values from the ttf directly). As your test with Microsoft Sans Serif shows though it's clearly related to it as the A and C widths are both zero in that font.
Huw.
Duane Clark wrote:
... Most of the other characters appear to be pixel identical (though the '7' is rendered one pixel to the right of where it is on Win2k).
Actually, the '7' is correct. The problem is the '8' (I had typed "6789"). Here are a couple of small images of the problem. The first, eights, shows the problem. The second, nines, is correct. On Win2k, the "eights" and "nines" with the Tahoma font render with the same spacing.
-
Duane Clark -
Huw D M Davies -
Huw Davies
-
Robert Shearman -
Steven Edwards -
Tony Lambregts