On Wed, Jan 18, 2017 at 03:19:31PM +0100, Jean-Marc Lasgouttes wrote: > > 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. > Is it Qt 4.8+ only? Yes, that method was introduced in Qt 4.8. > Will the bug exist on other systems with your > patch applied? Only if the fonts we use for math are not our owns. But if they are not, many other symbols would be broken. So, this would be only a minor issue. > But I see that you introduced this thing in f496ec3 and I presume that you > understand it! Actually, I introduced that style name in our fonts using fontforge. > Concerning master, applying your patch breaks \neq, presumably because > Guillaume worked around the problem manually. Possibly. But see below. > 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. I see that your patch is for master. I would advise to apply this patch only to stable (minus the lib/symbols bit, which is not needed there). This is because we know what is causing the issue in stable and thus the patch is fine. 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. As you can see, the \kern in the definition of \not is also in stable but it is not a problem there. My fear is that we put a patch on top of another patch without an understanding of what is happening, and this can bite later. -- Enrico
