FYI this particular example was resolved https://bugzilla.mozilla.org/show_bug.cgi?id=1131000 (i.e., Gecko and MathJax align again though further issues have been spotted). Peter. On Wed, Jan 14, 2015 at 12:55 PM, Peter Krautzberger < peter.krautzberger@mathjax.org> wrote: > > We could add it to the tracker, even better we could actually do it:-) > > I was hoping the former would help ensure the latter but yes, let's get > started. Where/how should we set it up? (I'd like to finish my other items > before getting into a new one though.) > > Peter. > > > On Wed, Jan 14, 2015 at 12:50 PM, David Carlisle <davidc@nag.co.uk> wrote: > >> On 14/01/2015 11:41, Peter Krautzberger wrote: >> >>> Yes. Can we add this to the WG tracker? >>> >> >> We could add it to the tracker, even better we could actually do it:-) >> >> David >> >> >

Hi all, The MathML specification allows specifying carries at south positions. In this case, when other rows of carries exists it is not clear how the formula must be rendered. For example, in the following formula <mstack><mscarries><mn>1</mn></mscarries><mscarries location="s"><mn>2</mn></mscarries><mn>3</mn><msline/><msrow/></mstack> What’s is the expected rendering? 1 3 2 Or maybe 1 3 2 ? Dani

On 16/03/2015 16:02, Daniel Marques wrote: > Hi all, > > The MathML specification allows specifying carries at south positions. > In this case, when other rows of carries exists it is not clear how the > formula must be rendered. > > For example, in the following formula > > <mstack><mscarries><mn>1</mn></mscarries><mscarries > location="s"><mn>2</mn></mscarries><mn>3</mn><msline/><msrow/></mstack> > > What’s is the expected rendering? > > 1 > > 3 > > 2 > > Or maybe > > 1 > > 3 > > 2 > > ? > > Dani > personal response but the spec says > the first row of carries annotates the second (following) row as if the second row had location="n". so the position of the 1 isn't affected by the fact that the 2 has location=s, it is positioned as if the 2 had location=n so just above where that would have been. But it goes on to say > This means that the second row, even if it does not draw, visually uses some (undefined by this specification) amount of space when displayed. so the exact amount of space below the 1 is implementation defined. David _____________________________________________________________________________________________________________________________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Microsoft Office 365. ______________________________________________________________________________________________________________________________________________________

I concur with David's reasoning. Neil On Mon, Mar 16, 2015 at 9:12 AM, David Carlisle <davidc@nag.co.uk> wrote: > On 16/03/2015 16:02, Daniel Marques wrote: > >> Hi all, >> >> The MathML specification allows specifying carries at south positions. >> In this case, when other rows of carries exists it is not clear how the >> formula must be rendered. >> >> For example, in the following formula >> >> <mstack><mscarries><mn>1</mn></mscarries><mscarries >> location="s"><mn>2</mn></mscarries><mn>3</mn><msline/><msrow/></mstack> >> >> What’s is the expected rendering? >> >> 1 >> >> 3 >> >> 2 >> >> Or maybe >> >> 1 >> >> 3 >> >> 2 >> >> ? >> >> Dani >> >> > personal response but the spec says > > > the first row of carries annotates the second (following) row as if > the second row had location="n". > > so the position of the 1 isn't affected by the fact that the 2 has > location=s, it is positioned as if the 2 had location=n so just above > where that would have been. > > But it goes on to say > > > This means that the second row, even if it does not draw, visually > uses some (undefined by this specification) amount of space when displayed. > > so the exact amount of space below the 1 is implementation defined. > > David > > > ____________________________________________________________ > ____________________________________________________________ > _____________________________ > > The Numerical Algorithms Group Ltd is a company registered in England and > Wales with company number 1249803. The registered office is: > > Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. > > > > This e-mail has been scanned for all viruses by Microsoft Office 365. > > ____________________________________________________________ > ____________________________________________________________ > ______________________________ > >

Thanks for the responses but we are not done! Assuming that both rows off carries are at south. <mstack><mscarries><mn location="s">1</mn></mscarries><mscarries location="s"><mn>2</mn></mscarries><mn>3</mn><mn>4</mn></mstack> Then, . . 3 2 1 4 Where the dots ‘.’ are used only to indicate some amount of vertical space. Is that correct? In addition, south carries move the rows the necessary amount of vertical space in order to do not overlap (the row with the ‘4’ has been moved two rows below). Do you agree? Dani *From:* neil.soiffer@gmail.com [mailto:neil.soiffer@gmail.com] *On Behalf Of *Neil Soiffer *Sent:* lunes, 16 de marzo de 2015 22:14 *To:* David Carlisle *Cc:* www-math@w3.org *Subject:* Re: mstack and south carries I concur with David's reasoning. Neil On Mon, Mar 16, 2015 at 9:12 AM, David Carlisle <davidc@nag.co.uk> wrote: On 16/03/2015 16:02, Daniel Marques wrote: Hi all, The MathML specification allows specifying carries at south positions. In this case, when other rows of carries exists it is not clear how the formula must be rendered. For example, in the following formula <mstack><mscarries><mn>1</mn></mscarries><mscarries location="s"><mn>2</mn></mscarries><mn>3</mn><msline/><msrow/></mstack> What’s is the expected rendering? 1 3 2 Or maybe 1 3 2 ? Dani personal response but the spec says > the first row of carries annotates the second (following) row as if the second row had location="n". so the position of the 1 isn't affected by the fact that the 2 has location=s, it is positioned as if the 2 had location=n so just above where that would have been. But it goes on to say > This means that the second row, even if it does not draw, visually uses some (undefined by this specification) amount of space when displayed. so the exact amount of space below the 1 is implementation defined. David _____________________________________________________________________________________________________________________________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Microsoft Office 365. ______________________________________________________________________________________________________________________________________________________

On 17/03/2015 09:48, Daniel Marques wrote: <mstack> <mscarries><mn location="s">1</mn></mscarries> <mscarries location="s"><mn>2</mn></mscarries> <mn>3</mn> <mn>4</mn> </mstack> > Then, > > . > > . > > 3 > > 2 > > 1 > > 4 > > Where the dots ‘.’ are used only to indicate some amount of vertical space. > > Is that correct? > No. the first is unaffected by the location attribute of the second row. It is positioned _as if_ the second row had location="n". so it is positioned above the first real row 3 % where 2 would have been with location=n 1 % south of where 2 would have been 3 % first normal row 2 % south carries on row 3 4 % second normal row David _____________________________________________________________________________________________________________________________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Microsoft Office 365. ______________________________________________________________________________________________________________________________________________________

Again, I concur with David. After a fix for a crash (MathPlayer 4, public beta 2 will have the fix), I get what David indicated. Neil On Tue, Mar 17, 2015 at 4:07 AM, David Carlisle <davidc@nag.co.uk> wrote: > On 17/03/2015 09:48, Daniel Marques wrote: > > <mstack> > <mscarries><mn location="s">1</mn></mscarries> > <mscarries location="s"><mn>2</mn></mscarries> > <mn>3</mn> > <mn>4</mn> > </mstack> > > > Then, >> >> . >> >> . >> >> 3 >> >> 2 >> >> 1 >> >> 4 >> >> Where the dots ‘.’ are used only to indicate some amount of vertical >> space. >> >> Is that correct? >> >> > > No. the first is unaffected by the location attribute of the second row. > It is positioned _as if_ the second row had location="n". > so it is positioned above the first real row 3 > > % where 2 would have been with location=n > 1 % south of where 2 would have been > 3 % first normal row > 2 % south carries on row 3 > 4 % second normal row > > > > David > > ____________________________________________________________ > ____________________________________________________________ > _____________________________ > > The Numerical Algorithms Group Ltd is a company registered in England and > Wales with company number 1249803. The registered office is: > > Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. > > > > This e-mail has been scanned for all viruses by Microsoft Office 365. > > ____________________________________________________________ > ____________________________________________________________ > ______________________________ >

Hi all, I don't know if there has been progress regarding the fixes to unicode.xml, but I still see two obvious errors in the AMS set: For U+21CE: <AMS>\nleftrightarrow</AMS> (should be an uppercase L as for other sets and similarly to U+21CD ; note that this is different from U+21AE) For U+2306: <AMS>\doublebarwedge ?</AMS> (question mark should be removed) Thanks, -- Frédéric Wang maths-informatique-jeux.com/blog/frederic

On 14/03/2015 14:29, Frédéric WANG wrote: > Hi all, > > I don't know if there has been progress regarding the fixes to > unicode.xml, but I still see two obvious errors in the AMS set: > > For U+21CE: <AMS>\nleftrightarrow</AMS> (should be an uppercase L as > for other sets and similarly to U+21CD ; note that this is different > from U+21AE) For U+2306: <AMS>\doublebarwedge ?</AMS> (question mark > should be removed) > > Thanks, > Thanks, fixed those in latest checkin. The ? was I suspect showing some doubt about that character and I note that U+2A5E was added at Unicode 3.2 which looks very similar and unicode-math assigns \doublebarwedge giving the new name \vardoublebarwedge to U+2306. I've just removed the ? for now, but I wonder if the AMS entry should align with unicode-math. I'll check with Barbara how she aligns the AMS name to STIX. David

On 15/03/2015 10:30, David Carlisle wrote: > Thanks, fixed those in latest checkin. The ? was I suspect showing some > doubt about that character and I note that U+2A5E was added at Unicode > 3.2 which looks very similar and unicode-math assigns \doublebarwedge > giving the new name \vardoublebarwedge to U+2306. > > I've just removed the ? for now, but I wonder if the AMS entry should > align with unicode-math. I'll check with Barbara how she aligns the AMS > name to STIX. Confirmed with Barbara Beeton, the STIX mapping of AMS names does use 2A5E here so I moved the <AMS> entry to that. (No change in the mathml/html entity definitions) David