Uwe Stöhr wrote:
Helge Hafting schrieb:

As I said, then he mark it as Greek in the GUI and get a perfect output.
>
That is a nice workaround - but a workaround is what it is.

That is no workaround, that's how it should work, this is intended. When you insert words from other language, mark them as such. When you document language is the same as the words you are inserting you don't need to have to anything.

LyX should aim to never get a compile failure, as long as no
bad ERT or homemade styles are used.

This is impossible, e.g. what should we do when you insert a Thai, Devanagari, Japanese, ... character? Even when you insert a e.g. French stuff you have to mark it as French to get the right hyphenation, etc. How should we know what language a character is for.

As I stated earlier in this thread there is no reason why we should handle Greek different than the other languages.
I did not say that we should try to guess the correct language, only
try our best to avoid _compile failure_.

If the user pastes his favourite french quote and don't mark it as french,
then the document compiles, the french quote prints,
but with stupid hyphenation. That is ok. If he wants correct output,
mark it as "french".

Similiarly, if the user pastes greek, cyrillic, thai, chinese or whatever,
then this stuff should be output if we can. I.e. LyX should try its best
to encode stuff properly, and  pull in  packages to support  this.

Or alternatively, LyX could warn about the problems. Soemthing like "please set the language to greek for greek text",
"please set the language to one of russian/ukrainian/belarusian/...
for cyrillic, and so on."

I understand this can be tricky with latex, fortunately, it
is easy enough with xetex where an utf8 encoding "just works"
even for chinese. There, all you need is a font that supports
the characters used - failing this you get white space but no
compile error.

Helge Hafting

Reply via email to