Closed Bug 118475 Opened 23 years ago Closed 23 years ago

The eagerness of the stretchy code needs to be controlled


(Core :: MathML, defect)

Not set





(Reporter: rbs, Assigned: rbs)



(3 files)

In its eargerness to find the glyph of best size for each particular situation, 
the stretchy code suffers from the drawback that the document as a whole can be 
less agreable. I will attach a screenshot to better illustrate the problem.
In the above screenshot, the MathML engine has determined that each glyph is
the one with best size in each situation. The problem is that several fonts
come into play, and since these fonts are not designed with the same
characterics, you see what you see.

Possible ways to address the problem:
1. once a character is stretched with a particular font, stick with that font
throughout the entire document
2. parameterize the fonts used during stretching, i.e., stick with a reduced
list, perhaps only one or two fonts
3. parameterize the fonts used for _each_ character

Of these
#1 doesn't look attractive to me (and it might take some precious cycles to
implement right now)

#2 and #3 are already implemented, but the current implementation requires the
user to fiddle with the so-called cryptic MathFont Property Files which do too
many other things that are intimidating.

It might instead be possible to control these particular elements via the pref
system that users are more familiar with, and which can even be exposed via the
UI. However, doing so for #3 is a pain (and it might take some precious cycles
to implement right now). So perhaps, only #2 can be handled via the pref, with
a fallback to wathever is set in the the MathFont Property files.
Attachment #63751 - Attachment description: example from the GNU Scientific Libary manpage → example from the GNU Scientific Library manpage
Summary: The eargerness of the stretchy code need to be controlled → The eargerness of the stretchy code needs to be controlled
Of the two renderings, the one that uses TeX fonts is definitely more pleasant 
to the eyes. Unfortunately, the Mathematica fonts have many glyphs that are not 
in TeX fonts (see So #3 
is probably the most desirable option since it would allow TeX fonts to be used 
as default fonts while other characters could be stretched with other fonts. But 
that would require to enlist all these in the MathFont property Files -- since I 
don't fancy the idea of hardcoding particular fonts in the MathML engine.

Ultimately (dreaming here...), it could be so cool to be able to click on a 
stretchy character to get -> Context Menu -> Properties -> Customize 
stretching... and from there provide the user with a GUI to add/update the 
default properties of the character. With this, a gradual customization of the 
list of properties of each individual character could be possible without having 
to fiddle with the MathFont Property Files explicitly. But again, perhaps just 
biting the bullet and enlisting these chars once for all is what is needed since 
it might require as much effort to build such a GUI.
[Hixie & style people, I am not proposing to use the following here since I 
already have a simpler implementation :-) But as I was considering alternative 
ways with which to expose various values via the pref system, I came to the 
thought that it might be possible to have a smooth integration with the style 
system using a nomenclature similar to url("..."). Thus if someone does:

font-family: -moz-pref("aKey", "aDefaultValue");

The Style System could interpret this at parsing time as: fetch the actual 
string to parse from the pref; if it isn't there, fallback to the given default 
string. There are bugs about customizing values that are hardcoded in the CSS 
files throughout the product. Perhaps, something like the above suggestion could 
help, e.g., viewsource.css could be redefined in these terms allowing GUI people 
to provide an interface to customize the viewsource rules. Food for thoughts.]
Filed related bug 118600 - parameterize the font used for stretchy characters at 
their base size.
Checked in a fix for this, and posted the following message to document how it 
works for users: news://
Closed: 23 years ago
Resolution: --- → FIXED
Summary: The eargerness of the stretchy code needs to be controlled → The eagerness of the stretchy code needs to be controlled
You need to log in before you can comment on or make changes to this bug.