emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Variable pitch text filling


From: Eli Zaretskii
Subject: Re: Variable pitch text filling
Date: Mon, 29 Nov 2021 16:01:15 +0200

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 29 Nov 2021 14:46:57 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Right.  This reminds me -- perhaps we'd want to distribute the extra
> >> space both before and after the glyph, to centre it within its allotted
> >> width?
> >
> > I don't think so, because that would move the leftmost character away
> > from the window-edge.
> 
> Yes...  but it that necessarily bad?

Yes, IMO, because the text will seem to shift.

It is also unnecessary, because having 2 pixels to the right of each
character is practically indistinguishable from having one pixel on
the left and 1 pixel on the right: you still end up with 2 pixels
between any two characters.

> > That's not the best possibility, because if some part of the affected
> > text uses a smaller font, you'd see glyphs that are too-widely spaced?
> 
> All these specs (`space' and whatnot) refer to FRAME_COLUMN_WIDTH in
> their logic.  (I mean, for those parts that aren't actual pixels.)

Yes, but FRAME_COLUMN_WIDTH only reflects the dimensions of the
frame's default face's font.  If you use another face with a different
(smaller) font, FRAME_COLUMN_WIDTH won't change.  Think about a
feature where footnotes are shown in a smaller font.

> And I'm not quite sure what you mean here -- we're talking about
> allowing people to "quantise" the widths to some common multiple, which
> means that that is indeed what you'd see.  But that's what the user
> asked for.
> 
> So mixing in smaller fonts in such a display wouldn't really be part of
> the remit...

I think it should be.  Each face in Emacs has what I call "ASCII
font": that's the face's font used for the ASCII (and usually also
Latin) characters.  My idea is to take the "standard" width from that
ASCII font of the face.  Then we can provide this feature for every
possible face, and the result will be visually reasonable, since
smaller faces will have smaller "standard" width, and will have fewer
added pixels to the double-width characters displayed in that face.

It's the same idea as I used for the enlarged height (which was
rejected, but not because of this aspect), just for the width and not
for the height.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]