[Top][All Lists]

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

Re: enriched-mode and switching major modes.

From: Oliver Scholz
Subject: Re: enriched-mode and switching major modes.
Date: Sat, 18 Sep 2004 23:54:56 +0200
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (windows-nt)

"Eli Zaretskii" <address@hidden> writes:

>> From: Oliver Scholz <address@hidden>
>> Date: Sat, 18 Sep 2004 22:02:04 +0200
>> Cc: address@hidden, address@hidden, address@hidden
>> > I suggest to discuss that and try to identify the specific problems
>> > that you think will cause such an approach to fail.  Then we might
>> > have a better idea of the limitations of this approach, and could talk
>> > about solutions.
>> Easy.  Just consider the HTML document attachted below.
> I looked at it, but I can't say I understand which specific problems
> you refer to.  Assuming that the Emacs buffer has the text layed out
> as you want it on the screen, plus whatever text properties that are
> necessary to preserve the style information, what specifically would
> cause Emacs to fail to display this as you want?

The nested blocks example:

The critical point here are the borders. As the comment says it is not
strictly speaking impossible: If I have a function to determine the
height of a face in pixels, I /could/ determine the height of a line,
programatically generate an PPM picture of the height of that line in
pixels, which is corresponds to a fraction of a vertical border line.
Doing this for each line I /could/ render the border. That's o.k. so
far. Then I have to update this whenever the user types something in
that paragraph. This seems to my like a reliable source for headaches.
But if you ask for impossibility, then you have a point here.

The table example:

The lines are not continous.  The font sizes differ widely, but the
relative line-spacing doesn't.

Maybe I can demonstrate it with another piece of code. If you evaluate
the code at this URL (I should have thought of posting links earlier):

<URL: http://home.arcor.de/utis/table-example.el>

you'll see a buffer with three table cells in a row. The problem here:
all table cells have the same line-spacing in pixels; they should have
the same /relative/ line spacing.  The middle cell, with the
smallest font size, should occupy much less vertical space than the
right column containing the largest font.

Oliver Scholz               Jour du Travail de l'Année 212 de la Révolution
Ostendstr. 61               Liberté, Egalité, Fraternité!
60314 Frankfurt a. M.       

reply via email to

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