GNU bug report logs -
#26959
Feature request: bold underlines
Previous Next
Full log
View this message in rfc822 format
> Cc: 26959 <at> debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel <at> live.com>
> Date: Wed, 17 May 2017 14:59:56 -0400
>
> > What all this means is that currently the exact visual effect of the
> > underline attribute is deliberately not well-defined: about the only
> > thing you can rely on is that you will get a horizontal line somewhere
> > in the lower portion of the characters.
> >
> > Implementing your suggestion would require that we define the behavior
> > much better, which is not easy given the different font drivers and
> > fonts, on which the user has almost no control. E.g., we will need to
> > decide whether thickness customization overrides the font-dependent
> > scaling, and if not, how these two play together. And if we want to
> > allow customization of the underline position (why not?), we will have
> > to decide what to do with it when the font size changes. And then we
> > will need to decide what to do if the font doesn't support scaling.
>
> That makes sense, but I'm not sure all of this is needed. I agree that it would be nice, but is it really necessary?
Perhaps not. But any subset of this we choose to implement should be
consistent and should make sense to users.
> In terms of code, my suggestion would translate into multiplying the `thickness' variable in xftfont by 2 when :bold t is specified in the underline's property list.
Even if the bold attribute starts in the middle of a consecutive run
of underlined characters? IOW, should this override the current
behavior of computing the thickness only once per such run?
This bug report was last modified 8 years and 29 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.