problem with GetTextMetrics() - Programmer

This is a discussion on problem with GetTextMetrics() - Programmer ; isn't TEXTMETRIC.tmMaxCharWidth supposed to be the width of the widest character in the font in pixels? with the DEFAULT_GUI_FONT on XP, shouldn't that be 'W'? 'W' is 9 pixels wide, but tmMaxCharWidth is 22. I'm sure the correct font is ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: problem with GetTextMetrics()

  1. problem with GetTextMetrics()

    isn't TEXTMETRIC.tmMaxCharWidth supposed to be the width of the widest
    character in the font in pixels? with the DEFAULT_GUI_FONT on XP, shouldn't
    that be 'W'? 'W' is 9 pixels wide, but tmMaxCharWidth is 22. I'm sure the
    correct font is selected into the DC which I am running GetTextMetrics() on.



  2. Re: problem with GetTextMetrics()

    SDK: The TEXTMETRIC structure contains basic information about a
    physical font. All sizes are specified in logical units; that is, they
    depend on the current mapping mode of the display context.


  3. Re: problem with GetTextMetrics()

    Which means use LPtoDP to convert the units.

    AliR.

    "stork" wrote in message
    news:1125417676.043959.191010@g47g2000cwa.googlegr oups.com...
    > SDK: The TEXTMETRIC structure contains basic information about a
    > physical font. All sizes are specified in logical units; that is, they
    > depend on the current mapping mode of the display context.
    >
    >




  4. Re: problem with GetTextMetrics()

    In article <43148492$1_5@alt.athenanews.com>, AliR@online.nospam says...
    > Which means use LPtoDP to convert the units.
    >
    > AliR.
    >
    > "stork" wrote in message
    > news:1125417676.043959.191010@g47g2000cwa.googlegr oups.com...
    > > SDK: The TEXTMETRIC structure contains basic information about a
    > > physical font. All sizes are specified in logical units; that is, they
    > > depend on the current mapping mode of the display context.


    Although this is certainly relevant, I don't think it explains the
    discrepancy. The default mapping mode is MM_TEXT, which has a
    one-to-one mapping for logical and device units.

    I wrote a little test program to verify the OP's results. I got the
    same value of 22 for the situation described, but both
    GetTextExtentPoint32() and GetCharWidth32() indicate that
    the widest characters (including "W") have a width of 11.
    All of these values are in logical units.


    --
    Tim Kannel

    TCAP - Captures console I/O to a file (DOS,Win9x)
    http://www.simtel.net/pub/pd/11141.shtml

  5. Re: problem with GetTextMetrics()

    > isn't TEXTMETRIC.tmMaxCharWidth supposed to be the width of the widest
    > character in the font in pixels? with the DEFAULT_GUI_FONT on XP,

    shouldn't
    > that be 'W'? 'W' is 9 pixels wide, but tmMaxCharWidth is 22. I'm sure the
    > correct font is selected into the DC which I am running GetTextMetrics()

    on.
    >
    >


    IIRC the default font is UNICODE so I would expect something like
    chinese or arbic characters to have larger pixel wides than W.




  6. Re: problem with GetTextMetrics()

    > IIRC the default font is UNICODE so I would expect something like
    > chinese or arbic characters to have larger pixel wides than W.


    The character set for the default font may depend on which
    language edition of Windows. However, based on this comment I rewrote my
    test program to support compiling as ANSI or UNICODE. In either case, the
    max width reported by GetTextMetrics() is 22 and the charset of the font
    is ANSI. The range of characters reported by GetTextMetrics() DOES change
    (which is odd since the charset didn't change), and the widest character
    (as determined using the functions that I mentioned earlier for
    characters in the reported range) is indeed something else;
    that character has a width of 15.

    So this still doesn't explain where that value of 22 comes from.
    And I would expect that the max char width would be based on
    the range of characters that is reported in that same structure.
    It apparently isn't.


    --
    Tim Kannel

    TCAP - Captures console I/O to a file (DOS,Win9x)
    http://www.simtel.net/pub/pd/11141.shtml

  7. Re: problem with GetTextMetrics()


    "Tim Kannel" wrote in message
    news:MPG.1d7f913eba6cb3ba98969e@newsgroups.comcast .net...
    >> IIRC the default font is UNICODE so I would expect something like
    >> chinese or arbic characters to have larger pixel wides than W.

    >
    > The character set for the default font may depend on which
    > language edition of Windows. However, based on this comment I rewrote my
    > test program to support compiling as ANSI or UNICODE. In either case, the
    > max width reported by GetTextMetrics() is 22 and the charset of the font
    > is ANSI. The range of characters reported by GetTextMetrics() DOES change
    > (which is odd since the charset didn't change), and the widest character
    > (as determined using the functions that I mentioned earlier for
    > characters in the reported range) is indeed something else;
    > that character has a width of 15.
    >
    > So this still doesn't explain where that value of 22 comes from.
    > And I would expect that the max char width would be based on
    > the range of characters that is reported in that same structure.
    > It apparently isn't.


    The character set contains a double width dash character.

    Norman
    Saperion Inc.



  8. Re: problem with GetTextMetrics()

    On Tue, 30 Aug 2005 15:48:46 -0500, Tim Kannel
    wrote:

    >In article <43148492$1_5@alt.athenanews.com>, AliR@online.nospam says...
    >> Which means use LPtoDP to convert the units.
    >>
    >> AliR.
    >>
    >> "stork" wrote in message
    >> news:1125417676.043959.191010@g47g2000cwa.googlegr oups.com...
    >> > SDK: The TEXTMETRIC structure contains basic information about a
    >> > physical font. All sizes are specified in logical units; that is, they
    >> > depend on the current mapping mode of the display context.

    >
    >Although this is certainly relevant, I don't think it explains the
    >discrepancy. The default mapping mode is MM_TEXT, which has a
    >one-to-one mapping for logical and device units.
    >
    >I wrote a little test program to verify the OP's results. I got the
    >same value of 22 for the situation described, but both
    >GetTextExtentPoint32() and GetCharWidth32() indicate that
    >the widest characters (including "W") have a width of 11.
    >All of these values are in logical units.


    An EM dash may be wider, as may many other characters. You may want to
    loop through all valid characters (preferably in Unicode) and
    determine which one is 22 units wide. (Unfortunately, GetTextExtent
    and friends are not designed particularly for single-character
    measurements.)

    GetTextExtentPoint32 tends to produce the most accurate results, and
    can take into account kerning and intercharacter spacing, especially
    when working with multiple glyphs.

    Also, if I remember correctly, tmMaxCharWidth does not take into
    account characters that exceed the max character box (for example,
    serifs and fancies that exceed the max width x max height. (Or perhaps
    it does, thus the discrepancy.)


    --
    Sev
    "And I am but a thought of mine, an egotisticality."

  9. Re: problem with GetTextMetrics()

    > You may want to
    > loop through all valid characters (preferably in Unicode) and
    > determine which one is 22 units wide.


    That's what I was doing. When called for one character at a time,
    GetTextExtentPoint32(), GetCharWidth32(), and GetCharABCWidths()
    all returned consistent results - none of the chars are
    wider than 15 units (assuming that my test program has
    no bugs, of course).

    Anyway, I was just trying to help out. I'd like to know
    if the OP ("Nobody") has gotten any useful info out of the responses.


    > Also, if I remember correctly, tmMaxCharWidth does not take into
    > account characters that exceed the max character box (for example,
    > serifs and fancies that exceed the max width x max height. (Or perhaps
    > it does, thus the discrepancy.)


    There are no serifs for this font. As the OP mentioned, the font
    in question is DEFAULT_GUI_FONT (a.k.a. "MS Shell Dlg" = "MS Sans
    Serif").


    --
    Tim Kannel

    TCAP - Captures console I/O to a file (DOS,Win9x)
    http://www.simtel.net/pub/pd/11141.shtml

  10. Re: problem with GetTextMetrics()

    Actually, I have and I haven't . This whole font thing has been a mess
    that I am still working on. Turns out DEFAULT_GUI_FONT is not even the damn
    "default" GUI font. Only MS would come up with something like that!

    "MS Shell Dlg" and DEFAULT_GUI_FONT are only the "real" "default" gui font
    on Win95/NT4. On XP, Win2k, 2003, you need to get the DEFAULT_GUI_FONT, then
    change the typeface to "MS Shell Dlg 2" to get the real "default" gui font.
    This whole thing is a mess...

    but for the portion of code I was inquiring about, I ended up just getting
    the width of a 'W' which was good enough for my purposes (sizing an edit
    control).



    "Tim Kannel" wrote in message
    news:MPG.1d80e3132137a96d98969f@newsgroups.comcast .net...
    >> You may want to
    >> loop through all valid characters (preferably in Unicode) and
    >> determine which one is 22 units wide.

    >
    > That's what I was doing. When called for one character at a time,
    > GetTextExtentPoint32(), GetCharWidth32(), and GetCharABCWidths()
    > all returned consistent results - none of the chars are
    > wider than 15 units (assuming that my test program has
    > no bugs, of course).
    >
    > Anyway, I was just trying to help out. I'd like to know
    > if the OP ("Nobody") has gotten any useful info out of the responses.
    >
    >
    >> Also, if I remember correctly, tmMaxCharWidth does not take into
    >> account characters that exceed the max character box (for example,
    >> serifs and fancies that exceed the max width x max height. (Or perhaps
    >> it does, thus the discrepancy.)

    >
    > There are no serifs for this font. As the OP mentioned, the font
    > in question is DEFAULT_GUI_FONT (a.k.a. "MS Shell Dlg" = "MS Sans
    > Serif").
    >
    >
    > --
    > Tim Kannel
    >
    > TCAP - Captures console I/O to a file (DOS,Win9x)
    > http://www.simtel.net/pub/pd/11141.shtml




+ Reply to Thread