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

CSS TF, Next meeting

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • December 13, 2018 • Permalink

Hi everybody,

Possible topics for the next CSS TF meeting next Monday, December 17h, 18h
CEST.

   1. Improvements of the document
   https://github.com/w3c/mathonwebpages/wiki/%5BCSS-TF%5D-TPAC-2018-preparations
   (since TPAC is over it is time to review the document and improve it).
   2. Decide which solution for stretchy characters we prefer, and we might
   be interested in develop a polyfill. See
   https://docs.google.com/document/d/1OMFIK_x7N40Qct4aNKHSQzOOdo1ZURUNC94mYVMglFA/edit?usp=sharing

Regards,

Dani

-- 

MathType 7 is out! Check the new version at wiris.com/mathtype 
<http://www.wiris.com/mathtype?utm_source=emailfooter>

ARIA and Assistive Technologies Community Group

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • December 05, 2018 • Permalink

Hi everybody,

Recently the following community group was created:
ARIA and Assistive Technologies Community Group

That seems relevant to the tasks we do in the MathOnWebPages CG since many
times we face the scenario where a feature is supposedly available in ARIA
but, then, the AT behaves in an unexpected way. For example, aria-label
does not override the text of an element.

For that reason, I suggest you join the ARIA and Assistive Technologies
Community Group. <https://www.w3.org/community/aria-at/>

Regards,

Dani from WIRIS

-- 

MathType 7 is out! Check the new version at wiris.com/mathtype 
<http://www.wiris.com/mathtype?utm_source=emailfooter>

[MathOnWeb] CSS task force minutes 2018-12-03

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

Hi everyone,

Apologies to the wider group but there were no minutes or recording of this
meeting. We discussed the pros&cons of several approaches for
standardization of stretchy constructions in CSS.

Best,
Peter.

[MathOnWeb] a11y task force meeting 2018-12-03

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

Hi everyone,

Apologies to the wider group but there were no minutes or recording of this
meeting.

Best,
Peter.

Re: next main CG meeting: Dec 6 (!)

Source: public-mathonwebpages@w3.org Mail Archives • Joanmarie Diggs (jdiggs@igalia.com) • November 28, 2018 • Permalink

Regrets. Travel day.
--joanie

On 11/22/18 4:45 AM, Peter Krautzberger wrote:
> Hi everyone,
> 
> It's Thanksgiving in the US so we are not having a main CG meeting this
> week. We will also not have a meeting on December 20 (again for holiday
> related reasons).
> 
> To compensate, we will have a meeting on December 6.
> 
> The Google Calendar has been updated (but lacks dial-in information
> right now -- we'll update that in time).
> 
> Best,
> Peter.

MathJax v3 beta.3 released

Source: MathJax • November 28, 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 third 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 nearly all the extensions are now available in v3.

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.

What’s New

This release fixes a number of display issues with the SVG output (see #153, #156, #157, #137) and improves the output for nested tables, particularly those with labels and those with percentage widths, in both CommonHTML and SVG output. Problems with table lines in SVG output in Safari and IE were fixed as well.

The TeX input has been updated to include nearly all the extensions that were available in v2, including the color, action, unicode, bbox, html, and several other extensions. These are all included in the webpacked files available in the demos repository (listed below), although the color extension is not enabled by default in order to preserve the behavior of \color in version 2 (this will probably change in the official release of v3).

In addition, there were some changes internally to how the MathDocument and MathItem classes, and the Handler class now allows more flexibility in overriding these. These changes are needed to better support extensions that may need to subclass the document and math-item classes. The next release will formalize the extension mechanisms and will include examples of how extensions will operate.

Finally, the TeX-lab.html and MML-lab.html files have been merged into a single v3-lab.html, and the original files removed. This late allows you to experiment will both input and both output formats, as well as enable/disable each of the extensions individual.

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!

[MathOnWeb] CSS task force minutes 2018-11-19

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

Hi everyone,

Here are the minutes from the meeting of the CSS task force this week.

Best,
Peter.

# Math On Web CSS TF, 2018-11-19

* Present: Dani, Peter
* Dani: baseline follow up
  * Peter: do we just point them to the spec we found?
  * Dani: not enough, we need to align at child still
  * same for mathaxis
* Dani: next steps?
  * Peter: hoping Arno might have more suggestions from the rest of TAPC
  * https://github.com/w3c/csswg-drafts/issues/1339#issuecomment-300293130
    * tabatkins and fantasai agreed there
      * parent has "I have special baseline"
      * child has "I'm the baseline"
  * Dani: I ran into the following: what if multiple children say "I'm the
baseline"
    * Peter: oh, good problem.
      * could we find CSS specs that might have a similar problem?
      * eg. subgrids -but two subgrids don't create conflicts.
  * Dani: then there's looking through baseline container, finding a child
that is baseline container
    * seems like it should stop looking?
    * Peter: eg nested fractions
  * Peter: yes, unless this child is itself a baseline container
    * bottom up: the child informs the parent but that parent might inform
its parent etc
  * [some discussion around this]
  * Peter: in terms of what to do with multiple children declaring
baselines, we just choose first or last and let CSS WG say what they prefer
  * Dani: maybe we should continue the thread with this
    * Peter: sounds good.
  * Dani: then what's next?
    * Peter: after discussion with Arno, maybe a Houdini-based polyfill
      * before going to a C++ patch example
    * Dani: Houdini is a bit different though
      * basically, "this box has a completely different layout"
    * Peter: I need to read up :)
    * Dani: but seems doable
* Dani: about stretchy constructions
  * maybe we can file an issue
  * we probably need to come to an agreement whether border glyphs are good
enough
  * Peter: I don't mind either way, I think border glyphs have independent
use cases and any implementation opens up the path to the other
    * if they're interested, I'd put our foucs there
    * Dani: sure but perhaps other options are just as interesting
      * we should at least try
  * [some discussion]
  * Dani: ACTION let's gather some ideas (eg. in a google doc)
    * be creative, figure out what we can do
    * we need to figure out
* [some discussion about stretchy vs size switching]

[MathOnWeb] a11y task force minutes 2018-11-19

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

Hi everyone,

Here are the minutes from the meeting of the accessibility task force this
week.

Best,
Peter.

# Math On Web a11y TF, 2018-11-19

* Present: Dani, Peter, Joanie, Charles, Sina,
* Dani: at TPAC, there was a discussion about joining ARIA
  * Follow up
  * Joanie: still with Michael
    * due diligence check necessary
    * what's the status?
    * Peter: Arno is "retired", Volker not associated, is already invited
expert for svga11y I think, I was an invited expert at PWG/DPUBIG until
recently
      * Joanie: ACTION will follow up
      * Sina: ping as well
* Dani: who wants to join this work? Seems like a lot
  * Joanie: my plan was to say "have math stuff once a month" to reduce load
  * Dani: sounds good.
* Peter: I didn't have time to write up stuff on the walker stuff
  * Sina: what's the link again?
    * Peter: https://krautzource.github.io/mathjax-sre-walker/
      * added a note that this demo needs ES6 modules (for dev ease, not
production)
      * Sina: what platform works?
      * Peter: Firefox, Chrome with NVDA is good, JAWS ok
      * Joanie: FF+ORCA seems good [use Fedora 28 not 29]
* Sina: what came up at the TPAC meetings?
  * Peter: just the Monday meeting as part of APA
  * Peter: there should be minutes somewhere...
    * Charles: https://www.w3.org/2018/10/22-apa-minutes.html#item02
  * Peter: we went through
https://github.com/w3c/mathonwebpages/wiki/%5Ba11y-TF%5D-TPAC-2018-preparations
    * APA was generally positive in response
    * plan to have some CG members become invited experts
* Peter: no meeting on US Thanksgiving
* Sina: calendar dates with zoom links in location would be very helpful

next main CG meeting: Dec 6 (!)

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

Hi everyone,

It's Thanksgiving in the US so we are not having a main CG meeting this
week. We will also not have a meeting on December 20 (again for holiday
related reasons).

To compensate, we will have a meeting on December 6.

The Google Calendar has been updated (but lacks dial-in information right
now -- we'll update that in time).

Best,
Peter.

poll - theorem-like environments in HTML

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

Hi MathOnWeb,

I was wondering how people mark up theorem-like environments in HTML
(definitions, theorems, lemmas, propositions, remarks etc).

Here's a quick poll for those interested

[1] div
[2] section
[3] article
[4] figure
[5] (something else)

Oh, and if you favor any additional markup (e.g., specific title markup,
ARIA landmarks, DPUB ARIA roles, schema.org), that would be interesting as
well, in particular in terms of affordances (e.g., styling, document
structure, AT exploration).

If there's enough interest, perhaps the CG can dive a bit deeper here and
come up with some recommendations.

Best,
Peter

UI Automation Math Text Support

Source: Murray Sargent: Math in Office • MurrayS3 • November 16, 2018 • Permalink

Microsoft products expose their contents for accessibility purposes via a set of interfaces known as UI Automation (UIA). Currently UIA has no special support for math text. Either the assistive technology program (AT) has to figure out if math is involved or the application has to return math-specific speech text as done with Office math speech. To support math more generally, UIA needs three additions:

  1. A document (ITextProvider) property that specifies the AT’s desired default math format (MathML, LaTeX, UnicodeMath, …) for math-zone text returned by calling ITextRangeProvider::GetText()
  2. A parameter that specifies the math format for an individual ITextRangeProvider::GetText() call
  3. Ways to navigate and select math zones

An AT like NVDA that handles all math accessibility (speech and braille of various verbosities and options) would use addition 1. With MathML containing the <maction> entity for UI, NVDA could generate math speech and braille enabling both speaking and editing of math. An AT like Narrator that doesn’t understand MathML would use addition 2, getting math speech with one call and math braille with another. This post describes these ways for improving UIA math support.

Recognizing Math Text

For the first two additions, it’s easy for an AT to recognize most math formats in a text string returned by UIA, especially since the AT chooses which format to return and can be looking for it. MathML math zones are XML strings that start with <mml:math> and end with </mml:math>. A LaTeX inline math zone starts with “$” or “\(“ and ends with “$” or “\)”. A LaTeX display math zone starts with “$$” or “\[“ and ends with “$$” or “\]”. A UnicodeMath math zone starts with “⁅” (U+2045) and ends with “⁆” (U+2046). Math braille is given by characters in the Unicode U+2800..U+28FF braille block. Non-math text uses other Unicode characters since braille engines can braille natural languages.

Math speech supplied by Office apps usually doesn’t have start and end math speech text. It might be worthwhile to have a math speech format type that includes the delimiters <mathspeech> and </mathspeech>. These delimiters wouldn’t be spoken but could be cues to speak the text as is and afterward to call for math braille if brailling is active. If a <mathspeech> XML element is added, it’d be worthwhile to support the Speech Synthesis Markup Language (SSML) more generally so that math character styles could be spoken with a different pitch, for example. Another possibility is to add <mathspeech> to SSML.

The sections below define methods that provide this UIA math functionality. Note that unless Narrator wants to take advantage of Office Nemeth math-braille capabilities, Windows doesn’t need to do anything other than document the new methods and include them in UIAutomationCore.h. Math speech already works well with Narrator, although it doesn’t offer math verbosity options (which differ from natural-language verbosity options).

Document Math Text Format Property

Typically, UIA doesn’t have UIA state properties. The properties it exposes are properties of the source content. But to define which math format ITextRangeProvider::GetText() should use by default, UIA needs to set a document property that specifies the math format. Accordingly, we define ITextProvider3 as follows

MIDL_INTERFACE("242A2469-3CAB-403E-9DA6-FAF1327C7FC6")
ITextProvider3 : public ITextProvider2
{
   public:
   virtual HRESULT STDMETHODCALLTYPE get_Property(
   /* [in] */ int Type,
   /* [retval][out] */ int *pValue) = 0;

   virtual HRESULT STDMETHODCALLTYPE set_Property(
   /* [in] */ int Type,
   /* [in] */ int Value) = 0;
};

Type specifies the property type. For now, there’s only the default math format: TextProperty_MathFormat (1). Its values are given by

enum MathFormatType
{
   MathFormatType_Default     = 0, // Same as GetText
   MathFormatType_MathML      = 1, // Math zones in MathML
   MathFormatType_Nemeth      = 2, // Math zones in Nemeth braille (U+2800 block)
   MathFormatType_LaTeX       = 3, // Math zones in LaTeX
   MathFormatType_UnicodeMath = 4, // Math zones in UnicodeMath
   MathFormatType_Speech      = 5, // Math zones with speech
};

Another property type could be TextProperty_MathVerbosity. To get an ITextProvider3 interface, the client calls

ITextProvider::QueryInterface(__uuidof(ITextProvider3), (LPVOID *)ppTextProvider3)

If this call fails, the program doesn’t have math-format support.

Range Math Text Property

To enable getting more than one math format, e.g., speech and braille, we define the range-level interface

MIDL_INTERFACE("724258C8-8A0D-407D-9622-E5E75D307513")
ITextRangeProvider3 : public ITextRangeProvider2
{
   public:
   virtual HRESULT STDMETHODCALLTYPE GetText2(
   /* [in] */ int maxLength,
   /* [in] */ int Flags,
   /* [retval][out] */ __RPC__deref_out_opt BSTR *pRetVal) = 0;
};

The arguments maxLength and pRetVal are the same as for ITextRangeProvider::GetText(maxLength, pRetVal). The low four bits of Flags are given by the MathFormatType enum above. The AT calls

ITextRangeProvider::QueryInterface(__uuidof(ITextRangeProvider3),
      (LPVOID *)ppTextRangeProvider3)

If this call fails, the program doesn’t have range-level math-format support.

Math Zone Navigation

There are two general kinds of math-zone navigation: 1) from one math zone to another, and 2) within a math zone. The latter can be accomplished with existing functionality, typically by following the program selection changes or by moving by UIA TextUnit_Character and TextUnit_Word.

To navigate up to a math zone or skip onto the next math zone, UIA needs to have a math-zone unit. UIA annotation and attribute values are distinct from the defined UIA TextUnit’s, since attributes are in the 40000 range and annotations are in the 60000 range, while the TextUnit’s are < 10. If we enable the ITextRangeProvider ExpandToEnclosingUnit() and Move(), etc., methods to treat AnnotationType_Mathematics as another unit, then an AT could move by math zones, expand to a math zone, etc. If the AT calls for moving by TextUnit_Format, a math zone would be a format break point. If the QueryInterface for an ITextProvider3 succeeds, then a client could expect that navigation by AnnotationType_Mathematics would work. If a call returns an HRESULT error, navigation and selection by AnnotationType_Mathematics isn’t supported.

Math Control

People have thought about an alternative approach that uses a UIA math control like a UIA hyperlink or table control. This approach is discussed in Math Accessibility Trees. While it makes sense theoretically, math zones can be numerous and are often very small such as the variable 𝑥, which is only a single character. So, it’s simpler and more efficient to treat math zones as text with a math-zone attribute. AnnotationType_Mathematics seems to fit the bill and it has been defined for several years.

Note that the Text Object Model (TOM) uses a math-zone attribute (tomMathZone—see tom.h) as a unit for navigation and selection. Version 2 of TOM has advanced support for math text processing some of which is described in the post Setting and Getting Math Speech, Braille, UnicodeMath, LaTeX… For UIA purposes, the relatively simple approaches given here seem to suffice.

Fwd: [CSSWG] Minutes Lyon F2F 2018-10-22 Part IV: Math on Web Pages Joint Meeting, WPT Joint Meeting

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

Hi MathOnWeb CG,

Here are the official CSS WG minutes for our meeting with them at TPAC.

Best,
Peter.

---------- Forwarded message ---------
From: Dael Jackson <daelcss@gmail.com>
Date: Di., 13. Nov. 2018 um 01:24 Uhr
Subject: [CSSWG] Minutes Lyon F2F 2018-10-22 Part IV: Math on Web Pages
Joint Meeting, WPT Joint Meeting
To: <www-style@w3.org>
Cc: <www-math@w3.org>, <public-test-infra@w3.org>


=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Math on Web Pages Joint Meeting
-------------------------------

  - The Math on Web Pages group presented a list of challenges they
      face trying to style math using CSS:
      https://lists.w3.org/Archives/Public/www-archive/2018Oct/0002.html
  - There were several proposals and use cases for the working group
      to review later which could be added to current or future specs.
      The ones touched on briefly during the meeting were a better way
      to handle baseline alignment and creating sticky fences to
      handle things like long brackets.

WPT Joint Meeting
-----------------

  - A year ago the CSSWG resolved to always require tests with CR
      changes; this meeting was to review the ramifications of that
      decision a year later.
  - There continues to be a resource problem where there are more
      changes put into specs than there are people writing tests and
      PRs still aren't getting reviewed in a timely manner.
  - A suggestion was to change the requirement to one test per commit
      which reduces the burden on authors, but still increases the
      likelihood that changes are noticed.
  - gregwhitworth and jensimmons also said they would continue to look
      into more community support for testing.

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/tpac-2018#schedule

Scribe: fantasai

Math on Web Pages Joint Meeting
===============================
  Full Presentation:
https://lists.w3.org/Archives/Public/www-archive/2018Oct/0002.html
  Simplified Presentation:
https://github.com/w3c/mathonwebpages/wiki/%5BCSS-TF%5D-TPAC-2018-preparations

Introductions
-------------

  arno: I used to be in CSSWG many years ago, but no longer with that
        employer so here representing myself
  arno: Wanted to talk about opportunities to make representing math
        on the Web better
  daniel: I'm co-chair of Math on Web Pages community group
  pkra: I'm an independent consultant working with STEM publishers
  VolkerS: I'm here in my role as 1/2 of mathjax development team. I'm
           mainly on the a11y side and parsing, but know a bit about
           the css

Overview of Challenges
----------------------

  arno: We only have 25min before the break, so we're going to try
  arno: Don't expect to solve the world's problems, but want to talk
        to you about some of the challenges we face in using HTML+CSS
        to present equations on the Web
  arno: There's lots of solutions that do that, not that it's
        unsolveable, but what we think is worth exploring is how we
        can make the authoring of this content easier using CSS
  arno: Using a lot of workarounds and hacky solutions
  arno: Have some solutions of improvements to make it easier for this
        type of content.
  arno: Also want to look at improvements that are not just beneficial
        for authoring MathML content
  arno: But some of these solutions could also benefit others
  arno: Talking about some of the things important to us, and
        solutions to those problems

  arno: First of all we care a lot about quality of the rendering
  arno: Our goal is to achieve the same quality on the Web as on print
  arno: No reason why you can't have the same precision in layout and
        same typographical quality on the web as you have in print
  arno: We recognize that getting there will take some time, but want
        to shoot for.

  arno: One issue we have, a lot of layouts we have to do in css for
        math, is that we have to use a lot of inline styles
  arno: Improved a lot so we don't have to do as much computation on
        the client side to do positioning
  arno: CSS added a lot of additional features which gives us more
        control to do layout
  arno: But still many cases where we have to bake in inline styles,
        e.g. exact lengths for vertical alignment
  arno: We'd prefer not to do that

  arno: ... content on the fly
  arno: If you modify the content, vertical alignment, inline styles
        have to be recalculated
  arno: This is acceptable if you're authoring a library or tool, but
        if we want the authoring to be more accessible
  arno: To be able to author math content with a text editor, need to
        get past this
  arno: So need a solution for that.

  arno: Would also like solutions that improve the stability of the
        layout
  arno: So if you make some changes to the content, would like to be
        able to do that without modifying the rest of the layout,
        having to recalculate everything and re-inject inline styles
        into the markup

  arno: Math fonts is a sort of emerging technology
  arno: For those not familiar, they're an OpenType standard that lets
        you put inside a font side metadata that will allow adapting
        mathematical glyphs, e.g. stretched fences and integrals
  arno: It's great to have that part of the font file
  arno: Today, oftentimes you have to carry them alongside a hard coded
        knowledge of specific fonts. Which is terrible
  arno: This isn't great because user can't just change the font
  arno: So having metric information about the layout, very promising
        technology

  arno: So that's an overview of where we're looking for improvements
  arno: Some of the challenges we have
  arno: Not an exhaustive list
  arno: Some of them we can sort of work around, but it's ugly
  arno: Focusing on ones where the workarounds are the ugliest
  arno: And try to have improvements that benefit beyond just math

  arno: One example is stretchy fences
  arno: Here's an example, it's genealogy
  arno: When you have a genealogical tree, you connect the parents and
        offspring with long brackets
  arno: This is something very common in math, that's used for group
        equations
  arno: Matrices
  arno: And other cases
  arno: Point of this is to remind you that this is something that's
        used beyond math cases
  arno: Doing stretchy fences is possible today, but requires a lot of
        trickeries and is very fragile
  <jensimmons> We (dauwhe, florian and I) were just saying this
               yesterday — it’d be awesome to have a ‘stretchy’ open
               bracket
  arno: Have to composite multiple glyphs together and hope they don't
        break as the layout changes, zoom level is increased, etc.
  arno: Wouldn't it be great if there was a simpler way to do this
        with CSS?
  arno: Especially to use the stretchy bracket as the border of a box.
  arno: And have the rendering engine take care of that

  Myles: Idea that you just described, stretchy... would you expect
         that the browser would create the form of the stretchy glyph
         itself or pick out glyphs from a font?
  arno: Ideally, information from the font would be used
  arno: in traditional typography, e.g. serif font and sans-serif font
        are different
  arno: Unicode has codepoints for this
  arno: So ideal world, we'd use the info from the font

  arno: Moving on to another challenge
  arno: Baseline alignment
  arno: It's one of those where it's not an unsolved problem, there
        are ways to do them, but all of them involve inline styles and
        positioning and vertical-align and all unpleasant
  arno: Depends on the content, and if the content changes, have to
        change the values for the line
  arno: Want to move away from inline styles as much as possible
  arno: Needed for lining up equations
  arno: But also needed for lining up fonts and icon text
  [arno shows example from his doc]
  arno: Don't have one specific solution in mind
  arno: There are some imperfect solutions today, and some discussed
        e.g. in css-inline-3
  arno: Having that incorporated into inline layout model would be
        fantastic
  arno: We'd love to make ourselves available if you have more
        questions
  arno: If that's the direction that you'd like to go

  TabAtkins: In the example the baseline is being taken from some
             descendant. It's not an arbitrary position.
  TabAtkins: If that's the case, I think the implementation shouldn't
             be too unreasonable, because we already drill down into
             descendants to find a baseline
  TabAtkins: So just need to be able to have a child say "I'm the
             baseline for this container" and the container to look
             for that child
  TabAtkins: This other example doesn't have such a case, the baseline
             is totally arbitrary place

  heycam: I've always thought that there should be some way for
          external svg elements should be able to declare where their
          baseline is
  fantasai: There were proposals in the past to be able to specify
            where the baseline of an atomic inline is. (Was deferred
            to later, not prioritized for this level.)

  koji: If there is another example that doesn't have text of the same
        font size, how do you align it?
  arno: If the size changes, would still use the baseline. Would still
        want to align along that axis.
  koji: So not really aligned to that red line (running along the
        alphabetic baseline)
  arno: There's another axis for the exponent, e.g. aetc.

  emilio: Webkit and Gecko have MathML implementations where you could
          do this?
  arno: We want improvements so you could express things with HTML and
        CSS only
  arno: Built in support is great, but ...
  emilio: Why?
  emilio: Why not use MathML which was explicitly designed to do this?
  arno: There are some use cases where MathML doesn't work.
  arno: For example, some software does interactive editing.
  arno: To be able to do the layout with CSS + HTML is better
  emilio: I don't know why you wouldn't be able to mutate MathML
  astearns: There's some cases here that aren't MathML, like the
            genealogical case
  florian: Another case where MathML isn't ideal, the type of MathML
           needed here is the presentational version, but for a11y the
           semantic version is better
  florian: Could instead render to HTML+CSS
  florian: Also presentational MathML is less interoperably and
           robustly implemented, so use a different technology
  florian: Store the semantics differently and render to HTML+CSS

  arno: So let me go quickly to another example of things that we're
        looking for
  arno: Here is enclosures, which is a way to annotate a MathML
        equation
  arno: This is something that is often used to highlight ? equation
  arno: This is also defined in MathML, but would also want to use it
        in other context
  arno: Want to use those constructs in other contexts
  arno: These are currently difficult to implement using CSS + HTML
  arno: Need to do the layout twice, calculate the size of the
        bounding box that you want to decorate
  arno: We hope it to be easier
  TabAtkins: I would think that a lot of this can be done in the Paint
             API
  TabAtkins: We've done a lot of work with Google teams about shaping
             around content, and would love to get more use cases
  TabAtkins: Talk to iank next to you :)

  myles: When you render to HTML+CSS, presumably the result is
         positioned... how?
  myles: Is it abspos?
  arno: No
  arno: Software I worked on -- there are others out there --
        mathdive, as much as possible the layout and positioning of
        glyphs is deferred to the layout engine
  arno: So horizontal positioning is done by the HTML. I just have to
        do some adjustments, especially for stacking, of the boxes
  arno: Used to be much more difficult to do
  arno: Other implementations that used abspos for glyphs, but I think
        that things have progressed enough
  arno: Now looking at the remaining gaps

  myles: But you don't use grid/flexbox?
  arno: Some implementations are
  arno: They're looking into it
  arno: A good opportunity to simplify some of the layout, especially
        for stacked constructs
  arno: baseline alignment
  arno: but in terms of making it able to have fewer inline styles,
        it's a good way

Summary
-------

  arno: Few more things to talk about
  arno: Roots, a special case of enclosures
  arno: stretch fences
  arno: Accents and decorations are a related topic
  arno: A few other topics
  arno: More on the list, less straightforward or more specific in
        their use cases
  arno: So wanted to focus on these
  arno: Wanted engagement with this community, how can we address
        these things
  arno: Use some features in CSS, or some features you're working on
        for next level of the modules
  arno: Happy to be sounding board, provide use cases
  arno: So that's what we're looking for

  astearns: Is this document public?
  arno: Can make it public
  florian: Please output to HTML or PDF and send to www-archive@w3.org
  florian: More long-lived than google docs
  astearns: Thanks, can work on some or all of these issues
  astearns: For now, let's work on break

  <br type=tea end=4pm>

Joint Meeting with WPT
======================
  Scribe: TabAtkins

  zcorpan: A year or so ago this group adopted a testing policy for
           some specs, including OM and OM-View
  zcorpan: And also specs in CR, that normative changes should be
           coupled with wpt
  zcorpan: I want to understand how this policy is working in
           practice, and if there are any blockers to using this for
           spec editors
  zcorpan: If there should be someone to work on testing specifically,
           or if it should be editors' responsibility.
  zcorpan: What is the process, and what do we want it to be? What, if
           anything, is blocking no-test-no-merge policy for CSS specs?

  florian: I think what happened is what we feared would happen. Some
           editors, like myself, who are responsible for a few specs
           but not the overall health of CSS, were able to stick to
           that policy. But Tab and Elika can't do that without
           dropping the amount of work they do on specs, and we don't
           want them to do that.
  florian: And nobody's picked up the tests to go with their changes.
  florian: So, it's not just the three of us in this WG that do specs
           and tests and such. But the policy as a group, is indeed
           blocked by the fact that there's not enough people writing
           tests to go along with the edits.
  florian: For some editors it's reasonable to drop spec output to
           increase test output, but not for other editors. I don't
           know how to solve that.
  florian: I'll keep doing my part, but... I don't think it's possible
           for the WG unless we have more people to do just tests to
           compensate.

  Chris_Lilley: We need more people to do edits, too, is the thing.
  fremy: Same point - I disagree we should say there should be
         spec-specific people, and I disagree that Tab and Elika
         should be reducing their output to write tests. We have a big
         group, we have a lot of ideas. We have big companies here, we
         should make sure we staff the testing group specifically.
  fremy: If we don't have enough people to even do the editing work,
         obviously we don't have enough for the testing work.

  rbyers: Of these changes that don't have tests, are there impl
          changes happening too?
  rbyers: In Chromium, devs need to land tests at the same time. Does
          that apply here?

  florian: A success here is the Contain spec. As an editor I focused
           on writing a test for every change I made, but we didn't
           have tests at the beginning. Igalia implemented, and wrote
           tests as they went; I also commissioned tests from Gérard
           to fill the gaps.

  dbaron: Another risk with not having tests is the implementor
          doesn't notice the change.
  dbaron: Because we don't have a great mechanism for making sure
          changes get into implementations... there's still a problem
          with noticing the change.
  <cbiesinger> agree with dbaron -- there's several flexbox spec
               changes I didn't notice until someone filed a bug
  <cbiesinger> or mozilla upstreamed a test :)
  foolip: Are bugs being filed in the issue trackers to track changes?
  fantasai: Not systematically done or tracked right now. We have a
            label for changes that need tests, but not one to track
            things that need bugs.
  Chris_Lilley: When I was doing Fonts 3, we were already well-tested
                and most things were implemented, so I was able to
                keep track of everything. But across all specs,
                they're at much different levels of implementation.
  foolip: What's also been happening is the spec change is made, then
          we have tests written before the change that contradict them.
  foolip: But the big risk is changes that don't get noticed by anyone.
  gsnedders: And the spec is then not implemented as written, because
             the change was never made in implementations and no test
             was written for it, and that isn't noticed.

  foolip: All the changes being made, what would happen if changes
          *were* blocked on tests.
  foolip: Where's the pressure to make changes in the first place?
  fantasai: It comes from people giving feedback on specs. Some are
            implementors, who can write a test immediately because
            they're implementing, but sometimes they just notice
            something but aren't working on it, and won't get back to
            it for a year.
  fantasai: Some are filed by users of the tech that have issues with
            how it behaves. Some are filed by WG members or other
            reviewers.
  fantasai: So some of these have incentive to write a test, others
            don't.
  foolip: So either they care enough to share a burden, or they don't.
          In HTML, random person writes a PR, then we require them to
          write a test.
  cbiesinger: Sometimes people in general will just file an issue that
              something needs to be clarified. It may not be clear
              what the right behavior even is, so it might be
              low-priority. By the time we get around to fixing the
              issue, the reporter might not even be around.
  florian: We have many cases of people qualified to point out a
           problem, but not qualified to fix it.
  florian: So it's we as a group that need to make the fix, and make
           the test.
  jensimmons: I'd have a big problem with this group deciding that
              only people who have the time and skill to write tests
              can contribute to CSS. That's not a route we want to go
              down.
  jensimmons: I do think we need more test-writing. I've had
              conversations; there are many people who'd like to write
              tests, but there's no clear way to get involved.
  jensimmons: And even when they do get wind of how to get involved,
              the tools are complex and there's lots of blockers that
              make people give up.
  jensimmons: There are people in this group, like Greg and Rachel,
              that have said that is an important thing they want to
              work on.
  jensimmons: I think there are hundreds of people who want to
              contribute, with an easier on-ramp.
  <florian> +1000 to what Jen said

  <heycam> a few years ago we had the Test the Web Forward project --
           was that successful?
  <TabAtkins> not really
  <glazou> heycam yes it was immensely helpful
  <gsnedders> I'm unaware of any repeat contributor we got from TTWF
  <glazou> gsnedders right, but it did help

  fremy: I think to answer your question, the answer is "backlog".
         There's already more work pouring in everyday than this group
         can work on.
  fremy: We as a group still care about fixing the spec, because it's
         wrong.
  foolip: For any big project, obviously there's a big backlog. Given
          the resources available, is it more effective to just work
          on the spec, or ensure that spec and test work happen
          together.
  foolip: Hypothesis I put forth last year is that if you do the test
          work, people will notice something has changed, and
          implementors will follow along faster.
  foolip: That's not proven, but if that's true, whatever amount of
          resources are available, doing this work together makes more
          sense than doing just the spec work.
  zcorpan: I think the experience with HTML is that it does result in
           impl changes more consistently.
  zcorpan: Before this policy we'd sometimes have spec changes, not
           write tests, then revert the change because nobody
           implemented it.
  zcorpan: I think this proposal helps with that issue.

  gregwhitworth: I still stand by what we said last year - we all have
                 wpt.fyi externally, so we can see the changes.
  gregwhitworth: To Jen's point, I've set up some mentorships with
                 folks; there's a lot more ramp-up to writing good
                 tests than I think we realize. There's a lot of
                 webdevs out there, but when we narrow it down, the
                 number who have the time is quite small, but still
                 something we should pursue.
  gregwhitworth: I'll grab some of the people that might be relevant
                 and talk about this.
  gregwhitworth: I don't want us to focus so hard on the suites
                 themselves. Is it worth spending 80% of time on the
                 20% of effort to perfect the testsuite?
  gregwhitworth: I don't want fantasai to spend so much time writing up
                 tests just because she's the most knowledgeable.
  gregwhitworth: I bet we have about 70 people in this room. Some of
                 us are tied to more implementors. So instead, just
                 think about a *single* test that fails.
  gregwhitworth: Putting together a *single* new test for a change
                 that would fail in non-conforming browsers would
                 still be a ton of help.
  foolip: And there's also the problem of big new features, where it's
          too formative to be worth writing a comprehensive suite.
  TabAtkins: I think I can commit to writing a single test per change.
             Just as a signaling mechanism that something has changed,
             that seems sufficiently high-value and low-effort that I
             think I can gate myself that way without a significant
             slowdown.

  heycam: I think I agree that making tests at same time as changes is
          ideal. Given resource constraints of the group, wonder if
          it's more important to track things that do need tests;
          seems that could be mostly automated.
  heycam: So when we have free time, or external people look at
          something, or a new implementor comes in...
  astearns: We do have a "Needs Tests" tag that we give to issues.
  heycam: That's tied to GH issues; not all changes are tied to GH
          issues, particularly early on.

  dbaron: There's been a lot of talk about resource constraints for
          editors.
  dbaron: Think about that in a different way.
  dbaron: One of the things we end up doing a lot is we end up
          revisiting changes, discussing multiple times, because
          they're not implemented and now we have a compat constraint.
  dbaron: There are reasons why, when we started using tests in
          software dev, even tho we spent more time writing tests, I
          think people agree that we overall moved faster.
  dbaron: I think HTML editors found the same thing. Even tho you're
          stopping to do this extra work, you can accomplish more,
          because it makes the work more likely to stick.
  dbaron: It also sometimes causes you to think more about the change,
          think about other cases.
  dbaron: But mostly it makes it less likely we have to revisit things
          later.
  <tantek> +1 what dbaron is saying
  dbaron: So I think the "one test per change" is good.

  florian: Another bottleneck is test reviews.
  florian: I have 13 open PRs right now, oldest back from April.
  florian: I can write as many tests as I want, but I can't review my
           own tests.
  foolip: What do you do when tests get stuck?
  florian: Poke, but often the best people to poke are Tab and Elika,
           and we're back to the bandwidth problem. ^_^
  foolip: This is an issue for many groups.
  foolip: I don't think it's a tooling problem.
  foolip: Say we add a role for someone to go thru Needs Tests label,
          or to write together with spec changes. Unless that's
          blocking, and keeps blocking, any changes you make will be
          eroded.
  florian: Another thing about test reviews is that they seem trivial,
           but they're not.
  florian: Ask the editor, it's probably not hard. Ask someone else,
           it's not. Reviewing one test might be a 20-hour task, as
           you have to read the spec first.

  krit: For Transforms there are some PRs I've put up, and they still
        need review.
  krit: For editors of the spec, could we lift the requirement that
        someone else needs to do a review?
  florian: I think it's good to have reviews, but if you're blocked...
  gregwhitworth: And they'll get reviewed by the implementors when
                 they review the test later anyway, when they see that
                 they're failing it.
  foolip: We could tweak wpt-pr-bot to not require reviews from
          certain people...


  <rachelandrew> having dug through all the legacy multicol tests
                 recently, and inlined them in the spec, very grateful
                 for the work TabAtkins did adding that functionality
                 to Bikeshed.

  <gregwhitworth> https://www.irccloud.com/pastebin/LvLPxBCS/
  <zcorpan> ty all

  <dbaron> I'm in favor of allowing editors to land tests without
           review.
  <AmeliaBR> The problem with editors writing their own tests without
             review is that sometimes they are testing what they
             *meant* the spec to say, not what it currently says. Can
             end up with requirements that only exist in the tests,
             not the spec.

  <foolip> I filed
https://github.com/web-platform-tests/wpt-pr-bot/issues/47

[CSSWG] Minutes Lyon F2F 2018-10-22 Part IV: Math on Web Pages Joint Meeting, WPT Joint Meeting

Source: www-math@w3.org Mail Archives • Dael Jackson (daelcss@gmail.com) • November 13, 2018 • Permalink

=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Math on Web Pages Joint Meeting
-------------------------------

  - The Math on Web Pages group presented a list of challenges they
      face trying to style math using CSS:
      https://lists.w3.org/Archives/Public/www-archive/2018Oct/0002.html
  - There were several proposals and use cases for the working group
      to review later which could be added to current or future specs.
      The ones touched on briefly during the meeting were a better way
      to handle baseline alignment and creating sticky fences to
      handle things like long brackets.

WPT Joint Meeting
-----------------

  - A year ago the CSSWG resolved to always require tests with CR
      changes; this meeting was to review the ramifications of that
      decision a year later.
  - There continues to be a resource problem where there are more
      changes put into specs than there are people writing tests and
      PRs still aren't getting reviewed in a timely manner.
  - A suggestion was to change the requirement to one test per commit
      which reduces the burden on authors, but still increases the
      likelihood that changes are noticed.
  - gregwhitworth and jensimmons also said they would continue to look
      into more community support for testing.

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/tpac-2018#schedule

Scribe: fantasai

Math on Web Pages Joint Meeting
===============================
  Full Presentation:
https://lists.w3.org/Archives/Public/www-archive/2018Oct/0002.html
  Simplified Presentation:
https://github.com/w3c/mathonwebpages/wiki/%5BCSS-TF%5D-TPAC-2018-preparations

Introductions
-------------

  arno: I used to be in CSSWG many years ago, but no longer with that
        employer so here representing myself
  arno: Wanted to talk about opportunities to make representing math
        on the Web better
  daniel: I'm co-chair of Math on Web Pages community group
  pkra: I'm an independent consultant working with STEM publishers
  VolkerS: I'm here in my role as 1/2 of mathjax development team. I'm
           mainly on the a11y side and parsing, but know a bit about
           the css

Overview of Challenges
----------------------

  arno: We only have 25min before the break, so we're going to try
  arno: Don't expect to solve the world's problems, but want to talk
        to you about some of the challenges we face in using HTML+CSS
        to present equations on the Web
  arno: There's lots of solutions that do that, not that it's
        unsolveable, but what we think is worth exploring is how we
        can make the authoring of this content easier using CSS
  arno: Using a lot of workarounds and hacky solutions
  arno: Have some solutions of improvements to make it easier for this
        type of content.
  arno: Also want to look at improvements that are not just beneficial
        for authoring MathML content
  arno: But some of these solutions could also benefit others
  arno: Talking about some of the things important to us, and
        solutions to those problems

  arno: First of all we care a lot about quality of the rendering
  arno: Our goal is to achieve the same quality on the Web as on print
  arno: No reason why you can't have the same precision in layout and
        same typographical quality on the web as you have in print
  arno: We recognize that getting there will take some time, but want
        to shoot for.

  arno: One issue we have, a lot of layouts we have to do in css for
        math, is that we have to use a lot of inline styles
  arno: Improved a lot so we don't have to do as much computation on
        the client side to do positioning
  arno: CSS added a lot of additional features which gives us more
        control to do layout
  arno: But still many cases where we have to bake in inline styles,
        e.g. exact lengths for vertical alignment
  arno: We'd prefer not to do that

  arno: ... content on the fly
  arno: If you modify the content, vertical alignment, inline styles
        have to be recalculated
  arno: This is acceptable if you're authoring a library or tool, but
        if we want the authoring to be more accessible
  arno: To be able to author math content with a text editor, need to
        get past this
  arno: So need a solution for that.

  arno: Would also like solutions that improve the stability of the
        layout
  arno: So if you make some changes to the content, would like to be
        able to do that without modifying the rest of the layout,
        having to recalculate everything and re-inject inline styles
        into the markup

  arno: Math fonts is a sort of emerging technology
  arno: For those not familiar, they're an OpenType standard that lets
        you put inside a font side metadata that will allow adapting
        mathematical glyphs, e.g. stretched fences and integrals
  arno: It's great to have that part of the font file
  arno: Today, oftentimes you have to carry them alongside a hard coded
        knowledge of specific fonts. Which is terrible
  arno: This isn't great because user can't just change the font
  arno: So having metric information about the layout, very promising
        technology

  arno: So that's an overview of where we're looking for improvements
  arno: Some of the challenges we have
  arno: Not an exhaustive list
  arno: Some of them we can sort of work around, but it's ugly
  arno: Focusing on ones where the workarounds are the ugliest
  arno: And try to have improvements that benefit beyond just math

  arno: One example is stretchy fences
  arno: Here's an example, it's genealogy
  arno: When you have a genealogical tree, you connect the parents and
        offspring with long brackets
  arno: This is something very common in math, that's used for group
        equations
  arno: Matrices
  arno: And other cases
  arno: Point of this is to remind you that this is something that's
        used beyond math cases
  arno: Doing stretchy fences is possible today, but requires a lot of
        trickeries and is very fragile
  <jensimmons> We (dauwhe, florian and I) were just saying this
               yesterday — it’d be awesome to have a ‘stretchy’ open
               bracket
  arno: Have to composite multiple glyphs together and hope they don't
        break as the layout changes, zoom level is increased, etc.
  arno: Wouldn't it be great if there was a simpler way to do this
        with CSS?
  arno: Especially to use the stretchy bracket as the border of a box.
  arno: And have the rendering engine take care of that

  Myles: Idea that you just described, stretchy... would you expect
         that the browser would create the form of the stretchy glyph
         itself or pick out glyphs from a font?
  arno: Ideally, information from the font would be used
  arno: in traditional typography, e.g. serif font and sans-serif font
        are different
  arno: Unicode has codepoints for this
  arno: So ideal world, we'd use the info from the font

  arno: Moving on to another challenge
  arno: Baseline alignment
  arno: It's one of those where it's not an unsolved problem, there
        are ways to do them, but all of them involve inline styles and
        positioning and vertical-align and all unpleasant
  arno: Depends on the content, and if the content changes, have to
        change the values for the line
  arno: Want to move away from inline styles as much as possible
  arno: Needed for lining up equations
  arno: But also needed for lining up fonts and icon text
  [arno shows example from his doc]
  arno: Don't have one specific solution in mind
  arno: There are some imperfect solutions today, and some discussed
        e.g. in css-inline-3
  arno: Having that incorporated into inline layout model would be
        fantastic
  arno: We'd love to make ourselves available if you have more
        questions
  arno: If that's the direction that you'd like to go

  TabAtkins: In the example the baseline is being taken from some
             descendant. It's not an arbitrary position.
  TabAtkins: If that's the case, I think the implementation shouldn't
             be too unreasonable, because we already drill down into
             descendants to find a baseline
  TabAtkins: So just need to be able to have a child say "I'm the
             baseline for this container" and the container to look
             for that child
  TabAtkins: This other example doesn't have such a case, the baseline
             is totally arbitrary place

  heycam: I've always thought that there should be some way for
          external svg elements should be able to declare where their
          baseline is
  fantasai: There were proposals in the past to be able to specify
            where the baseline of an atomic inline is. (Was deferred
            to later, not prioritized for this level.)

  koji: If there is another example that doesn't have text of the same
        font size, how do you align it?
  arno: If the size changes, would still use the baseline. Would still
        want to align along that axis.
  koji: So not really aligned to that red line (running along the
        alphabetic baseline)
  arno: There's another axis for the exponent, e.g. aetc.

  emilio: Webkit and Gecko have MathML implementations where you could
          do this?
  arno: We want improvements so you could express things with HTML and
        CSS only
  arno: Built in support is great, but ...
  emilio: Why?
  emilio: Why not use MathML which was explicitly designed to do this?
  arno: There are some use cases where MathML doesn't work.
  arno: For example, some software does interactive editing.
  arno: To be able to do the layout with CSS + HTML is better
  emilio: I don't know why you wouldn't be able to mutate MathML
  astearns: There's some cases here that aren't MathML, like the
            genealogical case
  florian: Another case where MathML isn't ideal, the type of MathML
           needed here is the presentational version, but for a11y the
           semantic version is better
  florian: Could instead render to HTML+CSS
  florian: Also presentational MathML is less interoperably and
           robustly implemented, so use a different technology
  florian: Store the semantics differently and render to HTML+CSS

  arno: So let me go quickly to another example of things that we're
        looking for
  arno: Here is enclosures, which is a way to annotate a MathML
        equation
  arno: This is something that is often used to highlight ? equation
  arno: This is also defined in MathML, but would also want to use it
        in other context
  arno: Want to use those constructs in other contexts
  arno: These are currently difficult to implement using CSS + HTML
  arno: Need to do the layout twice, calculate the size of the
        bounding box that you want to decorate
  arno: We hope it to be easier
  TabAtkins: I would think that a lot of this can be done in the Paint
             API
  TabAtkins: We've done a lot of work with Google teams about shaping
             around content, and would love to get more use cases
  TabAtkins: Talk to iank next to you :)

  myles: When you render to HTML+CSS, presumably the result is
         positioned... how?
  myles: Is it abspos?
  arno: No
  arno: Software I worked on -- there are others out there --
        mathdive, as much as possible the layout and positioning of
        glyphs is deferred to the layout engine
  arno: So horizontal positioning is done by the HTML. I just have to
        do some adjustments, especially for stacking, of the boxes
  arno: Used to be much more difficult to do
  arno: Other implementations that used abspos for glyphs, but I think
        that things have progressed enough
  arno: Now looking at the remaining gaps

  myles: But you don't use grid/flexbox?
  arno: Some implementations are
  arno: They're looking into it
  arno: A good opportunity to simplify some of the layout, especially
        for stacked constructs
  arno: baseline alignment
  arno: but in terms of making it able to have fewer inline styles,
        it's a good way

Summary
-------

  arno: Few more things to talk about
  arno: Roots, a special case of enclosures
  arno: stretch fences
  arno: Accents and decorations are a related topic
  arno: A few other topics
  arno: More on the list, less straightforward or more specific in
        their use cases
  arno: So wanted to focus on these
  arno: Wanted engagement with this community, how can we address
        these things
  arno: Use some features in CSS, or some features you're working on
        for next level of the modules
  arno: Happy to be sounding board, provide use cases
  arno: So that's what we're looking for

  astearns: Is this document public?
  arno: Can make it public
  florian: Please output to HTML or PDF and send to www-archive@w3.org
  florian: More long-lived than google docs
  astearns: Thanks, can work on some or all of these issues
  astearns: For now, let's work on break

  <br type=tea end=4pm>

Joint Meeting with WPT
======================
  Scribe: TabAtkins

  zcorpan: A year or so ago this group adopted a testing policy for
           some specs, including OM and OM-View
  zcorpan: And also specs in CR, that normative changes should be
           coupled with wpt
  zcorpan: I want to understand how this policy is working in
           practice, and if there are any blockers to using this for
           spec editors
  zcorpan: If there should be someone to work on testing specifically,
           or if it should be editors' responsibility.
  zcorpan: What is the process, and what do we want it to be? What, if
           anything, is blocking no-test-no-merge policy for CSS specs?

  florian: I think what happened is what we feared would happen. Some
           editors, like myself, who are responsible for a few specs
           but not the overall health of CSS, were able to stick to
           that policy. But Tab and Elika can't do that without
           dropping the amount of work they do on specs, and we don't
           want them to do that.
  florian: And nobody's picked up the tests to go with their changes.
  florian: So, it's not just the three of us in this WG that do specs
           and tests and such. But the policy as a group, is indeed
           blocked by the fact that there's not enough people writing
           tests to go along with the edits.
  florian: For some editors it's reasonable to drop spec output to
           increase test output, but not for other editors. I don't
           know how to solve that.
  florian: I'll keep doing my part, but... I don't think it's possible
           for the WG unless we have more people to do just tests to
           compensate.

  Chris_Lilley: We need more people to do edits, too, is the thing.
  fremy: Same point - I disagree we should say there should be
         spec-specific people, and I disagree that Tab and Elika
         should be reducing their output to write tests. We have a big
         group, we have a lot of ideas. We have big companies here, we
         should make sure we staff the testing group specifically.
  fremy: If we don't have enough people to even do the editing work,
         obviously we don't have enough for the testing work.

  rbyers: Of these changes that don't have tests, are there impl
          changes happening too?
  rbyers: In Chromium, devs need to land tests at the same time. Does
          that apply here?

  florian: A success here is the Contain spec. As an editor I focused
           on writing a test for every change I made, but we didn't
           have tests at the beginning. Igalia implemented, and wrote
           tests as they went; I also commissioned tests from Gérard
           to fill the gaps.

  dbaron: Another risk with not having tests is the implementor
          doesn't notice the change.
  dbaron: Because we don't have a great mechanism for making sure
          changes get into implementations... there's still a problem
          with noticing the change.
  <cbiesinger> agree with dbaron -- there's several flexbox spec
               changes I didn't notice until someone filed a bug
  <cbiesinger> or mozilla upstreamed a test :)
  foolip: Are bugs being filed in the issue trackers to track changes?
  fantasai: Not systematically done or tracked right now. We have a
            label for changes that need tests, but not one to track
            things that need bugs.
  Chris_Lilley: When I was doing Fonts 3, we were already well-tested
                and most things were implemented, so I was able to
                keep track of everything. But across all specs,
                they're at much different levels of implementation.
  foolip: What's also been happening is the spec change is made, then
          we have tests written before the change that contradict them.
  foolip: But the big risk is changes that don't get noticed by anyone.
  gsnedders: And the spec is then not implemented as written, because
             the change was never made in implementations and no test
             was written for it, and that isn't noticed.

  foolip: All the changes being made, what would happen if changes
          *were* blocked on tests.
  foolip: Where's the pressure to make changes in the first place?
  fantasai: It comes from people giving feedback on specs. Some are
            implementors, who can write a test immediately because
            they're implementing, but sometimes they just notice
            something but aren't working on it, and won't get back to
            it for a year.
  fantasai: Some are filed by users of the tech that have issues with
            how it behaves. Some are filed by WG members or other
            reviewers.
  fantasai: So some of these have incentive to write a test, others
            don't.
  foolip: So either they care enough to share a burden, or they don't.
          In HTML, random person writes a PR, then we require them to
          write a test.
  cbiesinger: Sometimes people in general will just file an issue that
              something needs to be clarified. It may not be clear
              what the right behavior even is, so it might be
              low-priority. By the time we get around to fixing the
              issue, the reporter might not even be around.
  florian: We have many cases of people qualified to point out a
           problem, but not qualified to fix it.
  florian: So it's we as a group that need to make the fix, and make
           the test.
  jensimmons: I'd have a big problem with this group deciding that
              only people who have the time and skill to write tests
              can contribute to CSS. That's not a route we want to go
              down.
  jensimmons: I do think we need more test-writing. I've had
              conversations; there are many people who'd like to write
              tests, but there's no clear way to get involved.
  jensimmons: And even when they do get wind of how to get involved,
              the tools are complex and there's lots of blockers that
              make people give up.
  jensimmons: There are people in this group, like Greg and Rachel,
              that have said that is an important thing they want to
              work on.
  jensimmons: I think there are hundreds of people who want to
              contribute, with an easier on-ramp.
  <florian> +1000 to what Jen said

  <heycam> a few years ago we had the Test the Web Forward project --
           was that successful?
  <TabAtkins> not really
  <glazou> heycam yes it was immensely helpful
  <gsnedders> I'm unaware of any repeat contributor we got from TTWF
  <glazou> gsnedders right, but it did help

  fremy: I think to answer your question, the answer is "backlog".
         There's already more work pouring in everyday than this group
         can work on.
  fremy: We as a group still care about fixing the spec, because it's
         wrong.
  foolip: For any big project, obviously there's a big backlog. Given
          the resources available, is it more effective to just work
          on the spec, or ensure that spec and test work happen
          together.
  foolip: Hypothesis I put forth last year is that if you do the test
          work, people will notice something has changed, and
          implementors will follow along faster.
  foolip: That's not proven, but if that's true, whatever amount of
          resources are available, doing this work together makes more
          sense than doing just the spec work.
  zcorpan: I think the experience with HTML is that it does result in
           impl changes more consistently.
  zcorpan: Before this policy we'd sometimes have spec changes, not
           write tests, then revert the change because nobody
           implemented it.
  zcorpan: I think this proposal helps with that issue.

  gregwhitworth: I still stand by what we said last year - we all have
                 wpt.fyi externally, so we can see the changes.
  gregwhitworth: To Jen's point, I've set up some mentorships with
                 folks; there's a lot more ramp-up to writing good
                 tests than I think we realize. There's a lot of
                 webdevs out there, but when we narrow it down, the
                 number who have the time is quite small, but still
                 something we should pursue.
  gregwhitworth: I'll grab some of the people that might be relevant
                 and talk about this.
  gregwhitworth: I don't want us to focus so hard on the suites
                 themselves. Is it worth spending 80% of time on the
                 20% of effort to perfect the testsuite?
  gregwhitworth: I don't want fantasai to spend so much time writing up
                 tests just because she's the most knowledgeable.
  gregwhitworth: I bet we have about 70 people in this room. Some of
                 us are tied to more implementors. So instead, just
                 think about a *single* test that fails.
  gregwhitworth: Putting together a *single* new test for a change
                 that would fail in non-conforming browsers would
                 still be a ton of help.
  foolip: And there's also the problem of big new features, where it's
          too formative to be worth writing a comprehensive suite.
  TabAtkins: I think I can commit to writing a single test per change.
             Just as a signaling mechanism that something has changed,
             that seems sufficiently high-value and low-effort that I
             think I can gate myself that way without a significant
             slowdown.

  heycam: I think I agree that making tests at same time as changes is
          ideal. Given resource constraints of the group, wonder if
          it's more important to track things that do need tests;
          seems that could be mostly automated.
  heycam: So when we have free time, or external people look at
          something, or a new implementor comes in...
  astearns: We do have a "Needs Tests" tag that we give to issues.
  heycam: That's tied to GH issues; not all changes are tied to GH
          issues, particularly early on.

  dbaron: There's been a lot of talk about resource constraints for
          editors.
  dbaron: Think about that in a different way.
  dbaron: One of the things we end up doing a lot is we end up
          revisiting changes, discussing multiple times, because
          they're not implemented and now we have a compat constraint.
  dbaron: There are reasons why, when we started using tests in
          software dev, even tho we spent more time writing tests, I
          think people agree that we overall moved faster.
  dbaron: I think HTML editors found the same thing. Even tho you're
          stopping to do this extra work, you can accomplish more,
          because it makes the work more likely to stick.
  dbaron: It also sometimes causes you to think more about the change,
          think about other cases.
  dbaron: But mostly it makes it less likely we have to revisit things
          later.
  <tantek> +1 what dbaron is saying
  dbaron: So I think the "one test per change" is good.

  florian: Another bottleneck is test reviews.
  florian: I have 13 open PRs right now, oldest back from April.
  florian: I can write as many tests as I want, but I can't review my
           own tests.
  foolip: What do you do when tests get stuck?
  florian: Poke, but often the best people to poke are Tab and Elika,
           and we're back to the bandwidth problem. ^_^
  foolip: This is an issue for many groups.
  foolip: I don't think it's a tooling problem.
  foolip: Say we add a role for someone to go thru Needs Tests label,
          or to write together with spec changes. Unless that's
          blocking, and keeps blocking, any changes you make will be
          eroded.
  florian: Another thing about test reviews is that they seem trivial,
           but they're not.
  florian: Ask the editor, it's probably not hard. Ask someone else,
           it's not. Reviewing one test might be a 20-hour task, as
           you have to read the spec first.

  krit: For Transforms there are some PRs I've put up, and they still
        need review.
  krit: For editors of the spec, could we lift the requirement that
        someone else needs to do a review?
  florian: I think it's good to have reviews, but if you're blocked...
  gregwhitworth: And they'll get reviewed by the implementors when
                 they review the test later anyway, when they see that
                 they're failing it.
  foolip: We could tweak wpt-pr-bot to not require reviews from
          certain people...


  <rachelandrew> having dug through all the legacy multicol tests
                 recently, and inlined them in the spec, very grateful
                 for the work TabAtkins did adding that functionality
                 to Bikeshed.

  <gregwhitworth> https://www.irccloud.com/pastebin/LvLPxBCS/
  <zcorpan> ty all

  <dbaron> I'm in favor of allowing editors to land tests without
           review.
  <AmeliaBR> The problem with editors writing their own tests without
             review is that sometimes they are testing what they
             *meant* the spec to say, not what it currently says. Can
             end up with requirements that only exist in the tests,
             not the spec.

  <foolip> I filed https://github.com/web-platform-tests/wpt-pr-bot/issues/47

Re: [MathML 4] Add rules to map from non-combining to combining accents

Source: www-math@w3.org Mail Archives • Frédéric WANG (fred.wang@free.fr) • November 12, 2018 • Permalink

Thanks David. I'll take a look later.

On 09/11/2018 16:58, David Carlisle wrote:
>
>
> I added some cross referencing elements that hopefully are equivalent to
> some merge of the data kindly provided by Murray and Frédéric
>
>
> https://github.com/w3c/xml-entities/commit/b4da8d5de24f9078e4d7011718481483906ac3b5
>
>
> Basically a combining character may have a <noncombref> element that
> reference a somehow related non combining character and conversely the
> non combining character has a <combref> the style attribute takes
> "above", "below" or "over" to give a hint about the context.
>
>
> 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.
>

-- 
Frédéric Wang - frederic-wang.fr




Re: [MathML 4] Add rules to map from non-combining to combining accents

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



I added some cross referencing elements that hopefully are equivalent to 
some merge of the data kindly provided by Murray and Frédéric


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



Basically a combining character may have a <noncombref> element that 
reference a somehow related non combining character and conversely the 
non combining character has a <combref> the style attribute takes 
"above", "below" or "over" to give a hint about the context.


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: [MathML 4] Add rules to map from non-combining to combining accents

Source: www-math@w3.org Mail Archives • William F Hammond (hammond@csc.albany.edu) • November 06, 2018 • Permalink

David Carlisle <davidc@nag.co.uk> writes:

> On 05/11/2018 18:45, William F Hammond wrote:
>> I think it would be helpful if your W3C group (does it
>> currently exist?)
>
> Not formally chartered however the group is of course on
> this list. and as you see, handling errata and extension
> suggestions.
>
>> went on record saying that the holes
>> should be filled.
>
> I'm not sure. It would have been better if they hadn't
> been there but they have been there many years now, so if
> they were "filled" it wouldn't simplify the code that is
> dealing with them, just add extra complication that had to
> deal with both possibilities.

For rendering, e.g., browsers, it would just involve filling
in the various fonts that have not previously been following
the Unicode table's cross references.

Present code for casting could be mostly left as it is
(although casting \mathit{h} to U+210E, "Planck constant",
is really, really awful).  New code for casting could
be sane.

I don't understand what you mean by extra complication for
dealing with both possibilities.  If one is worried by holes
in user platform fonts, one can serve webfonts.

                                    -- Bill

Re: [MathML 4] Add rules to map from non-combining to combining accents

Source: www-math@w3.org Mail Archives • William F Hammond (hammond@csc.albany.edu) • November 06, 2018 • Permalink

Murray Sargent <murrays@exchange.microsoft.com> writes:

> Agreed. It's lamentable that holes in 1D400..1D7FF were
> put in where characters already existed in the Letterlike
> Symbols block (2100..214F), e.g., math italic ℎ is 210E,
> not 1D455. Industry math code uses the current definitions
> and filling in the holes would break that code or not be
> interchangeable. So we have to live with the encoding as
> is.

NO.  Old code does not need to be changed.   See below.

"MATHEMATICAL ITALIC SMALL H" is missing in Unicode.  The
sporadic U+210E is defined to be "PLANCK CONSTANT".  And
actually the Planck constant is quite commonly represented
by a glyph that does not match what good taste would dictate
for the missing U+1D455.

In fact, the standard as it is broken for non-visual
purposes.  How is a blind individual supposed to interpret a
sudden appearance of "PLANCK CONSTANT" in an article about
number theory.

It would cause breakage to change the definition of U+210E
but no breakage to add "MATHEMATICAL ITALIC SMALL H" as
U+1D455.

> Btw, I'm the UTC member who wrote the Unicode math
> alphanumeric proposals and I recommended against having
> the holes when the math alphanumerics were standardized
> (Unicode 3.1, March 2001). I was overruled on the basis of
> the principle that Unicode shouldn't have duplicate
> characters ☹.

That conclusion on which you were overruled is simply wrong.
The characters missing from the alphabets are not the same
characters as their sporadic look-alikes.  They may (or may
not) be represented with the same glyphs, but Unicode is
supposed to be a list of characters, not a list of glyphs.

Filling in the holes would not create duplicate characters.

Filling in the missing characters would not break anything.
I am absolutely not suggesting that the sporadic characters
in the neighborhood of U+2100 be changed.  None of those
character names match the character names that would fill in
the holes.

Thanks for listening.

                     -- Bill

Math on the Web ? Not Only ! I prefer to say Math with Web Technology.

Source: public-mathonwebpages@w3.org Mail Archives • Abossolo Foh Guy (guy.abossolo.foh@scientificware.com) • November 06, 2018 • Permalink

 

Hi, 

I hope that all of you who came in Lyon enjoyed their stays in our town.


As I said before OpenJFX (JavaFX) MathML support is repaired. All
developper can used it from now with Java 8.192 and JavaFX 11/OpenJFX
11. They can reach Mac OS, Windows, Linux, ... so their can work with
Macs, PCs Raspberrys Pi, ... everywhere where JavaFX is supported and
may be mobiles with IOS and Android soon : 

I missed the meeting in Lyon because I was working on the second part of
my project, I'll wished to be ready for TPAC-lyon-2018 but I not succeed
:-(. 

I'm working hard because I hope to make another Pull Request to the
github javafxports/openjdk-jfx for the next release. 

- This work is tracked by Github Scientificware OpenJDK-JFX #issues26
[2]. 

- To validate my choices (described in my first mail), I build another
application called FXMessages. It's a mobile messenger application based
on SMS (that I also described precedently). I'm targeting IOS and
Android. The Android version [3] is near to be released (may be in one
week) and I'm going to test it with secondary school (for vocational
training) and also preparatory classe (two-year undergraduate intensive
course in mathematics and/or physics) students. 

___ 

The purpose of this application is editing only(#issue26). I already
worked on display and I hope my work will be available on Android as
soon as possible. But this part is Gluon's project [4] and I discussing
with them in MathML on JavaFX/Android or IOS #228 [5] and as you can
read in this report I've got a short term solution. This present
FXMessages version is based on CSS and the rendering is very bad. 

Guy. 

P.S. I'm not from Oracle and Gluon, I'm just a small contributor who
needs mathematics to work :-) 

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


Le 2018-06-22 10:20, Abossolo Foh Guy a écrit : 

> Hi Arno,
> 
> After our short discussion, I continued to work on WebKit support in JavaFX / OpenJFX.
> 
> I posted the Issue (JavaFX OpenJFS and MathML #71 [1]) on the new OpenJFX GitHub Contributor process and started to work as suggested by OpenJFX team.
> 
> I found and fixed the problem. I'm waiting now to get my pull request merged into OpenJFX. Some problems still remain but the support of MathML it's far better than in the previous version. I can now use it in my own applications. I hope it would interest others developpers.
> 
> On the picture, the reference goal TeX is on the left and the MalML rendering JavaFX/OpenJFX is on the right.
> 
> The small application for the test is not simply a web browser it's an editor (the HTLMEditor of JavaFX/OpenJFX). It can made some edits in formulas but we can not presently create formula. Many problems have to be fixed before we can use it. AsciiMath as authoring language seems to be a good entry point.
> 
> Of course one can use only the web browser JavaFX/OpenJFX component (WebView).
> 
> The test is from the Mozilla MathML Torture Test.
> 
> I hope to see it in the next OpenJFX release, I really need it.
> 
> Best regards.

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


> Hi Arno, 
> 
> Thanks for your answer, 
> 
>> ​That's an interesting use case. It might take a while to get there, given that SMS doesn't even support bold text, but a good use case to keep in mind. It might be easier to get support in other messaging platforms before SMS (SMS is tied to telecom standards that are slow to evolve).
> 
> By SMS, I mean, to use only its sequence of characters and to display it in a specific SMS Messenger. I agree with you that telecom standarts are slow to evolve that's why we need a specific messenger. 
> 
>> The status of JavaFX is a bit murky, but OpenJDK might be a way to contribute. I also note that the issue above has 0 votes. Furthermore, the issue seems to be with the MathML support in the host browsers, so really, until the host browsers (Chrome, Safari, IE) support MathML natively, the chances of seeing a fix for this bug are low.
> 
> I wrote "JavaFX", but in fact, I mean "OpenJFX" its open source version. OpenJFX includes a web browser "WebView" built over webkit that's why it supports MathML. 
> (https://docs.oracle.com/javase/9/docs/api/index.html?overview-summary.html) 
> But I don't understand why with the same webkit version, it works well on Safari and not on OpenJFX. As suggested by team OpenJFX leader, (http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-December/021113.html) I tried to see where is the problem, but it's not pure Java and build OpenJFX is a bit difficult than build OpenJDK. 
> 
>> - is the height of the container that needs to be surround by the fence, within certain margins? 
>> - if so, use a single glyph representing the fence: U+007d "{" 
>> - if the height is above those bounds, create a "stacked" fenced, by putting a glyph at the top U+23a7 "⎧", a glyph at the bottom U+23a9 "⎩", a glyph in the middle U+23a8 "⎨" and for the rest of it, a "repeating" glyph, U+23aa "⎪" (and so on for all the different types of fences)
> Before choosing a way to proceed, I tried to understand how TeX works. There is several prebuilt sizes of each fence (3 ou 4). TeX first tries to use these sizes and if it needs hiegher, TeX builts the "stacked" fenced as you discribed. But what about italic and other orientations ! ?
> So,I wonder why nobody tried to sent a simple font file with the right sized glyph draw to the glyph engine (Harfbuzz or other) as TeX but for each sizes and not only for the first four.
> I think that drawing a bracket as a curve is simpliest and economics than the algorithm that puts glyphs over other glyphs.
> That's the way I choose to proceed, I directly draw "{", "(" and "[". The inconvenience, is that I have to create them by hand and then to draw them but without use the glyph engine (a bit complicate for me because I don't know how to built a font file). Fortunately Java can draw it easily. The advantage, I have got symetric, italic and horizontal glyphs too, with the same curve.
> Best regards. 
> Guy.

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


> Le 2018-01-25 20:32, Abossolo Foh Guy a écrit :
> 
> Hi !
> 
> I try to follow your discussions. I wanted to post a small commentary to try to progress. I hope not to disturb this exchange thread.
> 
> The mathematic notation on web and others support like mails ou sms are the user adoption. I'm a teacher and my dream is to exchange mathematic SMS with collegues or students.
> 
> On my authoring tool that I try to developp, I realised that I need three interfaces :
> - An user interface : "Write As You Speak or Heard", "3 times 12" in english, "3 fois 12" in french, ... . I think this is the only way to be fast adoped.
> - An internal interface to display or save formula : MathML presentation markup or Latex.
> - And finaly an other internal interface to exchange formula with other applications : MathML content markup.
> 
> Common Users don't have to deal with complex Markup and we need them to generalise mathematic on web : JavaFX support MathML but the display has been broken since 7 ans. The developpment team answer me that it not a priority bug !
> 
> https://bugs.openjdk.java.net/browse/JDK-8147476
> 
> I have a dream, I hope that one day, many angry user mails will change this :-)
> 
> Displaying streching characters is also a problem. I found that Java/Swing solution was interresting. In some configurations it's allow to mixed glyphs from fonts and user glyph drawing. In fact all glyphs are curves, we can use a specific application (like Harfbuzz) to draw it or draw "by hand" for complexe glyph. I don't understand why nobody achieved to extend Donald Knuth approch with TextFont. As you discribe it, most of rendering mathematic application use different font sizes first and many glyphs for higher characters (exactly as Knuth several years ago). But computers speed is faster than in the past and we should be able to draw directly stretching glyphs.
> 
> Guy.

 

Links:
------
[1] https://github.com/javafxports/openjdk-jfx/issues/71
[2] https://github.com/scientificware/openjdk-jfx/issues/26
[3] https://play.google.com/store/apps/details?id=com.fxmessages
[4] http://www.gluonhq.com
[5] https://github.com/javafxports/openjdk-jfx/issues/228

RE: [MathML 4] Add rules to map from non-combining to combining accents

Source: www-math@w3.org Mail Archives • Murray Sargent (murrays@exchange.microsoft.com) • November 06, 2018 • Permalink

Probably splitting it into two proposals makes sense. One problem with adding new characters is that older systems will display boxes, but oh well!

Thanks,
Murray

-----Original Message-----
From: Will Robertson <wspr81@gmail.com> 
Sent: Monday, November 5, 2018 5:54 PM
To: Murray Sargent <murrays@exchange.microsoft.com>
Cc: David Carlisle <davidc@nag.co.uk>; William F Hammond <hammond@csc.albany.edu>; www-math@w3.org
Subject: Re: [MathML 4] Add rules to map from non-combining to combining accents

Hi Murray,

> On 6 Nov 2018, at 12:17 pm, Murray Sargent <murrays@exchange.microsoft.com> wrote:
> 
> Lower-case sans Greek is one alphabet in LaTeX and there're also two kinds of script (fancy and calligraphic). We've talked about encoding these, but kind of stalled. My post https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblogs.msdn.microsoft.com%2Fmurrays%2F2016%2F02%2F05%2Funicode-math-calligraphic-alphabets%2F&amp;data=02%7C01%7Cmurrays%40exchange.microsoft.com%7C41b9fb2e82744fb239bf08d6438ab5e4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636770660374338567&amp;sdata=TsWS5eHkKCmGMpNBRbFbPmF0B7q3QOhw6wAe9l0I%2F2k%3D&amp;reserved=0 discusses these possible additions in a little more detail.

Thanks for circulating, that brings back some of the discussions to mind. My recollection was that trying to sort out the script/cal problem really put the brakes on things (as there are numerous technological problems or differences in opinion, such as the fact that the TeX engines don’t handle variant selectors in mathematics or that different fonts have assumed different “defaults"), whereas for the sans Greek proposal there hasn’t been much objection except that it’s not that common (and your example there of chemical formulae is a good one that I hadn’t thought of).

Could it work to split the proposal into two, one for script/cal and one for sans greek? 

Regards,
Will


Re: [MathML 4] Add rules to map from non-combining to combining accents

Source: www-math@w3.org Mail Archives • Will Robertson (wspr81@gmail.com) • November 06, 2018 • Permalink

Hi Murray,

> On 6 Nov 2018, at 12:17 pm, Murray Sargent <murrays@exchange.microsoft.com> wrote:
> 
> Lower-case sans Greek is one alphabet in LaTeX and there're also two kinds of script (fancy and calligraphic). We've talked about encoding these, but kind of stalled. My post https://blogs.msdn.microsoft.com/murrays/2016/02/05/unicode-math-calligraphic-alphabets/ discusses these possible additions in a little more detail.

Thanks for circulating, that brings back some of the discussions to mind. My recollection was that trying to sort out the script/cal problem really put the brakes on things (as there are numerous technological problems or differences in opinion, such as the fact that the TeX engines don’t handle variant selectors in mathematics or that different fonts have assumed different “defaults"), whereas for the sans Greek proposal there hasn’t been much objection except that it’s not that common (and your example there of chemical formulae is a good one that I hadn’t thought of).

Could it work to split the proposal into two, one for script/cal and one for sans greek? 

Regards,
Will

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