Le 03/04/2023 à 00:36, Enrico Forestieri a écrit :
So how should I solve problem 1/ ? I see 3 solutions
a/ replace ≠ with a \neq directly in the document at input time; we
might not want to do that in case we eventually use unicode in math too
b/ replace ≠ with a \neq on screen only
c/ keep the ≠ on screen, but use the mathrel math class from \neq so
that we have a good spacing
I would say (a) but only for symbols that are actually translated in
output.
What I wonder is whether keeping the unicode characters in the document
could be helpful (for html/docbook export, for example) and avoid
overrriding users actions. I think I will try b/ first, until I have
other people (Günther, do you read this?) tell me that I can get rid of
unicode keys early.
Also, things like ² are translated to more complex commands like {}^2, I
am not sure that I want to insert it with an editable nucleus.
Then, I see that there are two ways of matching \neq to U+2260:
i/ lib/unicodesymbol has a "mathcommand" entry for that (which is
presumably used right now)
ii/ lib/symbols also links these elements
Which one is more reliable for what I want to do?
As I see it, (i) is for export and (ii) is for screen representation, so
I would suggest using (i).
Right.
My general problem is that, while I see what happens with \neq, I
suspect that many weird things can happen with other characters.
Any advice?
Be careful ;)
Indeed. This is probably not 2.4 material anyway, unless it turns out to
be very easy to implement.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
