Martin Vermeer wrote:
Change language for the paragraph containing a table:
first row gets underlined, which look odd.
Probably nothing to do with your patch though. Individual
table cells do not change - they remain in the document language.
Do users have to change language for each cell individually?
I think this is by design. From the viewpoint of the outer text, the
inset is just a "character". if this character has a foreign language
attribute (!= document language), it will get bluelined.
I see the point, but there are a couple of problems.
1. How to properly mark a table as "different language"? Underlining
the first row seems very arbitrary. And it might conflict with
language overrides in individual cells of the first row too.
Better to put the underline under the whole table, perhaps.
2. Does it matter at all what language is effective where the table
is inserted, as long as table-cell language is marked anyway?
If not, then showing this line is superfluous.
Not that it matters for 1.4.0 though.
Changing language for a single cell can be done, and the change will be
written to the .lyx file. BUT the display does not indicate the
language change - no blue underline, and nothing about language on the
status bar when the cursor visits such text.
Yes... seems that I cut the wrong corner with applyOuterFont ;-)
Please replace the patch part for text2.C by the attached. Works for me.
Works for me too. Great work!
Another issue that probably is unrelated to your patch:
Attempting to spellcheck some text in a different language
(select only that text) still tries to load the _document_ language
into aspell. This fail when there is no dictionary for that language,
even though the language for the selected text exist.
This prevents spellchecking.
I suppose it is unrelated, as my patch only touches rendering stuff. The
underlying document (on disk/in memory) remains untouched.
Unrelated then - I have yet to see mulitlingual spellchecking work anyway.
A remaining nit:
Insert an ERT box, minipage or a table into a document that has a
nondefault doc language.
Observe how the curor is L-shaped (i.e. underlined) as if
the language is different (from document language) even though it isn't.
There will be no stupid underlining when actually typing text, but the
cursor indicate otherwise. Perhaps the same fix should be applied to cursor
handling as well?
Yes, I see that too. From the code, the cursor is L-shaped when the
real_current_font language differs from the buffer/document language. I
suppose I should go through all the places where this var is being
assigned to... but I think this is a separate problem (perhaps
"blanketed" by the bigger blueline problem uptill now).
Sure, I always thought that was the same thing.
Helge Hafting
