Re: Pixel-based display functions

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Mon, 02 Feb 2015 11:43:23 -0500
> 
> > I don't think Lars's Elisp does what the display engine does.
> 
> All I know is that his code will give wrong results if it doesn't
> reproduce faithfully enough what the redisplay does.

Not necessarily, since an HTML browser doesn't need to implement all
the gazillion display features that redisplay needs to handle.  Not
even close.  It just needs to render text with faces and sometimes
with images.

> And that to me is a clear sign that it should reuse (some part of)
> the redisplay code

I agree, and it does.  font-get-glyphs, window-text-pixel-size,
vertical-motion, etc. all reuse the display engine code.

> > (Of course, he could insert each string into a scratch buffer, but
> > that's a waste, and doesn't solve the other problem, described below.)
> 
> I think this "waste" would be negligible.

Maybe, maybe not.  It all depends on how many small strings will be
needed to be rendered.

> > Second, there's a subtlety in move_it_* functions that was never
> > explicitly raised in this discussion, but which becomes rather
> > important if you want to consider reusing the move_it_* functions for
> > this use case: they produce glyphs in the _visual_ order.  So if the
> > text to be rendered includes R2L characters, you might break text
> > between screen lines incorrectly.  (If this isn't clear enough, I can
> > elaborate.)  Also, you will have to deal with the situation where
> > (position-of-pixel-in-text FROM TO) is _less_ than
> > (position-of-pixel-in-text FROM (1- TO)).  That is a complication that
> > Lars would surely like to avoid, I presume.  By contrast,
> > font-get-glyphs works in the logical order.
> 
> I think solving this problem is *hard*.

I explicitly suggested a way that avoids the need to solve it.

> The problem is not just whether you work on the logical or visual
> order, but in order to get the right behavior when filling bidi text
> inside columns, is that you'll have to partly reimplement the bidi
> code.

Not really.  Certainly not when the screen lines are L2R and there's
some R2L text in it.  R2L lines are slightly harder, in that you need
to append to such lines a 'space' display property of a suitably
calculated width, to make them flushed to the right.  What other
issues do you envision?  And what do you think the display engine does
to fill bidi text, anyway?

> Maybe the best approach would be to make position-of-pixel-in-text
> return some info about the reordering that redisplay performs.

What information would that be?  Why would an application be
interested in it?

> PS: who still would prefer refilling single-column text in the redisplay
> itself, since it makes it lazy, and makes it work right even when the
> buffer is displayed in different windows/frames with different fonts.

I agree that this feature would be useful.  However, how to use it in
this case is not clear to me: recall that there's no buffer to render
here, only a bunch of strings, each one with some kind of
specification, lifted from the HTML source, regarding their layout in
table cells.  The display engine cannot work with such kind of layout
spec, we'd need to invent some new machinery on top of teaching it how
to wrap at arbitrary pixel coordinate.