[Top][All Lists]

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

Re: Pixel-based display functions

From: Lars Ingebrigtsen
Subject: Re: Pixel-based display functions
Date: Sat, 31 Jan 2015 17:59:31 +1100
User-agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

> But all those computations of pixel sizes are really what the
> redisplay does.

When redisplay happens it's kinda too late to make layout decisions.
Unless you extend the display engine to allow constraint-based layouts.
That'd be cool, but I didn't think that was in the offing?

If that's what you're intending, then remember things like that the
document language may, for instance, describe a layout like this

|R1C1           |R1C2|RA1C2 With Space|R1C2                   |
|R2C1 and R2C2 in one|RC4-with-a-really-long-unbreakable-thing|
|simple box          |                                        |

where each of the two main columns are said to be 50% of the width, but
where one of the elements can't be filled, so you have to extend that
column and compress the other columns to make things fit.

And you may have columns that themselves contain further column
specification, where the same issues apply, so you have to do a descent
into each layout cell to try to make things fit.

And so on.

If this is not what you're planning, then shr needs access to pixel
sizes so that it can do these things, and the display engine can just do
what it does now.

(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

reply via email to

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