Re: Bug#318162: xterm: boldMode enabled even if bold font is used

2005-07-18 Thread Thomas Dickey
On Mon, Jul 18, 2005 at 12:46:49PM +0200, David Martínez Moreno wrote:
> El Domingo, 17 de Julio de 2005 12:34, Thomas Dickey escribió:
> > On Sun, Jul 17, 2005 at 10:17:32AM +0800, Eugene Konev wrote:
> > > The problem is font name stored in normal is being overwritten by a
> > > bold font name and then normal is used in comparison with a
> > > myfonts.f_b to decide whether they are the same and whether to turn on
> > > overstriking. The attached patch fixes it.
> >
> > thanks (now I'll have to look/see when it was broken...)
> 
>   Please, tell us if we could add the patch from Eugene to #203 patchset, 
> i.e., 
> if you found the patch valid, and fix the bold fonts issue with the next 
> release.

It looks valid, and I checked it into my development tree as part of changes
toward #204.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpTDAdK27wsg.pgp
Description: PGP signature


Re: Bug#318162: xterm: boldMode enabled even if bold font is used

2005-07-18 Thread David Martínez Moreno
El Domingo, 17 de Julio de 2005 12:34, Thomas Dickey escribió:
> On Sun, Jul 17, 2005 at 10:17:32AM +0800, Eugene Konev wrote:
> > The problem is font name stored in normal is being overwritten by a
> > bold font name and then normal is used in comparison with a
> > myfonts.f_b to decide whether they are the same and whether to turn on
> > overstriking. The attached patch fixes it.
>
> thanks (now I'll have to look/see when it was broken...)

Please, tell us if we could add the patch from Eugene to #203 patchset, 
i.e., 
if you found the patch valid, and fix the bold fonts issue with the next 
release.

Best regards,


Ender.
-- 
Uh, we had a slight weapons malfunction, but
 uh... everything's perfectly all right now. We're
 fine. We're all fine here now, thank you. How are you?
-- Han Solo (Star Wars).
--
Debian developer


pgpoNb1fdCOBw.pgp
Description: PGP signature


Bug#318162: xterm: boldMode enabled even if bold font is used

2005-07-17 Thread Thomas Dickey
On Sun, Jul 17, 2005 at 10:17:32AM +0800, Eugene Konev wrote:
> 
> The problem is font name stored in normal is being overwritten by a
> bold font name and then normal is used in comparison with a
> myfonts.f_b to decide whether they are the same and whether to turn on
> overstriking. The attached patch fixes it.

thanks (now I'll have to look/see when it was broken...)

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpqPcq6uisN4.pgp
Description: PGP signature


Bug#318162: xterm: boldMode enabled even if bold font is used

2005-07-16 Thread Eugene Konev

The problem is font name stored in normal is being overwritten by a
bold font name and then normal is used in comparison with a
myfonts.f_b to decide whether they are the same and whether to turn on
overstriking. The attached patch fixes it.

Index: xorg-x11-6.8.2.dfsg.1/programs/xterm/fontutils.c
===
--- xorg-x11-6.8.2.dfsg.1.orig/programs/xterm/fontutils.c   2005-07-16 
22:03:19.0 +0800
+++ xorg-x11-6.8.2.dfsg.1/programs/xterm/fontutils.c2005-07-16 
22:06:26.0 +0800
@@ -647,7 +647,7 @@
 Pixel new_normal;
 Pixel new_revers;
 char *tmpname = NULL;
-char normal[MAX_FONTNAME];
+char normal[MAX_FONTNAME], bold[MAX_FONTNAME];
 Bool proportional = False;
 
 memset(&myfonts, 0, sizeof(myfonts));
@@ -721,7 +721,7 @@
}
 
if (myfonts.f_wb == 0 && !is_double_width_font(bfs)) {
-   fp = get_font_name_props(screen->display, bfs, normal);
+   fp = get_font_name_props(screen->display, bfs, bold);
if (fp != 0) {
myfonts.f_wb = widebold_font_name(fp);
TRACE(("...derived wide/bold %s\n", myfonts.f_wb));


Bug#318162: xterm: boldMode enabled even if bold font is used

2005-07-16 Thread Thomas Dickey
On Sat, Jul 16, 2005 at 08:49:35AM +0200, Tobias Diedrich wrote:
> Thomas Dickey wrote:
> 
> > That sounds like what is being reported, but since I didn't touch _that_
> > part of the logic, I'm left with the impression that you have a slightly
> > different set of fonts installed than I - and the modifications I made to
> > the XLFD wildcards are breaking in that case.  If I had a debug-trace from
> > xterm (configure --enable-trace), I could probably see exactly what the
> > problem is.
> 
> FWIW, I use efonts:

thanks - that is something I can test (I didn't have those installed).
Since your font resources are specific, that's helpful.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpZaK00M5tZM.pgp
Description: PGP signature


Bug#318162: xterm: boldMode enabled even if bold font is used

2005-07-16 Thread Tobias Diedrich
Thomas Dickey wrote:

> That sounds like what is being reported, but since I didn't touch _that_
> part of the logic, I'm left with the impression that you have a slightly
> different set of fonts installed than I - and the modifications I made to
> the XLFD wildcards are breaking in that case.  If I had a debug-trace from
> xterm (configure --enable-trace), I could probably see exactly what the
> problem is.

FWIW, I use efonts:
ii  xfonts-efont-unicode   0.4.0-4/efont/
Unicode fonts for X which cover various scripts
ii  xfonts-efont-unicode-ib0.4.0-4/efont/
Unicode fonts for X (italic and bold)

And the following in .Xresources:

XTerm*locale: true
XTerm*wideChars: true
XTerm*cjkWidth: false
XTerm*eightBitInput: false
XTerm*tekInhibit: true
XTerm*visualBell: true

XTerm*fontMenu*fontdefault*Label:   Default
XTerm*font: -efont-fixed-medium-r-normal-*-16-160-75-75-c-80-iso10646-1
XTerm*wideFont: -efont-fixed-medium-r-normal-*-16-160-75-75-c-160-iso10646-1

XTerm*font1.Label: efont 12 pixel
XTerm*font1: -efont-fixed-medium-r-normal-*-12-120-75-75-c-60-iso10646-1
XTerm*wideFont1: -efont-fixed-medium-r-normal-*-12-120-75-75-c-120-iso10646-1
XTerm*font2.Label: misc  13 pixel
XTerm*font2: 
-misc-fixed-medium-r-semicondensed-*-13-120-75-75-c-60-iso10646-1
XTerm*wideFont2: -misc-fixed-medium-r-normal-*-13-120-75-75-c-120-iso10646-1
XTerm*font3.Label: efont 14 pixel
XTerm*font3: -efont-fixed-medium-r-normal-*-14-140-75-75-c-70-iso10646-1
XTerm*wideFont3: -efont-fixed-medium-r-normal-*-14-140-75-75-c-140-iso10646-1
XTerm*font4.Label: efont 16 pixel
XTerm*font4: -efont-fixed-medium-r-normal-*-16-160-75-75-c-80-iso10646-1
XTerm*wideFont4: -efont-fixed-medium-r-normal-*-16-160-75-75-c-160-iso10646-1
XTerm*font5.Label: misc  18 pixel
XTerm*font5: -misc-fixed-medium-r-normal-*-18-120-100-100-c-90-iso10646-1
XTerm*wideFont5: -misc-fixed-medium-r-normal-*-18-120-100-100-c-180-iso10646-1
XTerm*font6.Label: efont 24 pixel
XTerm*font6: -efont-fixed-medium-r-normal-*-24-240-75-75-c-120-iso10646-1
XTerm*wideFont6: -efont-fixed-medium-r-normal-*-24-240-75-75-c-240-iso10646-1

-- 
Tobias  PGP: http://9ac7e0bc.uguu.de


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#318162: xterm: boldMode enabled even if bold font is used

2005-07-15 Thread Thomas Dickey
On Thu, Jul 14, 2005 at 04:00:33PM +0200, Tobias Diedrich wrote:
> Package: xterm
> Version: 6.8.2.dfsg.1-2
> Followup-For: Bug #318162
> 
> 
> According to the xterm manpage, while boldMode is true by default,
> if a bold font variant is found for a given non-bold font or specified
> with -fb, boldMode should be turned off automatically.
> Apparently this is broken and xterm currently does overstriking of the
> bold font (producing an even bolder, near unreadable font).

That sounds like what is being reported, but since I didn't touch _that_
part of the logic, I'm left with the impression that you have a slightly
different set of fonts installed than I - and the modifications I made to
the XLFD wildcards are breaking in that case.  If I had a debug-trace from
xterm (configure --enable-trace), I could probably see exactly what the
problem is.

Since it's working fine for me, it'll otherwise be a while until I stumble
over the problem.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgp1vacYIFgYn.pgp
Description: PGP signature


Bug#318162: xterm: boldMode enabled even if bold font is used

2005-07-14 Thread Tobias Diedrich
Package: xterm
Version: 6.8.2.dfsg.1-2
Followup-For: Bug #318162


According to the xterm manpage, while boldMode is true by default,
if a bold font variant is found for a given non-bold font or specified
with -fb, boldMode should be turned off automatically.
Apparently this is broken and xterm currently does overstriking of the
bold font (producing an even bolder, near unreadable font).

Workaround:
Disable boldMode in .Xresources ("XTerm*boldMode: false").

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11.12-ac7-vs1.9.5-htbatm-imq
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages xterm depends on:
ii  libc6 2.3.2.ds1-22   GNU C Library: Shared libraries an
ii  libexpat1 1.95.8-3   XML parsing C library - runtime li
ii  libfontconfig12.3.2-1generic font configuration library
ii  libfreetype6  2.1.10-1   FreeType 2 font engine, shared lib
ii  libice6   6.8.2.dfsg.1-2 Inter-Client Exchange library
ii  libncurses5   5.4-8  Shared libraries for terminal hand
ii  libsm66.8.2.dfsg.1-2 X Window System Session Management
ii  libxaw8   6.8.2.dfsg.1-2 X Athena widget set library
ii  libxext6  6.8.2.dfsg.1-2 X Window System miscellaneous exte
ii  libxft2   2.1.7-1FreeType-based font drawing librar
ii  libxmu6   6.8.2.dfsg.1-2 X Window System miscellaneous util
ii  libxp66.8.2.dfsg.1-2 X Window System printing extension
ii  libxpm4   6.8.2.dfsg.1-2 X pixmap library
ii  libxrender1   1:0.9.0-2  X Rendering Extension client libra
ii  libxt66.8.2.dfsg.1-2 X Toolkit Intrinsics
ii  xlibs 6.8.2.dfsg.1-2 X Window System client libraries m
ii  xlibs-data6.8.2.dfsg.1-2 X Window System client data

Versions of packages xterm recommends:
ii  xutils6.8.2.dfsg.1-2 X Window System utility programs

-- debconf information:
  xterm/clobber_xresource_file: true
  xterm/xterm_needs_devpts:


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]