- From: Sergey Malkin <sergeym@microsoft.com>
- Date: Wed, 7 Aug 2019 19:49:46 +0000
- To: Frédéric Wang <fwang@igalia.com>, Murray Sargent <murrays@exchange.microsoft.com>
- CC: "public-mathml4@w3.org" <public-mathml4@w3.org>, Victor Kozyrev <victork@microsoft.com>, Peter Constable <petercon@microsoft.com>
- Message-ID: <SN6PR00MB041577636BEDE95B110E4BD4B3D40@SN6PR00MB0415.namprd00.prod.outlook.com>
Correct. For fractions, gap is between nominator/denominator and fraction bar, so axis position is part of computations. For stack, gap is between upper and lower parts. Axis position is not involved. On related note, you may notice that axis position is not part of computing initial positions for both fractions and stacks. Of course, shift-ups and shift-downs (defined by font designer) are such that parts are visually centered around math axis, but actual value is not used. Thanks, Sergey ________________________________ From: Frédéric Wang <fwang@igalia.com> Sent: Wednesday, August 7, 2019 12:35 PM To: Sergey Malkin <sergeym@microsoft.com>; Murray Sargent <murrays@exchange.microsoft.com> Cc: public-mathml4@w3.org <public-mathml4@w3.org>; Victor Kozyrev <victork@microsoft.com>; Peter Constable <petercon@microsoft.com> Subject: Re: Interpretation of OpenType MATH fraction shifts Hi, I was checking this again and for stacks I understand that AxisHeight is not involved at all in the layout. Is that correct? On 06/08/2019 20:32, Sergey Malkin wrote: I actually see in code that shift is relative to baseline. Look at PTLS7::CalcFractionOffsets function in LsMathFractionApi.cpp: LONG dvGapNumerator = dvNumeratorShiftUp - dvNumeratorDescent - (dvAxisHeight + dvRuleThicknessOver2); ... duvNumerator.v = dvAxisHeight + dvRuleThicknessOver2 + dvGapNumerator + dvNumeratorDescent; Which is equivalent to duvNumerator.v = dvNumeratorShiftUp This is consistent with shifts for other math structures, e.g. superscript, where making it relative to math axis doesn't make sense. Thanks, Sergey ________________________________ From: Murray Sargent <murrays@exchange.microsoft.com><mailto:murrays@exchange.microsoft.com> Sent: Tuesday, August 6, 2019 10:47 AM To: Frédéric Wang <fwang@igalia.com><mailto:fwang@igalia.com> Cc: public-mathml4@w3.org<mailto:public-mathml4@w3.org> <public-mathml4@w3.org><mailto:public-mathml4@w3.org>; Victor Kozyrev <victork@microsoft.com><mailto:victork@microsoft.com>; Sergey Malkin <sergeym@microsoft.com><mailto:sergeym@microsoft.com>; Peter Constable <petercon@microsoft.com><mailto:petercon@microsoft.com> Subject: RE: Interpretation of OpenType MATH fraction shifts Looking at the LineServices math fraction handler code, I think the OpenType math table numerator shift-up and denominator shift-down parameters are relative to the math axis. For confirmation, adding Victor, who wrote the math fraction handler code, Sergey, our OpenType math table expert, and Peter who has edited the OpenType math table spec. Thanks, Murray -----Original Message----- From: Frédéric Wang <fwang@igalia.com><mailto:fwang@igalia.com> Sent: Tuesday, August 6, 2019 7:53 AM To: public-mathml4@w3.org<mailto:public-mathml4@w3.org>; Murray Sargent <murrays@exchange.microsoft.com><mailto:murrays@exchange.microsoft.com> Subject: Interpretation of OpenType MATH fraction shifts Hi Murray, Can you please indicate whether numerator/denominator shifts should be relative to the fraction baseline: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmathml-refresh%2Fmathml%2Fissues%2F123&data=04%7C01%7Csergeym%40microsoft.com%7C23418ee72935478ed7d308d71a962c85%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637007104604276097%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C-1&sdata=nWBieXR82IXEct4YidbFW2XTyYiSW8pRRZl0U6otirs%3D&reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmathml-refresh%2Fmathml%2Fissues%2F123&data=02%7C01%7Csergeym%40microsoft.com%7C45145d40400d43345add08d71b6e6642%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637008033304867116&sdata=S4lPxolX7ksm4uUZDj5F2m8rNJHcvZgk35PTJ8on8JE%3D&reserved=0> Thanks, -- Frédéric Wang -- Frédéric Wang
Received on Wednesday, 7 August 2019 19:50:27 UTC