Closed Bug 237406 Opened 20 years ago Closed 20 years ago

RFE: There should be a Xfree86 font *.enc file for MathML fonts

Categories

(Core :: MathML, defect)

Product:
Core
Component:
MathML
Platform:
All
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: roland.mainz, Assigned: rbs)

Details

RFE: There should be a Xfree86 font *.enc file for MathML fonts (for non-Xft
builds).

Currently the MathML fonts are recognised per name and not via their XLFD
encoding, making it hard to provide other fonts as alternatives/replacements.

Two steps are required:
1. rbs:
Can you make mapping lists of {glyph_index, unicode_index} per mathml encoder
(e.g. "x-t1-cmex", "x-t1-cmsy", "x-t1-cmr", "x-t1-cmmi", "x-mathematica1",
"x-mathematica2",  "x-mathematica3", "x-mathematica4", "x-mathematica5") that I
can make encoding maps for Xfree86 from them ?

2. The XLFD code in gfx/src/{gtk|xlib}/nsFontMetrics(GTK|Xlib).cpp needs to be
adjusted to support the yet-to-be-defined XLFD encoding names.

Proposed names for the XLFD encodings:
Encoder name     ||  XLFD encoding name
"x-t1-cmex"      --> "*-math.cmex-0"
"x-t1-cmsy"      --> "*-math.cmsy-0"
"x-t1-cmr"       --> "*-math.cmr-0"
"x-t1-cmmi"      --> "*-math.cmmi-0"
"x-mathematica1" --> "*-math.mathematica-1"
"x-mathematica2" --> "*-math.mathematica-2"
"x-mathematica3" --> "*-math.mathematica-3"
"x-mathematica4" --> "*-math.mathematica-4"
"x-mathematica5" --> "*-math.mathematica-5"
These fonts are specific. You won't find other free fonts with the same glyphs
arranged in the same manner. Moreover, the Math{1-5} 4.1 fonts have been
discontinued and replaced with the Mathematica{1-5} 4.2 fonts. Even these sets,
coming fron the same vendor, didn't match the existing ones... Also, with the
STIX project nearing completion, the incentive is towards supporting it, rather
than doing further tweakings on the old things. [That's why I haven't bothered
with the Mathematica{1-5} 4.2 fonts, BTW.]

gisburn, I am marking this INVALID based on the explanations above.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
rbs:
The Xfree86 font encoding mapping code allowed to reencode existing fonts.
They do not need to have the glyphs in a specific order, they only have to
provide the glyphs (either via unicode index, truetype font index or postscript
name) and the Xfree86 font encoding code reorderes them as specified in the
*.enc file.
Virtual fonts, with glyphs picked here and there? It is sitll not desirable
because there will be misaligments when building stretchy characters. 

Stretching is working now because it relies on two fundamental assumptions:
- that the font designer have designed the pieces to match (with the font-size a
free parameter - i.e., the matching is sustain at arbitrary font-sizes)
- that the font engine (GDI, Xft) is consistent (with its hinting, rounding
errors, ...).

If we start to mix glyphs from different fonts, there would be severe
misagliments, and issues such as that described in bug 237152 will be exacerbated.
rbs@maths.uq.edu.au wrote:
> Virtual fonts, with glyphs picked here and there? 

Uhm, no. 
No virtual fonts composed from multiple other fonts involved.
Maybe it is better to try to explain this via showing parts of a Xfree86 *.enc
map:

The following is from Xfree86's adobe-dingbats.enc:
-- snip --
STARTENCODING adobe-dingbats
# This file is derived from data provided by Adobe
STARTMAPPING postscript
32 space
33 a1
34 a2
35 a202
36 a3
37 a4
38 a5
39 a119
40 a118
41 a117
42 a11
[snip]
STARTMAPPING unicode
UNDEFINE 0 0xFF
0x20 0x0020    # SPACE
0x21 0x2701    # UPPER BLADE SCISSORS
0x22 0x2702    # BLACK SCISSORS
0x23 0x2703    # LOWER BLADE SCISSORS
0x24 0x2704    # WHITE SCISSORS
0x25 0x260E    # BLACK TELEPHONE
0x26 0x2706    # TELEPHONE LOCATION SIGN
0x27 0x2707    # TAPE DRIVE
0x28 0x2708    # AIRPLANE
0x29 0x2709    # ENVELOPE
0x2A 0x261B    # BLACK RIGHT POINTING INDEX
0x2B 0x261E    # WHITE RIGHT POINTING INDEX
0x2C 0x270C    # VICTORY HAND
0x2D 0x270D    # WRITING HAND
-- snip --
One example for a font which has all glyphs for the "adobe-dingbats" encoding is
MonotypeSorts.ttf.
The fonts.dir entry for MonotypeSorts.ttf looks like this:
-- snip --
MonotypeSorts.ttf -monotype-monotype
sorts-regular-r---0-0-0-0-p-0-adobe-dingbats
MonotypeSorts.ttf -monotype-monotype
sorts-regular-r---0-0-0-0-p-0-monotype-extra1
-- snip --

So MonotypeSorts.ttf refers to two different XLFD entries with different
encodings. The "trick" of Xfree86 is now to get the encoding part of the XLFD
string, lookup the matching *.enc file ("adobe-dingbats.enc" or
"monotype-extra1.enc" in this example) and reencode the Truetype (or PostScript)
font to match that spec.

OK, I understand your idea. Seems okay for normal fonts where one can substitute
one for the other. But it doesn't look much useful to me for special fonts. 

There are two cases: 1) virtual: the *.enc is _not exactly_ that of, say Math1,
it would have to be virtual to cover the needed glyphs, in which case we have
the limitations I alluded to. You indicated that you are not referring to this.
Understood.

2) non-vrtucal: the *.enc is _exactly_ that of, say Math1. In this case, only
the physical Math1 font will match that in practice [i.e., you won't find
another font with those glyphs]. So, it is specific as I indicated earlier (you
will be mapping a font to itself, which isn't much practical, no?).
rbs:
Mozilla would be able to use the TrueType MathML fonts with such an enhancement.
The TTF font would simply be reencoded and then be treated like the PS Type1
ones - Mozilla wouldn't see any difference.
gisburn, those fonts are in type1.
rbs@maths.uq.edu.au wrote:
> gisburn, those fonts are in type1.

Even those used on Windows and Mac ? I mean that the TTF fonts could then be
used instead of the PS Type1 ones.
Those on Windows or Mac are TrueType. What is the benefit of asking users to
install them (along with the home made *.enc and the extra instrutions that come
with it) rather than just pointing at the type1, and be done with it?
rbs@maths.uq.edu.au wrote:
> Those on Windows or Mac are TrueType. What is the benefit of asking users to
> install them (along with the home made *.enc and the extra instrutions that 
> come with it) rather than just pointing at the type1, and be done with it?

1. The "home made" *.enc files would be part of Xfree86+FreeDesktop.org+Solaris,
they're likely of interest for other projects, too (incl. Wolfram people).
2. There would only be one set of fonts required for all platforms, not one per
platform (it may even be possible to stick everything in one TTC file, then only
one file would be needed).
3. PS Type1 fonts would no longer be restricted to a specific order of the
glyphs in the PostScript encoding vector. Instead of that a font designer could
grab an existing symbol font and add the glyphs missing for full MathML support
(PS fonts can have more than 256 glyphs per font (only the PS encoding vector is
restricted to 256 entries, other parts can be accessed via the glyph name (like
using the /glyphshow operator))) and the font gets reencoded to match the XLFD
mapping as specified in the *.enc file.

BTW: Who at Wolfram is currently responsible for the Unix font stuff - can you
CC: him/her, please ?
Re: 1. "The "home made" *.enc files would be part of
Xfree86+FreeDesktop.org+Solaris"
Convince the OS vendors and get that in place and we can talk :-) Right now, it
sounds more like wishful thinking.

Re: 2.
Depends on 1. Otherwise it would remain easier for users to just install the
type1 and be done with it.

Re: 3. "grab an existing symbol font and add the glyphs missing"
I already indicated that virtual fonts would have limitations in this context.

I am not sure who is the Unix font guru at Wolfram these days. The actual folks
who designed the Wolfram fonts don't have bugzilla accounts.
rbs@maths.uq.edu.au wrote:
> Re: 1. "The "home made" *.enc files would be part of
> Xfree86+FreeDesktop.org+Solaris"
> Convince the OS vendors and get that in place and we can talk :-) Right now, 
> it sounds more like wishful thinking.

This isn't wishfull thinking. Xfree86 even accepted *.enc files for XLFD
encodings only used on Solaris. And IBM's special encodings are supported, too.
And if Xfree86 and Freedesktop.org ship with these *.enc files all Linux
distribs are covered. Solaris is no big problem either.

> Re: 3. "grab an existing symbol font and add the glyphs missing"
> I already indicated that virtual fonts would have limitations in this context.

I wasn't talking about virtual fonts. I was talking about a qualified font
designer who knows what he/she does when he/she is adding new glyphs to a font
(using pfaedit etc.).

> I am not sure who is the Unix font guru at Wolfram these days. The actual
> folks who designed the Wolfram fonts don't have bugzilla accounts.

emails ?
support@wolfram.com, see also:
http://support.wolfram.com/mathematica/systems/unix/general/manualfontdownload.html
http://support.wolfram.com/mathematica/systems/windows/general/latestfonts.html

Re 3. it won't work -- those symbolic fonts have their mapping tables in
ucvmath, mathfont properties files, etc. Arbritrary symbolic fonts made of
random glyphs aren't used for stretchy MathML purposes -- which is primarily why
we need those special glyphs.

So setting these *.enc for TrueType don't really fall under the MathML work.
Might be something for the OS/Xfree86. You might have a try with WRI -- but they
might wonder if their type1 fonts have no value :-) WRI don't mind saying that
that it cost them a lot (may be up to a million dollar) to design their fonts
and professionally hint them and that's why they have so far declined to
open-source them. But following our lobbying they have softened their stance a
little bit and agreed to redistribute them.
You need to log in before you can comment on or make changes to this bug.