Closed Bug 65951 Opened 21 years ago Closed 7 months ago
Style sensitive Unicode should not be restylable
36.29 KB, image/gif
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
Reassign to erik, cc to firstname.lastname@example.org.
Assignee: nhotta → erik
This seems more like a MathML issue than a font one. Reassigning to Roger.
Assignee: erik → rbs
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.
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.
Adding qawanted keyword
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Style sensitive Unicode should not be restylable → [RFE] Style sensitive Unicode should not be restylable
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.
See bug 68841 comment 52 for ideas about how tor tackle this bug in a more general manner.
Summary: [RFE] Style sensitive Unicode should not be restylable → Style sensitive Unicode should not be restylable
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
I agree that this sounds like a font selection issue.
Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.