On Tue, 2006-01-31 at 14:17 +0100, Helge Hafting wrote: ...
> > > > > >>And when inserting a new inset in the middle of something, then > >>the new inset is likely in the same language as the surroundings. > >>So don't revert to document language all the time. > >> > >> > > > >OK... can be done. But the price is, that lyx 1.3 documents will not > >always be loaded and rendered faithfully. > > > > > Well, I don't see the connection - other than that this is what can be > done with a reasonably small patch. No, with a reasonably non-intrusive patch. The problem is that a piece of "infrastructure" is lacking to recover the information needed. > No matter how 1.4 works internally, > an 1.3 document can always be "fixed" by the converter so each and every > word show up in the same language as it did in 1.3. Unless 1.4 actually > loose ability for some language constellations. Of course, this may > mean extra work on the converter for which there isn't time right now. Actually I did this change manually on a test file and it worked... it means inserting one \lang <bufferlanguage> immediately before the inset and a \lang <whateverlanguagewasinforcejustoutsidetheinset> immediately inside. This will move the language attribute for the whole inset to the inside, after which it becomes well-behaved also in 1.4. I'm not sure this is easily automated though: we must test for the inset containing text. > >If you have a 1.3 doc containing an inset at a location that has a > >non-buffer language, containing text in which the language is reset to > >the buffer language (which somehow is just possible in 1.3), then upon > >loading, the latter font change will silently disappear. Saving makes > >the loss permanent. This is due to the buffer language (without my > >patch: the default language) doubling as "inherit_language". Under > >current architecture, there is no solution to this. Admittedly a corner > >case... I posit that we can live with this, provided we warn the users. > > > > > I believe what I asked for (or hoped for) was ability to select a range > containing all sorts of stuff and change the language of the lot. > > Do that imply that we can't reset part of a foreign-language inset > to document language at all? (I guess one can work around this by > setting the language explicit to whatever the doc language is, > instead of using "revert"?) No, won't work. I tried. The "infrastructure" isn't there. > To me, setting the language through editing > is completely orthogonal to loading an old document. > Seems that this isn't so then, without needing "too much work". This architectural problem affects both, no matter where the problem doc comes from: disk or keyboard. > >That is the bad news. The good news is that without my patch, lyx 1.4 > >will do even more crazy things with languages and fonts of a 1.3 > >document -- also without as much as a whimper ;-) > > > > > Substituting a small wrong for a big one is a win :-) It'd be worse > if we broke something error-free. I agree. > >Attached a still slightly simplified patch. Two small things were > >dropped which turned out to be unnecessary in further testing. And we > >need applyOuterFont after all. > > > >Helge, see if you can live with this one. > > > > > I'll try to look at it later today. Great!
signature.asc
Description: This is a digitally signed message part
