Georg Baum wrote:
Martin Vermeer wrote:
Hmmm. Actually this is straightforwardly fixable. It's just a policy
choice, how we understand noFontChange(). See attached. Only text.C and
rowpainter.C were changed. Works for me... 1.3 does it this way too (in
fact, it has *only* noFontChange-type insets; but language is inherited
into all of them. So I guess this is a regression fix.)
Sorry for chiming in so late, but I must admit that this patch becomes too
big for my liking, and partly goes into the wrong direction IMHO.
I did some intensive testing yesterday. Results:
- The attached 1.3 file is read correctly with and without your patch. Your
or Helge found a problem with 1.3 compatibility, but I can't find it
anymore. Could you please give an example again?
I have no idea of compatibility problems. My problem has always been
bugs with multilingual files, such as:
* Set the document language to something else than the default language
configured in lyx. Notice that some insets either have, or seem to have,
the lyx default language instead of the document language.
Before the patch, this happened only occationally, as 1.4cvs contain
a "imperfect" fix. The cause I believe is that the "lyx default language"
is consulted in cases where it shouldn't. It should only ever be used as
a default for the document language when creating a new document.
It is apparently used erroneously in some other cases as well.
The patch fixes this, and I hope at least the part that do this goes in.
* Selecting lots of text (that includes insets) and changing the language
on the selection has problems. Often, insets is not updated with the
language change, so one have to open each of them and apply the
language change. This is very irritating routine work - iterating
over all
those insets is exactly the sort of thing a computer should be good at.
Feel free to argue over implementation details, but I hope the end result
is that 1.4.0 _will_ change the language of everything inside a selection.
The patch as-is do that, and it is nice. I have a hard time
- The onscreen display in 1.3 is wrong for the texts with inherited language
("default") inside insets (no blue underline) if the insets are inside a
foreign language. This is the same in 1.4 without your patch.
- Selecting all and resetting the language works for text outside of
insets and for floats. It does not work for tabulars, boxes etc. This is
actually bug 1973, and it was decided to fix this for 1.4.1. I think that we
should fix the language setting at the same time when we fix the other font
attributes.
- The fact that the first line of tabulars (and e.g. inlined footnote
contents) is underlined if they are inside a foreign language is a
drawing problem and has nothing to do with wrong language settings. The
reason is that these insets are aligned with the baseline of the
surrounding text. In 1.3, the blue line was at the bottom line, now it is
at the baseline, and therefore goes through insets.
Your fix to not draw the line for insets can probably be very iritating for
inlined insets (such as specialchar, but I did not try).
We could use a huge switch (ugly) or yet another virtual inset method, I
don't know.
This case was improvement. Sure it can be delayed, but why.
There is no need for underlining the baseline of a table, for the
table itself is only lines. It has no language, just as a "hfill" have
no language. Table cell contents may have language changes,
and with the patch, they are underlined as they should. So no
need for a table underline, and no need for underlining any
no-text inset.
Helge Hafting
