Closed Bug 44201 Opened 24 years ago Closed 14 years ago

scriptsizemultiplier attribute not handled

Categories

(Core :: MathML, defect, P3)

x86
Linux
defect

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
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.
QA Contact: ian → mathml
Blocks: mathml-2
This was fixed by http://hg.mozilla.org/mozilla-central/rev/76075fc0b519
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla1.9.3a5
You need to log in before you can comment on or make changes to this bug.