Re: [MathML4] Deprecation/Removal of the mfenced element
Frédéric WANG <[email protected]> Tue, 26 Jul 2016 09:02:23 +0200
| Newsgroups | gmane.comp.web.mathematics |
|---|---|
| Message-ID | <[email protected]> |
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WAWUJidKnkRq7pTUhMNqi29UtxbSP0v0s Content-Type: multipart/mixed; boundary="C0OhXorq74Mh4kC6W1NuG6AgUjSWXx0k0" From: =?UTF-8?B?RnLDqWTDqXJpYyBXQU5H?= <[email protected]> To: Murray Sargent <[email protected]>, "[email protected]" <[email protected]> Message-ID: <[email protected]> Subject: Re: [MathML4] Deprecation/Removal of the mfenced element References: <[email protected]> <[email protected]> In-Reply-To: <[email protected]> --C0OhXorq74Mh4kC6W1NuG6AgUjSWXx0k0 Content-Type: multipart/alternative; boundary="------------59E8776B44E6616A04CA8596" This is a multi-part message in MIME format. --------------59E8776B44E6616A04CA8596 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 25/07/2016 =C3=A0 20:39, Murray Sargent a =C3=A9crit : > > Hmm. I like <mfenced>. It's an element that says up front what it > means. <mrow> is abstract and requires parsing before you know what it > means. In Microsoft Office math, there is the "delimiters" element <d> > that maps neatly into <mfenced>. The LineServices math handler formats > such elements automatically expanding to fit their arguments. The > result is math typography very much like TeX, but without the need for > control words like \biggl. > > =20 > > Our products can generate and input MathML using <mrow> instead of > <mfenced>, but parsing similar to that used for the math linear format > <http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf> is used > to convert to <d>. > > As I see, this is an internal implementation details for the Microsoft Word / LineServices that does not need to be exposed to the Web or handled everywhere. You already have import/export features between MathML to OfficeMath including between <mrow>/<mo> and <d> so I don't see how it helps to have an <mfenced> element when you have to handle the general case anyway. MathML is centered around mrow and mo elements with a dictionary of properties. Whether or not it is a good idea is a separate discussion, but it's a core feature of MathML and is unlikely to be changed in the future. That implies that you must implement these general cases anyway and so mfenced or Office's n-ary elements are duplicate features that do not bring anything new but pain for implementers. I would really be curious to hear progress from the Edge developers regarding the implementation of MathML. I'm dubious that the design of mfenced (renderer text provided in attributes, parsing needed to expand the element, duplicate of mrow+mo) make them happy. --=20 Fr=C3=A9d=C3=A9ric Wang --------------59E8776B44E6616A04CA8596 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html> <head> <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty= pe"> </head> <body bgcolor=3D"#FFFFFF" text=3D"#000000"> <div class=3D"moz-cite-prefix">Le 25/07/2016 =C3=A0 20:39, Murray Sar= gent a =C3=A9crit=C2=A0:<br> </div> <blockquote cite=3D"mid:[email protected]= " type=3D"cite"> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Du= tf-8"> <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:"\@SimSun"; panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:#0563C1; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:#954F72; text-decoration:underline;} p.MsoPlainText, li.MsoPlainText, div.MsoPlainText {mso-style-priority:99; mso-style-link:"Plain Text Char"; margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri",sans-serif;} span.PlainTextChar {mso-style-name:"Plain Text Char"; mso-style-priority:99; mso-style-link:"Plain Text"; font-family:"Calibri",sans-serif;} =2EMsoChpDefault {mso-style-type:export-only; font-family:"Calibri",sans-serif;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> <div class=3D"WordSection1"> <p class=3D"MsoPlainText">Hmm. I like <mfenced>. It's an element that says up front what it means. <mrow> is abstract and requires parsing before you know what it means. In Microsoft Office math, there is the "delimiters" element <d> that maps neatly into <mfenced>. The LineServices math handler formats such elements automatically expanding to fit their arguments. The result is math typography very much like TeX, but without the need for control words like \biggl.<o:p></o:p></p> <p class=3D"MsoPlainText"><o:p>=C2=A0</o:p></p> <p class=3D"MsoPlainText">Our products can generate and input MathML using <mrow> instead of <mfenced>, but parsing similar to that used for the <a moz-do-not-send=3D"true" href=3D"http://www.unicode.org/notes/tn28/UTN28-PlainTextMath= -v3.pdf">math linear format</a> is used to convert to <d>.<o:p></o:p>= </p> <br> </div> </blockquote> As I see, this is an internal implementation details for the Microsoft Word / LineServices that does not need to be exposed to the Web or handled everywhere. You already have import/export features between MathML to OfficeMath including between <mrow>/<mo> and <d> so I don't see how it helps to have an <mfenced> element when you have to handle the general case anyway.<br> <br> MathML is centered around mrow and mo elements with a dictionary of properties. Whether or not it is a good idea is a separate discussion, but it's a core feature of MathML and is unlikely to be changed in the future. That implies that you must implement these general cases anyway and so mfenced or Office's n-ary elements are duplicate features that do not bring anything new but pain for implementers.<br> <br> I would really be curious to hear progress from the Edge developers regarding the implementation of MathML. I'm dubious that the design of mfenced (renderer text provided in attributes, parsing needed to expand the element, duplicate of mrow+mo) make them happy.<br> <pre class=3D"moz-signature" cols=3D"72">--=20 Fr=C3=A9d=C3=A9ric Wang </pre> </body> </html> --------------59E8776B44E6616A04CA8596-- --C0OhXorq74Mh4kC6W1NuG6AgUjSWXx0k0-- --WAWUJidKnkRq7pTUhMNqi29UtxbSP0v0s Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXlwsGAAoJEL8nnpULUzQOCZMP/0ADAGd+FteYU7ZgiOqQWGQe LsAPDDGVf+Zm1wlxhWp1mGP33/uK8jSSZQHGHUjgZX6XQj+EDN8dkofnJnYCBPu4 t9SipGXKOYLr3AcEde6O3lRQLFMD92gMRmdww6F4y7/yjZTpSWvihrIuQzWqjjQ2 fJEIKHKfNodfs4B2tpzANstbwye/EtdJUYiC+UEEpyXV8Q28Yb2i9wHJjjmhdGuL TPVTMckGywq4+NyQVubofcwmEpgoURJyzJSOrW//qEwJ/15c/baFKE6drhYDsZyy kZKRFwdMWGPN/RtzZgZEr473mcwCHzBBpG4bjIsYZdCVQzq9FW58+GCVjMCIbl+D fYxROC/lGWwTe00pnr2/oSurxgen3glYISknaSQEXSNTSqB7QeYlQ5vgf9ivJ8Zn f6IWqYTN/0alIfrGXe5KcC40blN7Dy8lTr8ccmyR+7F1FOrhT3A/YKiaQ0oMWbze a3uId6lQxZS3vi5vk8Dz9FGbrT7QL7NWVmMztHQgokf8fx0lqgWOpPDYUzk7RNmq ygs9EyKbVn1V6Wau3NMrSJiahvTWRs1s36PLQ07IkU7llcWMuCsV90Z5gzkFH+Pd VBIqTt95vrWDeRb54IGXSLiqANZzIUeuG3UANmCedNDVT/3FgTHSii5VWw2ASDHc psmYdv9nvTOaSdkrcv6G =KUNc -----END PGP SIGNATURE----- --WAWUJidKnkRq7pTUhMNqi29UtxbSP0v0s--