Georg Baum wrote:
> Juergen Spitzmueller wrote:
> > Yes, I thought about this too. But is this safe for the future?
>
> Probably not. But we could add a big fat comment in LColor.C, or better
> provide getFromLaTeXName which is simply shortcircuited to getFromLyXName
> with an appropriate comment and a check for latexname == lyxname.

Yes, that would be the best (i.e. implement getFromLaTeXName).

> > I.e. will
> > lyx color be always the same as latex color?
>
> I don't know. Basically I don't know why we have the distinction of LyX and
> LaTeX name at all, since they are identical for every fixed color in
> LColor.C.

If possible, the two worlds should not be mixed anyway.

> >> We have still one problem (also without the patch): cursor movement via
> >> arrow keys goes always through cell(0), even if it is not displayed.
> >
> > Hm, it should be possible to "lock" this cell only (or if not, force the
> > cursor to move outside).
>
> I think so too, but don't know yet how to do it.

I think, if we do not display the cell, than the string solution is probably 
the cleanest.

> >> And then there is the problem with \normalcolor: This cannot be read
> >> anymore. Why did you not simply write cell(1) without any color in this
> >> case?
> >
> > Because if you have nested colorinsets, the color of the inner inset has
> > to be reset to \normalcolor.
>
> I see. And the nested inset has color "none" then? 

If the color is set to "none" in the character dialog, yes.

> Then I would suggest to 
> add a fourth case:
>
> if (normalcolor(cell(0)))
>         os << "{\\normalcolor " << cell(1) << '}';
> else if (!latexcolor(cell(0)))
>         os << cell(1);
> else if (oldstyle_)
>         os << "{\\color" << '{' << cell(0) << '}' << cell(1) << '}';
> else
>         os << "\\textcolor" << '{' << cell(0) << "}{" << cell(1) << '}';

Looks good IMO.

> And we need to modify math_parser.C and/or math_factory.C in order to be
> able to read that in.

Yes, but that's your world anyway :-)

Thank you for jumping in and fixing this properly (this concerns bug 1411 and 
1667 btw).

Jürgen

> Georg

Reply via email to