From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Abrahams Newsgroups: gmane.emacs.devel Subject: Re: Emacs defeats ClearType Date: Fri, 03 Jun 2005 11:27:08 -0400 Message-ID: References: <1117787455.42a0153fdf46f@webmail.freedom2surf.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: sea.gmane.org 1117813773 14040 80.91.229.2 (3 Jun 2005 15:49:33 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 3 Jun 2005 15:49:33 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 03 17:49:30 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DeEOu-00009y-0r for ged-emacs-devel@m.gmane.org; Fri, 03 Jun 2005 17:48:01 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DeEUW-0005L1-Un for ged-emacs-devel@m.gmane.org; Fri, 03 Jun 2005 11:53:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DeEQn-0003Yy-O4 for emacs-devel@gnu.org; Fri, 03 Jun 2005 11:49:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DeEQK-0003JC-Kn for emacs-devel@gnu.org; Fri, 03 Jun 2005 11:49:28 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DeEQD-00035W-W9 for emacs-devel@gnu.org; Fri, 03 Jun 2005 11:49:22 -0400 Original-Received: from [80.91.229.2] (helo=ciao.gmane.org) by monty-python.gnu.org with esmtp (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1DeEGb-0001k3-Or for emacs-devel@gnu.org; Fri, 03 Jun 2005 11:39:26 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DeE5b-0004aB-IT for emacs-devel@gnu.org; Fri, 03 Jun 2005 17:28:05 +0200 Original-Received: from 146-115-127-135.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com ([146.115.127.135]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 Jun 2005 17:28:03 +0200 Original-Received: from dave by 146-115-127-135.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 Jun 2005 17:28:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 86 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 146-115-127-135.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (windows-nt) Cancel-Lock: sha1:MOY3OPoD1lnxCGByyvosrfyiI2Q= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:38081 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:38081 --=-=-= jasonr@f2s.com writes: > Quoting David Abrahams : > >> 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 . 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. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=w32term.patch --- 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 --=-=-= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel --=-=-=--