Hi all, I'm (re)tying to draw some attention to the $n\choose k$-issue with OpenType math fonts. I've made some test files: http://dl.dropbox.com/u/151837/OpenType-Math.7z The best output is generated by LuaLaTeX (at least for Asana and Cambria). Would it be possible to correct the ConTeXt output as well? Regards Andreas
On 4-3-2011 2:09, Andreas Harder wrote:
Hi all,
I'm (re)tying to draw some attention to the $n\choose k$-issue with OpenType math fonts.
I've made some test files: http://dl.dropbox.com/u/151837/OpenType-Math.7z
The best output is generated by LuaLaTeX (at least for Asana and Cambria). Would it be possible to correct the ConTeXt output as well?
It depends what correction boils down to. Normally it's the opentype font parameters that control the threshold to the next step in a larger delimiter Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Am 04.03.2011 um 15:28 schrieb Hans Hagen:
On 4-3-2011 2:09, Andreas Harder wrote:
Hi all,
I'm (re)tying to draw some attention to the $n\choose k$-issue with OpenType math fonts.
I've made some test files: http://dl.dropbox.com/u/151837/OpenType-Math.7z
The best output is generated by LuaLaTeX (at least for Asana and Cambria). Would it be possible to correct the ConTeXt output as well?
It depends what correction boils down to. Normally it's the opentype font parameters that control the threshold to the next step in a larger delimiter
The placement is right for $n\above 1sp k$, only if the thickness of the par is set to 0, the ‚k‘ is lowered. Perhaps some patch in goodie-file is possible, so one could load it in a font definition. Andreas
Am 04.03.2011 um 15:28 schrieb Hans Hagen:
On 4-3-2011 2:09, Andreas Harder wrote:
Hi all,
I'm (re)tying to draw some attention to the $n\choose k$-issue with OpenType math fonts.
I've made some test files: http://dl.dropbox.com/u/151837/OpenType-Math.7z
The best output is generated by LuaLaTeX (at least for Asana and Cambria). Would it be possible to correct the ConTeXt output as well?
It depends what correction boils down to. Normally it's the opentype font parameters that control the threshold to the next step in a larger delimiter
This subject is also discussed on the LuaLaTeX mailing list. http://tug.org/pipermail/lualatex-dev/2011-March/thread.html#1118 Greeting Andreas
On 6-3-2011 1:25, Andreas Harder wrote:
Am 04.03.2011 um 15:28 schrieb Hans Hagen:
On 4-3-2011 2:09, Andreas Harder wrote:
Hi all,
I'm (re)tying to draw some attention to the $n\choose k$-issue with OpenType math fonts.
I've made some test files: http://dl.dropbox.com/u/151837/OpenType-Math.7z
The best output is generated by LuaLaTeX (at least for Asana and Cambria). Would it be possible to correct the ConTeXt output as well?
It depends what correction boils down to. Normally it's the opentype font parameters that control the threshold to the next step in a larger delimiter
This subject is also discussed on the LuaLaTeX mailing list. http://tug.org/pipermail/lualatex-dev/2011-March/thread.html#1118
hm, i actually decided to limit the number of mailing lists to follow so best provide a summary of conclusions instead of a link -) anyhow, I wonder if we really need to keep supporting this x \operator y kind of syntax (at least that's what crossed my mind when i saw that this atopwithdelims primitive was used in your example) .. maybe we should simply define a few extra commands and relax these primitives aditya: shouldn't we merge the m-newmath code into the core? I can add some configurability to lfg files so that one can tune fonts but even then the value are debatable Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Am 06.03.2011 um 12:54 schrieb Hans Hagen:
On 6-3-2011 1:25, Andreas Harder wrote:
Am 04.03.2011 um 15:28 schrieb Hans Hagen:
On 4-3-2011 2:09, Andreas Harder wrote:
Hi all,
I'm (re)tying to draw some attention to the $n\choose k$-issue with OpenType math fonts.
I've made some test files: http://dl.dropbox.com/u/151837/OpenType-Math.7z
The best output is generated by LuaLaTeX (at least for Asana and Cambria). Would it be possible to correct the ConTeXt output as well?
It depends what correction boils down to. Normally it's the opentype font parameters that control the threshold to the next step in a larger delimiter
This subject is also discussed on the LuaLaTeX mailing list. http://tug.org/pipermail/lualatex-dev/2011-March/thread.html#1118
hm, i actually decided to limit the number of mailing lists to follow so best provide a summary of conclusions instead of a link -)
OK
anyhow, I wonder if we really need to keep supporting this
x \operator y
kind of syntax (at least that's what crossed my mind when i saw that this atopwithdelims primitive was used in your example) .. maybe we should simply define a few extra commands and relax these primitives
I'm fine with \binom{x}{y} etc.
aditya: shouldn't we merge the m-newmath code into the core?
+1
I can add some configurability to lfg files so that one can tune fonts but even then the value are debatable
I don't know the best value either, but et least one could manipulate it. Thank you for your efforts! Andreas
On 6-3-2011 1:22, Andreas Harder wrote:
I don't know the best value either, but et least one could manipulate it.
the next beta will support parameter overload in the goodies parameters = { -- test values FactorA = 123.456, FactorB = false, FactorC = function(value,target,original) return 7.89 * target.factor end, FactorD = "Hi There!", }, ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Am 06.03.2011 um 15:33 schrieb Hans Hagen:
On 6-3-2011 1:22, Andreas Harder wrote:
I don't know the best value either, but et least one could manipulate it.
the next beta will support parameter overload in the goodies
parameters = { -- test values FactorA = 123.456, FactorB = false, FactorC = function(value,target,original) return 7.89 * target.factor end, FactorD = "Hi There!", },
Many thanks, Hans! I'm looking forward to try it. Regards Andreas
Am 06.03.2011 um 15:33 schrieb Hans Hagen:
On 6-3-2011 1:22, Andreas Harder wrote:
I don't know the best value either, but et least one could manipulate it.
the next beta will support parameter overload in the goodies
parameters = { -- test values FactorA = 123.456, FactorB = false, FactorC = function(value,target,original) return 7.89 * target.factor end, FactorD = "Hi There!", },
I'm afraid, I don't get it. Here is what I tried: I copied all stack-relevant values from asana-math.tma and put them in the return section of the goodies file (like showed in lm-math.lfg). But even if I set all values to zero, the output remains the same. Im I doing something wrong? Greeting Andreas
On Sun, 13 Mar 2011, Andreas Harder wrote:
I'm afraid, I don't get it. Here is what I tried: I copied all stack-relevant values from asana-math.tma and put them in = the return section of the goodies file (like showed in lm-math.lfg). But = even if I set all values to zero, the output remains the same. Im I = doing something wrong?=20
[snip]
return { name = "lm-asana", version = "1.00", comment = "Goodies that complement asana.", author = "Hans Hagen", copyright = "ConTeXt development team", parameters = { -- test values -- data = { metadata = { math = { StackBottomDisplayStyleShiftDown = 0, StackBottomShiftDown = 0, StackDisplayStyleGapMin = 0, StackGapMin = 0, StackTopDisplayStyleShiftUp = 0, StackTopShiftUp = 0, StretchStackBottomShiftDown = 0, StretchStackGapAboveMin = 0, StretchStackGapBelowMin = 0, StretchStackTopShiftUp = 0, }, }, -- }, }, }
The return name "lm-asana" is a bit strange. I am not sure if that is relevant or not. Aditya
Am 13.03.2011 um 16:51 schrieb Aditya Mahajan:
On Sun, 13 Mar 2011, Andreas Harder wrote:
I'm afraid, I don't get it. Here is what I tried: I copied all stack-relevant values from asana-math.tma and put them in = the return section of the goodies file (like showed in lm-math.lfg). But = even if I set all values to zero, the output remains the same. Im I = doing something wrong?=20
[snip]
return { name = "lm-asana", version = "1.00", comment = "Goodies that complement asana.", author = "Hans Hagen", copyright = "ConTeXt development team", parameters = { -- test values -- data = { metadata = { math = { StackBottomDisplayStyleShiftDown = 0, StackBottomShiftDown = 0, StackDisplayStyleGapMin = 0, StackGapMin = 0, StackTopDisplayStyleShiftUp = 0, StackTopShiftUp = 0, StretchStackBottomShiftDown = 0, StretchStackGapAboveMin = 0, StretchStackGapBelowMin = 0, StretchStackTopShiftUp = 0, }, }, -- }, }, }
The return name "lm-asana" is a bit strange. I am not sure if that is relevant or not.
I think "lm-asana" is right, otherwise compilation ends with " Math error: parameter \Umathquad\displaystyle is not set." Andreas
On Sun, 6 Mar 2011, Hans Hagen wrote:
On 6-3-2011 1:25, Andreas Harder wrote:
Am 04.03.2011 um 15:28 schrieb Hans Hagen:
On 4-3-2011 2:09, Andreas Harder wrote:
Hi all,
I'm (re)tying to draw some attention to the $n\choose k$-issue with OpenType math fonts.
I've made some test files: http://dl.dropbox.com/u/151837/OpenType-Math.7z
The best output is generated by LuaLaTeX (at least for Asana and Cambria). Would it be possible to correct the ConTeXt output as well?
It depends what correction boils down to. Normally it's the opentype font parameters that control the threshold to the next step in a larger delimiter
This subject is also discussed on the LuaLaTeX mailing list. http://tug.org/pipermail/lualatex-dev/2011-March/thread.html#1118
hm, i actually decided to limit the number of mailing lists to follow so best provide a summary of conclusions instead of a link -)
anyhow, I wonder if we really need to keep supporting this
x \operator y
kind of syntax (at least that's what crossed my mind when i saw that this atopwithdelims primitive was used in your example) .. maybe we should simply define a few extra commands and relax these primitives
At the macro package level, I agree with this. The \over, \choose, \atop etc macros can be made \undefined; We already have a high level interface for them. Do you also want to remove them from the engine? That will simplify the \mathstyle macros, but then luatex will not be backward compatible with tex. (I don't care about that, but others would).
aditya: shouldn't we merge the m-newmath code into the core?
Definitely. Aditya
On 6-3-2011 6:03, Aditya Mahajan wrote:
On Sun, 6 Mar 2011, Hans Hagen wrote:
On 6-3-2011 1:25, Andreas Harder wrote:
Am 04.03.2011 um 15:28 schrieb Hans Hagen:
On 4-3-2011 2:09, Andreas Harder wrote:
Hi all,
I'm (re)tying to draw some attention to the $n\choose k$-issue with OpenType math fonts.
I've made some test files: http://dl.dropbox.com/u/151837/OpenType-Math.7z
The best output is generated by LuaLaTeX (at least for Asana and Cambria). Would it be possible to correct the ConTeXt output as well?
It depends what correction boils down to. Normally it's the opentype font parameters that control the threshold to the next step in a larger delimiter
This subject is also discussed on the LuaLaTeX mailing list. http://tug.org/pipermail/lualatex-dev/2011-March/thread.html#1118
hm, i actually decided to limit the number of mailing lists to follow so best provide a summary of conclusions instead of a link -)
anyhow, I wonder if we really need to keep supporting this
x \operator y
kind of syntax (at least that's what crossed my mind when i saw that this atopwithdelims primitive was used in your example) .. maybe we should simply define a few extra commands and relax these primitives
At the macro package level, I agree with this. The \over, \choose, \atop etc macros can be made \undefined; We already have a high level interface for them.
Do you also want to remove them from the engine? That will simplify the \mathstyle macros, but then luatex will not be backward compatible with tex. (I don't care about that, but others would).
no, we can keep them there as we want that compatibility (for plain etc)
aditya: shouldn't we merge the m-newmath code into the core?
Definitely.
ok, will do Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (4)
-
Aditya Mahajan -
Andreas Harder -
Andreas Harder -
Hans Hagen