bug#26959: Feature request: bold underlines

bug#26959: Feature request: bold underlines

[Clément Pit--Claudel]

Hi bug-gnu-emacs,

Could underline thickness be made configurable? It would be nice to be able to pick between regular and thick/bold underlines (the later would be obtained by doubling the usual underline thickness, I imagine).

Thanks,
Clément.

bug#26959: Feature request: bold underlines

[Drew Adams]

> Could underline thickness be made configurable? It would be nice to be able
> to pick between regular and thick/bold underlines (the later would be
> obtained by doubling the usual underline thickness, I imagine).

See my reply to bug #26958.  Should we have two requests:

1. Wavy (and plain) underline to follow text scaling (#26958).
2. Be able to configure underline line-width (#26959).

Is #2 enough?  If we could customize the :line-width for :underline
(and :overline? and :strike-through?), would that be sufficient, or
is there also a need for such lines to be sensitive to text scaling?

bug#26959: Feature request: bold underlines

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1127 bytes --]

On 2017-05-17 00:21, Drew Adams wrote:
>> Could underline thickness be made configurable? It would be nice to be able
>> to pick between regular and thick/bold underlines (the later would be
>> obtained by doubling the usual underline thickness, I imagine).
> 
> See my reply to bug #26958.  Should we have two requests:

Thanks for your replies :)

> 1. Wavy (and plain) underline to follow text scaling (#26958).
> 2. Be able to configure underline line-width (#26959).

Yes, that's a great summary.

> Is #2 enough?  If we could customize the :line-width for :underline
> (and :overline? and :strike-through?), would that be sufficient, or
> is there also a need for such lines to be sensitive to text scaling?

I don't think so — sensitivity to text scaling would be a useful, distinct feature.  Otherwise Lisp code will have to inspect font sizes and adjust thickness based on it, which will cause inconsistencies.  Additionally, the amount of space between the text and the underline needs to be adjusted when the font size changes — and this is currently done on GNU/Linux already.

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#26959: Feature request: bold underlines

[Drew Adams]

> > See my reply to bug #26958.  Should we have two requests:
> > 1. Wavy (and plain) underline to follow text scaling (#26958).
> > 2. Be able to configure underline line-width (#26959).
> 
> Yes, that's a great summary.
> 
> > Is #2 enough?  If we could customize the :line-width for :underline
> > (and :overline? and :strike-through?), would that be sufficient, or
> > is there also a need for such lines to be sensitive to text scaling?
> 
> I don't think so — sensitivity to text scaling would be a useful, distinct
> feature.  Otherwise Lisp code will have to inspect font sizes and adjust
> thickness based on it, which will cause inconsistencies.  Additionally, the
> amount of space between the text and the underline needs to be adjusted when
> the font size changes — and this is currently done on GNU/Linux already.

Whatever decision is made about what the most appropriate behavior
is, should we make it optional, e.g., give users a way to _not_
scale such lines, boxes, etc.?

bug#26959: Feature request: bold underlines

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1241 bytes --]

On 2017-05-17 10:04, Drew Adams wrote:
>>> See my reply to bug #26958.  Should we have two requests:
>>> 1. Wavy (and plain) underline to follow text scaling (#26958).
>>> 2. Be able to configure underline line-width (#26959).
>>
>> Yes, that's a great summary.
>>
>>> Is #2 enough?  If we could customize the :line-width for :underline
>>> (and :overline? and :strike-through?), would that be sufficient, or
>>> is there also a need for such lines to be sensitive to text scaling?
>>
>> I don't think so — sensitivity to text scaling would be a useful, distinct
>> feature.  Otherwise Lisp code will have to inspect font sizes and adjust
>> thickness based on it, which will cause inconsistencies.  Additionally, the
>> amount of space between the text and the underline needs to be adjusted when
>> the font size changes — and this is currently done on GNU/Linux already.
> 
> Whatever decision is made about what the most appropriate behavior
> is, should we make it optional, e.g., give users a way to _not_
> scale such lines, boxes, etc.?

I think we should wait for an explicit request before introducing such an option: I have not seen complaints about the behavior as currently implemented in GNU/Linux.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#26959: Feature request: bold underlines

[Drew Adams]

> > Whatever decision is made about what the most appropriate behavior
> > is, should we make it optional, e.g., give users a way to _not_
> > scale such lines, boxes, etc.?
> 
> I think we should wait for an explicit request before introducing such an
> option: I have not seen complaints about the behavior as currently
> implemented in GNU/Linux.

So you are suggesting not only a change in the _default_ behavior
but a change in the behavior altogether.  Why is that the right
approach?  Don't you expect that there are some users or libraries
that currently expect or depend on the current behavior?

Just because someone thinks a change in behavior is a good idea
(and I have no opinion on this one, so far), it doesn't follow
that Emacs should make that change by default or (especially)
as the only possible behavior.

bug#26959: Feature request: bold underlines

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1394 bytes --]

On 2017-05-17 12:06, Drew Adams wrote:
>>> Whatever decision is made about what the most appropriate behavior
>>> is, should we make it optional, e.g., give users a way to _not_
>>> scale such lines, boxes, etc.?
>>
>> I think we should wait for an explicit request before introducing such an
>> option: I have not seen complaints about the behavior as currently
>> implemented in GNU/Linux.
> 
> So you are suggesting not only a change in the _default_ behavior
> but a change in the behavior altogether. 

My OP (in the other thread) was about underlines. With my proposal, the behavior would not change on Linux for straight underlines.

> Why is that the right
> approach?  Don't you expect that there are some users or libraries
> that currently expect or depend on the current behavior?

How would a library depend on this, given that it isn't consistent across platforms, and not observable from ELisp?

> Just because someone thinks a change in behavior is a good idea
> (and I have no opinion on this one, so far), it doesn't follow
> that Emacs should make that change by default or (especially)
> as the only possible behavior.

Sure. But until someone voices support for what others consider as a bug, it might not make sense to expend resources adding a flag to revert to the old behavior. 
In any case, maybe we should move this discussion to #26958?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#26959: Feature request: bold underlines

[Drew Adams]

> >>> Whatever decision is made about what the most appropriate behavior
> >>> is, should we make it optional, e.g., give users a way to _not_
> >>> scale such lines, boxes, etc.?
> >>
> >> I think we should wait for an explicit request before introducing such an
> >> option: I have not seen complaints about the behavior as currently
> >> implemented in GNU/Linux.

Have we seen complaints by MS Windows users that underlines (straight,
curly) do not scale with the text?

> > So you are suggesting not only a change in the _default_ behavior
> > but a change in the behavior altogether.
> 
> My OP (in the other thread) was about underlines. With my proposal,
> the behavior would not change on Linux for straight underlines.

But it would change for wavy underlines, no?

And it would likely change for underlines more generally on some
non-[GNU]Linux platforms, no?
 
> > Why is that the right
> > approach?  Don't you expect that there are some users or libraries
> > that currently expect or depend on the current behavior?
> 
> How would a library depend on this, given that it isn't consistent across
> platforms, and not observable from ELisp?

A user may be on only one platform.  A user's code (including a
library) might expect particular behavior on this or that platform.

Like it or not, people get used to existing behaviors, and people
write code that expects that behavior.

It's possible for Emacs to change the behavior, but it's unusual
to change not only the default behavior but the only possible one.

Is there a reason why we would have to do that?  Why not offer a
choice?  Why not let a user set her preference?  Why not let a
program control whether such line-scaling occurs?

> > Just because someone thinks a change in behavior is a good idea
> > (and I have no opinion on this one, so far), it doesn't follow
> > that Emacs should make that change by default or (especially)
> > as the only possible behavior.
> 
> Sure. But until someone voices support for what others consider as a bug, it
> might not make sense to expend resources adding a flag to revert to the old
> behavior.

If it is decided that the current behavior is just a bug then yes,
it could be changed unconditionally.  Is it that clear that this is
only a bug?  Is there a reason to suppose that no one would want
the current behavior or no one would want to choose whether to
scale such lines?

> In any case, maybe we should move this discussion to #26958?

Yes.  This one (#26959) already takes the point of view of allowing
users a choice.  (That's a good thing.)

bug#26959: Feature request: bold underlines

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 235 bytes --]

On 2017-05-17 15:48, Drew Adams wrote:
> Like it or not, people get used to existing behaviors, and people
> write code that expects that behavior.

I don't understand how Lisp code can depend on this behavior. Can you clarify?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#26959: Feature request: bold underlines

[Drew Adams]

> > Like it or not, people get used to existing behaviors, and people
> > write code that expects that behavior.
> 
> I don't understand how Lisp code can depend on this behavior.
> Can you clarify?

Is it clearer if I say that people write code to do something,
and they can expect it to do what it did previously.

The point is that it is not only about a user option.  You might
have written code that had a given behavior, and now that behavior
changes without your having changed the code.  Whether you are a
user of that code or its maintainer, you might not appreciate the
change.

Giving users and code a way to choose the behavior usually makes
sense.  Is there some special reason it would not make sense in
this case?  What is the imperative to change from A as the only
possible behavior to B as the only possible behavior, unless it
is agreed that A is a bug and B is the right fix for it?

This is all hypothetical.  I don't have a horse in this race.
I have no idea which behavior is better in general, or which
would be preferred by most users most of the time.  Maybe you
can point to a UI guideline somewhere or some doc that speaks
about this?

Why does it make sense, a priori, that an underline thickness
would scale along with the text?  Not to mention the nuances
that Eli tried to point out.  It is already tricky to deal
with Emacs box line-widths and such together with things like
interline spacing.

I think that before we even get to the question of whether
this should be changed unilaterally or offered as a new
possibility the behavior should be well specified or
demonstrated.

FWIW, I just checked in a non-Emacs application (Arbortext
editor) on MS Windows, and non-wavy underlining does not seem
to zoom along with the text.

Now maybe that's because the particular use of that wavy
underlining, in this application, is to highlight spelling errors.

One could imagine that in one use case it is used for something
like that, and it is deemed better not to scale it, but in
another use case, where the underlining is considered part of
the text itself, it is deemed better to scale the underlining
too.  I kind of expected that in the Arbortext case, expecting
to see that a normal (straight) underline would zoom along with
its text.  But no, at least for Arbortext that is not the case.

Still, I think it makes sense, a priori, to let Emacs code
decide in any given context: is the underlining to be treated
as in a sense part of the text, i.e., do you want it to scale
with the text, or is it to be treated separately?  (Clearly it
needs to zoom horizontally along with the text.)

I tried the same test with MS Word.  There, the wavy underline
to show spelling problems likewise does not scale with the text,
but a straight underline does scale with the text.  (That's what
I was expecting for Arbortext too.)

In terms of use cases I think it mostly comes down to whether
a given user or application wants to consider the particular
underlining style to be, in a sense, part of the text itself,
or to belong to some other level (e.g. content annotation/metadata).

(And we are still writing about bug #26959 in the bug #26958
thread...)

bug#26959: Feature request: bold underlines

[Clément Pit--Claudel]

On 2017-05-17 17:09, Drew Adams wrote:
> I tried the same test with MS Word.  There, the wavy underline
> to show spelling problems likewise does not scale with the text

Thanks for testing.  Did you check whether it scaled with pixel density, though? LibreOffice does that.

Clément.

bug#26959: Feature request: bold underlines

[Drew Adams]

> > I tried the same test with MS Word.  There, the wavy underline
> > to show spelling problems likewise does not scale with the text
> 
> Thanks for testing.  Did you check whether it scaled with pixel density,
> though? LibreOffice does that.

Dunno what that means.  I took screenshots and checked the number
of pixels in the screenshots (zooming in on them in an image editor).
HTH.

Please don't count on me to test or debug this.  I've already
spent more time on this than I wanted to.

bug#26959: Feature request: bold underlines

[Eli Zaretskii]

> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Wed, 17 May 2017 00:16:47 -0400
> 
> Could underline thickness be made configurable? It would be nice to be able to pick between regular and thick/bold underlines (the later would be obtained by doubling the usual underline thickness, I imagine).

You need to be aware of some subtleties with underlines as currently
implemented, and we should consider all of that when we decide what
kind of configurability we want and what should it do.  See below.

> > FWIW, on Windows I see neither straight nor wavy underline thicken.
> > They both continue to have the same line width (thickness) when
> > text-scaled.
> > 
> > Should they not stay the same?  Should they thicken?  Why?
> 
> Thanks for the reply! They do scale in GNU/Linux; the code in xftfont says:
> 
>       font->underline_position = -ft_face->underline_position * size / upEM;
>       font->underline_thickness = ft_face->underline_thickness * size / upEM;
> 
> The corresponding code in w32font says:
> 
>       font->underline_thickness = metrics->otmsUnderscoreSize;
>       font->underline_position = -metrics->otmsUnderscorePosition;
> 
> which might be missing the scaling?

Not all font back-ends support this scaling, and not with every font.
E.g., xfont.c doesn't support this at all, AFAICS.  And while we could
probably add this feature to MS-Windows, it will only be available
with OTF and TTF fonts (I believe it's the same on Unix and GNU
systems).

Moreover, if you mix fonts of different sizes on the same line in the
same run of consecutive underlined characters, you will see that Emacs
defines the thickness and the position of the underline at the first
character, and then reuses those values for the entire run, even if
the size of the font changes -- it doesn't recompute the values when
the font changes.  We do this because anything else will look uglier
than what we have now.

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.

Bottom line: I think the hard part here is to describe the new
behavior, and do that in way that makes sense.  Implementing that
(assuming the fonts and font backends support the requirements) should
be relatively easy, once all of these hidden issues are figured out.

bug#26959: Feature request: bold underlines

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 3630 bytes --]

On 2017-05-17 11:39, Eli Zaretskii wrote:
>> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
>> Date: Wed, 17 May 2017 00:16:47 -0400
>>
>> Could underline thickness be made configurable? It would be nice to be able to pick between regular and thick/bold underlines (the later would be obtained by doubling the usual underline thickness, I imagine).
> 
> You need to be aware of some subtleties with underlines as currently
> implemented, and we should consider all of that when we decide what
> kind of configurability we want and what should it do.  See below.
> 
>>> FWIW, on Windows I see neither straight nor wavy underline thicken.
>>> They both continue to have the same line width (thickness) when
>>> text-scaled.
>>>
>>> Should they not stay the same?  Should they thicken?  Why?
>>
>> Thanks for the reply! They do scale in GNU/Linux; the code in xftfont says:
>>
>>       font->underline_position = -ft_face->underline_position * size / upEM;
>>       font->underline_thickness = ft_face->underline_thickness * size / upEM;
>>
>> The corresponding code in w32font says:
>>
>>       font->underline_thickness = metrics->otmsUnderscoreSize;
>>       font->underline_position = -metrics->otmsUnderscorePosition;
>>
>> which might be missing the scaling?
> 
> Not all font back-ends support this scaling, and not with every font.
> E.g., xfont.c doesn't support this at all, AFAICS.  And while we could
> probably add this feature to MS-Windows, it will only be available
> with OTF and TTF fonts (I believe it's the same on Unix and GNU
> systems).

Makes sense. And, of course, the scaling is outside of Emacs' control on TTYs.

> Moreover, if you mix fonts of different sizes on the same line in the
> same run of consecutive underlined characters, you will see that Emacs
> defines the thickness and the position of the underline at the first
> character, and then reuses those values for the entire run, even if
> the size of the font changes -- it doesn't recompute the values when
> the font changes.  We do this because anything else will look uglier
> than what we have now.

I saw this, indeed.

> 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? 
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.

> Bottom line: I think the hard part here is to describe the new
> behavior, and do that in way that makes sense.  Implementing that
> (assuming the fonts and font backends support the requirements) should
> be relatively easy, once all of these hidden issues are figured out.

Thanks for the explanation.
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#26959: Feature request: bold underlines

[Eli Zaretskii]

> Cc: 26959@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@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?