65951 - Style sensitive Unicode should not be restylable

Status: RESOLVED FIXED

(Core :: Internationalization, enhancement)

Description

[Sampo Syreeni]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0; Nokia)
BuildID:    2000091312

There are characters in the Unicode standard which are style sensitive variants 
of existing ones. Especially in the new 3.1 version, we have mathematical 
characters which are with most likelihood meant to be rendered pretty much 
exactly with the style (weight, font, variant etc.) they appear in, in their 
base form. In the browser context, this would mean that those characters should 
not be stylable via CSS. E.g. italicizing a bold math character kills its 
semantics. Additionally, some of the math character ranges added in Unicode 3.1 
have holes in them for characters which have been allocated in existing ranges 
(like the blackboard bold capital C to denote complex numbers) which this 
request applies to, as well. There might be others, especially those characters 
noted as originating from mathematical fonts (like the euler function).

The problems caused by this are twofold. First, in presentational MathML, 
should ideally mark normal identifiers and identifiers containing style 
sensitive characters as the same. This means that one would probably assign 
font-style:italic to identifiers. But this italicizes e.g. blackboard bolded 
chars as well. Math typesetting does not permit this and there is CSS construct 
to force the style change to apply only to non-style sensitive characters. 
Neither is there a MathML construct to permit a markup sorta solution. (Which 
would become pretty presentation oriented anyways.)

Second, this is a problem of semantics. Most characters in Unicode are meant to 
be abstract. Dingbats, the new math character ranges and their extensions in 
other ranges are less so. This should be taken into account.

Reproducible: Always

Steps to Reproduce:
1.Ensure your system fonts support mathematical characters, like blackboard 
bold, and that MathML support has been included in your build
2.Go to the page
3.Find a blackboard bold character (capital 'R', 'C' or 'H')

Actual Results:  The characters appear in italics, which should not happen

Expected Results:  The style of these special characters should probably not be 
modifiable via CSS style, in this case the default MathML style for <mi/>'s

Comment 1

[nhottanscp]

Reassign to erik, cc to [e-mail].

Comment 2

[Erik van der Poel]

This seems more like a MathML issue than a font one. Reassigning to Roger.

Comment 3

[Sampo Syreeni]

Actually I think it has little to do with MathML, per se. In my mind these 
characters should be rendered in their nominal form always, quite irregardless 
of whether they are used in MathML or not. As I said, it's a matter of the 
exact style carrying semantics.

Comment 4

[Fabian Guisset]

Can someone from i18n take a look at this or reassign if needed? Or at least
confirm that it is a valid RFE? RFE's as soon as they are valid should not stay
unconfirmed if possible. Thanks.

Comment 5

[Keyser Sose]

Adding qawanted keyword

Comment 6

[Keyser Sose]

Marking NEW.

Comment 7

[rbs]

Attachment: screenshot with a build that has a preliminary fix

Comment 8

[rbs]

I have checked-in a preliminary code to disable styling some of the most 
frequently used double-struck characters inside the <mi>...</mi> tag (see the 
attached screenshot, they are not rendered in italics as other characters). 
Additional characters can be added within the MathFont Property File 
(specifically, in the mathfont.properties file). Since Mozilla doesn't yet 
support plane-1 characters, these are currently mapped to PUA codes, and it is a 
bit messy to list the fraktur characters, calligraphic characters, etc.

Comment 9

[rbs]

See bug 68841 comment 52 for ideas about how tor tackle this bug in a more
general manner.

Comment 10

[David Nesting]

I agree with Sampo in that this shouldn't be a fix "just" for MathML.  If styled
Unicode characters are being used, they're being used for a reason and
additional styling shouldn't be layered on top of that.  This probably needs a
more general solution.

This is discussed at some length in a W3C+Unicode joint document available at
http://www.unicode.org/unicode/reports/tr20/#Markup

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I agree that this sounds like a font selection issue.