Jean-Marc Lasgouttes wrote:

>>>>>> "Georg" == Georg Baum
>>>>>> <[EMAIL PROTECTED]>
>>>>>> writes:
> 
> Georg> lyx2lyx will convert \'{e} to é. But since '+e (or rather e+' -
> Georg> the accent comes after the accented char in unicode) is also
> Georg> possible in ucs4 encoding we have to support both. The latter
> Georg> could for example come from external sources (clipboard, plain
> Georg> text import) or the unicode insert lfun. The alternative would
> Georg> be convert all e+' that come from external sources to é, but
> Georg> that would be more messy, and qt4 does handle e+' just fine.
> 
> But this breaks kbd navigation, right?

Partially. You have two logical positions after the surrogate pair, but you
can go forward and backward as usual. The only thing that is not nice is
that you may have to press -> or <- twice.

>>> Second point: rather than putting in explicit preamble snippets I
>>> think we should go for feature (i.e. put "textcomp" there, and
>>> handle it in LaTeXFeatures).
> 
> Georg> That would be faster, but it would not be possible anymore to
> Georg> use arbitrary packages. We will never be able to ship a
> Georg> complete list (if you look e.g. at plastex it lacks many
> Georg> accents, although it has really a lot of symbols). Therefore I
> Georg> think it would be a good if users can add symbols even if they
> Georg> come from a specialist package (e.g. for ancient african
> Georg> languages or something like that) we don't even know. Maybe we
> Georg> can do both: use a feature for known packages, but allow to
> Georg> load other packages as well.
> 
> I'd prefer that indeed. It allows us to control better the
> interactions between different packages.

I implemented that: If the string in the symbols file starts with \ it will
be inserted verbatim, otherwise it is treated as a known feature.

>>> Can environment nesting really change the encoding?
> 
> Georg> Can it change the language? If yes, it can also change the
> Georg> encoding. If not, then we can leave it out.
> 
> The outerFont mechanism uses the layout font of outer paragraph, and
> this font cannot contains an encoding/language change AFAIK (at least
> it cannot be read in LyXFont::lyxRead).

This is what I found out in the meantime, too, and I got rid og this
outerfont stuff.


Georg

Reply via email to