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.
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.
========================================= 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
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
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.
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
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
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
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&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7C41b9fb2e82744fb239bf08d6438ab5e4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636770660374338567&sdata=TsWS5eHkKCmGMpNBRbFbPmF0B7q3QOhw6wAe9l0I%2F2k%3D&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
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
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, Murray -----Original Message----- From: Will Robertson <wspr81@gmail.com> Sent: Monday, November 5, 2018 5:22 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 On 6 Nov 2018, at 11:39 am, Murray Sargent <murrays@exchange.microsoft.com> wrote: > > 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 ☹. Ah well, it’s nice to know you tried! The sanity of that decision puzzled me at first. From an interface perspective a more pressing problem to me is the omission of lowercase sans Greek (when bold lowercase sans Greek does exist). We were discussing putting this to the Unicode Consortium to add at some point but I think the discussions were stalled around collecting evidence that lowercase sans Greek was actually used in extant mathematics. I went looking a while back but It wasn’t an easy thing to search for examples for. From my perspective, LaTeX has always had an interface to access these symbols even if they’re little used, so there’s that. And having bold but not regular case introduces a challenging interface problem for users. I know this is a high-jack of the current discussion but is it worth trying to push this forward again? Regards, Will
On 6 Nov 2018, at 11:39 am, Murray Sargent <murrays@exchange.microsoft.com> wrote: > > 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 ☹. Ah well, it’s nice to know you tried! The sanity of that decision puzzled me at first. From an interface perspective a more pressing problem to me is the omission of lowercase sans Greek (when bold lowercase sans Greek does exist). We were discussing putting this to the Unicode Consortium to add at some point but I think the discussions were stalled around collecting evidence that lowercase sans Greek was actually used in extant mathematics. I went looking a while back but It wasn’t an easy thing to search for examples for. From my perspective, LaTeX has always had an interface to access these symbols even if they’re little used, so there’s that. And having bold but not regular case introduces a challenging interface problem for users. I know this is a high-jack of the current discussion but is it worth trying to push this forward again? Regards, Will
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. 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 ☹. Murray From: David Carlisle <davidc@nag.co.uk> Sent: Monday, November 5, 2018 4:45 PM To: William F Hammond <hammond@csc.albany.edu> Cc: www-math@w3.org Subject: Re: [MathML 4] Add rules to map from non-combining to combining accents 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. 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nag.co.uk%2Fcontent%2Fprivacy-notice&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ca3f5e9e8fd3a48071e0708d643815a3b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636770620179419121&sdata=yyOasjYzMhRjh0KrFB4mcnyyHKoq3kG7siwOTL%2BKcNA%3D&reserved=0> 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.
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. 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.
David Carlisle writes: > On 04/11/2018 17:04, William F Hammond wrote: >> David Carlisle in part: >> >>> Syntax to be determined but something in the style of the existing >>> <surrogate mathvariant="bold" ref="U00041"/> >>> which maps the "holes" in the math alphabet blocks to the equivalent >>> bmp character. >> >> The holes in the math alphabet blocks represent missing *characters* >> in those blocks. There are no equivalent BMP *characters*, so one is >> just borrowing *glyphs* from sporadic BMP characters, each of which arose >> earlier in the history of unicode for one or more special intentions. >> >> -- Bill >> >> > yes I know, I just meant add a similar cross reference element in > unicode.xml, not that the specific details of the characters were the same. > > David Oh, I know that you knew. In fact you knew before I knew. I just want to make sure that everyone here knows. The existence of the holes compromises the Unicode standard. It forces writers of software for processing LaTeX's \mathbb, \mathcal, \mathfrak, and all "casting" facilitators in LaTeX and in other worlds where math is input to write ugly cumbersome code. The holes should be filled in the Unicode standard. I think it would be helpful if your W3C group (does it currently exist?) went on record saying that the holes should be filled. -- Bill
Also, the calendar doesn't list the main CG meeting as this week. Do you need to adjust the calendar or is your email incorrect? Neil On Mon, Nov 5, 2018 at 12:06 AM Peter Krautzberger <peter@krautzource.com> wrote: > Hi everyone, > > A quick reminder that the task forces are meeting today (Nov 5) and there > is a main CG meeting on Thursday (Nov 8). > > The main topics will probably be reports from those of us who attended > TPAC two weeks ago. > > Also, there's now also a calendar embed on the homepage [1] as well as > subscribe links on the wiki [2]. > > Best, > Peter. > > [1] https://w3c.github.io/mathonwebpages/ > [2] https://github.com/w3c/mathonwebpages/wiki >
Hello everyone, Here is the audio recording with transcript<https://benetech.zoom.us/recording/play/bi23LIsy2oaRnPz0lKJ1cRmVfMRnLKpYec7MNZasZvsLDeMtwFmzq6ot0xTKGMW0?continueMode=true> from todays meeting. Oh and Neil there was no [baby crying in the background] audio description :) Thanks everyone. Thanks EOM Charles LaPierre Technical Lead, DIAGRAM and Born Accessible Twitter: @CLaPierreA11Y Skype: charles_lapierre Phone: 650-600-3301 On Nov 5, 2018, at 12:05 AM, Peter Krautzberger <peter@krautzource.com<mailto:peter@krautzource.com>> wrote: Hi everyone, A quick reminder that the task forces are meeting today (Nov 5) and there is a main CG meeting on Thursday (Nov 8). The main topics will probably be reports from those of us who attended TPAC two weeks ago. Also, there's now also a calendar embed on the homepage [1] as well as subscribe links on the wiki [2]. Best, Peter. [1] https://w3c.github.io/mathonwebpages/ [2] https://github.com/w3c/mathonwebpages/wiki
Apologies. I had to go out of the house on short notice. On Mon, 5 Nov 2018, 4:00 pm Neil Soiffer <soiffer@alum.mit.edu wrote: > The calendar event lists a google hangout for the meetings, but (at least) > the accessibility group web page lists zoom. Which is it? > > Neil > > > On Mon, Nov 5, 2018 at 12:06 AM Peter Krautzberger <peter@krautzource.com> > wrote: > >> Hi everyone, >> >> A quick reminder that the task forces are meeting today (Nov 5) and there >> is a main CG meeting on Thursday (Nov 8). >> >> The main topics will probably be reports from those of us who attended >> TPAC two weeks ago. >> >> Also, there's now also a calendar embed on the homepage [1] as well as >> subscribe links on the wiki [2]. >> >> Best, >> Peter. >> >> [1] https://w3c.github.io/mathonwebpages/ >> [2] https://github.com/w3c/mathonwebpages/wiki >> >
The calendar event lists a google hangout for the meetings, but (at least) the accessibility group web page lists zoom. Which is it? Neil On Mon, Nov 5, 2018 at 12:06 AM Peter Krautzberger <peter@krautzource.com> wrote: > Hi everyone, > > A quick reminder that the task forces are meeting today (Nov 5) and there > is a main CG meeting on Thursday (Nov 8). > > The main topics will probably be reports from those of us who attended > TPAC two weeks ago. > > Also, there's now also a calendar embed on the homepage [1] as well as > subscribe links on the wiki [2]. > > Best, > Peter. > > [1] https://w3c.github.io/mathonwebpages/ > [2] https://github.com/w3c/mathonwebpages/wiki >
Hi everyone, A quick reminder that the task forces are meeting today (Nov 5) and there is a main CG meeting on Thursday (Nov 8). The main topics will probably be reports from those of us who attended TPAC two weeks ago. Also, there's now also a calendar embed on the homepage [1] as well as subscribe links on the wiki [2]. Best, Peter. [1] https://w3c.github.io/mathonwebpages/ [2] https://github.com/w3c/mathonwebpages/wiki
On 04/11/2018 20:43, Murray Sargent wrote: > FWIW, RichEdit’s MathML reader uses the following table to translate > from non-combining to combining marks > Murray thanks for that data I'll do another iteration that includes those (possibly not tonight:-) 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.
On 04/11/2018 17:04, William F Hammond wrote: > David Carlisle in part: > >> Syntax to be determined but something in the style of the existing >> <surrogate mathvariant="bold" ref="U00041"/> >> which maps the "holes" in the math alphabet blocks to the equivalent >> bmp character. > > The holes in the math alphabet blocks represent missing *characters* > in those blocks. There are no equivalent BMP *characters*, so one is > just borrowing *glyphs* from sporadic BMP characters, each of which arose > earlier in the history of unicode for one or more special intentions. > > -- Bill > > yes I know, I just meant add a similar cross reference element in unicode.xml, not that the specific details of the characters were the same. 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.
Planet MathML features:
David Carlisle Design Science News FMath Getting Math
onto Web Pages Community Group MathJax Murray Sargent: Math in
Office SF.net - ASCIIMathML SF.net - DocBook to LaTeX
Publishing SF.net - MathCast Equation
Editor SF.net - MathStudio SF.net - Open Math Edit SF.net - PyMathML SF.net - SVGMath SF.net - UniWakka SF.net - jsMath SF.net - jscl-meditor SF.net - pMML2SVG Updates | Frédéric Wang W3C Blog W3C Math Home W3C News WebKit public-digipub-ig@w3.org
Mail Archives public-html-a11y@w3.org
Mail Archives public-html@w3.org Mail
Archives public-mathonwebpages@w3.org
Mail Archives public-webapps@w3.org Mail
Archives www-math@w3.org Mail
Archives www-style@w3.org Mail
ArchivesIf 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.
