On Mon, 2006-01-30 at 16:39 +0100, Georg Baum wrote: > Martin Vermeer wrote: > > > What is 1.3 behaviour (of noFontChange viz. language)? > > I don't know. Therefore I wanted you to find out ;-)
OK, I did. It works like you described: Norwegian if noFontChange =
false, Swedish if true. So for noFontChange disabled, text inside insets
inherits the outer language set for the location of the inset.
However, I tested also whether my patched LyX loads a 1.3-generated file
with insets, languages, bluelines etc. truthfully.
I have good news and bad news.
The good news is that if I remove language inheritance for insets, then
1.3 generated files are loaded and presented on-screen truthfully.
However, if I have the language inheritance code included in
applyOuterFont, i.e.:
if (font.language() == bufferFont().language())
font.setLanguage(font_.language());
then you cannot truthfully present buffer language text inside a
non-buffer-language inset, even if the loaded file contains such.
Precisely the problem I mentioned earlier. For some unfathomable reason,
1.3 doesn't have this problem. I would say, leave this code out.
> > And what would
> > you want 1.4 to do?
>
> The same ;-)
>
> Seriously, when discussing bug 1973 with Jean-Marc we came to the conclusion
> that noFontChange() does not do currently for what it has been designed,
> but that now is not the time to change it.
> IMHO we should not try to correct/redesign language handling now, only make
> it work like it does in 1.3.
It appears that that is not easily possible, for the above reason. I
would prefer 1.4 to fully honour existing 1.3 files, even if that means
that the user-visible behaviour changes slightly. It's illusory, after
the major rewriting that has happened, to precisely duplicate 1.3
behaviour anyway.
- Martin
signature.asc
Description: This is a digitally signed message part
