Le 18/01/2017 à 19:23, Enrico Forestieri a écrit :
I am not completely sure what this styleName thing does. Is it mac/windows
only?
No, it is platform independent. For example, if you ask for a font with
name cmsy10, Qt would pick the first cmsy10.ttf it stumbles upon. This
would be unfortunate because, due to its idiosyncratic behavior, Qt will
not display many symbols with a certain codepoint. So, we replicated some
glyphs at different positions and tell Qt to display those ones. In order
to be sure of using our fonts, we ask for a font with a given name *and*
style "LyX". This is our own style name, so we can be sure we are using
the right fonts.
I was asking because of the sentence in the QFont docs:
It depends on system font support, thus only works for macOS and X11
so far. On Windows
irregular styles will be added as separate font families so there is
no need for this.
Is it Qt 4.8+ only?
Yes, that method was introduced in Qt 4.8.
Does it mean that the bug does not exist on earlier systems, or that our
workaround does not work?
Here is what I came up with. Is it what you had in mind, or should the || in
the test become a && ?
No, the || is fine. My rationale is the following. Qt has its own idea
of what a font should contain, and in the past we had to workaround its
shortcomings several times. So, when we are sure that a certain code works
with our fonts, we should stick with it to avoid bad surprises. Now we have
a way of telling when we are dealing with our fonts through the styleName
thing.
You can see that the \kern in the definition of \not is gone, and this is
definitely a good thing.
However, the issue does not manifest in master, meaning
that someone deployed a corrective action to avoid it. We have to
understand what this action was and then decide.
Here is what happened
1/ I change randomly (!) the spacing of math equations in the MathRow work
2/ as a consequence the formulas in lib/symbols are often wrong
3/ I fix the problem with arabic test at e832d2e90f
4/ I do a new round of modifications of lib/symbols at 7335ee8e,
without realizing that what I am fixing is a consequence of the commit
3/ and not of the ongoing work 1/
Does this make sense to you? The fact that the right value now is
without explicit kern is a proof that all this work on math formula
spacing has been done correctly (almost!)
JMarc
