On Fri, 30 Oct 1998, Jean-Marc Lasgouttes wrote:

> >>>>> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
> 
> >> >>>>> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
> >> 
> >> LyXFont::latexWriteStartChanges(LString & file, LyXFont const &
> >> base) const { LyXFont f = *this; f.reduce(base);
> >> f.setLatex(INHERIT); // ignore any latex change <<<<<<<<<<<<<<<<<<

That's smarter than the fix I came up with, for sure. Asger came up with
one that was better than mine, too, but approximately equal to what you
did. 

> Asger> Ok, it seems that there is not enough information in the passed
> Asger> parameters.  Therefor, we have to do what Amir concluded:
> Asger> Either change the interface of latexWriteStartChanges, or hack
> Asger> paragraph.C to not compare on LaTeX-property.
> 
> Asger> The latter is probably the easiest.  Just make a copy of the
> Asger> two fonts, and the use "font1.setLatex(LyXFOnt::INHERIT)" and
> Asger> "font2.setLatex(LyXFont::INHERIT)" before the comparision.
> 
> I'll try that. However, why is the f.setLatex(INHERIT) not enough in
> this case? It should make the test f.bits == inherit work...
>
> Moreover, I do not really understand why the {\small..} is broken in
> parts... fonts mysteries...

Warning: long explanation coming.

The problem is that there are three LyXfont objects in paragraph.C.

- basefont is the base font of that paragraph - usually something like
roman medium up normal(size), though I guess it might be large for
section, e.g.

- running_font is the font of the last thing your printed out

- font is the font of the thing you're about to print out.

if font != running_font, then you call
font.latexWriteStartChanges(basefont). This compares font (what you're
about to write) & base font, and writes the changes to get from one to the
other. Then it sets open_font=true to say you've opened a font
description. 

if font !=running_font && open_font, then you call
running_font.latexWriteEndChanges(basefont). This compares running_font
(what you've been writing), and basefont, and writes the right number of
'}' characters to finish the font changes. (running_font is then set to
basefont, so if the font of the next character isn't basefont, then after
writing the '}' characters, you'll write the font changing commands
necessary for the next characters).

Anyway, as it is now, it's broken. Why? Well, let's take the example of
(the lyx equivalent of) \textbf{12 \AA is a lot}. First, you call
font.StartChanges(basefont). It compares font & basefont (with
LyXfont::reduce) and writes the necessary starting commands, which is
fine. THe problem comes when you get to \AA. running_font has "bold
nolatex", and font is "bold latex". Those are different, so you call
running_font.EndChanges(basefont). But basefont is "medium nolatex". So
even if you ignore the latex portion of the font, basefont and
running_font are different series. 

IF you called running_font.EndChanges(font) instead of
running_font.EndChanges(basefont), THEN the only difference between the
two would be latex/nolatex, in which case it wouldn't write anything. Then
you could call font.StartChanges(running_font), and again the only
difference would be latex/nolatex, so it wouldn't write any font changing
commands there, and would just continue the "\textbf{" that had been
started a while ago. In general, this would result in many fewer font
changing commands.

Hm. Is it possible that if you were doing this, then you could combine
StartChanges and EndChanges? I wonder. But probably not, because it sounds
too elegant to be possible. 

I can't tell you exactly why the current system is used, but my guess is
that it's hard to keep track of how many font changes you've made and need
to make. Asger can probably give you reasons. This way, every piece of
text is given its own font commands.  FWIW, in reLyX I've got a "struct"
that contains a stack for each commandtype (size, series, etc.). I have no
idea if something like that would work for LyX and/or if it would be too
bulky and slow. However, you might want to look into some sort of solution
to create cleaner LaTeX for 1.1. It would be nice for collaborating with
non-LyX aware folk. (I of course tend to be very sensitive to that issue
since that's one of reLyX's main reasons for existence.) 

Anyway, this is what Asger means when he says "not enough information is
being passed", and this explains why the solution of ignoring the latex
value when comparing font and running_font in paragraph.C will work.

-Amir

Reply via email to