Re: [math-on-web] CG meeting minutes, 2018/01/18

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

​Thank you for participating!​



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

​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).



> 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.
>
​Yes, I think that makes sense and potentially goes to show that different
representations are useful for different purposes.​


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
>
​In open source projects, "not a priority" often means "nobody volunteered
to do the work that would be required".​ 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 have a dream, I hope that one day, many angry user mails will change this
> :-)
>
​In my experience, angry emails directed at open source project
contributors rarely result in forward motion. I would suggest some
alternatives: propose a new spec, or a modification to an existing spec,
contribute by giving input and feedback on existing proposals that have
been put forward, contribute code implementing the proposed spec, or
contribute test cases.

One thing to consider: the more complicated a spec is to implement, the
less likely it is to be implemented. Every contributor to a project has to
make am evaluation of the benefit vs. the cost of investing time and
resources in implementing something. Math is unfortunately something with a
relatively small audience (compare to say, text or images). Therefore, any
proposal that is high in cost, but only serve the relatively narrow use
case of math, will have difficulty in getting traction. I'm afraid that
this is where we are with MathML adoption in browsers. I would suggest, and
I think there might be consensus in this group, that we would be better
served by proposing enhancements/improvements to existing standards that
would both be easier to implement, and that would also serve broader use
cases. Stretched fences being a good example of 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.
>
​I think you mean MetaFont? In fact, existing standards do have the same
support than MetaFont does. In fact, they were "inspired" by what MetaFont
had pioneered. ​

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.
>
​I don't believe that the support for stretchable fences require support in
fonts or font standards. Fonts, and the standards related to drawing the
glyphs they contain, only concern themselves with relatively simple
(compared to what's require for math typography) composition of glyphs. In
particular, for a stretched fence, for a multi-row matrix for example, you
need to be able to specify a precise height that the fence should have,
that is, the height of the container of the matrix "data". You can't really
do that with a font, or with a font API. Instead, you need to do some
higher level composition, which is more akin to layout. Note that this is
what TeX does. MetaFont does not have facilities to "draw" a stretched
fence. Instead, there is logic in TeX that goes something like this:
- 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)


​I believe that all those operations should be performed by the HTML text
engine of the web browsers, via a CSS extension that would probably be
similar to the quote attribute. I should probably follow my own advice and
write a proposal about this :)

Best,
Arno.
​




> ------------------------------------------------------------
> ---------------------------------
>
> Le 2018-01-25 18:54, Peter Krautzberger a écrit :
>
> Hi everyone,
>
> The minutes are blow.
>
> The next meeting will be on Feb 1 and we will focus on kick-starting the
> task forces for 2018.
>
> Best,
> Peter.
>
> # MathOnWeb CG 2018-01-18
>
> * Volker: didn't write a comment; it would have been "let's not re-hash
> the same old discussions every week"
> * Dani: I think F2F will be best to sort some things out
> * Peter:
>   * review call for comments
>   * plan potential task forces for 2018
> * Neil: font improvements are interesting. Anyone interested?
>   * Volker:
>   * Arno: only have one font b/c I can't get access to metrics of fonts
>     * interesting beyond equations
>     * reference for other work?
>     * Peter: https://discourse.wicg.io/t/font-metrics-api/2417
>   * Neil: is Houdini alive?
>     * Peter: yes. Look up Tab Atkins
> * Dani: for equation display, I see two approaches
>   * 1) no JS. I.e., HTML+CSS
>   * 2) with JS. Then have to compute metrics
>   * Neil: right. metrics means client-Side JS
>     * Peter: though Houdini sits in between as it uses JS for new CSS,
> claims its path towards new CSS features
>   * Arno: editing obviously needs JS
>     * Think we need both and they might differ
>   *  Dani: agreed. It's just that it requires different task forces
>     * Peter: agreed, while I wished it wasn't the case
>       * ideally, client and server-side rendering would be identical
>   * Peter: @Dani so propose two task forces for client / server rendering?
>     * Dani: yes but I personally more on server-side
> * Peter: is there interest in purely client-side rendering (web
> components, Houdini)?
>   * Neil: I'd be interested but have no plans
>   * Peter: you might want to talk to the developer of fmath
> * Neil: promise to write a comment
> * Volker: interested in ARIA spec for navigation
>   * Dani: I'd be interested in that
> * Dani: if we can come up with a unified vision for mathematics, then we
> can try to bring that to TPAC for feedback
>   * Dani: we come across as divided
> * Neil: it would be good to take one piece of CSS and try to get wider
> support from web devs
>   * Peter: makes sense; it's what I've been trying to do and continue
> * Neil: stretchy characters might be another
>   * Peter: anyone interested?
> * Neil: strike-through might be another
>   * Arno: interested
> * Arno: my email had two CSS definitions
>   * stretchy
>   * menclose-like notations (crossing out etc)
> * Dani: I think we need to document how people are doing things right now
>   * ACTION: Peter should start with collecting that
> * Peter: should we set up two meetings, both bi-weekly?
>   * ACTION send out test doodles
> * ACTION:
>   * @Everyone start your task forces
>   * @task forces: start gathering existing techniques
>   * @Arno write email about ideas for common abstract format needs
>
>
>
>