[Top][All Lists]

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

Re: Pixel-based display functions

From: Eli Zaretskii
Subject: Re: Pixel-based display functions
Date: Wed, 18 Feb 2015 17:29:42 +0200

> From: Stefan Monnier <address@hidden>
> Cc: Lars Ingebrigtsen <address@hidden>,  address@hidden,  address@hidden
> Date: Wed, 18 Feb 2015 00:53:15 -0500
> >> The line longest in characters doesn't really say much about what line
> >> is longest in pixels.
> > I beg to differ.
> They are correlated but I agree with Lars that the correlation is not
> strong enough that one can simply take the longest-line-in-chars,
> measure it, and expect the result to be the longer in pixel than all
> other lines.
> A long line of "llllllll" can be significantly shorter in pixels than
> a slightly-less-long line of "mmmmmmm" if you use something
> like Helvetica.
> And a long line of "mmmmm" can be significantly shorter than a much
> shorter line of "lllll" if the line of "lllll" uses a much larger face
> or has an embedded after-string, or ...

Granted, I knew that.

I never said this was simple, or that the longest line in character
units is the only candidate.  I suggested to use the character-unit
length of the lines inserted into the temporary buffer as a criterion
for finding a subset of lines that is large enough to estimate the
pixel width of the whole chunk of text, and yet small enough to slash
the time needed for window-text-pixel-size to do its job.

IOW, I suggested to find a heuristic that would allow to invoke
window-text-pixel-size on a shorter chunk of text.

Maybe that's unworkable (I didn't try to develop the idea far enough
to see if it is), but that's the only idea I had, take it or leave it.

reply via email to

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