[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);
#endif
+
+ 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
www.boost-consulting.com
- Emacs defeats ClearType, David Abrahams, 2005/06/02
- Re: Emacs defeats ClearType, jasonr, 2005/06/03
- Re: Emacs defeats ClearType, David Abrahams, 2005/06/03
- Re: Emacs defeats ClearType,
David Abrahams <=
- [PING] ClearType Patch, David Abrahams, 2005/06/08
- Re: [PING] ClearType Patch, Eli Zaretskii, 2005/06/08
- Re: [PING] ClearType Patch, David Abrahams, 2005/06/08
- Re: [PING] ClearType Patch, Stefan Monnier, 2005/06/08
- Re: [PING] ClearType Patch, David Abrahams, 2005/06/08
- Re: [PING] ClearType Patch, Eli Zaretskii, 2005/06/08