Hi,
> (...)
>> However, according to:
>> http://en.wikipedia.org/wiki/Caron
>> http://de.wikipedia.org/wiki/Caron
>> these four special characters (d,l,L,t) are ONLY used with caron in Czech
>> and Slovak languages, and ALWAYS with the "special caron" form.
> (...)
> I think this part could go really in, since it is no risk and it seems to
> be very important for Jacek.
No, it is not. You gained an incorrect impression.
I noticed this "inconsistency" (between LyX window display and LaTeX
generated ps files) some time ago, so I notified JMarc. He developed the
patch very quickly, but then I "objected" as the only information I had
was that it required the "T1" encoding. In the meantime I collected more
informations about it ... and the outcome is ... it seems that one can
safely apply this "unconditional" patch for the reasons mentioned above.
The only thing I can add to what I have already written is ...
By default, LaTeX does not recognize the "special caron" \q ... in order
to use it you would have to add "\usepackage[czech]{babel}" or
"\usepackage[slovak]{babel}" in the Document->LaTeX_Preamble... .
However, you do not really need it, as the LaTeX with fontenc:T1, used in
LyX by default, recognizes there characters with the standard caron and
treats them properly, automatically applying the special caron form, which
looks like an apostrophe just after the character (note however, it still
does NOT understand \q without appropriate czech/slovak babel loaded).
I'm sorry but this is all I know about this issue.
>> Please commit this patch. This is a bug fix. A serious one for me. On a
>> couple of occasions, I have already reported that, the current LyX
>> produces INCORRECT LaTeX code when it finds a character, in the ".kmap"
> (...)
> Can you give an example please? E.g. character typed in, resulting stuff in
> the .lyx file and resulting .tex output.
> (...)
> normally type in LyX, that means not arbitrary LaTeX. Therefore I don't
> think the part that patches TransManager is correct.
I'm sorry but this is the only patch that I really care about very much.
This patch DOES WORK. I tested it with many different characters and
symbols that LyX cannot display natively, but LaTeX can.
Just try to put into your preferred .kmap file characters like "\\euro{}",
"\\oe{}", "\\ng{}", "{\\euro}", "{\\oe}", "{\\ng}", "$\\nicefrac{1}{4}$",
"$\\nicefrac{1}{2}$", ... and then try to press the corresponding key
sequence in LyX ... then apply my patch, recompile LyX ... and try to
press the corresponding key sequence again ... you'll notice the
difference.
(Note, it's LyX-1.4, no LyX-1.5 for me for the next couple of years ...)
Last, but not least, LyX does not provide any other way, for a user, to
redefine "key sequences". The only way is to use kmap files. That is why
it is important that this is working. I believe that even in future, with
unicode characters, the user should be able to bind his/her own characters
and/or symbols to dedicated key sequences, especially if these characters
and/or symbols are not present in unicode and thus require dedicated short
LaTeX code.
> If they can't upgrade to 1.5, how can they upgrade to 1.4.4? It looks like
You decided to drop support for xforms and qt-3 in LyX-1.5. You only
support qt>=4.1. This is a blocking issue.
As I have already written, I need a "common standard" that works on
a couple of different OS flavors and different OS versions ...
For the moment my basic system is based on RHEL-3 with qt-3.1. In one year
from now moving probably to RHEL-5 (once it is there, certified, ...) ...
I doubt it will use qt-4 ... especially as even the newest (free) RedHat
Fedora Core 6 still uses qt-3.3 ...
Yes I know I can compile qt-4 myself, but this is not really an option for
me ... I have to be flexible, be able to work in multisystem environment.
The choice is clear. Either LyX-1.4 or pure LaTeX2e.
Best regards,
Jacek.
