Closed
Bug 44201
Opened 24 years ago
Closed 14 years ago
scriptsizemultiplier attribute not handled
Categories
(Core :: MathML, defect, P3)
Tracking
()
RESOLVED
FIXED
mozilla1.9.3a5
People
(Reporter: masmef=bugzilla, Assigned: rbs)
References
()
Details
(Keywords: helpwanted)
Setting the scriptsizemultiplier attribute in <mstyle> elements is ignored. <msup> <mi>x</mi> <mstyle scriptsizemultiplier=".5"><mi>y</mi></mstyle> </msup> is rendered exactly as <msup> <mi>x</mi> <mi>y</mi> <!-- default value for scriptsizemultiplier is .71 --> </msup>
This is a subtle delicacy that wasn't yet implemented. Until now, there was no demand. Accepting.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I have reworked the scriptsizing code so that the size of script elements decrease gradually in a top-down manner, really nice (a la TeX), and the decrease stops at the predfined value of scriptminize="8pt", so that embedded elements don't become unreadably small. The process still relies on a number of hard-coded rules in mathml.css, which are expected in the C++ side. At the frame level, changing the style context when it has been resolved is very hard (and very expensive). Handling user-supplied scriptminsize and scriptsizemultiplier is even harder and expensive. To fix this bug with the current setup (i.e., not hooks in the Style System) would require to setup/apply variable style rules on the fly (other than the default font-size: 71%, 50%, 36%, etc), and to make sure there are only applied to the relevant element.) Futuring this bug, and marking helpwanted. Maybe with a hook in the style system, things could be much simpler.
Keywords: helpwanted
Target Milestone: --- → Future
Comment 3•24 years ago
|
||
For various reasons, I would recommend changing the '8pt' to '8px'. The main reason is that 8 points might map to fewer than 8 pixels, and thus be unreadable, simply depending on the output device's resolution. Should I file a separate bug for that?
OK, if 8pt will cause some other troubles let's change then to 8px. Since it is a departure from the spec, do well to summarize the rationale, so that I can add it as comment in the corresponding code-sections to justify the departure.
I changed to 8px and added this comment... // Ian Hixie says '8px' should be preferred over '8pt', because 8pt might // map to fewer than 8px, and end up unreadable, depending on the output // device's resolution. So we are using 8px as the default scriptminsize here.
Reverting to 8pt, after testing, 8px looks very small... Feel free to open a separate bug to discuss the issue.
dbaron has suggested using max(8pt, 9px); I will see how this other option goes.
Now that there is a browser-wide pref for a user' minimum actual font-size, no need to bother doing the max{8px,8pt} anymore as it will be filtered out anyway.
Updated•15 years ago
|
QA Contact: ian → mathml
Comment 9•14 years ago
|
||
This was fixed by http://hg.mozilla.org/mozilla-central/rev/76075fc0b519
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•14 years ago
|
Target Milestone: Future → mozilla1.9.3a5
You need to log in
before you can comment on or make changes to this bug.
Description
•