> I think we already discussed this and the best solution we came uppon
> is to add it as a property to the LyXFont (am I right Asger?)
Yes.
This would allow having separate language for every word.
However, the current LyXFont is suboptimal, and not suitable for this
addition. (Reasons follow below.) We should rewrite it to allow for
inheritance in the font specs, just like we have it with paragraph
environments now.
Also, since we would add stuff like language, it doesn't really make
much sense to denote it as font. It should be either span (like in
HTML) or character properties/parameters, or something like that.
The way I imagine it to work is something like this:
We have a CharParams class than contains the different parameters
that apply at character level. This includes all the current font
stuff, and also language, encoding, whether we should spellcheck this,
and other things that make sense at this level.
Each of these parameters can have the value "inherit", which means
that the value is inherited from a parent environment.
Specifically, each CharParams class also contains a CharParams reference,
which can specify additional parameters.
In this way, a hierarchy of CharParams can be build, on top of each other,
such that lower properties only redefine the stuff that is changed from the
base. This is exactly similar to the paragraph environments we have now,
just for the character level.
However, when we have to draw on the screen or do other work, we have to
resolve the CharParams to make all parameters concrete. This resolution
is done like this:
First we go ask the potential parent CharParams, which in turn will ask
it's parents, and so on. This will not necessarily resolve all parameters,
so what we do now is go and ask the hosting paragraph. This might trigger
another round of questions to the hosting paragraph of the paragraph, etc.
In other words, each paragraph will also host a default CharParams that
specifies the parameters for usage in this paragraph. Actually we have
that already. (And it's a hierarchy once again: A paragraph can inherit
the CharParams from the hosting paragraphs, in the case of nested paragraphs.)
This means that it could take up to maybe five iterations to resolve the
character parameters for a specific character. This is too slow to be
practical. Therefor, we need to redo the font stuff before we get this.
With a redesign, it is practical to add caching to the CharParams such that
we get close to amortized constant time resolution: We would only resolve
character parameters for every different CharParams in a paragraph, rather
than at every character.
These CharParams are the mayor lacking mechanism in LyX at this point
in time IMO. They even beat ERT on the priorotiy list! ;-) (But before
we start flaming, having CharParams would make resolving ERT a bit easier,
so it's a step on the way to beat ERT.)
Having such logical character parameters will enable LyX to be fully logical:
We can mark that this text is "code", and this text is a "name", etc. And
the actual look is defined elsewhere.
Greets,
Asger Alstrup
