- From: Neil Soiffer <soiffer@alum.mit.edu>
- Date: Mon, 22 Jun 2020 13:00:45 -0700
- To: public-mathml4@w3.org
- Message-ID: <CAESRWkB=mw17VULVsM_QriycYGdkU1N2BXrpOTK9=Gt2DNCqXw@mail.gmail.com>
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
The meeting was recorded:
https://benetech.zoom.us/rec/share/9Z0vMY_g-FhLXc_QuUXDe5EAJJXuaaa8gHQfrPUPyUytdQadzc1YBw4BFIhA_CJs
(Access Password: 8K+0u#5+)
More OpenType things:
-
The "math" script tag #223
<https://github.com/mathml-refresh/mathml/issues/223> [about <mtext>]
This seemed only needed for rtlm and ssty => move to level-2?
-
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.
-
NS: The spec says mtext
-
FW: But it is supposed to be for all token elements really, but we
want to remove that.
-
MS: I call them “cutins”; placement of superscripts relative to
bases? In other words, it's a kerning concept…
-
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
-
NS: (reads relevant spec text about the script tag)
-
MS: I will look to see how this is used in our code
-
NS: If this got pushed to level 2, what difference does this make?
-
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
-
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
-
FW: So my question is just making sure that this is really only about
ssty etc - because if so, we should remove it.
-
MS: It is only in our code for right to left math
-
NS: We pushed right to left off to level 2
-
MS: Although, I really want to get all of that working everywhere
-
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
-
MS: I think it is very reasonable to push that one out
-
NS: Resolved...
-
Define fallback for OpenType MATH parameters
https://mathml-refresh.github.io/mathml-core/#layout-constants-mathconstants
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?
-
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.
-
NS/MS: We are good with pushing this off to level 2. Any
objections/other thoughts?
-
NS: Resolved
-
MathKernInfo / MathTopAccentAttachment
Put at risk and remove ISSUE label?
https://mathml-refresh.github.io/mathml-core/#glyph-information-mathglyphinfo
-
FW: This is, I think an extension - it is kerning/subkerning. MS can
speak better
-
NS: I think integrals
-
FW: No for those we use italic correction
-
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.
-
FW: You said italic correction is not specific to the glyph, but in
core it is
-
MS: It doesn't depend on pairs of glyphs
-
FW: It is more generic
-
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
-
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
-
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.
-
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?
-
DC: Even happens in TeX. Fonts change and the rendering changes… you
can't say it is pixel identical in 50 years.
-
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.
-
BK: Would WPT tests break?
-
FW: No
-
BK: Then I think it is probably ok, because the font analogy seems
pretty good to me
-
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.
-
NS: I thought though that a goal of core was for rendering to be the
same
-
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.
-
MS: I think this is ok, if you shoot for the moon it's easy to miss
-
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
-
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.
-
NS: So what is the proposal for the spec
-
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.
-
NS: It sounds like there are a number of changes to the spec that are
necessary if we punt on this?
-
FW: Yes, but it is removing text which is far easier than making
tests and choices and implementations and so on…
-
NS: What do other people think?
-
MS: I have to agree that some of these are really hard to do well, I
can appreciate that. <shows examples>
-
-
Example of cut-ins (math kerning)
-
MS:: So, you can see that accents, for example, are tricky.
-
FW: Firefox doesn’t do a good job now.
-
NS: Does TeX use different characters for a hat depending on the
character beneath it?
-
DC: Not counting \widehat, LuaTex can do this, but not by default.
-
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.
-
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.
-
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.
-
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://github.com/mathml-refresh/mathml/issues/135> Remove label?
-
NS: I dont think there are any out there that I know of for Math
fonts - are there?
-
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.
-
NS: I think this is easy because there isn't much you can do right
now anyway.
-
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.
-
NS: Ok resolved not L1
Follow-ons from last week's meeting
-
href (#125 <https://github.com/mathml-refresh/mathml/issues/125>) [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://github.com/mathml-refresh/mathml/issues/146>
Skipping for now
3.1 Visual formatting model
-
Issue #18 <https://github.com/mathml-refresh/mathml/issues/18> 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://github.com/mathml-refresh/mathml/issues/112> 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.
Received on Monday, 22 June 2020 20:01:11 UTC