emacs-devel
[Top][All Lists]
Advanced

[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: Sun, 01 Feb 2015 12:26:02 +1100
User-agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> +---------------+----+----------------+-----------------------+
>> |R1C1           |R1C2|RA1C2 With Space|R1C2                   |
>> +---------------+----+----------------+-----------------------+
>> |R2C1 and R2C2 in one|RC4-with-a-really-long-unbreakable-thing|
>> |simple box          |                                        |
>> +--------------------+----------------------------------------+
>
> How to decipher the RnCm notation here? "row n, column m"?  If so, why
> are there two instances of R1C2, and what does RA1C2 mean?

Sorry; the text doesn't really mean anything here.  It was just a test
case I had handy...

> Also what is the order of the texts in a buffer, i.e. is any of the
> RnCm a continuation of text in some other cell, or are they all
> independent strings that don't exits as single contiguous text in any
> buffer?

They are all independent texts.

>> 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.
>
> I'm not sure I understand how the layout is specified on the "document
> language" (whatever that is) level.  IOW, what is known about the
> layout when this text is about to be rendered?

The layout for web pages is specified in HTML in either a <table> (which
is equivalent, more or less, to a TCL-ish "gridbaglayout", if you've
played with that back in the 90s) or CSS3, which has a different type of
layout specification.

Anyway, I've now implemented the face/script segmentation version, and
it does help speed-wise.  A typical Gnus info node now takes 0.02s
instead of 0.04s.  However, it's still too slow to be usable for complex
layouts where we need to compute the widths of things a lot (like a
Wikipedia page with a huge genealogy table).

-- 
(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]