Cron <luatex@vz3> /var/www/luatex.org/www/bin/luatex-svn
------------------------------------------------------------------------ r3189 | taco | 2009-11-23 16:37:01 +0100 (Mon, 23 Nov 2009) | 2 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/tex/mlist.c fix large operator super/subscript relative displacement for OT MATH fonts ------------------------------------------------------------------------ r3190 | taco | 2009-11-23 16:53:47 +0100 (Mon, 23 Nov 2009) | 3 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/tex/mlist.c fix a lack of negating the automatic italic correction addition in the creation of var_delimiter for large operators. ------------------------------------------------------------------------ r3191 | hhenkel | 2009-11-23 22:04:08 +0100 (Mon, 23 Nov 2009) | 2 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/image/writeimg.c small image cleanup ------------------------------------------------------------------------
On Mon, Nov 23, 2009 at 10:28:31PM +0100, Cron Daemon wrote:
------------------------------------------------------------------------ r3189 | taco | 2009-11-23 16:37:01 +0100 (Mon, 23 Nov 2009) | 2 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/tex/mlist.c
fix large operator super/subscript relative displacement for OT MATH fonts
------------------------------------------------------------------------ r3190 | taco | 2009-11-23 16:53:47 +0100 (Mon, 23 Nov 2009) | 3 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/tex/mlist.c
fix a lack of negating the automatic italic correction addition in the creation of var_delimiter for large operators.
Though large operator super/subscript are better now, I think it is still broken. Compare the attached office2007 and luatex generated PDFs. Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer
Khaled Hosny wrote:
On Mon, Nov 23, 2009 at 10:28:31PM +0100, Cron Daemon wrote:
------------------------------------------------------------------------ r3189 | taco | 2009-11-23 16:37:01 +0100 (Mon, 23 Nov 2009) | 2 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/tex/mlist.c
fix large operator super/subscript relative displacement for OT MATH fonts
------------------------------------------------------------------------ r3190 | taco | 2009-11-23 16:53:47 +0100 (Mon, 23 Nov 2009) | 3 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/tex/mlist.c
fix a lack of negating the automatic italic correction addition in the creation of var_delimiter for large operators.
Though large operator super/subscript are better now, I think it is still broken. Compare the attached office2007 and luatex generated PDFs.
See the last comment on http://tracker.luatex.org/view.php?id=286 Hans has a new beta (on the ftp site only) that corrects this last glitch as well. Best wishes, Taco
On Wed, Nov 25, 2009 at 12:35:28AM +0100, Taco Hoekwater wrote:
Khaled Hosny wrote: See the last comment on http://tracker.luatex.org/view.php?id=286
From the ticket: "The result is now still too wide, but that is truly cambria's fault: the integrals have large italic corrections while in fact they fit in their bounding boxes." This isn't Cambria's fault per se, as any font that is to be used with MS Office as well is going Cambria's route (so does Asana Math and my two math fonts.) So, IMHO this should be the default behaviour for new math fonts, and old TeX fonts pretending to be new math fonts should compensate for this, not the other way around. Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer
Khaled Hosny wrote:
On Wed, Nov 25, 2009 at 12:35:28AM +0100, Taco Hoekwater wrote:
Khaled Hosny wrote: See the last comment on http://tracker.luatex.org/view.php?id=286
From the ticket: "The result is now still too wide, but that is truly cambria's fault: the integrals have large italic corrections while in fact they fit in their bounding boxes."
This isn't Cambria's fault per se, as any font that is to be used with MS Office as well is going Cambria's route (so does Asana Math and my two math fonts.)
So, IMHO this should be the default behaviour for new math fonts, and old TeX fonts pretending to be new math fonts should compensate for this, not the other way around.
I am not quite convinced yet. The MATH spec seems to disagree with both the font metrics and the actual behavior of Word. What would happen is Word 2010 (say) fixes that? AFAICS, the only reason for Asana being like Cambria is that it copies the font literally instead of the looking at the spec. One thing I could possibly do is to auto-correct in the engine if there is a big difference between width+italic correction and actual glyph bounding box. Best wishes, Taco
Taco Hoekwater wrote:
One thing I could possibly do is to auto-correct in the engine if there is a big difference between width+italic correction and actual glyph bounding box.
And even then it would be some FixItalicWidthThreshold parameter which then is font dependent in which case fixing the font at runtime is cleaner Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Wed, Nov 25, 2009 at 08:11:53AM +0100, Taco Hoekwater wrote:
Khaled Hosny wrote:
On Wed, Nov 25, 2009 at 12:35:28AM +0100, Taco Hoekwater wrote:
Khaled Hosny wrote: See the last comment on http://tracker.luatex.org/view.php?id=286
From the ticket: "The result is now still too wide, but that is truly cambria's fault: the integrals have large italic corrections while in fact they fit in their bounding boxes."
This isn't Cambria's fault per se, as any font that is to be used with MS Office as well is going Cambria's route (so does Asana Math and my two math fonts.)
So, IMHO this should be the default behaviour for new math fonts, and old TeX fonts pretending to be new math fonts should compensate for this, not the other way around.
I am not quite convinced yet. The MATH spec seems to disagree with both the font metrics and the actual behavior of Word. What would happen is Word 2010 (say) fixes that?
Until office2010 is released, office2007 is the standard implementation (well, windows 7 does math typesetting system wide, and the bundled Cambria exhibits the same behaviour, so I doubt there will be a change anytime soon.) I'll try to talk to Murray Sargent of MS, may be we can get more clarifications. Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer
Khaled Hosny wrote:
On Wed, Nov 25, 2009 at 12:35:28AM +0100, Taco Hoekwater wrote:
Khaled Hosny wrote: See the last comment on http://tracker.luatex.org/view.php?id=286
From the ticket: "The result is now still too wide, but that is truly cambria's fault: the integrals have large italic corrections while in fact they fit in their bounding boxes."
This isn't Cambria's fault per se, as any font that is to be used with MS Office as well is going Cambria's route (so does Asana Math and my two math fonts.) So, IMHO this should be the default behaviour for new math fonts, and old TeX fonts pretending to be new math fonts should compensate for this, not the other way around.
well, as long as there is no standard saying "for integral glyphs (of any size) you need to subtract the italic correction from the width" we cannot say that this is "expected behaviour" the fact that Asana etc follow cambria in this is not making it a standard either; at least with tex we're able to deal with such bugs and i'm pretty sure that other applications also hav ebuilt ion compensations and fixes if we end up in some 'we mimick the first font using some kind of otf technology' approach even if it concerns bugs, then what's a standard worth (in that respect open type is already a bit of a mess anyway) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Wed, Nov 25, 2009 at 10:20:14AM +0100, Hans Hagen wrote:
Khaled Hosny wrote:
On Wed, Nov 25, 2009 at 12:35:28AM +0100, Taco Hoekwater wrote:
Khaled Hosny wrote: See the last comment on http://tracker.luatex.org/view.php?id=286
From the ticket: "The result is now still too wide, but that is truly cambria's fault: the integrals have large italic corrections while in fact they fit in their bounding boxes."
This isn't Cambria's fault per se, as any font that is to be used with MS Office as well is going Cambria's route (so does Asana Math and my two math fonts.) So, IMHO this should be the default behaviour for new math fonts, and old TeX fonts pretending to be new math fonts should compensate for this, not the other way around.
well, as long as there is no standard saying "for integral glyphs (of any size) you need to subtract the italic correction from the width" we cannot say that this is "expected behaviour"
Literally speaking, there is no standard at all, just an unofficial spec document, so things are a bit stretched, and again office implantation is the de facto standard here until there is an official published standard that one can point to (even then, people are likely to follow what MS implantation does and we will need to adapt to it.) Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer
Khaled Hosny wrote:
On Mon, Nov 23, 2009 at 10:28:31PM +0100, Cron Daemon wrote:
------------------------------------------------------------------------ r3189 | taco | 2009-11-23 16:37:01 +0100 (Mon, 23 Nov 2009) | 2 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/tex/mlist.c
fix large operator super/subscript relative displacement for OT MATH fonts
------------------------------------------------------------------------ r3190 | taco | 2009-11-23 16:53:47 +0100 (Mon, 23 Nov 2009) | 3 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/tex/mlist.c
fix a lack of negating the automatic italic correction addition in the creation of var_delimiter for large operators.
Though large operator super/subscript are better now, I think it is still broken. Compare the attached office2007 and luatex generated PDFs.
if you look in the font you will notice that the cambria integral signs have a wrong boundingbox (too much white at the right); as it happens, compensating with the italic correction sort of solves this so we guess that word is doing something like that however, subtractive the italic correction from the width of a glyph makes no sense (it can be compensated at th emacro package end for this particular set of glyph, which is what we do in context now) so, the problem is noticed and once there are more official open type math fonts out there, we can have a further look at it and see what the policies have become Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Wed, Nov 25, 2009 at 10:14:07AM +0100, Hans Hagen wrote:
Khaled Hosny wrote:
Though large operator super/subscript are better now, I think it is still broken. Compare the attached office2007 and luatex generated PDFs.
if you look in the font you will notice that the cambria integral signs have a wrong boundingbox (too much white at the right); as it happens, compensating with the italic correction sort of solves this so we guess that word is doing something like that
I tried to follow the spec, and the result was pretty broken (the sup and superscripts came effectively behind the operator), so office is expecting Cambria's behaviour from all fonts, so I can't see why new fonts will not do the same. Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer
Khaled Hosny wrote:
On Wed, Nov 25, 2009 at 10:14:07AM +0100, Hans Hagen wrote:
Khaled Hosny wrote:
Though large operator super/subscript are better now, I think it is still broken. Compare the attached office2007 and luatex generated PDFs. if you look in the font you will notice that the cambria integral signs have a wrong boundingbox (too much white at the right); as it happens, compensating with the italic correction sort of solves this so we guess that word is doing something like that
I tried to follow the spec, and the result was pretty broken (the sup and superscripts came effectively behind the operator), so office is expecting Cambria's behaviour from all fonts, so I can't see why new fonts will not do the same.
so why only integral and not all characters? what is ms's (otf math) definition of italic correction then? Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Wed, Nov 25, 2009 at 01:44:08PM +0100, Hans Hagen wrote:
Khaled Hosny wrote:
On Wed, Nov 25, 2009 at 10:14:07AM +0100, Hans Hagen wrote:
Khaled Hosny wrote:
Though large operator super/subscript are better now, I think it is still broken. Compare the attached office2007 and luatex generated PDFs. if you look in the font you will notice that the cambria integral signs have a wrong boundingbox (too much white at the right); as it happens, compensating with the italic correction sort of solves this so we guess that word is doing something like that
I tried to follow the spec, and the result was pretty broken (the sup and superscripts came effectively behind the operator), so office is expecting Cambria's behaviour from all fonts, so I can't see why new fonts will not do the same.
so why only integral and not all characters? what is ms's (otf math) definition of italic correction then?
I don't know, this is just what I've found after several hours debugging the font trying to understand why it doesn't work as expected, it'd have made my life easier if they followed their own spec from the start. Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer
participants (4)
-
Hans Hagen -
Khaled Hosny -
root＠www.metatex.org -
Taco Hoekwater