Planet MathML

The Planet MathML aggregates posts from various blogs that concern MathML. Although it is hosted by W3C, the content of the individual entries represent only the opinion of their respective authors and does not reflect the position of W3C.

Latest articles

Audio Recording from Monday's meeting 10/08/18

Source: public-mathonwebpages@w3.org Mail Archives • Charles LaPierre (charlesl@benetech.org) • October 11, 2018 • Permalink


Hello everyone,
Not sure if I sent this out, I don’t see it in my folder for this group so lets just go with it.
Here are the audio recording with transcript<https://benetech.zoom.us/recording/share/wxujeCxulpzi94Vi4ICJmtZ0uHG_EuNr7zueff_qwUawIumekTziMw> for our accessible math meeting


Thanks
EOM

Charles LaPierre
Technical Lead, DIAGRAM and Born Accessible
Twitter: @CLaPierreA11Y
Skype: charles_lapierre
Phone: 650-600-3301



reminder: meetings this week

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • October 08, 2018 • Permalink

Hi everyone,

A quick reminder that the task forces are meeting today; there is no main
CG meeting on Thursday.

Best,
Peter.

TPAC 2018 - Registration closes on 14 October

Source: public-mathonwebpages@w3.org Mail Archives • Alexandra Lacourba (alex@w3.org) • October 08, 2018 • Permalink

Dear Advisory Committee Representative,
Chairs, Working Groups and Community Groups who signed up to meet (bcc’ed),

The TPAC 2018 registration will close on 14 October 2018.
If you have not done so, please fill in the form available at: 
https://www.w3.org/2002/09/wbs/35125/TPAC2018-Late/,
and linked from the TPAC 2018 overview page [1]

See you in Lyon!
Alexandra.

[1] https://www.w3.org/2018/10/TPAC/

On 19/09/2018 19:21, Alexandra Lacourba wrote:
> Dear Advisory Committee Representative,
> Chairs, Working Groups and Community Groups who signed up to meet 
> (bcc’ed),
>
> A couple of reminders:
>
> - The standard rate of EUR 135 (EUR 160 with VAT) will expire on 30 
> September.
> The late/onsite rate will start on 1 October and will be EUR 170 (EUR 
> 205 with VAT).
>
> See registration details:
> https://www.w3.org/2018/10/TPAC/Overview.html#registration
>
> - The last special rates negotiated with hotels are about to expire:
> You have until 20 September for the Crowne Plaza Lyon Cité 
> Internationale and
> until 21 September for the Ibis and Mercure hotels to book your room.
>
> After these dates, the booking will be subject to availability.
> Further information at: 
> https://www.w3.org/2018/10/TPAC/Hotels-Transportation.html#accommodations
>
> Thank you,
>
> Alexandra.
>

-- 
Alexandra Lacourba - Administration             mailto:alex@w3.org
World Wide Web Consortium                       http://www.w3.org
W3C/ERCIM - 2004 route des Lucioles - Sophia Antipolis 06410 Biot - FR
Voice: +33.4.92.38.50.76                                        Fax: +33.4.92.38.78.22

Community Groups meetings during TPAC 2018

Source: public-mathonwebpages@w3.org Mail Archives • Alexandra Lacourba (alex@w3.org) • October 06, 2018 • Permalink

Dear Community Groups,

You will meet during TPAC 2018. We would like to inform you that no 
speakerphone will be available in the room.

We invite you to make your own arrangements if needed.

We thank you for your understanding.

Best regards,
Alexandra.

-- 
Alexandra Lacourba - Administration             mailto:alex@w3.org
World Wide Web Consortium                       http://www.w3.org
W3C/ERCIM - 2004 route des Lucioles - Sophia Antipolis 06410 Biot - FR
Voice: +33.4.92.38.50.76                                        Fax: +33.4.92.38.78.22

MathJax v3 beta.2 released

Source: MathJax • October 05, 2018 • Permalink

The MathJax team has been working hard on a major rewrite of MathJax from the ground up, with the goal of modernizing MathJax’s internal infrastructure, bringing it more flexibility for use with contemporary web technologies, making it easier to use with NodeJS for pre-processing and server-side support, and making it faster to render your mathematics. We have made headway in all these areas and we are pleased to announce the second public beta release of MathJax v3.

Where to Find the Beta Release

The code for the release is available in the beta branch of the MathJax v3 github repository.

Examples of how to use MathJax v3 in web pages are available in the mj3-demos repository. This includes several pre-packaged versions of MathJax for common use cases (e.g., converting TeX to HTML in a web page) that you can link to for your own test pages, along with sample HTML pages that call them and documentation on how to configure MathJax v3. There are also instructions on how to make your own custom webpacked version of MathJax v3.

Examples of how to use MathJax v3 in NodeJS are available in the mj3-demos-node repository. These include samples of how to convert a TeX string to an HTML string, an SVG string, or a MathML string, for example, or how to process a complete HTML page containing math.

What’s Included in MathJax v3

This beta version includes two input processors (TeX and MathML) and two output processors (CommonHTML and SVG). Other input and output processors (e.g., AsciiMath input) will be added in the future.

The current TeX input processor has all the core functionality of the MathJax v2 TeX input, and several of the extensions built in, but some extensions are still to come. For example, \unicode, \bbox, and the color extension are not yet available.

The CommonHTML and SVG output implement all the MathML elements that they do in v2, but do not yet include support for line breaking (neither automatic nor explicit ones); this will be implemented in a later beta version. Both output renderers currently only support the MathJax TeX font; other fonts will be added in the future.

The CommonHTML output currently uses a very large CSS file that encodes the font information needed for all the characters in the MathJax TeX fonts. This is a preliminary implementation of the font support, which will be updated to reduce the size of the CSS in future versions.

The SVG output currently uses explicit SVG <path> elements for the characters it displays, whereas version 2 cached the paths in a common SVG <defs> element so that paths didn’t have to be repeated in the individual expressions that used them. This will be implemented in a future version.

The MathJax contextual menu is not yet implemented.

The ability to customize MathJax through a configuration object, as in v2, is limited at the moment, but see the mj3-demos repository for examples of how this can be done currently. In version 3, this type of customization is handled through building custom packed versions of MathJax, and that is not yet fully documented; again, the demo repository includes examples.

NOTE

Mathjax v3 is in beta release. Do not use this in production, but please test it and report issues on the MathJax v3 issue tracker!

We are continuing to add more functionality to version 3, and will be releasing additional beta versions as new features become available. So watch this site for more news to come!

Re: source that PDF supports MathML

Source: public-mathonwebpages@w3.org Mail Archives • Olaf Drümmer (olaf@druemmer.com) • October 01, 2018 • Permalink

Hi Stephen,

- PDF 2.0 (ISO 32000-2), published in summer 2017, supports MathML in tagged PDF; some info can be found on the pdfa.org <http://pdfa.org/> website (use this search term: "mathml site:pdfa.org <http://pdfa.org/>" )
- in addition, PDF 2.0 has a mechanism called "associated files" which makes it straightforward to associate content like an equation in PDF (that in itself may not reflect the inner structure of that equation) with a file containing a suitable representation of that equation, e.g. using MathML, LaTeX, ASCIIMath or whatever (or several files, each with a different representation form of that content).
- Ross Moore from the Mathematics Dept at  Macquarie University/Australia has done a lot of work regarding creation of math PDF from TeX/LaTeX, if you want to do any work in this field you should get in touch with him (search for "ross moore mathml tex" to find more info)

Olaf



> On 1. Oct 2018, at 00:30, Blosser, Stephen <blossers@msu.edu <mailto:blossers@msu.edu>> wrote:
> 
> Dear Krista,
> Are you referring to this:
> https://helpx.adobe.com/framemaker/tutorials/improved-support-inline-mathml-equations-video.html <https://helpx.adobe.com/framemaker/tutorials/improved-support-inline-mathml-equations-video.html> ?
>  
> If you find anything about PDF support of mathml I am also looking. I have a small grant to develop LaTeX to mathml this is what I have so farhttp://msumathonline.com/ <http://msumathonline.com/>
>  
> The blind students I work with like to use screen readers to read mathml however I find it tedious to convert everything else in the tex document we get from the math professors to html. Since tex easily converts to PDF I could use what you are looking for.
>  
>  
> Stephen Blosser
> Assistive Technology Specialist, Michigan State University
> Resource Center For Persons with Disabilities (RCPD)
> 434 Farm lane, 120 Bessey Hall East Lansing, MI 48824-1033
> Honorary Ambassador, Consultant Rehabilitation Engineer
> Child Impact International http://childimpact.org <http://childimpact.org/>   Cell Phone: 517 648-9191
>  
>  
> From: Krista Greear <krista@inclusiveinstructionaldesign.com <mailto:krista@inclusiveinstructionaldesign.com>> 
> Sent: Sunday, September 30, 2018 12:28 AM
> To: public-mathonwebpages@w3.org <mailto:public-mathonwebpages@w3.org>
> Subject: source that PDF supports MathML
>  
> My Google sleuthing skills are failing me. Can anyone point me to the announcement that PDF supports MathML (although it's limited from what I remember and/or requires MathPlayer or something like that). 
>  
> Thanks!
>  
> -- 
> Krista Greear
> Accessibility and Inclusivity Crusader 

Re: source that PDF supports MathML

Source: public-mathonwebpages@w3.org Mail Archives • Noble,Stephen L. (steve.noble@louisville.edu) • October 01, 2018 • Permalink

It can be done. Here's the test results on Benetech's Math Support Finder:

https://msf.mathmlcloud.org/setups/20


There's a link on that page to a sample PDF file with MathML. The only assistive technology that has bothered to support MathML in PDF is NVDA (when you have MathPlayer installed). Then there's the issue of creating the files in the first place--there are no automated tools to create such files...they have to be hand-coded.


--Steve Noble


________________________________
From: Krista Greear <krista@inclusiveinstructionaldesign.com>
Sent: Sunday, September 30, 2018 12:28 AM
To: public-mathonwebpages@w3.org
Subject: source that PDF supports MathML

My Google sleuthing skills are failing me. Can anyone point me to the announcement that PDF supports MathML (although it's limited from what I remember and/or requires MathPlayer or something like that).

Thanks!

--
Krista Greear
Accessibility and Inclusivity Crusader

RE: source that PDF supports MathML

Source: public-mathonwebpages@w3.org Mail Archives • Blosser, Stephen (blossers@msu.edu) • September 30, 2018 • Permalink

Dear Krista,
Are you referring to this:
https://helpx.adobe.com/framemaker/tutorials/improved-support-inline-mathml-equations-video.html ?

If you find anything about PDF support of mathml I am also looking. I have a small grant to develop LaTeX to mathml this is what I have so far http://msumathonline.com/


The blind students I work with like to use screen readers to read mathml however I find it tedious to convert everything else in the tex document we get from the math professors to html. Since tex easily converts to PDF I could use what you are looking for.


Stephen Blosser
Assistive Technology Specialist, Michigan State University
Resource Center For Persons with Disabilities (RCPD)
434 Farm lane, 120 Bessey Hall East Lansing, MI 48824-1033
Honorary Ambassador, Consultant Rehabilitation Engineer
Child Impact International http://childimpact.org   Cell Phone: 517 648-9191


From: Krista Greear <krista@inclusiveinstructionaldesign.com>
Sent: Sunday, September 30, 2018 12:28 AM
To: public-mathonwebpages@w3.org
Subject: source that PDF supports MathML

My Google sleuthing skills are failing me. Can anyone point me to the announcement that PDF supports MathML (although it's limited from what I remember and/or requires MathPlayer or something like that).

Thanks!

--
Krista Greear
Accessibility and Inclusivity Crusader

OfficeMath

Source: Murray Sargent: Math in Office • MurrayS3 • September 30, 2018 • Permalink

Microsoft Word 2007 and RichEdit 6.0 introduced the native Office math facility. PowerPoint, Excel, and OneNote followed suit in 2010, and Mac Word followed in 2011. But ironically the native math facility hasn’t had a recognizable name. “Microsoft Equation Editor” (MEE) seems natural, but it’s the name of the Design Science math editor that shipped first in Office on Windows and the Mac in 1992 and was recently discontinued due to security problems. In fact, the post Converting Microsoft Equation Editor Objects to OfficeMath needs a name for the native math facility since it describes how you can convert MEE OLE math objects into native math zones. Sometimes people refer to the native math facility as OMML (Office Math Markup Language), which is the XML file format that encapsulates the in-memory math model and is used in docx, pptx, and xlsx files. But the facility is more than a file format since it has TeX typographical quality, is based on Unicode, has user interfaces (UI) and works with an OpenType math font. “Microsoft Math” is a possible name, but other companies might want to ship something similar. None of its specifications are proprietary.

A good name is OfficeMath. “Office” alludes to Microsoft Office but needn’t be exclusive. “Office” suggests a high-quality level (okay, maybe I’m biased ☺). OfficeMath might suggest calculations rather than math text, but documentation can resolve that ambiguity, which also exists for the linear formats AsciiMath and UnicodeMath. The heart of OfficeMath is its in-memory model, named “Professional” in the OfficeMath UI. This model is mirrored in the OMML file format. It features N-ary structures such as integrals with limits and integrands, subscripts, superscripts and accents with well-defined bases, and math functions with function names and arguments. This level of detail is ordinarily reserved for content math formats such as Content MathML and OpenMath. OfficeMath incorporated these structures to support high-quality math typography, with the nice side effect of facilitating symbolic manipulations and graphing (OneNote Math Assistant). This post summarizes OfficeMath’s history, model, file format support, interoperability, math font, and math formatting, and includes links to further information in OfficeMath-oriented posts in Math in Office. OfficeMath UI will be discussed in a separate post.

History

A fun place to learn about the origins of OfficeMath is the post LineServices, which tells how the LineServices line-layout component came to be and how it evolved to yield TeX-quality math typography. OfficeMath depends on other technologies as well, including the creation of the math-font OpenType standard described in High-Quality Editing and Display of Mathematical Text in Office 2007 and OpenType Math Tables. For older history, the post How I got into technical WP describes the first math display program (Scroll, 1970) and predecessors of UnicodeMath.

OfficeMath was based on Unicode from the start. Unicode 3.2 (March, 2002) already had most of the current Unicode math character set. The Unicode Technical Committee is committed to including all attested math symbols in the Unicode Standard, so Unicode makes an ideal foundation on which to build math functionality. It also streamlines incorporation into Microsoft Office applications, since they are based on Unicode.

Math Model

As with [La]TeX, MathML, MathType, and other math presentation programs, OfficeMath puts all math expressions and equations into math zones. Math-zone typography differs from the typography of ordinary text (see the section on Formatting below).

In the OfficeMath in-memory "Professional" format, mathematical objects like fraction and subscript are represented by a start delimiter, the first argument, an argument separator if the object has more than one argument, the second argument, etc., with the final argument terminated by an end delimiter. For example, the fraction 𝑎/𝑏 is represented in built-up format by {frac 𝑎|𝑏} where {frac is the start delimiter, | is the argument separator, and } is the end delimiter. Similarly, the subscript object 𝑎𝑏 is represented by {sub 𝑎|𝑏}. The start delimiter is the same character for all math objects as are the separator and end delimiters. In RichEdit, these delimiters are given by the Unicode characters U+FDD0, U+FDEE, and U+FDEF, respectively. In OMML, the start delimiter is represented by an container element, such as <f> for fraction and arguments appear within argument element containers, such as <num>…</num> for a numerator.

The type of object is specified by a character-format property associated with the start delimiter. In plain text, the built-up forms of the fraction and subscript are identical if the fraction arguments are the same as their subscript counterparts. In the example here, a plain-text search for {frac 𝑎|𝑏} matches {sub 𝑎|𝑏} as well as {frac 𝑎|𝑏}. Searching for OfficeMath equations involves plain-text searches like this together with comparison of the object types as discussed in Math Find/Replace and Rich Text Searches. The OfficeMath math objects are listed in the table in the next section along with their OMML and Presentation MathML representations. The objects are represented by prefix notation: the character formatting of the object start delimiter contains the object properties (see ITextRange2::GetInlineObject()). This differs from infix notation like 𝑎/𝑏, which needs to be parsed. The OfficeMath in-memory format is a “built-up” format as distinguished from linear formats like UnicodeMath and LaTeX.

Supported File formats

The OMML format is the XML format that encapsulates the OfficeMath in-memory “Professional” format. When OfficeMath was designed, Presentation MathML 3.0 was nearing publication. But Presentation MathML is missing two important elements which therefore require <mrow> emulations to represent OfficeMath. Specifically, Presentation MathML doesn’t have an explicit N-ary element, nor does it have an explicit math-function element. Furthermore, OfficeMath needs to embed client (Word, PowerPoint, Excel, …) XML easily into the math XML. The MathML <semantics> element can embed such information, but it’s awkward. Accordingly, OMML was created to describe the OfficeMath in-memory format naturally. With best practices, MathML without the <semantics> element can be used to round-trip OfficeMath equations apart from non-math formatting like revision markings and embedded objects.

Here is a listing from MathML and Ecma Math (OMML) of the OMML elements and exact or approximate MathML counterparts

Built-up Office Math Object... OMML tag... MathMl
Accent acc mover/munder
Bar bar mover/munder
Box box menclose (approx)
Boxed Formula borderBox menclose
Delimiters d mfenced
Equation Array eqArr mtable (with alignment groups)
Fraction f mfrac
Math Function func mrow with FunctionApply (2061) mo
Left SubSup sPre mmultiscripts (special case of)
Lower Limit limLow munder
Matrix m mtable
N-ary nary mrow msubsup/moverunder with N-ary mo
Phantom phant mphantom and/or mpadded
Radical rad msqrt/mroot
Group Char groupChr mover/munder
Subscript sSub msub
SubSup sSubSup msubsup
Superscript sSup msup
Upper Limit limUpp mover

Other OMML references are Extracting OMML from Word 2003 Math Zone Images and OMML Specification, Version 2.

More MathML discussion is given in MathML 3.0, Improved MathML support in Word 2007, Rendering MathML in HTML5, and MathML on the Windows Clipboard.

Mathematical RTF is essentially OMML in RTF syntax. See also Office Math RTF and OMML Documentation and Updated RTF Specification.

Linear Format Notations for Mathematics include UnicodeMath and LaTeX Math in Office. See also Recognizing LaTeX Input in UnicodeMath Input Model.

Interoperability

Major interoperability is afforded via Presentation MathML and [La]TeX math. In addition, the Design Science MEE and MathType equations can be converted to OfficeMath as described in Converting Microsoft Equation Editor Objects to OfficeMath. MathType can convert OfficeMath to MathType equations. These equation facilities are compared in Equation-Editor Office-Math Feature Comparison and Other Office Math Editing Facilities. The latter also compares them to the Microsoft Word EQ Field.

With a bit of effort, equations can be imported into Office applications from Wikipedia articles as described in Copying Equations from Wikipedia into Office Applications. You can create HTML documents with equations in them as described in Creating Math Web Documents using Word 2007.

Math Font

A basic part of OfficeMath is the Unicode OpenType math font. The first such font, Cambria Math, and the OpenType math tables were developed together with the Office 2007 math software, each influencing the other to obtain high quality results. Some history is given in the post High-Quality Editing and Display of Mathematical Text in Office 2007. The font contains extensive math tables, glyph variants and glyphs for most of the Unicode math character set. The tables were incorporated into the OpenType standard as noted in OpenType Math Tables. Posts elaborating on the math font are Special Capabilities of a Math Font and High Fonts and Math Fonts.

Cambria Math and Cambria are serifed fonts designed to look good on digital displays. As such, the stem widths never get skinny, in contrast to Times Roman fonts. If you prefer, the STIX math font is a Times Roman font that includes the OpenType math table support and works with OfficeMath. This font is discussed further in Math STIX Fonts 2.0 and UTR #25 Updates.

Formatting

This section discusses how OfficeMath handles math formatting involving math spacing, math styles, and alignments, and gives links to posts with further information. A math zone is defined by the math-zone character-format effect, an effect like bold or italic. As such, this is a non-nestable property, unlike math objects like fractions, which can be nested arbitrarily deeply. Adjacent math zones automatically merge into a single math zone.

An essential part of good math typography is math spacing. Within a math zone, OfficeMath follows the math spacing rules given in Appendix G of The TeXbook plus some enhancements that weren’t added to TeX for reasons of archivability. Section 3.16 of UnicodeMath summarizes the rules for the most common situations. Also see User Spaces in Math Zones for ways that OfficeMath autocorrects typical user input spacing errors. Two Math Typography Niceties shows how phantom objects can improve math spacing beyond the standard spacing rules.

Math bold and math italic define different math variables in math zones (𝐚 ≠ 𝑎 ≠ a ≠ 𝒂), while in ordinary text, bold and italic are used for emphasis. In math zones, math bold and math italic characters are different Unicode alphanumeric characters, while in ordinary text, bold and italic are character format attributes with no change in character codes. For example, 𝐚 is U+1D41A, 𝑎 is U+1D44E, a is U+0061, and 𝒂 is U+1D482. Even though the math and ordinary-text uses of bold/italic are unrelated semantically, the user can control these math styles using the usual bold and italic UI as described in Using Math Italic and Bold in Word 2007. There are other math styles that yield still different mathematical variables, such as open-face, script, Fractur, and sans serif (see Section 2.2 of Unicode Technical Report #25). In general, character formatting is controlled in math zones as described in Restricted Math Zone Character Formatting. In informal documents, people may want to use sans-serif characters instead of serif characters for aesthetic reasons rather than for defining different variables. Currently OfficeMath doesn’t support this choice, but maybe it should.

Occasionally one needs to embed ordinary text, such as words, into math zones. OfficeMath defines a character format attribute “ordinary text” for this purpose. Text with this attribute uses standard character formatting for italic, bold, etc. Unless the “ordinary text” attribute is active, the bold and italic settings only affect math alphanumerics; ASCII digits, punctuation, operators, and non-math characters are all rendered nonbold and upright.

In addition, OfficeMath has a “no-build-up” attribute to treat operator characters literally rather than use them in build-up translations. For example, if ‘\’ is marked with this attribute, build up in UnicodeMath mode leaves it as the character ‘\’ rather than converting it with the arguments around it into a built-up “stacked” fraction.

Since math zones are one level deep, you can embed ordinary text into a math zone, but you can’t nest a math zone within that ordinary text or elsewhere within the math zone. This hasn’t proven to be a limitation, although TeX can embed ordinary text inside math zones and nested math zones inside the ordinary text. It always seems to be possible to unwrap such nested math-zone scenarios into unnested math zones.

It’s useful to be able to define math properties for an entire document, rather than specify them for each math zone. This is described in Default Document Math Properties. A new property could be defined to use sans-serif math characters instead of serif characters.

There are two kinds of math zones: inline and display. For example, an inline math zone in TeX has the form $...$ and a display math zone has the form $$...$$. Inline math zones use reduced spacing and character sizes to make expressions fit better in line with normal text. In OfficeMath a display math zone starts at the start of a document or follows a hard or soft paragraph end (U+000D or U+000B, respectively) and ends with a hard or soft paragraph end. In some cases, it would be useful to apply display math-zone formatting to inline math zones, but this isn’t currently available.

Inter-equation alignment and line breaking involve multiple lines. To handle these cases and equation numbering, OfficeMath has the Math Paragraph, while MathML uses tables and MathType uses PILEs. A math paragraph is a sequence of one or more display math zones separated by soft paragraph ends (U+000B). Line breaking can be automatic or manual as described in Breaking Equations into Multiple Lines. Background on paragraph formatting is given in Paragraphs and Paragraph Formatting.

In a document with more than a few equations, it’s useful to number equations referred to from elsewhere in the document. The math paragraph has elegant equation-number support, but it hasn’t been exposed beyond prototyping. The earliest way to handle equation numbering is described in Cool Equation Number Macros for Word 2007. Later ideas are in More on Equation Numbering and equation numbering using equation arrays is described in Equation Numbering in Office 2016. This last approach isn’t quite as convenient as the ideal math-paragraph equation numbering, but it can handle virtually all cases.

Re: [Japanese] Completed translation of XML Entity Definitions for Characters (2nd Edition)

Source: www-math@w3.org Mail Archives • 高村 吉一 (soco__kankyo@hotmail.com) • September 30, 2018 • Permalink

Dear David

I directly translated the HTML.

Thank you for telling me github and sources of Editor's draft.

Best regards,
Yoshikazu

________________________________
差出人: David Carlisle <davidc@nag.co.uk>
送信日時: 2018年9月28日 22:45
宛先: Xueyuan; 高村 吉一
CC: w3c-translators@w3.org; www-math@w3.org
件名: Re: [Japanese] Completed translation of XML Entity Definitions for Characters (2nd Edition)

On 28/09/2018 08:54, Xueyuan wrote:
>
> Hi Yoshikazu,
>
>
> Thank you very much!

Yoshikazu,

yes thanks for this!

May I ask did you directly translate the HTML or did you translate the
source XML and XSLT files?

I ask as some of the English text (notably headings for the generated
tables) is inserted by the XSLT build stylesheet and that could have an
option to insert Japanese (or other) texts instead of English, which may
help keep future translations in sync, if they are generated from
translated source XML?

The editor's draft is on github at

https://w3c.github.io/xml-entities/

with sources at

https://github.com/w3c/xml-entities

Especially as Xueyuan mentioned a github based workflow for translations
in future, it seemed worth pointing at these versions.
(There are no changes in the editors draft other than using the newer
css styles and updating to Unicode 11 (which doesn't affect any of the
normative parts of the spec)

David



Disclaimer

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. Please see our Privacy Notice<https://www.nag.co.uk/content/privacy-notice> for information on how we process personal data and for details of how to stop or limit communications from us.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.

source that PDF supports MathML

Source: public-mathonwebpages@w3.org Mail Archives • Krista Greear (krista@inclusiveinstructionaldesign.com) • September 30, 2018 • Permalink

My Google sleuthing skills are failing me. Can anyone point me to the
announcement that PDF supports MathML (although it's limited from what I
remember and/or requires MathPlayer or something like that).

Thanks!

-- 
Krista Greear
Accessibility and Inclusivity Crusader

Re: [Japanese] Completed translation of XML Entity Definitions for Characters (2nd Edition)

Source: www-math@w3.org Mail Archives • David Carlisle (davidc@nag.co.uk) • September 28, 2018 • Permalink

On 28/09/2018 08:54, Xueyuan wrote:
> 
> Hi Yoshikazu,
> 
> 
> Thank you very much!

Yoshikazu,

yes thanks for this!

May I ask did you directly translate the HTML or did you translate the 
source XML and XSLT files?

I ask as some of the English text (notably headings for the generated 
tables) is inserted by the XSLT build stylesheet and that could have an 
option to insert Japanese (or other) texts instead of English, which may 
help keep future translations in sync, if they are generated from 
translated source XML?

The editor's draft is on github at

https://w3c.github.io/xml-entities/

with sources at

https://github.com/w3c/xml-entities

Especially as Xueyuan mentioned a github based workflow for translations 
in future, it seemed worth pointing at these versions.
(There are no changes in the editors draft other than using the newer 
css styles and updating to Unicode 11 (which doesn't affect any of the 
normative parts of the spec)

David

Disclaimer

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 and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. 

Re: [Japanese] Completed translation of XML Entity Definitions for Characters (2nd Edition)

Source: www-math@w3.org Mail Archives • Xueyuan (xueyuan@w3.org) • September 28, 2018 • Permalink


Hi Yoshikazu,


Thank you very much!


As you might know that W3C is currently exploring new approach to better 
support translators and promote the valuable translations. Dom has 
explained the new proposal at:
https://lists.w3.org/Archives/Public/w3c-translators/2018JulSep/0048.html

Any of your input (feedback, question, participation...) is highly 
welcome and much appreciated. :)


Thanks again, for being an active and continuous contributor to W3C 
translations.


Best,
Xueyuan


On 27/09/2018 23:21, 高村 吉一 wrote:
> Dear Xueyuan,
>
> Thanks very much for your advice,
> and I'm sorry I mistake the pointer to the original English document.
>
> Now, I fixed the pointer.
>
> Warm regards,
> Yoshikazu
>
> ------------------------------------------------------------------------
> *差出人:* Xueyuan <xueyuan@w3.org>
> *送信日時:* 2018年9月27日 23:02
> *宛先:* 高村 吉一
> *CC:* w3c-translators@w3.org; www-math@w3.org
> *件名:* Re: [Japanese] Completed translation of XML Entity Definitions 
> for Characters (2nd Edition)
>
>
> Dear Yoshikazu,
>
>
> Thanks very much for your continuous contribution!
>
>
> In the Disclaimer of the translation, the pointer to the original 
> English document currently is
>
> "https://www.w3.org/TR/2010/REC-xml-entity-names-20140410/" 
> <https://www.w3.org/TR/2010/REC-xml-entity-names-20140410/>
>
> which I suppose is
> "https://www.w3.org/TR/2014/REC-xml-entity-names-20140410/" 
> <https://www.w3.org/TR/2014/REC-xml-entity-names-20140410/>.
>
>
> Could you please fix it?
>
>
> Warm regards,
>
> Xueyuan
>
>
> On 26/09/2018 20:51, 高村 吉一 wrote:
>> Dear Translators
>> And Dear W3C Math mailing list Members
>>
>> I would like to announce that I have completed the translation into 
>> Japanese of the following document:
>>
>> XML Entity Definitions for Characters (2nd 
>> Edition)(http://www.w3.org/TR/2014/REC-xml-entity-names-20140410/)
>> 文字に対するXML実体の定義(第2版)(http://takamu.sakura.ne.jp/xml-entity-names-ja/index.html)
>>
>> I confirm that, in compliance with the W3C Intellectual Property FAQ 
>> (http://www.w3.org/Consortium/Legal/IPR-FAQ-20000620#translate), I 
>> have placed a prominent disclaimer in my translation(s) in which I 
>> disclose, (1) the title of and link to the original English document, 
>> (2) that my document is a translation which may contain errors, and 
>> (3) that the original English document on the W3C website is the one 
>> that is official. (Items (2) and (3) are in the target language.)
>>
>> I confirm that the links within my translation(s) are valid and I 
>> have endeavored to provide valid markup and CSS (validation tools are 
>> at http://validator.w3.org/).
>>
>> And I changed URL of translation that is following 1st Edition document.
>>
>> XML Entity Definitions for 
>> Characters(http://www.w3.org/TR/2010/REC-xml-entity-names-20100401/)
>> 文字に対するXML実体の定義(http://takamu.sakura.ne.jp/xml-entity-names-20100401-ja/index.html)
>>
>> Sincerely
>>
>> 26.Sep.2018
>>
>> 高村 吉一(Yoshikazu Takamura)
>> MailAdress : soco__kankyo@hotmail.com <mailto:soco__kankyo@hotmail.com>
>

MathOnWeb CG -- meeting minutes 2018-09-27

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • September 27, 2018 • Permalink

Hi everyone,

Here are the minutes from the meeting on Sept 27.

Best,
Peter.

# MathOnWeb CG main meeting 2018-09-27

* Present: Joanie, Peter, Krista, Neil, Charle
  * Regrets: Dani, Arno
* Neil: no agenda?
  * Peter: with new setup, let's make it open mic night / catching up
* Joanie: I saw that personalization came up on the a11y meeting
  * Joanie: keeping separated what a user wants (personalization spec)
    * separate from implementation details
    *  Personalization TF was split off ARIA so I'm not sure if it has come
up there?
      * Charles: we're catching up on initial set of tasks
      * Charles: items like colors for dyslexia hasn't come up yet
* Neil: what's the CSS TF up to for TPAC?
  * Peter: [recapping
https://github.com/w3c/mathonwebpages/wiki/%5BCSS-TF%5D-TPAC-2018-preparations
]
    * we're focused on preparing 3-5 focus areas
    * with enough buffer if 1-3 are discarded quickly
    * thinking about aligning issues strategically so that we can dive
deeper when there's interest
    * E.g., baseline => math axis
    * e.g. stretchy constructions => css drawings / traditional characters
stacks  / houdini / variable fonts
      * could lead deeper, e.g., to css border improvements, browser zoom
improvements, font metric access,
    * focus on building a relationship for future work
  * Neil: any other updates from this week?
    * Peter: no meeting due to travel
* => we're all caught up, let's wrap it up

Re: [Japanese] Completed translation of XML Entity Definitions for Characters (2nd Edition)

Source: www-math@w3.org Mail Archives • 高村 吉一 (soco__kankyo@hotmail.com) • September 27, 2018 • Permalink

Dear Xueyuan,

Thanks very much for your advice,
and I'm sorry I mistake the pointer to the original English document.

Now, I fixed the pointer.

Warm regards,
Yoshikazu

________________________________
差出人: Xueyuan <xueyuan@w3.org>
送信日時: 2018年9月27日 23:02
宛先: 高村 吉一
CC: w3c-translators@w3.org; www-math@w3.org
件名: Re: [Japanese] Completed translation of XML Entity Definitions for Characters (2nd Edition)



Dear Yoshikazu,


Thanks very much for your continuous contribution!


In the Disclaimer of the translation, the pointer to the original English document currently is

"https://www.w3.org/TR/2010/REC-xml-entity-names-20140410/"<https://www.w3.org/TR/2010/REC-xml-entity-names-20140410/>

which I suppose is
"https://www.w3.org/TR/2014/REC-xml-entity-names-20140410/"<https://www.w3.org/TR/2014/REC-xml-entity-names-20140410/>.


Could you please fix it?

Warm regards,

Xueyuan

On 26/09/2018 20:51, 高村 吉一 wrote:
Dear Translators
And Dear W3C Math mailing list Members

I would like to announce that I have completed the translation into Japanese of the following document:

XML Entity Definitions for Characters (2nd Edition)(http://www.w3.org/TR/2014/REC-xml-entity-names-20140410/)
文字に対するXML実体の定義(第2版)(http://takamu.sakura.ne.jp/xml-entity-names-ja/index.html)

I confirm that, in compliance with the W3C Intellectual Property FAQ (http://www.w3.org/Consortium/Legal/IPR-FAQ-20000620#translate), I have placed a prominent disclaimer in my translation(s) in which I disclose, (1) the title of and link to the original English document, (2) that my document is a translation which may contain errors, and (3) that the original English document on the W3C website is the one that is official. (Items (2) and (3) are in the target language.)

I confirm that the links within my translation(s) are valid and I have endeavored to provide valid markup and CSS (validation tools are at http://validator.w3.org/).

And I changed URL of translation that is following 1st Edition document.

XML Entity Definitions for Characters(http://www.w3.org/TR/2010/REC-xml-entity-names-20100401/)
文字に対するXML実体の定義(http://takamu.sakura.ne.jp/xml-entity-names-20100401-ja/index.html)

Sincerely

26.Sep.2018

高村 吉一(Yoshikazu Takamura)
MailAdress : soco__kankyo@hotmail.com<mailto:soco__kankyo@hotmail.com>

Re: [Japanese] Completed translation of XML Entity Definitions for Characters (2nd Edition)

Source: www-math@w3.org Mail Archives • Xueyuan (xueyuan@w3.org) • September 27, 2018 • Permalink


Dear Yoshikazu,


Thanks very much for your continuous contribution!


In the Disclaimer of the translation, the pointer to the original  
English document currently is

"https://www.w3.org/TR/2010/REC-xml-entity-names-20140410/"

which I suppose is
"https://www.w3.org/TR/2014/REC-xml-entity-names-20140410/".


Could you please fix it?


Warm regards,

Xueyuan


On 26/09/2018 20:51, 高村 吉一 wrote:
> Dear Translators
> And Dear W3C Math mailing list Members
>
> I would like to announce that I have completed the translation into  
> Japanese of the following document:
>
> XML Entity Definitions for Characters (2nd  
> Edition)(http://www.w3.org/TR/2014/REC-xml-entity-names-20140410/)
> 文字に対するXML実体の定義(第2版)(http://takamu.sakura.ne.jp/xml- 
> entity-names-ja/index.html)
>
> I confirm that, in compliance with the W3C Intellectual Property FAQ  
> (http://www.w3.org/Consortium/Legal/IPR-FAQ-20000620#translate), I  
> have placed a prominent disclaimer in my translation(s) in which I  
> disclose, (1) the title of and link to the original English document,  
> (2) that my document is a translation which may contain errors, and  
> (3) that the original English document on the W3C website is the one  
> that is official. (Items (2) and (3) are in the target language.)
>
> I confirm that the links within my translation(s) are valid and I have  
> endeavored to provide valid markup and CSS (validation tools are at  
> http://validator.w3.org/).
>
> And I changed URL of translation that is following 1st Edition document.
>
> XML Entity Definitions for  
> Characters(http://www.w3.org/TR/2010/REC-xml-entity-names-20100401/)
> 文字に対するXML実体の定義(http://takamu.sakura.ne.jp/xml-entity-names- 
> 20100401-ja/index.html)
>
> Sincerely
>
> 26.Sep.2018
>
> 高村 吉一(Yoshikazu Takamura)
> MailAdress : soco__kankyo@hotmail.com

Re: [Japanese] Completed translation of XML Entity Definitions for Characters (2nd Edition)

Source: www-math@w3.org Mail Archives • Naomi Yoshizawa (naomi@w3.org) • September 26, 2018 • Permalink

Dear Yoshikazu,

Thanks so much for the translation with the high quality on this
technology! It’s absolutely a great textbook for Japanese Web community as
well.

Best regards,

Naomi

—
Naomi Yoshizawa, W3C, Keio University
5322 Endo, Fujisawa, Kanagawa 252-0882 Japan
+813.3516.2504

2018年9月26日(水) 21:53 高村 吉一 <soco__kankyo@hotmail.com>:

> Dear Translators
> And Dear W3C Math mailing list Members
>
> I would like to announce that I have completed the translation into
> Japanese of the following document:
>
> XML Entity Definitions for Characters (2nd Edition)(
> http://www.w3.org/TR/2014/REC-xml-entity-names-20140410/)
> 文字に対するXML実体の定義(第2版)(
> http://takamu.sakura.ne.jp/xml-entity-names-ja/index.html)
>
> I confirm that, in compliance with the W3C Intellectual Property FAQ (
> http://www.w3.org/Consortium/Legal/IPR-FAQ-20000620#translate), I have
> placed a prominent disclaimer in my translation(s) in which I disclose, (1)
> the title of and link to the original English document, (2) that my
> document is a translation which may contain errors, and (3) that the
> original English document on the W3C website is the one that is official.
> (Items (2) and (3) are in the target language.)
>
> I confirm that the links within my translation(s) are valid and I have
> endeavored to provide valid markup and CSS (validation tools are at
> http://validator.w3.org/).
>
> And I changed URL of translation that is following 1st Edition document.
>
> XML Entity Definitions for Characters(
> http://www.w3.org/TR/2010/REC-xml-entity-names-20100401/)
> 文字に対するXML実体の定義(
> http://takamu.sakura.ne.jp/xml-entity-names-20100401-ja/index.html)
>
> Sincerely
>
> 26.Sep.2018
>
> 高村 吉一(Yoshikazu Takamura)
> MailAdress : soco__kankyo@hotmail.com
>
-- 
--
吉澤直美
慶應義塾大学 W3C (World Wide Web Consortium)
〒252-0882 神奈川県藤沢市遠藤5322
Tel:03-3516-2504

[Japanese] Completed translation of XML Entity Definitions for Characters (2nd Edition)

Source: www-math@w3.org Mail Archives • 高村 吉一 (soco__kankyo@hotmail.com) • September 26, 2018 • Permalink

Dear Translators
And Dear W3C Math mailing list Members

I would like to announce that I have completed the translation into Japanese of the following document:

XML Entity Definitions for Characters (2nd Edition)(http://www.w3.org/TR/2014/REC-xml-entity-names-20140410/)
文字に対するXML実体の定義(第2版)(http://takamu.sakura.ne.jp/xml-entity-names-ja/index.html)

I confirm that, in compliance with the W3C Intellectual Property FAQ (http://www.w3.org/Consortium/Legal/IPR-FAQ-20000620#translate), I have placed a prominent disclaimer in my translation(s) in which I disclose, (1) the title of and link to the original English document, (2) that my document is a translation which may contain errors, and (3) that the original English document on the W3C website is the one that is official. (Items (2) and (3) are in the target language.)

I confirm that the links within my translation(s) are valid and I have endeavored to provide valid markup and CSS (validation tools are at http://validator.w3.org/).

And I changed URL of translation that is following 1st Edition document.

XML Entity Definitions for Characters(http://www.w3.org/TR/2010/REC-xml-entity-names-20100401/)
文字に対するXML実体の定義(http://takamu.sakura.ne.jp/xml-entity-names-20100401-ja/index.html)

Sincerely

26.Sep.2018

高村 吉一(Yoshikazu Takamura)
MailAdress : soco__kankyo@hotmail.com

Re: [MathOnWeb] a11y task force minutes 2018-09-24

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • September 26, 2018 • Permalink

Thanks, Neil.

Am Mi., 26. Sep. 2018 um 07:29 Uhr schrieb Neil Soiffer <
soiffer@alum.mit.edu>:

> Small correction: my dyslexia example is that 3 and 8 are sometimes
> confused, as are 6 and 9, 5 and 2, + and ÷. There are others things also.
>
>     Neil
>
>
> On Tue, Sep 25, 2018 at 1:11 PM Peter Krautzberger <peter@krautzource.com>
> wrote:
>
>> Hi everyone,
>>
>> Here are the minutes from the meeting of the accessibility task force
>> this week.
>>
>> Best,
>> Peter.
>>
>> # MathOnWeb Accessibility Task Force meeting, 2018-09-24
>>
>> * Present: Volker, Charles, Peter, Neil, Krista
>>   * Regrets: Joanie, Kevin, Dani
>> * Peter: TPAC
>>   * last time we listed labeling and navigation and had a discussion
>> about the place of tooling
>>   * how do we get there?
>> * Charles: there's also the CSS meeting
>>   * Peter: yes, mostly the TF but everyone welcome (I think)
>>   * Neil: is there something a11y related?
>>     * Peter: not as such. It's focused on layout
>>   * Neil: dyslexia
>>     * unclear research on fonts
>>     * other ideas though
>>   * Charles: there was also color, bolding etc?
>>     * Neil: right. lots of complications
>>       * can you even do this on a character level?
>>     * Peter: not on a dev level, but engines might
>>   * Neil: would be good to ask this but not sure if it's trivial?
>>     * ACTION: Charles to find out the state
>>   * Krista: what's the background on this?
>>     * why would you change the color?
>>     * Neil: helps people who have trouble identifying shapes
>>       * e.g. E and 3,  8 and B
>>       * you can use colors to identify each, and rotate colors
>>     * Krista: ok, makes sense for those users
>>       * would need user controlled removal for color blindness
>>       * Neil: right.
>>       * Charles: customization can help
>> * Peter: it seems to me that our disambiguation work does not lend itself
>> to discussion at TPAC
>>   * not really constructive, just tells us how complicated it is
>>   * what do people think?
>>   * Neil: we don't really have a proposal
>> * Volker: but we wanted to discuss navigation?
>>   * Peter: right. Just back tracking
>>   * ACTION: peter and volker to summarize the approaches used in MathJax
>> a11y extensions, light walker (and possibly other tools in this space)
>> * Peter: this connects to labeling
>>   * but that came from Dani
>>   * Maybe make it an action for him
>>   * ACTION Dani to write up page on labeling
>> * Krista: question: I'm working with instructors on making accessible
>> content
>>   * do you have guidelines for instructors for authoring?
>>   * and beyond web to word and PDF
>>   * Neil: PDF does have MathML nowadays
>>     * but no authoring tools
>>   * Peter: authoring guidelines is definitely in scope
>>     * print maybe not so much but technically we can do whatever people
>> want to tackle
>> * Krista: is MathML in LMS a topic?
>>   * Peter: it's come up before but no specific work items
>>   * Neil: LMS integration of WIRIS tools probably the standard
>> * Krista: for faculty, do you have recommendations to answer "how to
>> produce this accessibly"?
>>   * Charles: Benetech has some groups on this
>>   * Neil: for LMS, there's WIRIS's tools
>>   * Charles: there's math support finder and ebook prototype
>> * Krista: I recommend MathML in docx files. Is that reasonable?
>>   * Neil: yes. Peter will disagree
>>   * Peter: for non-web and not being sued, yes. For best quality, imho, no
>>   * Volker: there are limitations, especially on more advanced fields
>>     * one should never throw away sources, e.g., LaTeX
>>
>

Re: [MathOnWeb] a11y task force minutes 2018-09-24

Source: public-mathonwebpages@w3.org Mail Archives • Neil Soiffer (soiffer@alum.mit.edu) • September 26, 2018 • Permalink

Small correction: my dyslexia example is that 3 and 8 are sometimes
confused, as are 6 and 9, 5 and 2, + and ÷. There are others things also.

    Neil


On Tue, Sep 25, 2018 at 1:11 PM Peter Krautzberger <peter@krautzource.com>
wrote:

> Hi everyone,
>
> Here are the minutes from the meeting of the accessibility task force
> this week.
>
> Best,
> Peter.
>
> # MathOnWeb Accessibility Task Force meeting, 2018-09-24
>
> * Present: Volker, Charles, Peter, Neil, Krista
>   * Regrets: Joanie, Kevin, Dani
> * Peter: TPAC
>   * last time we listed labeling and navigation and had a discussion about
> the place of tooling
>   * how do we get there?
> * Charles: there's also the CSS meeting
>   * Peter: yes, mostly the TF but everyone welcome (I think)
>   * Neil: is there something a11y related?
>     * Peter: not as such. It's focused on layout
>   * Neil: dyslexia
>     * unclear research on fonts
>     * other ideas though
>   * Charles: there was also color, bolding etc?
>     * Neil: right. lots of complications
>       * can you even do this on a character level?
>     * Peter: not on a dev level, but engines might
>   * Neil: would be good to ask this but not sure if it's trivial?
>     * ACTION: Charles to find out the state
>   * Krista: what's the background on this?
>     * why would you change the color?
>     * Neil: helps people who have trouble identifying shapes
>       * e.g. E and 3,  8 and B
>       * you can use colors to identify each, and rotate colors
>     * Krista: ok, makes sense for those users
>       * would need user controlled removal for color blindness
>       * Neil: right.
>       * Charles: customization can help
> * Peter: it seems to me that our disambiguation work does not lend itself
> to discussion at TPAC
>   * not really constructive, just tells us how complicated it is
>   * what do people think?
>   * Neil: we don't really have a proposal
> * Volker: but we wanted to discuss navigation?
>   * Peter: right. Just back tracking
>   * ACTION: peter and volker to summarize the approaches used in MathJax
> a11y extensions, light walker (and possibly other tools in this space)
> * Peter: this connects to labeling
>   * but that came from Dani
>   * Maybe make it an action for him
>   * ACTION Dani to write up page on labeling
> * Krista: question: I'm working with instructors on making accessible
> content
>   * do you have guidelines for instructors for authoring?
>   * and beyond web to word and PDF
>   * Neil: PDF does have MathML nowadays
>     * but no authoring tools
>   * Peter: authoring guidelines is definitely in scope
>     * print maybe not so much but technically we can do whatever people
> want to tackle
> * Krista: is MathML in LMS a topic?
>   * Peter: it's come up before but no specific work items
>   * Neil: LMS integration of WIRIS tools probably the standard
> * Krista: for faculty, do you have recommendations to answer "how to
> produce this accessibly"?
>   * Charles: Benetech has some groups on this
>   * Neil: for LMS, there's WIRIS's tools
>   * Charles: there's math support finder and ebook prototype
> * Krista: I recommend MathML in docx files. Is that reasonable?
>   * Neil: yes. Peter will disagree
>   * Peter: for non-web and not being sued, yes. For best quality, imho, no
>   * Volker: there are limitations, especially on more advanced fields
>     * one should never throw away sources, e.g., LaTeX
>

Feeds

Planet MathML features:

If you own a blog with a focus on MathML, and want to be added or removed from this aggregator, please get in touch with Bert Bos at bert@w3.org.

(feed)This page as an Atom feed

A mechanical calculation machine (with an added W3C logo)

Bert Bos, math activity lead
Copyright © 2008–2015 W3C®

Powered by Planet