Patch: overstrike/bold in Windows build

Patch: overstrike/bold in Windows build

[Ben North]

The patch below fixed a problem I've noticed with a recent Windows build
of emacs (first noticed in the binary distribution from

   http://ourcomments.org/Emacs/EmacsW32.html

but, if I'm using arch correctly, also present in the latest CVS/arch
code).

When overstriking to simulate a bold font, the display is often/usually
slightly garbled.  The first character of an output string then gets its
leftmost column doubled, but the rest just shifts rightwards one pixel.
The patch fixes this for me, and the setting/resetting of the background
mode does not seem too expensive.  It's possible that the save/restore
is unnecessary because SetBkMode() seems to be called everywhere it
matters, so the patch could perhaps be simplified to the second version,
which also seems to work for me.  Somebody who knows the code better
would be able to tell.

Reproduction of the problem might be tricky since it relies on a
particular font set-up.  The problem does not appear in a build for the
X windowing system, and the patch below changes the logic in w32term.c
so that it seems to mirror what happens in xterm.c, with regard to
handling of the 'for_overlaps' field, so I think it's right.

Ben.


---- first version of patch, with save/restore of background mode ----

--- ORIG/w32term.c
+++ w32term.c   2006-10-26 15:24:52.005290300 +0100
@@ -1591,7 +1591,10 @@
         {
           /* For overstriking (to simulate bold-face), draw the
              characters again shifted to the right by one pixel.  */
+          int old_BkMode = GetBkMode (s->hdc);
+          SetBkMode (s->hdc, TRANSPARENT);
           w32_text_out (s, x + 1, s->ybase - boff, s->char2b, s->nchars);
+          SetBkMode (s->hdc, old_BkMode);
         }
     }
   if (s->font && s->font->hfont)


---- second version of patch, without save/restore of background mode ----

--- ORIG/w32term.c
+++ w32term.c   2006-10-26 15:24:20.439586300 +0100
@@ -1591,6 +1591,7 @@
         {
           /* For overstriking (to simulate bold-face), draw the
              characters again shifted to the right by one pixel.  */
+          SetBkMode (s->hdc, TRANSPARENT);
           w32_text_out (s, x + 1, s->ybase - boff, s->char2b, s->nchars);
         }
     }

Re: Patch: overstrike/bold in Windows build

[Juanma Barranquero]

On 10/26/06, Ben North <ben@redfrontdoor.org> wrote:

> When overstriking to simulate a bold font, the display is often/usually
> slightly garbled.  The first character of an output string then gets its
> leftmost column doubled, but the rest just shifts rightwards one pixel.

Is this the same problem shown here:
http://lists.gnu.org/archive/html/emacs-devel/2006-01/msg01232.html
? If so, I'm gonna be a very happy chap.

> Reproduction of the problem might be tricky since it relies on a
> particular font set-up.

I have no problem reproducing the bug, I see it every day on my
laptop. I'll try your fix later today and report.

-- 
                    /L/e/k/t/u

Re: Patch: overstrike/bold in Windows build

[Ben North]

Juanma Barranquero <lekktu@gmail.com>:
> On 10/26/06, Ben North <ben@redfrontdoor.org> wrote:
> > When overstriking to simulate a bold font, the display is often/usually
> > slightly garbled.  The first character of an output string then gets its
> > leftmost column doubled, but the rest just shifts rightwards one pixel.
>
> Is this the same problem shown here:
> http://lists.gnu.org/archive/html/emacs-devel/2006-01/msg01232.html
> ?

Looks very much like it might be, yes.

> I'll try your fix later today and report.

Thanks --- hope it works for you.

Ben.

Re: Patch: overstrike/bold in Windows build

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

I've tested your patch in a setup which *doesn't* suffer the problem,
and the results are a little weird.

The 1-* set of images is for Lucida Console.

The 2-* set is for a font which I did once by adding the euro sign to
a font whose name I've forgotten (perhaps Lucida Sans Typewriter).
That's the one I use everywhere; it looks OK on desktop computers, but
on the laptop it shows the problem you're trying to fix.

In every set, *-normal is the non-bold face, *-bold is the bold face
before your patch, and *-patched is the bold face after your patch. As
you can see, the 2-* font is almost unusable in bold mode with your
patch.

I'll try at home and report any other relevant info.

-- 
                    /L/e/k/t/u

[-- Attachment #2: 1-normal.png --]
[-- Type: image/png, Size: 1493 bytes --]

[-- Attachment #3: 1-bold.png --]
[-- Type: image/png, Size: 1436 bytes --]

[-- Attachment #4: 1-patched.png --]
[-- Type: image/png, Size: 1477 bytes --]

[-- Attachment #5: 2-normal.png --]
[-- Type: image/png, Size: 1598 bytes --]

[-- Attachment #6: 2-bold.png --]
[-- Type: image/png, Size: 1637 bytes --]

[-- Attachment #7: 2-patched.png --]
[-- Type: image/png, Size: 1802 bytes --]

[-- Attachment #8: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Patch: overstrike/bold in Windows build

[Ben North]

Juanma Barranquero <lekktu@gmail.com> wrote:
> I've tested your patch in a setup which *doesn't* suffer the problem,
> and the results are a little weird.

Thanks for trying this out and providing the resulting PNGs.

> The 1-* set of images is for Lucida Console.

These look as I would expect in both the -bold and -patched images.
1-bold show the doubled left column of the starting "w", then every
other character is just shifted right one pixel.  1-patched correctly
"OR"s them together.  (I haven't checked pixel-by-pixel, but it looks
like that is what's happening.)

> The 2-* set is for a font which I did once by adding the euro sign to
> a font whose name I've forgotten (perhaps Lucida Sans Typewriter).
> That's the one I use everywhere; it looks OK on desktop computers, but
> on the laptop it shows the problem you're trying to fix.

One idea: Is the 2-* set made with a BDF font?  That would go through a
different code-path, although I haven't fully got to grips with those
details.

It looks like 2-bold is already doing some sort of antialiasing, despite
the fact that in the unpatched code, it looks like the background-mode
is OPAQUE for the one-pixel-shifted rendering.  Perhaps there's some
interaction with what antialiasing and/or ClearText (on laptops?) is
specified in the font and/or system-wide?

As you can tell, I've only started looking at this code in the past day
or two so don't really know what I'm doing.  I'm not sure how much time
I'll have to hack on this, but if you send me the font used in 2-* and
relevant settings (maybe off-list), I can see if I can reproduce your
results.

Re: Patch: overstrike/bold in Windows build

[Juanma Barranquero]

On 10/27/06, Ben North <ben@redfrontdoor.org> wrote:

> One idea: Is the 2-* set made with a BDF font?

No. As I said, I used some long-forgotten font editor to open a font I
liked, I pasted the euro sign from a similar font at the right
codepoint, and I've been using it happily ever after. (I think all
this is not strictly illegal, as it is a personal use of the font and
I've never distributed it, but who knows...)

> Perhaps there's some
> interaction with what antialiasing and/or ClearText (on laptops?)

ClearText was inactive.

Hmm. Very interesting. The font I'm using already has Bold, Oblique
and Bold Oblique variants. So I think what's happening is that, when I
set the font to bold, Emacs uses the bold variant... and then somehow
thinks it doesn't support bold and tries to synthesize it. If I remove
the variants from \Windows\fonts and leave just the normal font, your
code works right.

-- 
                    /L/e/k/t/u

Re: Patch: overstrike/bold in Windows build

[Ben North]

> Very interesting. The font I'm using already has Bold, Oblique
> and Bold Oblique variants. So I think what's happening is that, when I
> set the font to bold, Emacs uses the bold variant... and then somehow
> thinks it doesn't support bold and tries to synthesize it. If I remove
> the variants from \Windows\fonts and leave just the normal font, your
> code works right.

This sounds like what is happening, yes, and explains why the 2-bold
file looked bold and antialiased --- it is the real bold font.  It looks
like my patch is correct, then, but that it's revealing a problem
elsewhere, i.e., in the code that decides when "synthetic" bold is
required?  I'll dig into that if I have time, but if someone who knows
that part of the code better beats me to it, so much the better.

Re: Patch: overstrike/bold in Windows build

[Juanma Barranquero]

On 10/27/06, Ben North <ben@redfrontdoor.org> wrote:

> It looks like my patch is correct, then, but that
> it's revealing a problem elsewhere, i.e., in the code
> that decides when "synthetic" bold is required?

Isn't it nice, when fixing a bug reveals another? :)

> I'll dig into that if I have time, but if someone who
> knows that part of the code better beats me to it,
> so much the better.

Additional info: without your patch, I see the original problem only
when I have ClearType enabled.

-- 
                    /L/e/k/t/u

Re: Patch: overstrike/bold in Windows build

[Ben North]

Juanma Barranquero <lekktu@gmail.com> wrote:
> On 10/27/06, Ben North <ben@redfrontdoor.org> wrote:
> > It looks like my patch is correct, then, but that
> > it's revealing a problem elsewhere, i.e., in the code
> > that decides when "synthetic" bold is required?
>
> Isn't it nice, when fixing a bug reveals another? :)

Hmm.  Very curious.  The code which decides whether overstriking is
necessary is in xfaces.c, around line 6689.  The logic is:

      if (want_weight > XLFD_WEIGHT_MEDIUM && want_weight > got_weight)
	{
	  /* We want a bold font, but didn't get one; try to use
	     overstriking instead to simulate bold-face.  However,
	     don't overstrike an already-bold fontn unless the
	     desired weight grossly exceeds the available weight.  */
	  if (got_weight > XLFD_WEIGHT_MEDIUM)
	    *needs_overstrike = (got_weight - want_weight) > 2;
	  else
	    *needs_overstrike = 1;
	}

but the outer "if" means that we only get inside if got_weight <
want_weight, and in that case, the value of (got_weight - want_weight)
depends on whether your compiler represents the enum as signed or
unsigned.  The test code

   #include <stdio.h>

   int main(int argc, char **argv)
   {
      enum E { E1, E2 };
      enum E e1 = E1, e2 = E2;

      if (e1 - e2 > 2)
         printf("yes\n");
      else
         printf("no\n");
   }

produces "yes" when compiled with gcc, but "no" when compiled with
MSVC's "cl".  In any case, the comment suggests that subtraction is the
wrong way round.  I suspect you must be building with gcc, to get the
incorrect overstrike behaviour?  I'm building with MSVC so don't see it.
Could you try swapping the subtraction round, as in this patch?  (Also
fixes typo in comment.)

--- ORIG/xfaces.c
+++ xfaces.c    2006-10-27 17:57:43.034173200 +0100
@@ -6688,10 +6688,10 @@
         {
           /* We want a bold font, but didn't get one; try to use
              overstriking instead to simulate bold-face.  However,
-             don't overstrike an already-bold fontn unless the
+             don't overstrike an already-bold font unless the
              desired weight grossly exceeds the available weight.  */
           if (got_weight > XLFD_WEIGHT_MEDIUM)
-            *needs_overstrike = (got_weight - want_weight) > 2;
+            *needs_overstrike = (want_weight - got_weight) > 2;
           else
             *needs_overstrike = 1;
         }

Re: Patch: overstrike/bold in Windows build

[Juanma Barranquero]

On 10/27/06, Ben North <ben@redfrontdoor.org> wrote:
> I suspect you must be building with gcc, to get the
> incorrect overstrike behaviour?

That's correct.

> Could you try swapping the subtraction round, as in this patch?  (Also
> fixes typo in comment.)

With both of your patches applied, now I get a readable, correctly
boldfaced font either with or without ClearType.

Thanks!

Please commit the changes (or send them to me with an appropriate
ChangeLog entry if you don't have write access).

                    /L/e/k/t/u