On Fri, 2006-02-03 at 09:29 +0100, 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?
A file with Norsk as default/buffer language, text set to Swedish, an
inset inserted into the text, text inside the inset set back to Norsk.
In 1.3 the text inside the inset will be Norsk. In 1.4 unpatched I don't
remember; with my patch, Swedish (Norsk is interpreted as
"inherit_language")
> - 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.
OK
> - 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).
I did. Quotes etc. indeed do not get underlined with my patch. So it is
wrong. A solution might be to give paintForeignMark an additional
"descent" parameter and use that to put the line at the right level.
> 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.
OK in principle... but could you list in detail which pieces of the
patch you want included and which excluded? BTW being both
bug-compatible with 1.3 and reasonably well behaved may be undoable.
> 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 looked at that... didn't get anywhere. Yes, in principle.
> 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?
Yes, shouldn't be a problem.
I expect that this will go to 1.4.1. And 1.4.0 will in practice be
pre5...
- Martin
signature.asc
Description: This is a digitally signed message part
