Am Sun, 27 Feb 2022 09:41:02 +0100 schrieb Jürgen Spitzmüller <sp...@lyx.org>:
> Am Sonntag, dem 27.02.2022 um 05:05 +0100 schrieb Thibaut Cuvelier:
> > I had a new look at this issue. What do you think about adding a new
> > flag? It would work exactly like "deprecated", but without the
> > implications of having symbols deprecated. I would call this new flag
> > "improper", to indicate that the mapping is typical for LaTeX, but
> > it's improper use of the Unicode symbol: its use should not really be
> > advised in general to use this LaTeX command for that Unicode
> > character.
> > That would be the case for 0x204e: this asterisk is supposed to be
> > low, but LaTeX always uses a centred asterisk.
> >
> > Of course, I could just add a "deprecated" flag to all these symbols
> > to trigger the expected behaviour, but it doesn't feel right.
> >
> > For now, I have implemented the basic change with a "deprecated"
> > flag, with a comment each time to indicate why these mappings are
> > indicated as deprecated. This is enough to eliminate all the cases
> > you mentioned in your file sent on Feb 20. I'm splitting it into two
> > patches, with the second one having potentially more impact than the
> > first one (due to my lesser understanding).
>
> I see no reason to state that IPA is less "wanted by users" that Greek.
> I also see no reason to flag 0x025b (or tipa's \textepsilon)
> "deprecated" or "improper" as it is in no way deprecated and a
> perfectly proper command and glyph. Also, it is not as easy as to
> assume an ipacommand analogouous to text and math, as \textepsilon
> (IPA) works outside the \textipa context as soon as tipa is loaded,
> where as \textepsilon (Greek) works inside \textgreek or Greek language
> context.
>
> IMHO Advance F&R needs to get to grips with the fact that there is no
> 1:1-mapping of command names and semantics in LaTeX and it needs to
> consider the context in which a character is being used. Unicodesymbols
> already provides the necessary information, no need to flag characters
> deviant in addition to that. The latter would lead to the same amount
> of false interpretation if the context is not being considered.
>
> Jürgen
>
That is easy to say.
OTOH, if F&R gets the unicode directly, there is no problem. The whole issue is
to
convert command names to unicode. F&R works on unicode only.
Kornel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
pgp5E_0uGeZYB.pgp
Description: Digitale Signatur von OpenPGP
-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
