On Sun, Nov 09, 2003 at 11:15:04PM -0500, Branden Robinson wrote:
| On Sat, Nov 08, 2003 at 12:09:16PM +0800, Cameron Patrick wrote:
| > I nevertheless maintain that if the requested glyph /isn't/ available,
| > it is more useful to display some approximation of the requested
| > character than a l
On Sat, Nov 08, 2003 at 12:09:16PM +0800, Cameron Patrick wrote:
> I nevertheless maintain that if the requested glyph /isn't/ available,
> it is more useful to display some approximation of the requested
> character than a little white box.
Uh, you seem to be rather glibly overlooking the require
On Sun, Nov 09, 2003 at 02:35:06PM +0100, Eduard Bloch wrote:
| Okay, I see your problem now, the terminal emulator _may_ replace the
| presented chars with equivalents in the font. But it's hell of work if
| done right, it has to check every char, locate most similar character
| in some encodings
#include
* Cameron Patrick [Sun, Nov 09 2003, 08:32:54PM]:
> On Sun, Nov 09, 2003 at 12:37:43PM +0100, Eduard Bloch wrote:
>
> | > That may be so, but gnome-terminal /does/ cope with this situation by
> | > displaying replacing the hyphen with a minus sign when the font doesn't
> |
> | Then gnom
On Sun, Nov 09, 2003 at 12:37:43PM +0100, Eduard Bloch wrote:
| > That may be so, but gnome-terminal /does/ cope with this situation by
| > displaying replacing the hyphen with a minus sign when the font doesn't
|
| Then gnome-terminal is broken and deservers a bug report.
I disagree. gnome-ter
#include
* Cameron Patrick [Sun, Nov 09 2003, 01:15:53PM]:
> | That's not a problem with the certain terminal emulator, that is a
> | problem with groff syntax not understood by many authors. Xterm works
> | just fine as UTF-8 terminal as well as mlterm/pterm/konsole/gnome-terminal
> | but the ma
On Sat, Nov 08, 2003 at 09:03:49PM +0100, Eduard Bloch wrote:
| > Many TrueType fonts don't have both a hyphen (0x2010) and a minus sign
| > (0x2212); however, groff (and thus man pages) differentiates between the
| > two in UTF-8 locales. This results in lots of man pages displaying ugly
| > box
#include
* Cameron Patrick [Fri, Nov 07 2003, 05:31:12PM]:
> Package: xterm
> Version: 4.3.0-0pre1v4
>
> Many TrueType fonts don't have both a hyphen (0x2010) and a minus sign
> (0x2212); however, groff (and thus man pages) differentiates between the
> two in UTF-8 locales. This results in lots
Cameron Patrick <[EMAIL PROTECTED]> writes:
> I nevertheless maintain that if the requested glyph /isn't/ available,
> it is more useful to display some approximation of the requested
> character than a little white box.
Agreed.
> Mozilla already handles this kind of thing. So do gvim and
> gno
On Fri, Nov 07, 2003 at 10:49:16PM -0500, Branden Robinson wrote:
| > If the default Unicode fonts are incomplete enough that they lack this
| > character, then that is probably worthy of a bug (and this one could just
| > be reassigned),
The default bitmap fonts that come with XFree are fine for
On Fri, Nov 07, 2003 at 01:11:29PM -0700, Joel Baker wrote:
> [ Disclaimer: I'm part of the XSF, but I don't generally deal with]
> [ [u]xterm So this is merely my opinion. ]
>
> It seems to me like this is an emminently *bad* slope to start down; the
> ent
On Fri, Nov 07, 2003 at 01:11:29PM -0700, Joel Baker wrote:
> If the default Unicode fonts are incomplete enough that they lack this
> character, then that is probably worthy of a bug (and this one could just
> be reassigned), but I fail to see why the application should be expected to
> do somethi
On Fri, Nov 07, 2003 at 05:31:12PM +0800, Cameron Patrick wrote:
> Package: xterm
> Version: 4.3.0-0pre1v4
>
> Many TrueType fonts don't have both a hyphen (0x2010) and a minus sign
> (0x2212); however, groff (and thus man pages) differentiates between the
> two in UTF-8 locales. This results in
Package: xterm
Version: 4.3.0-0pre1v4
Many TrueType fonts don't have both a hyphen (0x2010) and a minus sign
(0x2212); however, groff (and thus man pages) differentiates between the
two in UTF-8 locales. This results in lots of man pages displaying ugly
boxes where hyphens should be in a uxterm,
14 matches
Mail list logo
