[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs defeats ClearType

From: David Abrahams
Subject: Re: Emacs defeats ClearType
Date: Fri, 03 Jun 2005 11:27:08 -0400
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (windows-nt)

address@hidden writes:

> Quoting David Abrahams <address@hidden>:
>> When ClearType
>> (http://www.microsoft.com/typography/cleartype/tuner/Step1.aspx) is
>> enabled on an NT build of Emacs, it's very common for emacs to "slice
>> off" a few antialiased pixels on either side of a character's vertical
>> member.  It happens especially in lines that are being typed.  You can
>> see examples in this sentence of characters whose vertical members
>> appear to be thin, red lines (image enclosed).
> This happens because Windows tells lies about the width of characters when
> sub-pixel antialiasing is in effect.
> You are welcome to investigate a way around this if you want.

Fantastic; it turned out to be easy.  I have enclosed a patch that
works for me.  The use of those strange #defines

#define W32_spi_getfontsmoothing 0x4A
#define W32_spi_getfontsmoothingtype 0x0200A
#define W32_fe_fontsmoothingcleartype 0x2

is because the use of -D_WIN32_WINNT=0x0400 on the compiler
command-line makes the corresponding MS constants unavailable through
<windows.h>.  I wasn't sure what the best way to handle this stuff
might be -- i.e. what's most consistent with regular Emacs coding
practice.  I would be happy to change the approach in whatever way is
deemed necessary.  I also release all rights to my patch to the FSF.

Incidentally, it seemed to work just fine for me if I remove the
checks for whether cleartype is enabled altogether, and just make the
width adjustments unconditionally.  That would eliminate the issue
with those constants described above and probably make a small
difference in speed.  Seems like a viable option to me.

--- w32term.c   25 Mar 2005 19:19:53 -0500      1.224
+++ w32term.c   03 Jun 2005 11:21:29 -0400      
@@ -903,6 +903,29 @@
          int real_width;
          GetCharWidth (hdc, *char2b, *char2b, &real_width);
+          BOOL smoothing_enabled;
+          UINT smoothing_type;
+          /* Attempt to account for ClearType antialiasing.
+           * GetCharABCWidths fails to report the fractional pixels
+           * used for subpixel antialiasing
+           */
+#define W32_spi_getfontsmoothing 0x4A
+#define W32_spi_getfontsmoothingtype 0x0200A
+#define W32_fe_fontsmoothingcleartype 0x2
+          if (SystemParametersInfo(W32_spi_getfontsmoothing, 0, 
&smoothing_enabled, 0)
+              && smoothing_enabled
+              && SystemParametersInfo(W32_spi_getfontsmoothingtype, 0, 
&smoothing_type, 0)
+              && smoothing_type == W32_fe_fontsmoothingcleartype
+          )
+          {
+              char_widths.abcA -=1;
+              char_widths.abcB +=2;
+              char_widths.abcC -= 1;
+          }
          pcm->width = char_widths.abcA + char_widths.abcB + char_widths.abcC;
 #if 0
          /* As far as I can tell, this is the best way to determine what
Dave Abrahams
Boost Consulting

reply via email to

[Prev in Thread] Current Thread [Next in Thread]