# 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.

## Contact

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.

All times are UTC.

Atom feed

## en December 05, 2013 Decomposition of 2D-transform matrices

Author: | Channel: Blog de Frédéric - Tag - mathml

−⁡π

Note: some parts of this blog post (especially the Javascript program) may be lost when exported to Planet or other feed aggregators. Please view it on the original page.

I recently took a look at the description of the CSS 2D / SVG transform matrix(a, b, c, d, e, f) on MDN and I added a concrete example showing the effect of such a transform on an SVG line, in order to make this clearer for people who are not familiar with affine transformations or matrices.

This also recalled me a small algorithm to decompose an arbitrary SVG transform into a composition of basic transforms (Scale, Rotate, Translate and Skew) that I wrote 5 years ago for the Amaya SVG editor. I translated it into Javascript and I make it available here. Feel free to copy it on MDN or anywhere else. The convention used to represent transforms as 3-by-3 matrices is the one of the SVG specification.

## Live demo

Enter the CSS 2D transform you want to reduce and decompose or pick one example from the list . You can also choose between LU-like or QR-like decomposition: .

CSS

Here is the reduced CSS/SVG matrix as computed by your rendering engine ? and its matrix representation:

After simplification (and modulo rounding errors), an SVG decomposition into simple transformations is ? and it renders like this:

SVG

After simplification (and modulo rounding errors), a CSS decomposition into simple transformations is ? and it renders like this:

CSS

A matrix decomposition of the original transform is:

## Mathematical Description

The decomposition algorithm is based on the classical LU and QR decompositions. First remember the SVG specification: the transform matrix(a,b,c,d,e,f) is represented by the matrix

(a c e b d f 0 0 1)

and corresponds to the affine transformation

(x y)&map(a c b d)(x y)+(e f)

which shows the classical factorization into a composition of a linear transformation (a c b d) and a translation (e f). Now let's focus on the matrix (a c b d) and denote Δ=ad−bc its determinant. We first consider the LDU decomposition. If a≠0, we can use it as a pivot and apply one step of Gaussian's elimination:

(1 0 −b/a 1)(a c b d)=(a c 0 Δ/a)

and thus the LDU decomposition is

(a c b d)=(1 0 b/a 1)(a 0 0 Δ/a)(1 c/a 0 1)

Hence if a≠0, the transform matrix(a,b,c,d,e,f) can be written translate(e,f) skewY(atan(b/a)) scale(a, Δ/a) skewX(c/a). If a=0 and b≠0 then we have Δ=−cb and we can write (this is approximately "LU with full pivoting"):

(0 c b d)=(0 −1 1 0)(b d 0 −c)=(cos(π/2) −sin(π/2) sin(π/2) cos(π/2))(b 0 0 Δ/b)(1 d/b 0 1)

and so the transform becomes translate(e,f) rotate(90°) scale(b, Δ/b) skewX(d/b). Finally, if a=b=0, then we already have an LU decomposition and we can just write

(0 c 0 d)=(c 0 0 d)(1 1 0 1)(0 0 0 1)

and so the transform is translate(e,f) scale(c, d) skewX(45°) scale(0, 1).

As a consequence, we have proved that any transform matrix(a,b,c,d,e,f) can be decomposed into a product of simple transforms. However, the decomposition is not always what we want, for example scale(2) rotate(30°) will be decomposed into a product that involves skewX and skewY instead of preserving the nice factors.

We thus consider instead the QR decomposition. If Δ≠0, then by applying the Gram–Schmidt process to the columns (a b),(c d) we obtain

(a c b d)=(a/r −b/r b/r a/r)(r (ac+bd)/r 0 Δ/r)=(a/r −b/r b/r a/r)(r 0 0 Δ/r)(1 (ac+bd)/r 2 0 1)

where r=a 2+b 2≠0. In that case, the transform becomes translate(e,f) rotate(sign(b) * acos(a/r)) scale(r, Δ/r) skewX(atan((a c + b d)/r^2)). In particular, a similarity transform preserves orthogonality and length ratio and so ac+bd=(a b)⋅(c d)=0 and Δ=&DoubleVerticalBar(a b)&DoubleVerticalBar&VerticalBar(c d)&DoubleVerticalBarcos(π/2)=r 2. Hence for a similarity transform we get translate(e,f) rotate(sign(b) * acos(a/r)) scale(r) as wanted. We also note that it is enough to assume the weaker hypothesis r≠0 (that is a≠0 or b≠0) in the expression above and so the decomposition applies in that case too. Similarly, if we let s=c 2+d 2 and instead assume c≠0 or d≠0 we get

(a c b d)=(cos(π/2) −sin(π/2) sin(π/2) cos(π/2))(−c/s d/s −d/s −c/s)(Δ/s 0 0 s)(1 0 (ac+bd)/s 2 1)

Hence in that case the transform is translate(e,f) rotate(90° - sign(d) * acos(-c/s)) scale(Delta/s, s) skewY(atan((a c + b d)/s^2)). Finally if a=b=c=d=0, then the transform is just scale(0,0).

The decomposition algorithms are now easy to write. We note that none of them gives the best result in all the cases (compare for example how they factor Rotate2 and Skew1). Also, for completeness we have included the noninvertible transforms in our study (that is Δ=0) but in practice they are not really useful (try NonInvertible).

## en-US December 04, 2013 HighWire supports MathJax as a MathJax Supporter

Author: | Channel: MathJax

HighWire is giving the MathJax project a boost by joining our sponsorship program as MathJax Supporter. A division of the Stanford University Libraries, HighWire hosts the largest repository of peer-reviewed content.

Founded in 1995, HighWire pioneered today’s online journal. As a partner to independent scholarly publishers, societies, associations, and university presses HighWire facilitates the digital dissemination of 1757 journals, reference works, books, and proceedings, including the Journal of Biological Chemistry (JBC Online), Science, the Journal of Neuroscience, and Proceedings of the National Academy of Science (PNAS). HighWire continually improves the reader’s experience by adopting the information technology’s best-practices, standards, and architecture.

“Many of the HighWire affiliated publishers are adopting MathJax’s flexible, light-weight mathematical display technology,” said Xenia Siller, HighWire’s Director of Content Systems and Services. “The MathJax team is great to work with, and we’re pleased to be able to support the program from the inside.”

Becoming a MathJax Supporter allows HighWire to make optimal use of MathJax, and makes an important contribution to keeping MathJax the reliable, flexible and open technology for mathematics on the web.

## UND November 28, 2013 Bitingduck Press Releases Truly Tricky Graduate Physics Problems ...

Channel: Ask.com News Search for "mathml"

 PRWeb - Found Nov. 28, 2013 All of the problems are solved in painstaking detail by physicists who have been there. The book is typset as an epub file with MathML.

## UND November 28, 2013 Bitingduck Press Releases Truly Tricky Graduate Physics Problems in ...

Channel: Ask.com News Search for "mathml"

 Individual.com - Found Nov. 28, 2013 All of the problems are solved in painstaking detail by physicists who have been there. The book is typset as an epub file with MathML.

## en-US November 26, 2013 Project Euclid continues as a MathJax Supporter

Author: | Channel: MathJax

Project Euclid continues to support the MathJax project as a MathJax Supporter.

Project Euclid, jointly managed by Cornell University Library and Duke University Press, addresses the unique needs of independent and society journals. Through a collaborative partnership arrangement, these publishers join forces to create a vibrant online information community for independent and society journals. Project Euclid has been an early MathJax supporter as well as large-scale adopter of MathJax, providing native, high quality, and accessible mathematics for its readers.

“Project Euclid is delighted to continue its support of MathJax,” said Mira Waller, Project Euclid Manager at Duke University Press. “We are pleased to have expanded MathJax’s presence on Project Euclid’s soon-to-be-launched new site, and we look forward to continuing our partnership with MathJax to enhance and further develop the experience of math online.”

The MathJax team looks forward to the continued collaboration with Project Euclid, and welcomes their ongoing support for the MathJax project.

## enNovember 26, 2013 “Mathematics in ebooks”: project looking for sponsors

Channel: W3C Math Home

Frédéric Wang, well-known for his work on MathML in Firefox and MathJax, has launched a call for sponsors for a project called Mathematics in ebooks.

Although Firefox supports MathML, and MathJax can be used to emulate MathML in browsers that support JavaScript, the resulting rendering is not as good as one would hope: Before you convert a book with mathematical formulas to an e-book, you would want typesetting closer to the quality of paper books.

The problem is lack of programmer time. There are few people who can do the programming and they have little spare time. Frédéric Wang is one of them and the project is meant to allow him to work full-time for a few months.

The main goals of the project are twofold:

1. Create a collection of educational & scientific documents that will serve as examples & test cases for publishers and implementers.
2. Improve rendering quality in WebKit and Gecko so that EPUB publishers can rely on it.

His initial target is € 3960, or one person in France working full-time for three months.

## UNDNovember 24, 2013 [Project Announcement] Improving MathML in Gecko & WebKit and Creating a collection of EPUB samples

Author: | Channel: www-math@w3.org Mail Archives

Hi,

As announced earlier, I've been preparing a project to boost MathML
developments in Gecko & WebKit. I called it "Mathematics in ebooks" and
its main goals will be to:

* Create a collection of educational & scientific documents that will
serve as examples & test cases for publishers and implementers.
* Improve rendering quality in WebKit and Gecko so that EPUB publishers
can rely on it.

I published it one week ago on the Ulule Website. If your wish to know
more and to spread the word, here is the project page:

http://www.ulule.com/mathematics-ebooks/

Thank you.

--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic

Hi, As announced earlier, I've been preparing a project to boost MathML developments in Gecko & WebKit. I called it "Mathematics in ebooks" and its main goals will be to: * Create a collection of educational & scientific documents that will serve as examples & test cases for publishers and implementers. * Improve rendering quality in WebKit and Gecko so that EPUB publishers can rely on it. I published it one week ago on the Ulule Website. If your wish to know more and to spread the word, here is the project page: http://www.ulule.com/mathematics-ebooks/ Thank you. -- Frédéric Wang maths-informatique-jeux.com/blog/frederic

## UNDNovember 22, 2013 First Call for Papers: Conf. Intelligent Computer Mathematics (CICM 2014)

Author: | Channel: www-math@w3.org Mail Archives

﻿[Apologies for multiple copies]

CICM 2014 - Conferences on Intelligent Computer Mathematics
July 7-11, 2014 at University of Coimbra, Portugal

http://www.cicm-conference.org/2014

First Call for Papers

-------------------------------------------------------------------

As   computers   and   communications  technology   advance,   greater
opportunities  arise for  intelligent mathematical  computation. While
computer  algebra, automated  deduction,  mathematical publishing  and
novel user interfaces individually have long and successful histories,
we  are now seeing  increasing opportunities  for synergy  among these
areas.  The  Conferences on  Intelligent  Computer Mathematics  (CICM)
offer a venue for discussing these areas and their synergy.

CICM has been held annually  as a joint meeting since 2008, colocating
related conferences  and workshops to advance work  in these subjects.
Previous meetings have been held in Birmingham (U.K. 2008), Grand Bend
(Canada  2009), Paris  (France 2010),  Bertinoro (Italy  2011), Bremen
(Germany 2012) and Bath (U.K. 2013).

This is  a call for papers  for CICM 2014,  which will be held  at the
University   of  Coimbra,   7-11   July  2014,   following  the   10th
International Workshop on Automated Deduction in Geometry.

The principal tracks of the conference will be:

Calculemus (Symbolic Computation and Mechanised Reasoning)
Chair: James Davenport

DML (Digital Mathematical Libraries)
Chair: Petr Sojka

MKM (Mathematical Knowledge Management)
Chair: Josef Urban

Systems and Projects
Chair: Alan Sexton

The local  arrangements will be coordinated by  the Local Arrangements
Chair,  Paedro  Quaresma  (U.  Coimbra,  Portugal),  and  the  overall
programme will be organised by the General Program Chair, Stephen Watt

as a volume in Lecture Notes in Artificial Intelligence (LNAI).

As in  previous years, it is  anticipated that there will  be a number
co-located workshops, including one to mentor doctoral students giving
presentations.

----------------------------------------------------------------
Important dates
----------------------------------------------------------------

Conference submissions:

Abstract submission:          28 February 2014
Reviews sent to authors:      4 April 2014
Rebuttals due:                8 April 2014
Notification of acceptance:   14 April 2014
Camera ready copies due:      25 April 2014

Work in progress and Doctoral Programme submissions:

(Doctoral: Abstract+CV)
Notification of acceptance:   19 May 2014
Camera ready copies due:      26 May 2014

Conference:                     7-11  July 2014

----------------------------------------------------------------
Tracks
----------------------------------------------------------------

================================================================
Track Calculemus: Symbolic Computation and Mechanised Reasoning
================================================================

Calculemus   2014  invites   the  submission   of   original  research
contributions to be considered for publication and presentation at the
conference.  Calculemus  is a series  of conferences dedicated  to the
integration  of  computer  algebra   systems  (CAS)  and  systems  for
mechanised  reasoning  like   interactive  proof  assistants  (PA)  or
automated theorem  provers (ATP).  Currently,  symbolic computation is
divided into several (more  or less) independent branches: traditional
ones  (e.g., computer  algebra and  mechanised reasoning)  as  well as
newly emerging ones (on  user interfaces, knowledge management, theory
exploration, etc.) The main concern  of the Calculemus community is to
bring these  developments together in order to  facilitate the theory,
design,  and  implementation   of  integrated  mathematical  assistant
systems  that  will  be  used routinely  by  mathematicians,  computer
scientists and  all others who need  computer-supported mathematics in

All  topics  in  the  intersection  of computer  algebra  systems  and
automated  reasoning systems  are  of interest  for Calculemus.  These
include but are not limited to:

* Automated theorem proving in computer algebra systems.
* Computer algebra in theorem proving systems.
* Adding reasoning capabilities to computer algebra systems.
* Adding computational capabilities to theorem proving systems.
* Theory, design and implementation of interdisciplinary systems for
computer mathematics.
* Case studies and applications that involve a mix of computation and
reasoning.
* Case studies in formalization of mathematical theories.
* Representation of mathematics in computer algebra systems.
* Theory exploration techniques.
* Combining methods of symbolic computation and formal deduction.
* Input languages, programming languages, types and constraint languages,
and modeling languages for mathematical assistant systems.
* Homotopy type theory.
* Infrastructure for mathematical services.

================================================================
Track DML: Digital Mathematical Libraries
================================================================

Mathematicians  dream of  a digital  archive containing  all validated
mathematical literature ever published, reviewed, properly linked, and
verified.   It is  estimated that  the entire  corpus  of mathematical
knowledge  published over  the centuries  does not  exceed 100,000,000
pages,   an   amount   easily   manageable  by   current   information
technologies.

The  track objective  is to  provide a  forum for  the  development of
math-aware  technologies, standards,  algorithms and  formats  for the
fulfillment  of the  dream of  a global  digital  mathematical library
(DML).  Computer scientists (D) and  librarians of the digital age (L)
are  especially welcome to  join mathematicians  (M) and  discuss many
aspects of DML preparation.

Track topics  are all topics of mathematical  knowledge management and
digital libraries applicable in the context of DML building, including
the  processing  of  mathematical  knowledge expressed  in  scientific
papers in natural languages:

* Math-aware text mining (math mining) and MSC classification
* Math-aware representations of mathematical knowledge
* Math-aware computational linguistics and corpora
* Math-aware tools for [meta]data and fulltext processing
* Math-aware OCR and document analysis
* Math-aware information retrieval
* Math-aware indexing and search
* Authoring languages and tools
* MathML, OpenMath, TeX and other mathematical content markup
languages
* Web interfaces for DML content
* Mathematics on the web, math crawling and indexing
* Math-aware document processing workflows
* Archives of written mathematics
* DML rights handling, funding, sustainability
* DML content acquisition, validation and curation
* Reports and experience from running existing DMLs

================================================================
Track MKM: Mathematical Knowledge Management
================================================================

Mathematical  Knowledge Management  is an  interdisciplinary  field of
research in the intersection of mathematics, computer science, library
science, and scientific publishing. The objective of MKM is to develop
new and better ways  of managing sophisticated mathematical knowledge,
based on innovative technology  of computer science, the Internet, and
intelligent   knowledge   processing.  MKM   is   expected  to   serve
mathematicians,  scientists,   and  engineers  who   produce  and  use
mathematical  knowledge; educators  and students  who teach  and learn
mathematics;   publishers  who   offer   mathematical  textbooks   and
disseminate   new    mathematical   results;   and    librarians   and
mathematicians who catalog and organize mathematical knowledge.

The  track is  concerned with  all aspects  of  mathematical knowledge
management. A non-exclusive list of important topics includes:

* Representations of mathematical knowledge
* Authoring languages and tools
* Repositories of formalized mathematics
* Deduction systems
* Mathematical digital libraries
* Diagrammatic representations
* Mathematical OCR
* Mathematical search and retrieval
* Math assistants, tutoring and assessment systems
* MathML, OpenMath, and other mathematical content standards
* Web presentation of mathematics
* Data mining, discovery, theory exploration
* Computer algebra systems
* Collaboration tools for mathematics
* Challenges and solutions for mathematical workflows

================================================================
Track Systems and Projects
================================================================

The  Systems and  Projects  track of  the  Conferences on  Intelligent
Computer Mathematics  is a forum for presenting  available systems and
new and ongoing  projects in all areas and topics  related to the CICM
conferences:

* Deduction and Computer Algebra (Calculemus)
* Digital Mathematical Libraries (DML)
* Mathematical Knowledge Management (MKM)

The track aims  to provide an overview of  the latest developments and
trends within the CICM community  as well as to exchange ideas between
developers and introduce systems to an audience of potential users.

----------------------------------------------------------------
Submission Instructions
----------------------------------------------------------------

Electronic submission is done through Easychair

http://www.easychair.org/conferences/?conf=cicm2014

All papers should be prepared  in LaTeX and formatted according to the
requirements of Springer's LNCS  series (the corresponding style files
By submitting  a paper  the authors  agree that if  it is  accepted at
least one of the authors will attend the conference to present it.

Submissions  to the research  tracks (Calculemus,  DML, MKM)  must not
exceed 15 pages  in the LNCS style and will  be reviewed and evaluated
with respect to relevance,  clarity, quality, originality, and impact.
Shorter papers,  e.g., for  system descriptions, are  welcome. Authors
will have  an opportunity to  respond to their papers'  reviews before
the programme committee makes a decision.

System descriptions  and projects descriptions should be  2-4 pages in
the LNCS style and should present

* newly developed systems,
* systems not previously been presented to the CICM community, or
* significant updates to existing systems.

by the general public as a web application.

Project presentations should describe

* projects that are new or about to start,
* ongoing projects that have not yet been presented to the CICM community or
* significant new developments in ongoing previously presented projects.

Presentations of  new projects  should mention relevant  previous work
and  include  a roadmap  that  outlines  concrete  steps. All  project
submissions must have a live  project website and should contain links

Accepted conference submissions from all tracks will be published as a
volume in  the series Lecture Notes in  Artificial Intelligence (LNAI)
by  Springer. In  addition to  these formal  proceedings,  authors are
permitted and encouraged to publish the final versions of their papers
on arXiv.org.

Work-in-progress submissions  are intended to provide a  forum for the
presentation of original  work that is not yet in  a suitable form for
submission as a full paper for a research track or system description.
This includes work in progress  and emerging trends. Their size is not
limited, but we recommend 5-10 pages.

The  programme   committee  may  offer  authors   of  rejected  formal
submissions  the   opportunity  to  publish   their  contributions  as
work-in-progress   papers  instead.   Depending  on   the   number  of
work-in-progress  papers  accepted,  they  will be  presented  at  the
conference either  as short talks or as  posters. The work-in-progress
proceedings will be published as a technical report, as well as online
with CEUR-WS.org.

----------------------------------------------------------------
Doctoral Programme
----------------------------------------------------------------

Chair: David Wilson (University of Bath, UK)

CICM  is  an  excellent  opportunity  for graduate  students  to  meet
established researchers from the  areas of computer algebra, automated
deduction, and mathematical publishing.

The Doctoral Programme provides a  dedicated forum for PhD students to
present  and discuss  their ideas,  ongoing or  planned  research, and
achieved  results   in  an  open   atmosphere.  It  will   consist  of
presentations  by  the  PhD  students to  get  constructive  feedback,
and  other PhD  students.  Each PhD  student  will be  assigned to  an
experienced researcher  from the research advisory board  who will act
as a mentor and who will provide detailed feedback and advice on their
intended and ongoing research.

Students at  any stage of  their PhD can  apply and should  submit the
following documents through EasyChair:

questions,  research   plans,  completed  and   remaining  research,
evaluation plans and publication plans;

* A   two-page  CV   that  includes   background   information  (name,
university,  supervisor), education  (degree sought,  year/status of
degree, previous degrees), employments, relevant research experience
(publications,  presentations,  attended  conferences or  workshops,
etc.)

----------------------------------------------------------------
Programme Committee
----------------------------------------------------------------

General chair: Stephen Watt (University of Western Ontario, Canada)

Calculemus track
James Davenport, University of Bath, UK  (Chair)
Matthew England, University Of Bath, UK,
Dejan Jovanović, SRI, USA
Laura Kovács, Chalmers University of Technology, Sweden
Assia Mahboubi, INRIA, France
Adam Naumowicz, Institute of Informatics, U. Bialystok, Poland
Grant Passmore, U. Cambridge and U. Edinburgh, UK
Florian Rabe, Jacobs University Bremen. Germany
Claudio Sacerdoti Coen, University of Bologna, Italy
Freek Wiedijk, Radboud University Nijmegen, Netherlands
(Other invitations pending)

DML track
Petr Sojka, Masaryk University, Brno, CZ  (Chair)
Akiko Aizawa, NII, University of Tokyo, Japan
Łukasz Bolikowski, ICM, University of Warsaw, Poland
Thierry Bouche, Université Joseph Fourier, Grenoble, france
Yannis Haralambous, Inst Mines-Télécom - Télécom Bretagne, France
Janka Chlebíková, School of Computing, University of Portsmouth, UK
Michael Kohlhase, Jacobs University Bremen, Germany
Jiří Rákosník, Institute of Mathematics AS CR, CZ
David Ruddy, Cornell University, USA
Volker Sorge, University of Birmingham, UK
Frank Tompa, University of Waterloo, Canada
Richard Zanibbi, Rochester Institute of Technology, USA

MKM track
Josef Urban, Radboud University Nijmegen, The Netherlands  (Chair)
Rob Arthan, Queen Mary University of London, UK
David Aspinall, Univerity of Edinburgh, UK
Michael Beeson, San Jose State University, USA
Claudio Sacerdoti Coen, University of Bologna, Italy
Thomas Hales, University of Pittsburgh, USA
Johan Jeuring, Open Universiteit Nederland and Universiteit Utrecht, NL
Peter Jipsen, Chapman University, USA
Cezary Kaliszyk, University of Innsbruck, Austria
Michael Kohlhase, Jacobs University Bremen, Germany
Christoph Lange, University of Birmingham, UK
Paul Libbrecht, Weingarten University of Education, Germany
Ursula Martin, Queen Mary University of London, UK
Bruce Miller, NIST, USA
Adam Naumowicz, University of Bialystok, Poland
Florian Rabe, Jacobs University Bremen, Germany
Alan Sexton, University of Birmingham, UK
Enrico Tassi, INRIA, France
Stephen Watt, University of Western Ontario, Canada
Makarius Wenzel, Université Paris-Sud 11, France
Freek Wiedijk, Radboud University Nijmegen, The Netherlands

Systems & Projects track
Alan Sexton, University of Birmingham, UK  (Chair)
Christoph Lange, University of Bonn, Germany
Jesse Alama, Technical University of Vienna, Austria
Rob Arthan, Queen Mary University of London, UK
Deyan Ginev, Jacobs University Bremen, Germany
Jónathan Heras, University of Dundee, Scotland
Mateja Jamnik, University of Cambridge, UK
Predrag Janičić, University of Belgrade, Serbia
Christoph Lüth, DFKI and University of Bremen, Germany
Bruce Miller, NIST, Gaithersburg, Maryland, USA
Hendrik Tews, TU Dresden, Germany


## en-USNovember 18, 2013 MathJax v2.3 now available

Author: | Channel: MathJax

After a successful beta run, we’re happy to officially release MathJax v2.3.

Version 2.3 is available on the CDN at

http://cdn.mathjax.org/mathjax/2.3-latest/MathJax.js

and starting today the files at the

http://cdn.mathjax.org/mathjax/latest/MathJax.js

address will be switched over the v2.3; it will take 24h-48h for the changes to propagate out to the distributed cloud servers.

During the time that the files are making their way out to the CDN’s servers, there may be a mixture of files in a browser cache, and so users may need to clear their cache and restart their browser in order to get a consistent version of the files.

If you are a page author and concerned about this, you can change (temporarily) to the mathjax/2.3-latest URL instead of mathjax/latest since that is a new address that will not have any cached older versions to worry about. You can switch back to mathjax/latest in a few days when the new version has migrated to all the locations in the cloud.

See http://docs.mathjax.org/en/latest/whats-new-2.3.html for details about the changes in v2.3, and some caveats about the effect of these changes on existing sites. We anticipate a smooth upgrade from v2.2 to v2.3, but as always, let us know on the bug tracker if you experience problems with this new version of MathJax.

Thank you for your continued support.

The MathJax Team.

## What’s New in MathJax v2.3

MathJax v2.3 includes a number of new features, as well a more than 40
important bug fixes.

## Features:

• New webfonts. MathJax v2.3 adds new webfonts for STIX,
Asana Math, Neo Euler, Gyre Pagella, Gyre Termes, and
Latin Modern.

• Localization improvements. MathJax has been accepted into
TranslateWiki.net. Thanks to the TWN community we could add 12
complete and over 20 partial translations.

• MathML improvements. MathJax’s “Show Math as” menu will now expose
the MathML annotation features. There are also two new preview
options for the MathML input mode: mathml (now the default) and
altimage which will show the original MathML and an alternative
image respectively.

• Miscellaneous improvements. A new extension MatchWebFonts improves
the interaction with the surrounding content. A new configuration
method allows configurations by using a regular JavaScript variable
window.MathJax.

• MathJax is now available as a Bower package thanks to community
contributions.

## TeX input:

• Prevent the TeX pre-processor from rendering TeX in MathML
annotation-xml. (Issue #484)
• Fix sizing issue in cases environment (Issue #485)

## Fonts:

• Fix block-letter capital I (U+2111) appearing as J in MathJax font
(Issue #555)
• Fix issue with script mathvariant characters in IE (Issue #621)

## MathML:

• Improved workarounds for MathML output on WebKit (Issue #482)
• Handle empty multiscript nodes in Native MathML output (Issue #486
• Replace non-standard MJX-arrow class by new menclose notation (Issue #481)
• Fix incorrect widths in Firefox MathML output (Issue #558)
• Fix display math not being centered in XHTML (Issue #650)

## HTML-CSS/SVG output

• Fix MathJax not rendering in Chrome when sessionStorage is disabled (Issue #584)
• Fix \mathchoice error with linebreaking in SVG output (Issue #604)

## Miscellaneous:

• Localization: improved fallbacks for IETF tags (Issue #492)
• Localization: support RTL in messages (Issue #627)
• Improve PNG compression (Issue #44)
• Fix poor linebreaking of “flat” MathML (Issue #523)

## UND November 18, 2013 No Hesitations: The e-Writing Jungle Part 2: The MathML Impasse ...

Author: | Channel: mathml - Google Blog Search

Back to LaTeX and MathJax and MathML and Python and Sphinx and IPython and R and Knitter and Firefox and Chrome and ... In Part 1, I praised e-books done as LaTeX to pdf to the web, perhaps surprisingly. Now let's go ...

## UNDNovember 10, 2013 Re: W3C ENTITIES Combined Set

Author: | Channel: www-math@w3.org Mail Archives

On 09/11/2013 19:23, Darton Williams wrote:
> I recently used the combined entities at
> http://www.w3.org/2003/entities/2007/w3centities-f.ent as an inline DTD
> in MS SQL Server (this automatically resolves entities to their
> character codes) and noticed a couple of issues:
>
> 1. <!ENTITY amp "&#38;#38;" ><!--AMPERSAND -->
> The value should be "&#x00026;"
>
> 2. <!ENTITY lt "&#38;#60;" ><!--LESS-THAN SIGN -->
> The value should be "&#x0003C;"
>
> The values above were tested and produced the correct characters when
> rendered in a browser as HTML. The uppercase variants of these entities
> also contain incorrect values.
>
> 3. <!ENTITY nvlt "&#38;#x0003C;&#x020D2;" ><!--LESS-THAN SIGN with
> vertical line -->
> AFAIK, the value should be "&#x0003C;&#x020D2;" but I just noticed this
> one and haven't tested.
>
> Regards,

No, you need to quote & and <. an entity with definition "&#x00026;"
would not be well formed.

See the definition of amp here:

http://www.w3.org/TR/xml/#sec-predefined-ent

David

On 09/11/2013 19:23, Darton Williams wrote: > I recently used the combined entities at > http://www.w3.org/2003/entities/2007/w3centities-f.ent as an inline DTD > in MS SQL Server (this automatically resolves entities to their > character codes) and noticed a couple of issues: > > 1. <!ENTITY amp "&#38;#38;" ><!--AMPERSAND --> > The value should be "&#x00026;" > > 2. <!ENTITY lt "&#38;#60;" ><!--LESS-THAN SIGN --> > The value should be "&#x0003C;" > > The values above were tested and produced the correct characters when > rendered in a browser as HTML. The uppercase variants of these entities > also contain incorrect values. > > 3. <!ENTITY nvlt "&#38;#x0003C;&#x020D2;" ><!--LESS-THAN SIGN with > vertical line --> > AFAIK, the value should be "&#x0003C;&#x020D2;" but I just noticed this > one and haven't tested. > > Regards, No, you need to quote & and <. an entity with definition "&#x00026;" would not be well formed. See the definition of amp here: http://www.w3.org/TR/xml/#sec-predefined-ent David

## UNDNovember 09, 2013 W3C ENTITIES Combined Set

Author: | Channel: www-math@w3.org Mail Archives

I recently used the combined entities at
http://www.w3.org/2003/entities/2007/w3centities-f.ent as an inline DTD in
MS SQL Server (this automatically resolves entities to their character
codes) and noticed a couple of issues:

1. <!ENTITY amp "&#38;#38;" ><!--AMPERSAND -->
The value should be "&#x00026;"

2. <!ENTITY lt "&#38;#60;" ><!--LESS-THAN SIGN -->
The value should be "&#x0003C;"

The values above were tested and produced the correct characters when
rendered in a browser as HTML. The uppercase variants of these entities
also contain incorrect values.

3. <!ENTITY nvlt "&#38;#x0003C;&#x020D2;" ><!--LESS-THAN SIGN with vertical
line -->
AFAIK, the value should be "&#x0003C;&#x020D2;" but I just noticed this one
and haven't tested.

Regards,

Darton Williams

I recently used the combined entities at http://www.w3.org/2003/entities/2007/w3centities-f.ent as an inline DTD in MS SQL Server (this automatically resolves entities to their character codes) and noticed a couple of issues: 1. <!ENTITY amp "&#38;#38;" ><!--AMPERSAND --> The value should be "&#x00026;" 2. <!ENTITY lt "&#38;#60;" ><!--LESS-THAN SIGN --> The value should be "&#x0003C;" The values above were tested and produced the correct characters when rendered in a browser as HTML. The uppercase variants of these entities also contain incorrect values. 3. <!ENTITY nvlt "&#38;#x0003C;&#x020D2;" ><!--LESS-THAN SIGN with vertical line --> AFAIK, the value should be "&#x0003C;&#x020D2;" but I just noticed this one and haven't tested. Regards, Darton Williams

## UNDNovember 08, 2013 Re: MathML and dashes in element names

Author: | Channel: www-math@w3.org Mail Archives

On 08/11/2013 21:07, Dimitri Glazkov wrote:
> Hello MathML peeps!
>
> Your colleague from WebApps WG here. I am editor of the Custom
> Elements spec (http://www.w3.org/TR/custom-elements/).
>
> This specification enables authors to define their own types of DOM
> elements (hence the "custom elements" name). To distinguish "custom"
>  elements from "built-in" elements within the HTML namespace, we use
>  the presence of a dash (U+002D HYPHEN-MINUS character) in the tag
> name of the element and a blacklist of pre-existing dash-containing
> tag names: http://www.w3.org/TR/custom-elements/#concepts
>
> Naturally, this approach would only work if existing specifications
> whose tag names coexist in HTML namespace (SVG and MatML) would avoid
> creating elements with dash-containing names in the future revisions
> of their specifications.
>
> SVG WG (via Tab Atkins, cc'd) already stated that they will do so. I
>  was hoping I coordinate the same with you guys. Can I get an amen?
> :)
>
> Here's the spec bug that covers this:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23256
>
> Happy Friday!
>

As you know there is one existing one: <annotation-xml> .

Speaking personally I don't think undertaking not to add more would be a
problem, especially as there are no immediate plans to add any new elements.

David

On 08/11/2013 21:07, Dimitri Glazkov wrote: > Hello MathML peeps! > > Your colleague from WebApps WG here. I am editor of the Custom > Elements spec (http://www.w3.org/TR/custom-elements/). > > This specification enables authors to define their own types of DOM > elements (hence the "custom elements" name). To distinguish "custom" > elements from "built-in" elements within the HTML namespace, we use > the presence of a dash (U+002D HYPHEN-MINUS character) in the tag > name of the element and a blacklist of pre-existing dash-containing > tag names: http://www.w3.org/TR/custom-elements/#concepts > > Naturally, this approach would only work if existing specifications > whose tag names coexist in HTML namespace (SVG and MatML) would avoid > creating elements with dash-containing names in the future revisions > of their specifications. > > SVG WG (via Tab Atkins, cc'd) already stated that they will do so. I > was hoping I coordinate the same with you guys. Can I get an amen? > :) > > Here's the spec bug that covers this: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=23256 > > Happy Friday! > As you know there is one existing one: <annotation-xml> . Speaking personally I don't think undertaking not to add more would be a problem, especially as there are no immediate plans to add any new elements. David

## UNDNovember 08, 2013 MathML and dashes in element names

Author: | Channel: www-math@w3.org Mail Archives

Hello MathML peeps!

Your colleague from WebApps WG here. I am editor of the Custom Elements
spec (http://www.w3.org/TR/custom-elements/).

This specification enables authors to define their own types of DOM
elements (hence the "custom elements" name). To distinguish "custom"
elements from "built-in" elements within the HTML namespace, we use the
presence of a dash (U+002D HYPHEN-MINUS character) in the tag name of the
element and a blacklist of pre-existing dash-containing tag names:
http://www.w3.org/TR/custom-elements/#concepts

Naturally, this approach would only work if existing specifications whose
tag names coexist in HTML namespace (SVG and MatML) would avoid creating
elements with dash-containing names in the future revisions of their
specifications.

SVG WG (via Tab Atkins, cc'd) already stated that they will do so. I was
hoping I coordinate the same with you guys. Can I get an amen? :)

Here's the spec bug that covers this:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23256

Happy Friday!

:DG<

Hello MathML peeps! Your colleague from WebApps WG here. I am editor of the Custom Elements spec (http://www.w3.org/TR/custom-elements/). This specification enables authors to define their own types of DOM elements (hence the "custom elements" name). To distinguish "custom" elements from "built-in" elements within the HTML namespace, we use the presence of a dash (U+002D HYPHEN-MINUS character) in the tag name of the element and a blacklist of pre-existing dash-containing tag names: http://www.w3.org/TR/custom-elements/#concepts Naturally, this approach would only work if existing specifications whose tag names coexist in HTML namespace (SVG and MatML) would avoid creating elements with dash-containing names in the future revisions of their specifications. SVG WG (via Tab Atkins, cc'd) already stated that they will do so. I was hoping I coordinate the same with you guys. Can I get an amen? :) Here's the spec bug that covers this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23256 Happy Friday! :DG<

## en November 07, 2013 Gecko-based EPUB Readers and LaTeXML

Author: | Channel: Blog de Frédéric - Tag - mathml

This morning, Deyan Ginev announced on the LaTeXML mailing list that the first alpha version of LaTeXML with LaTeX to EPUB support is now available. This is a very good news for people willing to encourage researchers to move from offline formats to more modern Web formats. Although, some people had already been successful to combine LaTeX-to-XHTML converters and XHTML-to-EPUB converters, this is the first tool that I'm aware of that can do the direct LaTeX to EPUB3 (XHTML+MathML) conversion. I already mentioned a couple of Gecko-based EPUB tools in my previous blog post, so let's have a look at three of them. Feel free to mention more Gecko-based EPUB tools in the comments, I'm particularly interested to hear about FirefoxOS applications that would be similar to Apple's iBooks.

I have updated the LaTeXML samples based on Boris Zbarsky's thesis that we demonstrated at the Innovation Fairs in Santa Clara & Brussels. This shows how to generate the traditional PDF version, the Web version, the Web version with MathJax fallback and now the EPUB version! Here are some screenshots using the Firefox extension Lucifox:

Boris' Thesis in Lucifox ; page 2

Boris' Thesis in Lucifox ; page 4

I have intentionally not shown the diagram that are incorrectly converted by LaTeXML due to missing Xy-pic support (this is still in development). However, Gecko supports mixing SVG and MathML via the foreignObject element so this would not be a problem for Gecko-based EPUB readers. Here are some screenshots of an ebook about regular polygon that can be constructed with compass and straightedge that I have created with the help of itex2MML. They are viewed in EPUBReader which is another Firefox extension:

Lucifox and EPUBReader have a big drawback: they do not support EPUB pages with the "scripted" property. This means that you can not use Javascript to create dynamic ebooks with live samples or interactive exercices... but this is one of the reason to use Web formats! Fortunately, there is a XUL application called AZARDI that supports this feature. I have created another ebook that shows an interactive course on matrices. Click on the image to see the video on YouTube:

AZARDI, Interactive Course on Matrices

## UNDNovember 06, 2013 RE: RTL directionality in LaTeX

Author: | Channel: www-math@w3.org Mail Archives

Some of my conclusions:

1. The MathML 3 specification allows the dir at any level (remember the
original question was related to MathML and LaTeX mutual conversion, thus
math mode only).
2. We assume that UTF-8 is used for encoding Arabic or Hebrew characters
(this is not related to RTL but worth to mention).
3. "As far as directionality is concerned, there is only two models; LTR
and RTL. Other changes are merely differences in the notation used and
this should be reflected in the content of the equations themselves
(unless some form of abstraction is used)." (Khaled)
4. The \dir and \mathdir are already used as macro names.
5. The use of \style{direction:rtl}{x^2} is tempting but difficult to
implement in TeX/LaTeX (although I do not care very much).
6. The use of {\mathdir{rtl}x^2} seems a quite good compromise solution.
7. Another option is to use \mathRTL and \mathLRT as a possible extension
of the \RTL and \LTR commands of the bidi package.

Dani

-----Original Message-----
From: Ross Moore [mailto:ross.moore@mq.edu.au]
Sent: martes, 05 de noviembre de 2013 23:05
To: David Carlisle
Cc: Murray Sargent; Peter Krautzberger; Frédéric WANG; Khaled Hosny;
www-math@w3.org; Azzeddine LAZREK
Subject: Re: RTL directionality in LaTeX

Hi David,

On 06/11/2013, at 8:07 AM, David Carlisle wrote:

> On 05/11/2013 20:34, Ross Moore wrote:
>> Directionality is a property of the math environment, not of the
>> content in that environment
>
>
> Usually but not always. After the review of use cases in the Arabic
> math note, directionality in MathML3 is allowed at the level of
> <mrow>, not just on the top level [itex]. (Whether any particular TeX
> or MathML rendering agent can support switching at that level is
> another issue but the specification allows it.)

OK. Thanks for that clarification.

On 06/11/2013, at 8:43 AM, Khaled Hosny wrote:

> On Wed, Nov 06, 2013 at 07:34:05AM +1100, Ross Moore wrote:
>> I would vote for inserting something like \mathdir{rtl}
>
> primitive name.
>
> Regards,
> Khaled
>
> 1. In case of LuaTeX it is "hidden" by default, but formats my choose to
>   enable it.

With this information, my advice would be to have a macro that effectively
just sets a switch, in the usual TeX-like way, whose value is confined to
a brace-delimited environment.
Internal macro expansion either respects the value of that switch or
ignores it.
The details are left to developers to fill in.

e.g. user-syntax could be:
$x^2 + 2\,x + 1 = \begin{cases} (x+1)^2 & \text{ in Roman LTR script (LTR)}\\ {\setmathdir{rtl} (x+1)^2 } & \text{in Arabic (RTL)} \end{cases}$

Thus in Omega/Aleph/LuaTeX  the primitive is set locally.
Other formats would need to implement much more to get it right, or just
gobble the argument and issue a warning message that directionality
support is not yet available.

This is in accordance, I think, with the discussion here:

http://tug.org/pipermail/luatex/2012-December/003929.html

where direct use of the primitive is delimited.

>
> David

Hope this helps,

Ross

------------------------------------------------------------------------
Ross Moore                                       ross.moore@mq.edu.au
Mathematics Department                           office: E7A-206
Macquarie University                             tel: +61 (0)2 9850 8955
Sydney, Australia  2109                          fax: +61 (0)2 9850 8114
------------------------------------------------------------------------

Some of my conclusions: 1. The MathML 3 specification allows the dir at any level (remember the original question was related to MathML and LaTeX mutual conversion, thus math mode only). 2. We assume that UTF-8 is used for encoding Arabic or Hebrew characters (this is not related to RTL but worth to mention). 3. "As far as directionality is concerned, there is only two models; LTR and RTL. Other changes are merely differences in the notation used and this should be reflected in the content of the equations themselves (unless some form of abstraction is used)." (Khaled) 4. The \dir and \mathdir are already used as macro names. 5. The use of \style{direction:rtl}{x^2} is tempting but difficult to implement in TeX/LaTeX (although I do not care very much). 6. The use of {\mathdir{rtl}x^2} seems a quite good compromise solution. 7. Another option is to use \mathRTL and \mathLRT as a possible extension of the \RTL and \LTR commands of the bidi package. Dani -----Original Message----- From: Ross Moore [mailto:ross.moore@mq.edu.au] Sent: martes, 05 de noviembre de 2013 23:05 To: David Carlisle Cc: Murray Sargent; Peter Krautzberger; Frédéric WANG; Khaled Hosny; www-math@w3.org; Azzeddine LAZREK Subject: Re: RTL directionality in LaTeX Hi David, On 06/11/2013, at 8:07 AM, David Carlisle wrote: > On 05/11/2013 20:34, Ross Moore wrote: >> Directionality is a property of the math environment, not of the >> content in that environment > > > Usually but not always. After the review of use cases in the Arabic > math note, directionality in MathML3 is allowed at the level of > <mrow>, not just on the top level [itex]. (Whether any particular TeX > or MathML rendering agent can support switching at that level is > another issue but the specification allows it.) OK. Thanks for that clarification. On 06/11/2013, at 8:43 AM, Khaled Hosny wrote: > On Wed, Nov 06, 2013 at 07:34:05AM +1100, Ross Moore wrote: >> I would vote for inserting something like \mathdir{rtl} > > Please note that \mathdir is already an Omega/Aleph/LuaTeX[1] > primitive name. > > Regards, > Khaled > > 1. In case of LuaTeX it is "hidden" by default, but formats my choose to > enable it. With this information, my advice would be to have a macro that effectively just sets a switch, in the usual TeX-like way, whose value is confined to a brace-delimited environment. Internal macro expansion either respects the value of that switch or ignores it. The details are left to developers to fill in. e.g. user-syntax could be: $x^2 + 2\,x + 1 = \begin{cases} (x+1)^2 & \text{ in Roman LTR script (LTR)}\\ {\setmathdir{rtl} (x+1)^2 } & \text{in Arabic (RTL)} \end{cases}$ Thus in Omega/Aleph/LuaTeX the primitive is set locally. Other formats would need to implement much more to get it right, or just gobble the argument and issue a warning message that directionality support is not yet available. This is in accordance, I think, with the discussion here: http://tug.org/pipermail/luatex/2012-December/003929.html where direct use of the primitive is delimited. > > David Hope this helps, Ross ------------------------------------------------------------------------ Ross Moore ross.moore@mq.edu.au Mathematics Department office: E7A-206 Macquarie University tel: +61 (0)2 9850 8955 Sydney, Australia 2109 fax: +61 (0)2 9850 8114 ------------------------------------------------------------------------

## UNDNovember 05, 2013 Re: RTL directionality in LaTeX

Author: | Channel: www-math@w3.org Mail Archives

Hi All,

I have developed the RyDArab package for composing Arabic mathematical
notation in LaTeX.

It works very well; however, I don’t maintained any more since some years
ago.

In RyDArab, We can choose the default notation in preamble:

\usepackage[options]{rydarab} with options are: arabmath, latinmath, …

and we can specify another in a local expression by: \arabmath, \latinmath,
…

as is presented in attachment file or in RyDArab package :

http://www.ucam.ac.ma/fssm/rydarab/system/zip/rydarab.rar

We find also all possible notation’s translation and Arabic mathvariants.

Azzeddine

2013/11/5 Ross Moore <ross.moore@mq.edu.au>

> Hi David,
>
> On 06/11/2013, at 8:07 AM, David Carlisle wrote:
>
> > On 05/11/2013 20:34, Ross Moore wrote:
> >> Directionality is a property of the math environment, not of the
> >> content in that environment
> >
> >
> > Usually but not always. After the review of use cases in the Arabic math
> > note, directionality in MathML3 is allowed at the level of <mrow>, not
> > just on the top level [itex]. (Whether any particular TeX or MathML
> > rendering agent can support switching at that level is another issue but
> > the specification allows it.)
>
> OK. Thanks for that clarification.
>
>
> On 06/11/2013, at 8:43 AM, Khaled Hosny wrote:
>
> > On Wed, Nov 06, 2013 at 07:34:05AM +1100, Ross Moore wrote:
> >> I would vote for inserting something like \mathdir{rtl}
> >
> > name.
> >
> > Regards,
> > Khaled
> >
> > 1. In case of LuaTeX it is "hidden" by default, but formats my choose to
> >   enable it.
>
>
> With this information, my advice would be to have a macro that
> effectively just sets a switch, in the usual TeX-like way,
> whose value is confined to a brace-delimited environment.
> Internal macro expansion either respects the value of that switch
> or ignores it.
> The details are left to developers to fill in.
>
> e.g. user-syntax could be:
>   $> x^2 + 2\,x + 1 = > \begin{cases} > (x+1)^2 & \text{ in Roman LTR script (LTR)}\\ > {\setmathdir{rtl} (x+1)^2 } & \text{in Arabic (RTL)} > \end{cases} >$
>
> Thus in Omega/Aleph/LuaTeX  the primitive is set locally.
> Other formats would need to implement much more to get it right,
> or just gobble the argument and issue a warning message that
> directionality support is not yet available.
>
> This is in accordance, I think, with the discussion here:
>
>   http://tug.org/pipermail/luatex/2012-December/003929.html
>
> where direct use of the primitive is delimited.
>
>
> >
> > David
>
>
> Hope this helps,
>
>         Ross
>
> ------------------------------------------------------------------------
> Ross Moore                                       ross.moore@mq.edu.au
> Mathematics Department                           office: E7A-206
> Macquarie University                             tel: +61 (0)2 9850 8955
> Sydney, Australia  2109                          fax: +61 (0)2 9850 8114
> ------------------------------------------------------------------------
>
>
>
>
>


Hi All, I have developed the RyDArab package for composing Arabic mathematical notation in LaTeX. It works very well; however, I don’t maintained any more since some years ago. In RyDArab, We can choose the default notation in preamble: \usepackage[options]{rydarab} with options are: arabmath, latinmath, … and we can specify another in a local expression by: \arabmath, \latinmath, … as is presented in attachment file or in RyDArab package : http://www.ucam.ac.ma/fssm/rydarab/system/zip/rydarab.rar We find also all possible notation’s translation and Arabic mathvariants. Azzeddine 2013/11/5 Ross Moore <ross.moore@mq.edu.au> > Hi David, > > On 06/11/2013, at 8:07 AM, David Carlisle wrote: > > > On 05/11/2013 20:34, Ross Moore wrote: > >> Directionality is a property of the math environment, not of the > >> content in that environment > > > > > > Usually but not always. After the review of use cases in the Arabic math > > note, directionality in MathML3 is allowed at the level of <mrow>, not > > just on the top level [itex]. (Whether any particular TeX or MathML > > rendering agent can support switching at that level is another issue but > > the specification allows it.) > > OK. Thanks for that clarification. > > > On 06/11/2013, at 8:43 AM, Khaled Hosny wrote: > > > On Wed, Nov 06, 2013 at 07:34:05AM +1100, Ross Moore wrote: > >> I would vote for inserting something like \mathdir{rtl} > > > > Please note that \mathdir is already an Omega/Aleph/LuaTeX[1] primitive > > name. > > > > Regards, > > Khaled > > > > 1. In case of LuaTeX it is "hidden" by default, but formats my choose to > > enable it. > > > With this information, my advice would be to have a macro that > effectively just sets a switch, in the usual TeX-like way, > whose value is confined to a brace-delimited environment. > Internal macro expansion either respects the value of that switch > or ignores it. > The details are left to developers to fill in. > > e.g. user-syntax could be: > $> x^2 + 2\,x + 1 = > \begin{cases} > (x+1)^2 & \text{ in Roman LTR script (LTR)}\\ > {\setmathdir{rtl} (x+1)^2 } & \text{in Arabic (RTL)} > \end{cases} >$ > > Thus in Omega/Aleph/LuaTeX the primitive is set locally. > Other formats would need to implement much more to get it right, > or just gobble the argument and issue a warning message that > directionality support is not yet available. > > This is in accordance, I think, with the discussion here: > > http://tug.org/pipermail/luatex/2012-December/003929.html > > where direct use of the primitive is delimited. > > > > > > David > > > Hope this helps, > > Ross > > ------------------------------------------------------------------------ > Ross Moore ross.moore@mq.edu.au > Mathematics Department office: E7A-206 > Macquarie University tel: +61 (0)2 9850 8955 > Sydney, Australia 2109 fax: +61 (0)2 9850 8114 > ------------------------------------------------------------------------ > > > > >

## UNDNovember 05, 2013 Re: RTL directionality in LaTeX

Author: | Channel: www-math@w3.org Mail Archives

Hi David,

On 06/11/2013, at 8:07 AM, David Carlisle wrote:

> On 05/11/2013 20:34, Ross Moore wrote:
>> Directionality is a property of the math environment, not of the
>> content in that environment
>
>
> Usually but not always. After the review of use cases in the Arabic math
> note, directionality in MathML3 is allowed at the level of <mrow>, not
> just on the top level [itex]. (Whether any particular TeX or MathML
> rendering agent can support switching at that level is another issue but
> the specification allows it.)

OK. Thanks for that clarification.

On 06/11/2013, at 8:43 AM, Khaled Hosny wrote:

> On Wed, Nov 06, 2013 at 07:34:05AM +1100, Ross Moore wrote:
>> I would vote for inserting something like \mathdir{rtl}
>
> name.
>
> Regards,
> Khaled
>
> 1. In case of LuaTeX it is "hidden" by default, but formats my choose to
>   enable it.

With this information, my advice would be to have a macro that
effectively just sets a switch, in the usual TeX-like way,
whose value is confined to a brace-delimited environment.
Internal macro expansion either respects the value of that switch
or ignores it.
The details are left to developers to fill in.

e.g. user-syntax could be:
$x^2 + 2\,x + 1 = \begin{cases} (x+1)^2 & \text{ in Roman LTR script (LTR)}\\ {\setmathdir{rtl} (x+1)^2 } & \text{in Arabic (RTL)} \end{cases}$

Thus in Omega/Aleph/LuaTeX  the primitive is set locally.
Other formats would need to implement much more to get it right,
or just gobble the argument and issue a warning message that
directionality support is not yet available.

This is in accordance, I think, with the discussion here:

http://tug.org/pipermail/luatex/2012-December/003929.html

where direct use of the primitive is delimited.

>
> David

Hope this helps,

Ross

------------------------------------------------------------------------
Ross Moore                                       ross.moore@mq.edu.au
Mathematics Department                           office: E7A-206
Macquarie University                             tel: +61 (0)2 9850 8955
Sydney, Australia  2109                          fax: +61 (0)2 9850 8114
------------------------------------------------------------------------


Hi David, On 06/11/2013, at 8:07 AM, David Carlisle wrote: > On 05/11/2013 20:34, Ross Moore wrote: >> Directionality is a property of the math environment, not of the >> content in that environment > > > Usually but not always. After the review of use cases in the Arabic math > note, directionality in MathML3 is allowed at the level of <mrow>, not > just on the top level [itex]. (Whether any particular TeX or MathML > rendering agent can support switching at that level is another issue but > the specification allows it.) OK. Thanks for that clarification. On 06/11/2013, at 8:43 AM, Khaled Hosny wrote: > On Wed, Nov 06, 2013 at 07:34:05AM +1100, Ross Moore wrote: >> I would vote for inserting something like \mathdir{rtl} > > Please note that \mathdir is already an Omega/Aleph/LuaTeX[1] primitive > name. > > Regards, > Khaled > > 1. In case of LuaTeX it is "hidden" by default, but formats my choose to > enable it. With this information, my advice would be to have a macro that effectively just sets a switch, in the usual TeX-like way, whose value is confined to a brace-delimited environment. Internal macro expansion either respects the value of that switch or ignores it. The details are left to developers to fill in. e.g. user-syntax could be: $x^2 + 2\,x + 1 = \begin{cases} (x+1)^2 & \text{ in Roman LTR script (LTR)}\\ {\setmathdir{rtl} (x+1)^2 } & \text{in Arabic (RTL)} \end{cases}$ Thus in Omega/Aleph/LuaTeX the primitive is set locally. Other formats would need to implement much more to get it right, or just gobble the argument and issue a warning message that directionality support is not yet available. This is in accordance, I think, with the discussion here: http://tug.org/pipermail/luatex/2012-December/003929.html where direct use of the primitive is delimited. > > David Hope this helps, Ross ------------------------------------------------------------------------ Ross Moore ross.moore@mq.edu.au Mathematics Department office: E7A-206 Macquarie University tel: +61 (0)2 9850 8955 Sydney, Australia 2109 fax: +61 (0)2 9850 8114 ------------------------------------------------------------------------

## UNDNovember 05, 2013 Re: RTL directionality in LaTeX

Author: | Channel: www-math@w3.org Mail Archives

As far as directionality is concerned, there is only two models; LTR and
RTL. Other changes are merely differences in the notation used and this
should be reflected in the content of the equations themselves (unless
some form of abstraction is used).

Regards,
Khaled

On Tue, Nov 05, 2013 at 11:28:48AM -0800, Peter Krautzberger wrote:
> I'm wondering how many BIDI variants there are to consider. From
> http://www.w3.org/TR/arabic-math/, I see 3-4 different styles of BIDI math.
> These should be reflected in a TeX-like syntax, I think.
>
> Are there other variants?
> Peter.
>
>
> On Tue, Nov 5, 2013 at 6:57 AM, Frédéric WANG <fred.wang@free.fr> wrote:
>
> > Le 05/11/2013 15:43, Khaled Hosny a écrit :
> >
> >
> >  Since the direction of text and math are not always the same (many RTL
> >> languages set math LTR), the command need to be explicitly for math.
> >>
> > Yes, that was one of the reason to make Gecko interpret CSS direction
> > property the same way as MathML dir attribute (the other reason is that it
> > simplifies the implementation). In an ideal world where MathML
> > implementations are compatible with CSS, people could then just use
> > something like
> >
> > math { direction: rtl; }
> >
> > or with CSS selectors
> >
> > div.MyArabicDiv math { direction: rtl; }
> >
> > to set the direction on all the math elements rather than having to
> > explicitly attach a dir="rtl" attribute on each one.
> >
> >  But if it is just some pseudo-LaTeX syntax, I don’t think the actual
> >> notation matters much, but \rtl{} looks more LaTeX-like to me.
> >>
> > Or perhaps \dir[rtl]{...} with an optional parameter so that someone can
> > still switch back to LTR with \dir[ltr]{...}.
> >
> > --
> > Frédéric Wang
> > maths-informatique-jeux.com/blog/frederic
> >
> >
> >

As far as directionality is concerned, there is only two models; LTR and RTL. Other changes are merely differences in the notation used and this should be reflected in the content of the equations themselves (unless some form of abstraction is used). Regards, Khaled On Tue, Nov 05, 2013 at 11:28:48AM -0800, Peter Krautzberger wrote: > I'm wondering how many BIDI variants there are to consider. From > http://www.w3.org/TR/arabic-math/, I see 3-4 different styles of BIDI math. > These should be reflected in a TeX-like syntax, I think. > > Are there other variants? > Peter. > > > On Tue, Nov 5, 2013 at 6:57 AM, Frédéric WANG <fred.wang@free.fr> wrote: > > > Le 05/11/2013 15:43, Khaled Hosny a écrit : > > > > > > Since the direction of text and math are not always the same (many RTL > >> languages set math LTR), the command need to be explicitly for math. > >> > > Yes, that was one of the reason to make Gecko interpret CSS direction > > property the same way as MathML dir attribute (the other reason is that it > > simplifies the implementation). In an ideal world where MathML > > implementations are compatible with CSS, people could then just use > > something like > > > > math { direction: rtl; } > > > > or with CSS selectors > > > > div.MyArabicDiv math { direction: rtl; } > > > > to set the direction on all the math elements rather than having to > > explicitly attach a dir="rtl" attribute on each one. > > > > But if it is just some pseudo-LaTeX syntax, I don’t think the actual > >> notation matters much, but \rtl{} looks more LaTeX-like to me. > >> > > Or perhaps \dir[rtl]{...} with an optional parameter so that someone can > > still switch back to LTR with \dir[ltr]{...}. > > > > -- > > Frédéric Wang > > maths-informatique-jeux.com/blog/frederic > > > > > >

## UNDNovember 05, 2013 Re: RTL directionality in LaTeX

Author: | Channel: www-math@w3.org Mail Archives

On Wed, Nov 06, 2013 at 07:34:05AM +1100, Ross Moore wrote:
> I would vote for inserting something like \mathdir{rtl}