GNU bug report logs - #25309
11.89.8; multi-level script fontification stacks incorrectly

Previous Next

Full log

Message #56 received at 25309 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Gennady Uraltsev <gennady.uraltsev <at> gmail.com>
Cc: Uwe Brauer <oub <at> mat.ucm.es>, 25309 <at> debbugs.gnu.org
Subject: Re: bug#25309: 11.89.8;
 multi-level script fontification stacks incorrectly
Date: Sun, 01 Jan 2017 17:20:16 +0100

[Message part 1 (text/plain, inline)]

Gennady Uraltsev <gennady.uraltsev <at> gmail.com> writes:

Hi Gennady,

> The relevant variables with apropriate values are:
>
> font-latex-fontify-script multi-level
> font-latex-scipt-display ((raise -0.3) raise 0.3)
>
> and the two faces
>
> Font Latex Superscript Face ((t
>   (:height 0.8)))
>
>  Font Latex Subscript Face: ((t
>   (:height 0.8)))

Right.

> What happens is that the font faces always get applied and the
> compound (you see the font getting smaller progressively) this is
> because for font specifications, specifying a fractional value means
> taking the parent font and modifying it by that factor (for hight).

Seems to be the case although only with scripts containing {...} with
nested scripts.

> A different behavior happens for font-latex-scipt-display ((raise
> -0.3) raise 0.3).  According to manual the first part is relative to
> subscripts and the second to superscripts.
>
> Immagine an expression like
>
> base^{u2^{u3_{d1}}}_{d2_{d3^{u4_{d4^{u5}}}}}}
>
> the raising gets applied only if the first consecutive sub or super
> script of a series. That means that ^{x} appears raised unless the
> containing expression is also a superscript.  Similarly lowering a
> subscript gets applied only if the containing expression is NOT
> another subscript.

Yes, that seems to be the current behavior.

> In the above example the raising gets applied to u2 u4 u5 and not u3
> Lowering (negative raising) gets applied to d1 d2 d4 but not d3
>
> Notice also that the raising gets calculated with respect to the base
> line and not the containing level.
>
> Finally the "apparent" going down of the stack
> 1^{2^{3^{4}}} is due simply to the fact that the font gets smaller

I've also re-read the docs in the meantime and wondered how this feature
could have worked at all at.  But I'm pretty sure that back at that time
when I added the feature, $x^y^z$ was displayed as one would expect,
i.e., y raised above x and smaller, z raised above y and smaller.  Uwe,
do you remember?

But again, even if it worked it would be a mystery why...

Bye,
Tassilo

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.