- From: Frédéric Wang <fwang@igalia.com>
- Date: Wed, 24 Jun 2020 09:54:37 +0200
- To: public-mathml4@w3.org
- Message-ID: <babf8fd4-0f04-9e93-e3e7-7e07c227945f@igalia.com>
Hi Murray,
Although it's a different use case (and less obvious for the users than
sizes of prescripted glyphs), I think the logic is the same: depending
on scriptlevel, use the proper glyph variant provided by ssty.
I checked this morning and Cambria Math, STIX Two and Latin Modern Math
provides ssty glyph substitution for prime.
(not that this different from character-level change mentioned for U+002D)
Issue:
https://github.com/mathml-refresh/mathml/issues/19#issuecomment-648633028
On 23/06/2020 01:14, Murray Sargent wrote:
>
> Note that ‘ssty’ is also used to get glyph variants for script and
> script-script sub/superscript levels. Heavier characters are used so
> that when they are scaled down to 70% or 60% of base height, they
> still have similar stem widths. This greatly enhances the typographic
> quality of math text containing superscripts and subscripts. I highly
> recommend that Chromium support this use of ssty. The code isn’t
> complicated.
>
> Here’s an example of nested superscripts that uses this feature
>
>
>
>
>
> This is also an example of where variable fonts could be useful in the
> future.
>
>
>
> Thanks,
>
> Murray
>
>
>
> *From: *Neil Soiffer <mailto:soiffer@alum.mit.edu>
> *Sent: *Monday, June 22, 2020 1:01 PM
> *To: *public-mathml4@w3.org <mailto:public-mathml4@w3.org>
> *Subject: *[EXTERNAL] Minutes: MathML Core Meeting 22, June 2020
>
>
>
> Big thanks to Brian Kardel for copious minutes!
>
>
>
> Attendees:
>
> * David Carlisle
> * Neil Soiffer
> * Brian Kardell
> * Murray Sargent
> * Rob Buis
> * Bruce Miller
> * Louis Maher
> * Patrick Ion
> * Frédéric Wang
>
>
>
> Agenda:
> https://github.com/mathml-refresh/mathml/issues/8#issuecomment-644531714
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmathml-refresh%2Fmathml%2Fissues%2F8%23issuecomment-644531714&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861198687&sdata=QmRjk%2FxwcmbHVVcSolPzoew4MZgLyjN0ZORVS4ZBQ38%3D&reserved=0>
>
>
>
> The meeting was recorded:
> https://benetech.zoom.us/rec/share/9Z0vMY_g-FhLXc_QuUXDe5EAJJXuaaa8gHQfrPUPyUytdQadzc1YBw4BFIhA_CJs
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbenetech.zoom.us%2Frec%2Fshare%2F9Z0vMY_g-FhLXc_QuUXDe5EAJJXuaaa8gHQfrPUPyUytdQadzc1YBw4BFIhA_CJs&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861198687&sdata=MLMZoz0YFvQSeeDWenMjBdCnukuqozkeCs6cZql6YXI%3D&reserved=0>(Access
> Password: 8K+0u#5+)
>
>
>
>
> More OpenType things:
>
> * The "math" script tag#223
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmathml-refresh%2Fmathml%2Fissues%2F223&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861208683&sdata=JmMMJZdi%2F7NBuBT2LVbJhhfGuiS4e6dsUJfkvvtd98s%3D&reserved=0>[about
> <mtext>]
> This seemed only needed for rtlm and ssty => move to level-2?
>
> o FW: any element that uses mtext layout - basically all token
> elements except mspace. Based on our changes last week I was
> updating the spec text and now that we removed rtlm/ssty I
> don't think this is necessary anymore.
> o NS: The spec says mtext
> o FW: But it is supposed to be for all token elements really,
> but we want to remove that.
> o MS: I call them “cutins”; placement of superscripts relative
> to bases? In other words, it's a kerning concept…
> o FW: If you check the math table spec, you have this tag at
> the end…
> https://docs.microsoft.com/en-us/typography/opentype/spec/math#opentype-layout-tags-used-with-the-math-table
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftypography%2Fopentype%2Fspec%2Fmath%23opentype-layout-tags-used-with-the-math-table&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861208683&sdata=k87T3y8emVSzGS%2BST8Gu9IlJs39zqjXY2BWlf7zOxdU%3D&reserved=0>
> o NS: (reads relevant spec text about the script tag)
> o MS: I will look to see how this is used in our code
> o NS: If this got pushed to level 2, what difference does this make?
> o FW: As I say, I'm not really sure - but as I understand there
> is this script tag, so in the case of this it is like a
> specific language for math that allows ssty and all of this..
> I think if we drop ssty there is no use
> o MS: if you are not doing right to left math it seems it
> doesn't matter. Ssty is the wrong way to do that really,
> should do that all of that upfront before you get to the
> layout engine
> o FW: So my question is just making sure that this is really
> only about ssty etc - because if so, we should remove it.
> o MS: It is only in our code for right to left math
> o NS: We pushed right to left off to level 2
> o MS: Although, I really want to get all of that working everywhere
> o FW: We all do, but keeping this bit of text that does nothing
> in core level one seems confusing, we should remove it if that
> is the case
> o MS: I think it is very reasonable to push that one out
> o NS: Resolved...
>
>
>
>
> * Define fallback for OpenType MATH parameters
> https://mathml-refresh.github.io/mathml-core/#layout-constants-mathconstants
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmathml-refresh.github.io%2Fmathml-core%2F%23layout-constants-mathconstants&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861208683&sdata=uI%2FMNow9DzxxXSMwRQXgNE23kTmW3kXVcoAsGbLOcCQ%3D&reserved=0>It
> does not seem something fundamental and hard to test and it's not
> clear whether complex fallback is acceptable.
> Keep the current text and remove the ISSUE label?
>
> o FW: I have just added some fallbacks, I don't know that they
> are all great, but I don’t know what you want to do here.
> o NS/MS: We are good with pushing this off to level 2. Any
> objections/other thoughts?
> o NS: Resolved
>
>
>
>
> * MathKernInfo / MathTopAccentAttachment
> Put at risk and remove ISSUE label?
> https://mathml-refresh.github.io/mathml-core/#glyph-information-mathglyphinfo
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmathml-refresh.github.io%2Fmathml-core%2F%23glyph-information-mathglyphinfo&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861218676&sdata=667occspSmiTLLtjVEFsfmffbZMXzjA7yms0l0DREmY%3D&reserved=0>
>
> o FW: This is, I think an extension - it is kerning/subkerning.
> MS can speak better
> o NS: I think integrals
> o FW: No for those we use italic correction
> o MS: It's important for good typography. I call these cutins,
> it allows you to kern in a super/subscript into the base in a
> way that looks good. Say you had a capital V and you put a
> subscript 2, the bottom of the V is narrow, so you want to
> pull the 2 in a little bit.
> o FW: You said italic correction is not specific to the glyph,
> but in core it is
> o MS: It doesn't depend on pairs of glyphs
> o FW: It is more generic
> o NS: Let's break this discussion apart: MathKernInfo and
> MathTopAccentAttachment. If I type sin, I assume that is when
> kerning would be used to make it look good
> o FW: I think this is different - I think this is about having a
> base and attaching glyphs. It's horizontal positioning of the
> scripts, but it is depending on the vertical position. You
> have a table that gives a mapping of how much to apply
> o MS: Each character has 4 corners, tlbr - you have a certain
> amount you can move in on all corners. In TeX what you have to
> do is different, I think this came up and we made it automatic
> based on discussions with Knuth - he would have done it if he
> could but because it can't break, he never went back to do it.
> o NS: Seems like a problem. Suppose level 2 supports it - it's
> not like "here are some new features we can use". It is like
> "the rendering just changed" and nothing changed in my
> document. It's sort of like CSS adding some features and it
> just starts rendering differently. Is this a problem?
> o DC: Even happens in TeX. Fonts change and the rendering
> changes… you can't say it is pixel identical in 50 years.
> o FW: I was wondering if you know if STIX has this table, last I
> checked latin modern math didn't and maybe only cambria has it.
> o BK: Would WPT tests break?
> o FW: No
> o BK: Then I think it is probably ok, because the font analogy
> seems pretty good to me
> o FW: So, if we want to support this feature we will have to
> write some tests with some fonts that actually support this.
> This is why I say it is kind of difficult to support,
> supporting the tests itself is involved.
> o NS: I thought though that a goal of core was for rendering to
> be the same
> o FW: Well, they will be the same on this in FF/Safari and we
> will get there - just can't achieve it all at once.
> o MS: I think this is ok, if you shoot for the moon it's easy to
> miss
> o NS: DC’s argument makes some sense, although it still seems
> problematic. However, I agree - we can move this out. Let's
> go to MathTopAccentAttachment
> o FW: Ok this is about how you position the glyph horizontally,
> and we had a number of other issues with accents, I don't
> think we can fix them all in L1. I think for at least large
> operators or mrow layout we use italic correction, but for
> scripts in general we don't (except for integral). So I guess
> the question is that the spec is ahead of implementation in a
> way that we probably can't get it all, so we need to decide
> how much we want to leave in that won't be achieved the same.
> o NS: So what is the proposal for the spec
> o FW: I don't really have one - I am just pointing out that
> there are some things in the spec that are not in our plan and
> we probably can't get done at once. I'm wondering what we
> want to do with that. We don't have tests for it, there's a
> lot to do there.
> o NS: It sounds like there are a number of changes to the spec
> that are necessary if we punt on this?
> o FW: Yes, but it is removing text which is far easier than
> making tests and choices and implementations and so on…
> o NS: What do other people think?
> o MS: I have to agree that some of these are really hard to do
> well, I can appreciate that. <shows examples>
> o
> o Example of cut-ins (math kerning)
> o MS:: So, you can see that accents, for example, are tricky.
> o FW: Firefox doesn’t do a good job now.
> o NS: Does TeX use different characters for a hat depending on
> the character beneath it?
> o DC: Not counting \widehat, LuaTex can do this, but not by
> default.
> o FW: I guess we can keep the spec text for now and see if it is
> an issue and come back and decide. We want to do italic
> correction for scripts, that is really similar.
> o NS: My proposal is that if you can't do the really fancy
> stuff, at least do italic correction. The placement over an
> “f” will look terrible otherwise.
> o FW: I don’t know if this is going to get perfect things, I was
> suggesting that the logic is very similar maybe we can do a
> little more to get it done -- as I say, we would still need to
> do more work and more tests and so on, so I can't promise, but
> we can try and we can come back to it.
> o NS: Resolved we can wait and look at where implementations are
> in a bit and come back to this one, but not push to L2 yet -
> mark it as at-risk
>
>
> * Variable fonts
> Does not seem something under our control, but something to
> standardize at OpenType first and to be used by math font creator
> first.#135
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmathml-refresh%2Fmathml%2Fissues%2F135&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861218676&sdata=vDfjjF6rqulHMyYWg4cO1G5SsM6wHBkBlIUpYaP0b58%3D&reserved=0>
> Remove label?
>
> o NS: I dont think there are any out there that I know of for
> Math fonts - are there?
> o FW: they are gaining popularity and they are good because you
> have abilities for things like stretchy operators - you have
> just one glyph and you can in theory give parameters. But
> what in math you want to do is give a target size, which is
> kind of the opposite of variable fonts. I'm not sure what we
> do with that.
> o NS: I think this is easy because there isn't much you can do
> right now anyway.
> o MS: I think it is a very cool tech and it is something that
> will get into math font tech at some point - we've been
> talking about it… But as a practical matter, nothing has
> happened yet and your comments are valid, and there are other
> things too. So, an exciting thing for the future, but not
> relevant in the present.
> o NS: Ok resolved not L1
>
>
>
>
> Follow-ons from last week's meeting
>
> * href (#125
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmathml-refresh%2Fmathml%2Fissues%2F125&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861228670&sdata=f7uiIBBCRpJCILJ%2F2VrUgwBr9laEudjnkAWNlkqbf7c%3D&reserved=0>)
> [TAG feedback?]
> * BK: NS and I both left comments, I had some discussion as well,
> but it is waiting for their next breakout -- it is tagged for this
> week, but they have a long list, so we'll see.
>
>
>
> * Character substitution ('-', primes, etc)#146
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmathml-refresh%2Fmathml%2Fissues%2F146&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861228670&sdata=x5f4G2kZwfYs3bKQo%2BjH7NgdAN7Z2GbaWHPpaUezRTE%3D&reserved=0>
>
> Skipping for now
>
>
>
>
> 3.1 Visual formatting model
>
> * Issue#18
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmathml-refresh%2Fmathml%2Fissues%2F18&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861238664&sdata=tNAERp1wWLRav5vkCSRR0RQWDyZENjtuDtA7tkM1Plo%3D&reserved=0>
> Should a future version of this specification support vertical
> writing mode?
> * FW: I think we previously agreed that we won’t do this.
> * NS: We didn’t find much use for it.
> * FW: Could be that there isn’t software to do it.
> * NS: Resolved: put this off to level 2
>
>
>
> * Issue#112
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmathml-refresh%2Fmathml%2Fissues%2F112&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861238664&sdata=byBrDH7y3GtwBQylOXG%2BYrkdXkxpcHm3iH0s4JqonRM%3D&reserved=0>Should
> future a version of this specification support line breaking?
>
> FW: I think we had agreed to postpone this already
>
> NS: Right, but I had a request - I want to generate a polyfill, and I
> have currently no way to do that… Is there a way that I can keep it
> mathml and not just turn it into a table or something?
>
> FW: Inline or display linebreaking
>
> NS: display, I am thinking. From what I have thought about so far, if
> core supported one value on the mo which would be linebreak=”newline”.
> Basically support a forced break and start a new line.
>
> FW: I think mathml 3 had a way…
>
> NS: Right, so if that got supported I could polyfill a forced
> linebreak/indent
>
> FW: I'm not sure what the advantage…
>
> NS: well, it's far less destructive to the code than to turn it into
> something completely different.
>
> FW: This means you need tests for both things, it adds a lot. If you
> have 2 lines, you have to decide which baseline you align with on the
> next line
>
> NS: I would say it aligns to the first baseline
>
> FW: Right, but you remember during this whole year we have been having
> discussions that seem simple but the more you dig into them they get
> very complicated - I am not really confident that this is not a really
> long chain of discussions and questions. I think the way google would
> like to handle this with Houdini…
>
> NS: My thinking was the more we polyfill, the more we are showing and
> figuring out what it is we need to do.
>
> BM: A forced line break is a first step component to automatic
> linebreaking. I've done a lot of experiments here myself, but like you
> say you don't have the right tools to experiment without really
> destroying the tree.
>
> NS: It’s been a complaint for years about Firefox’s rendering.
>
> FW: There are a lot of complications with interactions with CSS. It is
> too much to think about now.
>
>
>
> Meeting next week.
>
>
>
--
Frédéric Wang
Received on Wednesday, 24 June 2020 07:55:09 UTC