w3c/mathml

Intent for distinguishing uses of spaces

NSoiffer opened this issue · 4 comments

We have tentatively agreed to add a concept name blank to cover the case of "fill in the blank". I'm struggling with heuristics for MathCAT to distinguish an intentional space from a tweaking space. In speech, the difference is not important, but in many braille codes, spacing should be reflected in the braille. The decision to include a space is rather subjective because people introduce spacing for typographical reasons (i.e., to make something look better) vs spaces introduced to make something more obvious (e.g., spaces before/after parens to make the contents standout).

So three uses of spaces: blanks, typographical tweaks, visual spacing. I think we need to add at least one more concept to distinguish the uses. Adding two more I think is best. I can see generalizing the tweak case to a concept intent='ignore' that might apply to other cases.

Thoughts?

dginev commented

We probably don't need intent='ignore' given that we have intent='_'.

This reminds me: I was wondering if the empty literal should or shouldn't be usable for denoting longer and briefer pauses in speech.

Compare:

possible use markup
silence intent="_"
maybe brief pause? intent="_(_)"
maybe medium pause? intent="_(_,_)"
maybe long pause? intent="_(_,_,_)"

The literal spaces could be "speech pause tweaks" that in a way mirror the need for inked typographic "spacing tweaks".

As to Braille, the spec currently states:

In terms of accessibility, the major difference is that intent does not affect braille generation.

Is that still the case? I think it makes a difference whether we are considering only speech pauses, only Braille space codes, or both.

It feels more like a property to me, especially if used on mspace rather than a token element with a space character

<mspace width="1em" intent=":typographic"/> ?

Not speaking something doesn't necessarily translate into ignoring it for braille. So I my feeling that using intent='_' to mean two potentially different things is not great.

As to Braille, the spec currently states:

In terms of accessibility, the major difference is that intent does not affect braille generation.

Is that still the case? I think it makes a difference whether we are considering only speech pauses, only Braille space codes, or both.

My feelings have changed some as I've done more braille implementations. In general, intent isn't useful in braille because braille doesn't follow speech, it mostly follows the syntax. But that's not 100% the case. In Nemeth code, "ratio" is called out. "blanks" vs spaces need to be distinguish is most (all?) codes. Chemistry requires a slight tweak to the rules in UEB that deal with capitalization. The Spanish/Portuguese code says that if a decimal number represents a logarithm, then it is brailled differently: the characteristic and mantissa have a special coding -- weird to me but that's the standard and it's not something that MathCAT can even guess at. So intent would be useful for those cases and a few other special braille cases.

On the other hand, (so far) all the braille codes add spaces before and after comparison (relational) operators and arrows. This sort of mimics typography. Potentially one could say we should have a property for that, but I don't think that's necessary because it is possible to list out all the comparison operators. Of course (as I'm sure Deyan will point), people will use some comparison operator in a way that isn't actually a comparison and vice-versa. I don't think the braille standards are advanced enough to say what should be done in those situations. They just show some examples of comparison operators and with the exception of Nemeth code, very minimal in their examples.

Functions are another area where there are some special cases. However, well marked up code with use &#x2061;, so those cases can be detected. The same goes for speech.

closing as blank concept added to core