Martin Vermeer wrote:
On Mon, Nov 05, 2007 at 11:13:34PM +0200, Dov Feldstern wrote:
Martin Vermeer wrote:
On Mon, 05 Nov 2007 15:49:22 +0100
Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Jean-Marc Lasgouttes wrote:
Martin Vermeer <martin.vermeer-RGpGn/[EMAIL PROTECTED]> writes:
But I am not sure I understand. Why is forceLTR true for ERT? Just for
display purpose?
The truth is, it shouldn't be. We're overloading the usage of forceLTR
--- a slight misunderstanding between me and Martin. I actually
suggested having *two* separate options in the layout: "forceLTR" and
"Language".
I think that was _my_ original idea... or then I missed your proposal.
I dropped it thinking that you only wanted forceLRT, and that that was
a good idea ;-)
Hmmm... let's start this over again:
Normally, if within an RTL paragraph we insert an inset whose contents
are LTR, then the language/direction will be switched *inside* the
inset; this is taken care of automatically by the inset itself. However,
there are some situations in which we won't be able to switch the
language/direction once we're inside the inset --- for example, inside a
\url, where any language switch commands would just be output verbatim.
For this reason, in these cases we need to force the language/direction
to LTR *before* opening the inset. That's what forceLTR is used for, and
so far it's the *only* case where it's required, I think.
A (separate?) issue is that sometimes we want to force the
language/encoding to Latin. For example, again, inside \url. The reason
that we want to force Latin in this case, is that we don't know how to
tell latex to switch the encoding inside the \url --- if we try to use
the encoding switch commands, they will be output verbatim. So in fact,
we're forced to use only a single encoding --- and that might as well be
Latin.
In ERT we need to force Latin for a similar, but different, reason:
currently, LyX recognizes the encoding (to be used by iconv when
generating the latex file) based on the LyX language of the text.
However, (I think, but I'm not sure about this) we don't want to allow
multiple LyX languages inside ERT, because then the language switching
latex commands would go to the ERT text in the latex file. But if we
were to allow multiple encodings inside ERT, but not multiple Languages
(which would be OK in terms of our requirements, as we agree below) then
LyX would be presented with Unicode text inside the ERT which it would
not know how to encode when generating the latex file, because there is
no language associated with it! Note that we *need* the language
information here, because the same characters might be encoded
differently depending on the language with which they're associated. And
latex is later going to have to know how they were encoded in the latex
file. The best solution here might be to somehow make sure that language
switch commands are *not* output in ERT, and to then allow true natural
languages inside ERT. Doesn't sound very clean, though...
So, for better or for worse, at the moment we want to force Latin in
these cases --- and this also implies disabling the language switching
commands.
The question is, do these things (force Latin, forceLTR, disable
language switching in the GUI) always go together? I'm not sure, but ATM
the only exception I can think of is ERT...
Almost always, these properties would be set together. But
ERT is a good example where only "Language" should be set.
But you need to suppress the \L thingy too...
As explained above, forceLTR is used to *add* the \L thingy, which is
normally *not* output; so forceLTR does the opposite of what we want in
this respect...
So now, the question becomes "Why is Language set to latex_language for
ERT?"
And I believe the answer is: "Yes, just for display purpose".
Hmmm. It is to force the language, and thus the encoding, to Latin1.
LaTeX needs that; LyX display would be happy with Unicode, but isn't
smart enough to convert it to Latin1 without some help (i.e., the
language attribute).
This is not accurate. It's true for URL, for example, but not for ERT. I
agree with Abdel that ideally, in ERT we should allow any encoding the
user wants, and it should be up to the user to make sure that any
necessary commands are included in the ERT for letting latex know about
the encoding changes. Why? Because the point of ERT is to as much as
possible let the user do whatever he wants, just as if he had the .tex
file and could now touch it up however he likes.
Actually I believe you can do that now. Insert your own encoding
commands, and insert, e.g., Hebrew byte sequences, by copy/paste from
the surrounding text. Yes, they will display wrong, but hey, it's ERT,
and it comes out right in print. And if that's what you want to do, it's
really easier to do outside ERT, which is meant for code, not language.
I just played around with this, and realized that the problem is with
the *encoding* of the text inside the ERT into the latex file. See above...
However, in practice it may be a little more complicated. First of all,
I think that switching *languages* (as opposed to encodings) should
*not* be allowed in ERT. So we have to decouple the language from the
encoding; and this would be quite confusing to the user, I think. So
until we work out exactly how that should work, I'm OK with having ERT
be "force Language latex_language".
In ERT, things are allowed to be confusing ;-) The question to ask is,
does separating language and encoding serve a sensible purpose outside
ERT? My first impulse is 'no'... but...
I tend to agree with you, including the "but..."
But the forceERT really should be separated in two, I guess...
ForceERT? Freudian?
But what does it mean? :D
- Martin
