Martin Vermeer wrote:
On Sun, Oct 28, 2007 at 09:37:36AM +0200, Martin Vermeer wrote:
On Sun, Oct 28, 2007 at 02:27:25AM +0200, Dov Feldstern wrote:
Martin Vermeer wrote:
There's another consideration which you may already be aware of, but which I
only just found out now, after playing around with this: part of the problem
is that some of these latex commands process their contents in a verbatim
fashion. For example, \url does not allow other latex commands inside it ---
e.g., typing "\selectlanguage{hebrew}" inside a \url just gets processed
verbatim. I had not realized that this was a latex --- rather than a LyX ---
limitation. So I guess that that's what the 'verbatim' option is signifying
in this case.
Yes, but it's also a verbatim LyX property now.
Now, there's also another problem with the URL inset. Currently, I'm having
the same problem we were having a few weeks back with the ERT insets: if I
try to insert a URL while typing Hebrew text, the font inside it is Hebrew,
and I can't switch it to English (well, again, I guess what I actually want
is latin, not English per-se?) because we disabled the lfuns. So we should
be forcing the font inside the inset to latin, and I guess the best way we
have for doing that is by forcing the font to latex_language. Does this
sound right (despite what I was saying above about not expanding the usage
of latex_language :( ) --- i.e., should we be forcing latex_language for all
'verbatim' insets?
I would not be happy about this as I said. Elaborating, the
problem of needing in this case to switch encodings is due to
a LaTeX limitation. If LaTeX were Unicode-capable, we could
just write, and the typed chars would come out right by
themselves. As it is, the Unicode must be converted to 8-bit
encodings with switches inbetween. LyX2lyx ought to handle this
transparently.
How is the encoding decision taken BTW in LyX? Only based on
the language mark-up? Or could it look at the actual characters
too?
Only language I think (but I am not sure).
Abdel.
