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?
- 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.
I would suggest to only apply the obvious changes, and leave the fixes for
correctly propagating language changes to insets out. Especially the
meaning of noFontChange() should not be changed, since it is wrong
already.
The problem with inherited language in insets should IMO be fixed by setting
an explicit language upon reading a file and creating new stuff. Then the
language is never inherited, and the underlining will automatically be
correct.
I share Jean-Marcs concern about the bufferFont() method. It uses bv_oner,
but that pointer is scheduled for removal and should not be used for new
code. Wouldn't it be possible to create a BufferParams::getFont() and use
that instead?
Georg
2115-221.lyx
Description: application/lyx
