Closed Bug 35236 Opened 24 years ago Closed 14 years ago

TrueType cmsy10 and cmex10 fonts not recognized on Linux

Categories

(Core :: MathML, defect, P3)

Product:
Core
Component:
MathML
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 127063
Milestone:
Future

People

(Reporter: endico, Assigned: rbs)

Details

Attachments

(2 files)

broken math fonts from scheffer.xml
16.11 KB, image/png
Details
fonts.alias for ttf font with iso8859-1 encoding
216 bytes, text/plain
Details 
I have both the cmsy10 and cmex10 fonts installed on my (linux)
system and mathml is not recognizing them. The fonts seem to be
installed correctly because they work fine in another application
(the gimp). Some characters show up as question marks and the
space next to the radical is a black box. The black box seems
to be the missing stretchy symbol and is about the correct width.

Using xlsfonts makes it look like the font name is 
lower case but from the error message, it seems like mathml is
looking for an upper case font name.

loading this url
http://www.maths.ox.ac.uk/~gartside/mozBugs/sheffer.xml
-----------------------------------------
nsXMLContentSink::AddDocTypeDecl
WARNING *** Missing the CMSY10 font to stretch MathML symbols!
            Why don't you install the CMSY10 font on your system for a better
MathML experience!
WARNING *** Missing the CMEX10 font to stretch MathML symbols!
            Why don't you install the CMEX10 font on your system for a better
MathML experience!
WARNING *** Missing the MT Extra font to stretch MathML symbols!
            Why don't you install the MT Extra font on your system for a better
MathML experience!

-----------------------------------------
[endico@beefaroni bin]$ xlsfonts | grep mex
-2rebels-cmex10-medium-r-normal--0-0-0-0-p-0-ascii-0
[endico@beefaroni bin]$ xlsfonts | grep cmsy
-2rebels-cmsy10-medium-r-normal--0-0-0-0-p-0-ascii-0
btw, my cmex10 and cmsy10 fonts are truetype. I also have the unix
version of the mathematica fonts installed. I don't have MT Extra
There are related comments about this font problem on bug 27860.
so paul, what did you do to work around your problem? From looking
at the screen shots in bug 27860, it looks like the same problem as
mine. I've verified however that X sees my tex fonts because I can
use them in the gimp. Mozilla is able to use other truetype fonts
(verdana) so its not that. I still suspect the capitalization problem
but i'll wait to hear from paul before i fool around with that.
Here is how I solved this. (Surely not the best way - but works for me.)

My cm tex fonts are in /usr/share/texmf/fonts/type1/bluesky/cm/ .
I first noticed that the directory doesnt contain fonts.dir and fonts.scale
which (I believe) are needed for xfs (the x font server). So I downloaded
type1inst from  ftp://ftp.metalab.unc.edu/pub/Linux/X11/xutils/ (untarred it).
Changed directory to /usr..../bluesky/cm and ran type1inst. This created the
relevant files.
Next I checked that /usr..../cm was not on my font path (xset -q).
So I added it with `xset fp+ /usr.../cm ; xset fp rehash'
Restarting mozilla and looking at a relevant mathml page should bring you
wonderful stretchy union signs etc!
To keep /usr.../cm on the font path, Ive put `xset fp+ /.../cm ; fp rehash' in
my .bash_profile file. (I would like to make it a global change - which I should
be abe to do by editing XF86Config - but on my system this is a sym link to a
non-existent file...)

Paul.

I suspect it has to do with the ascii-0 encoding. Try creating, or adding to, a
fonts.alias file in that particular font directory with entries like
-2rebels-cmex10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific  \
 -2rebels-cmex10-medium-r-normal--0-0-0-0-p-0-ascii-0
(all on one line). If that doesn't work, try more aliases with iso8859-1 instead
of adobe-fontspecific.

Actually, you can put, or add to, a fonts.alias file in any directory in the
font path. Do "man mkfontdir" for more info.


tenthumbs is probably on the right track. My machine uses the
iso8859-1 encoding although trying his suggestions didn't work
even after restarting xfs.
Hmm... Dawn would you check back again to sheffer.xml. -I had not copied the new
mathml.css into my bug reporting directory (which contains sheffer.xml). 
To see stretching and the tex fonts more clearly, try 
http://www.maths.ox.ac.uk/~gartside/mozBugs/stretchybug.xml


Also, what do people think of including the cmex10 and cmsy10 fonts directly 
in with Mozilla? These two fonts and their `helper' files take up about 66k. A
simple `xset xp+ $MOZPATH/fonts/cm ; xset fp rehash' in the Mozilla startup
shell script (and similarly for Windows and Mac) would (?) make them
automatically available to MathMl-Moz. I raised the question of
re-distributability of the ams fonts on the news group, and someone from the AMS
replied they are absolutely freely distributable - and this is confirmed at the
website...


I don't think it's a good idea to mess with X's font path all the time. A script
that added to thw font path every time Mozilla started would probably break
something eventually. Since the fonts are available from AMS, I think a
description of what's needed and where to get them is more appropriate. Let the
user install the fonts just once.

Shifting the the truetype problem, I would suggest trying 
xfd -fn '-2rebels-cmex10-medium-r-normal--14-0-0-0-p-0-ascii-0'
(note the request for 14 pixels). If xfd fails then try any aliases for the
font. If xfd stil fails then it's a problem with the font. What to do depends on
where the problem lies.
Dawn, did you finally succeeded in the installation of the fonts?
Status: NEW → ASSIGNED
This still doesn't work for me although my fonts seem to be installed
correctly. (they work in other applications) I'm using true type fonts
and it looks like paul is using type1. Waqar suggested that maybe some
additional magic X is needed by mathml to use these fonts. He was going
to look into it but i haven't heard back yet.
Dawn what version of Linux are you running? To install TT fonts you need to run 

ttmkfdir command to create the fonts.scale file as well.



ttmkfdir . > fonts.scale

mkfontdir -e /usr/X11R6/lib/X11/fonts/encodings \

-e /usr/X11R6/lib/X11/fonts/encodings/large .



and then rerun xfs.


i'm running redhat 6.1. I already did tmkfontdir but I dont' recall
doing mkfontdir -e. I'll have to play with that when i get home.
thanks.
I've reinstalled fonts, rebooted my machine and have a new m16 build compiled
yesterday. Somewhere in the process things got a lot worse. The mathml torture
test works ok but Gartside's complain about missing fonts and now almost none
of the math renders at all.

WARNING *** Missing the CMSY10 font to stretch MathML symbols!
            Why don't you install the CMSY10 font on your system for a better
MathML experience!
WARNING *** Missing the MT Extra font to stretch MathML symbols!
            Why don't you install the MT Extra font on your system for a better
MathML experience!
WARNING *** Missing the Math4 font to stretch MathML symbols!
            Why don't you install the Math4 font on your system for a better
MathML experience!


    
    

    
  
It is interesting to note that CMEX10 was installed properly this time.
Indeed, it is not listed as missing, and furthermore the glyphs on the 
screenshot come from CMEX10. It looks strange that CMEX10 is recognized
while the other fonts are not. Didn't you install all the fonts with the
same procedure?

The weird rendering comes from the fact the TrueType and T1 formats of TeX fonts
have different encoding indices. By default, the code uses the T1 encoding on
Linux. (The TTF encoding is used by default on Win32). Wrong glyphs are being
picked on the screenshot due to the mismatch: the code is using the T1 encoding
with your TrueType CMEX10 font.

On Linux, it will be necessary to differentiate between TTF and T1 in order to
use the appropriate encoding. Erik, is there a way to know which is which when
loading the font in GFX?


    
    

    
  
As a data point, Mozilla seems to work well with the type1 fonts from AMS.

I think the problem is that ttmkfdir is not recognizing cmex10 and cmsy10
properly because there are many glyphs missing. I would copy the fonts into a
empty directory and run ttmkfdir -m 66 and see if anything interesting turns up
in the fonts.scale. If so, try adding these entries to the real fonts.scale, run
mkfontdir, and restart xfs.


    
    

    
  
There is no reliable way to distinguish TrueType and Type1 fonts on X, as far as
I know. ttmkfdir can produce a number of encodings for a single TrueType font.
One way might be to get ttmkfdir to somehow produce the encoding that the Type1
font uses (since you say that Mozilla defaults to that). Another way might be
to get ttmkfdir to pass the original TrueType encoding straight through to X,
with a suitable XLFD font name suffix so that Mozilla will switch to that
encoding automatically.

    
    

    
  
oops. the CMSY font was missing from my fonts.aliases file. I've added it
and now both of these fonts are recognized, however the document is still
unviewable because I'm missing the "MT Extra" and "Math4" fonts. I'm not
sure what "Math4" is, but its impossible for me to get mt extra on this
machine. Should I close this bug and file a new one about the fact that
this document is no longer viewable?


WARNING *** Missing the MT Extra font to stretch MathML symbols!
            Why don't you install the MT Extra font on your system for a better
MathML experience!
WARNING *** Missing the Math4 font to stretch MathML symbols!
            Why don't you install the Math4 font on your system for a better
MathML experience!

    
    

    
  
The Math4 font is one of the Mathematica fonts. No need to pay attention to them
here since these are not yet hooked on Linux (they are only hooked on Win32 for
now. I will be sending a patch to Paul for verification when they are ready to
be hooked).

I am curious as to why the fonts were first recognized in other applications
like the Gimp before, but this is a disgression...

The fact that the document is not rendered as expected is due to the encoding 
indices used by the font. tenthumbs, the ucvmath module already has the mappings
for both the TTF and T1 formats. The fonts are treated as special in GFX and
what remains is to make sure that all the pieces fit together without mismatch.

As Erik mentioned, since there is no way to distinguish the T1 and TTF formats
at load time from within GFX, we need another work-around. It seems to me
it would be easier to deal with a specific XLFD font name, than to go through
the route of generating a fake encoding.

How do you feel about naming the font as cmex10tff?  Whatever name is
picked, I will have to update the GFX code accordingly in order to cause
the appropriate encoding to be used. Upon verification that all is well,
the bug could be closed, and someone (Paul?) could document all these 
tricks needed to get the fonts to work on Linux. 


    
    

    
  
Attaching my fonts.alias file. Since I have to make aliases anyway, I could 
have easily munged the name even further and added "ttf" to the name.

    
    

    
  
Happy to check patches.

And ok to do documentation.   :-)

Paul.


    
    

    
  
At the moment, I don't think using truetype CM fonts is a good idea for
Unix.

I don't know what fonts Dawn is using but I found a set of truetype CM
fonts at <http://www.biz.uiowa.edu/class/6F113_stutzer/TTFONTS/>. In a
sense, these fonts are defective because they are not really iso646 or
iso8859-anything but they are encoded as if they were. There's just a
straight-forward linear assignments of glyphs starting at 0x20 in the
Windows Unicode mapping.

Because there are a large number of missing glyphs, ttmkfdir treats them
only as ascii-0 encodings. It's not at all clear to me that the font
server will deliver glyphs for characters > 0x7F with this encoding even
though they exist in the font. Using just the ascii-0 encoding, Mozilla
actually renders something fairly reasonable for the test pages.

If I change the ascii-0 encoding to iso8859-1 (which is just about as
reasonable as anything else), Mozilla falls apart. It looks like the
missing glyphs trigger Mozilla's rather aggressive font substitution
policies and the page is filled with question marks. It looks like using
standard encodings won't work.

Using the type1 CM fonts from AMS works best of all. There are still a few
question marks floating around and Mozilla is still trying font
substitution but it's fairly reasonable.

I think this works well because all the AMS fonts as well as the
Mathematica type1 fonts and the standard X symbol font all have the
adobe-fontspecific encoding. It's probably possible to play encoding
tricks with the truetype fonts but not all font servers use encoding files
so it wouldn't be universally applicable.

While it's certainly possible to attach an arbitrary xlfd family name to
any font, you still have to specify an encoding and none of the standard
ones fit these TT fonts.


    
    

    
  
Advising people to only use t1 fonts sounds like a fine idea.
I only installed truetype because they happened to be the
first ones I found. I didn't realize they would lead to all
this fun.

On the other hand, won't most mathematicians already have CM 
fonts installed? I wonder if there will be many problems
with conflicting pre-installed fonts.

    
    

    
  
tenthumbs, what you are saying makes a lot of sense. The problem with these
"symbolic" math fonts is that they don't fit an encoding standard. So they
are currently treated in a special way in GFX (using adobe-fontspecific in
Linux, and checking their registered names in Win32). Custom maps are there
to basically do what you said, i.e., "playing the encoding tricks". These maps
are hosted in the single location of the ucvmath module. That's how the
T1 versions of these fonts are working now.

The TTF and T1 have the same number of glyphs (in fact, the space is 
included in the TTF but not in the T1). 

Regarding hooking the TTF versions, it is indeed a lot of hassle for little
gain. The T1 versions are working fine and are readily available, so I concur
that we can leave things are they are.

If we want Mozilla to work with the TTF versions of the fonts if these are
the only ones that a user has installed, is there a slick way to do so other
than re-naming the fonts (and adding the further corresponding hooks in GFX)?
If it was possible to know that a font being loaded is the TTF version, things
would be much easier and there wouldn't been need to worry about potential
conflicts.

    
    

    
  
The type1 and truetype CM fonts aren't exactly identical. The type1 fonts have
some of the glyphs duplicated in positions 0 - 0x1f whereas the TT fonts have
nothing there. I have no idea if anyone relies on this.

XFree86 4.0 and the later xfsft font servers use encoding files so it is
possible to create an arbitrary encoding for any given truetype font and then
alias that encoding to something an application understands. One could create
a cm-0, or cm-1, or mathpua-2 encoding file, use that encoding directly or
alias a particular font to something like the adobe-fontspecific encoding.
This is what I was talking about when I mentioned "encoding games" because
it's invisible to the application.

In theory, this is an elegant solution to the problem. In practice, it would
be a nightmare. Since there are no "official" truetype CM fonts, for example,
one would have to examine each truetype font individually to see how it's
encoded and, perhaps, create a special encoding file. In addition, this is
rather new so not all platforms support it.

I would postpone any truetype support until later. There are far more
important problems now.


    
    

    
  
> The type1 and truetype CM fonts aren't exactly identical. The type1 fonts have
> some of the glyphs duplicated in positions 0 - 0x1f whereas the TT fonts have
> nothing there. I have no idea if anyone relies on this.

Yes the MathML code relies on these. The glyphs are of varying sizes/outlines
(or are you refererring to something else?). On the TTF version, the control
zone is unoccupied due to some Windows restriction on TTF. But the MathML engine
sees the same number of glyphs in total on both versions, and picks the glyph
with the best outline in a given situation (if none of the glyph is ok, it
looks in another font).

Since the support of TTF is out the game on Linux for now, I am updating
the title and marking the bug as LATER.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → LATER
Summary: cmsy10 and cmex10 fonts not recognized → TrueType cmsy10 and cmex10 fonts not recognized on Linux

    
    

    
  
It's not easy to tell but it looks like some of the glyphs in the 0xA0-0xFF
range also appear, in a different order, in the 0 - 0x1F range. I think the two
regions use the same glyphs so the only question is whether someone out there
uses the lower region.

    
    

    
  
->Future (LATER is deprecated)
Status: RESOLVED → REOPENED
Resolution: LATER → ---
Target Milestone: --- → Future

    
    

    
  
bstell, 

Would your recent truetype work on linux help this situation?
(or the upcoming xft work?) Shaver just ran in to this problem.
Comment 27 seems to be a good summary of the bug.

    
    

    
  
I am just adding Linux TrueType support for MathML fonts. See bug 127063.

This will allow moz to use the TrueType MathML fonts but will not address
core X fonts for MathML (Type1).

    
    

    
  
isn't this a duplicate of bug 127063, which is fixed?

    
    

    
  
Down,

bug 127063 is about using MathML TrueType fonts with FreeType2 library ( see bug
116147 ). This bug is about using MathML TrueType fonts with standard core X
fonts routines.

I don't know if patch for bug 127063 also fixed this one. I think it doesn't

    
    

    
  
I'm experiencing a similar problem, except that I have the tetex 
Type1 fonts installed on my Gentoo Linux machine.  
Mozilla (version 1.2.1) complains that I need to install CMEX10, CMSY10, Math1,
Math2, Math4, and Symbol.  But xlsfonts shows, e.g.

xlsfonts | egrep 'cmex10|cmsy10'
-unknown-cmex10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
-unknown-cmsy10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific

Gentoo 1.4_rc2, running xfs, nvidia XFree86 driver 3123-r2, XFree86 4.2.1
The Gimp, e.g., can find and use these fonts also.


    
    

    
  
Oops, I forgot to include the full version number for Mozilla:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030117
Thanks.

    
    

    
  
Using Red Hat Linux 2.4.20-9 i686 i686 i386 GNU/Linux and the stock Mozilla/5.0
(X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225, build 2003022516.

I tried installing Type1 fonts, as instructed, from the AMS build.  I tried
several variations on the installation using type1inst.  I can get XFS and
xlsfonts to see the fonts CMEX10 and CMSY10, but not Mozilla.  Math* fonts are
OK as is Symbol (from my Acrobat installation).  My variations include putting a
fonts.alias file directly referring to CMEX10 and CMSY10, and using the teTeX
Type1 fonts.  I also editing fonts.cache-1 to add lang=en to the fonts, none of
which listed en as a valid language.

Installing the TTF fonts just results in random glyphs. 

I'm sitting with basically the same problem as Keith Frost above and have run
out of things to try.  Exactly how does Mozilla request these fonts from XFS? 
Could I be missing a foundry specification?


    
    

    
  
Try your luck with the debugging tips given in bug 196460 to see that if that
helps to shed some light on the problem.

    
    

    
  
So, to repeat what was in bug 196460: it Mozilla 1.2 and 1.3 aren't working with
Xft (the Freetype renderer) and hence with xfs (the X11 font server that uses
it).  The way to get MathML rendering working is to install the fonts as
described then  set an environment variable

   setenv  GDK_USE_XFT 0

which disables the use of XFT with Mozilla.  The downside is that the pretty,
sub-pixel rendered fonts are disabled, making Mozilla ugly again.  I understand
from bug 128153 that Mozilla 1.4 will have this fixed.

(I've put this here since this bug is still labelled for "troubleshooting" from
the projects MathML->Fonts page.)


    
    

    
  
Things still aren't right.  The lower case Greek letters are displayed as upper
case, and upper case Greek letters as some arbitrary glyph.  The GDK_USE_XFT
hack doesn't work for me, although it gets rid of the font complaints.  I'm using
Type1 fonts.

    
    

    
  
Hi,

I help support MathML at MIT and we are currently trying to install the fonts on
our campus-wide Athena system made of Red Hat Linux and Solaris workstations and
for which Mozilla is the default browser (current version: 1.2.1). 

I also had problems with the CM TeX fonts under Red Hat Linux 7.3 that I'm
reporting here along with a workaround in case other users run into similar
problems.

The problem:

We downloaded the fonts from the mozilla site and ran type1inst to create the
fonts.dir and fonts.scale files. However, when adding the fonts using "xset fp+
directory_where_the _fonts_are", our system complains and produces the following
error message:

X Error of failed request:  86
  Major opcode of failed request:  51 (X_SetFontPath)
  Serial number of failed request:  8
  Current serial number in output stream:  10

Workaround:

Use the command "chkfontpath" to add the fonts (requires log in as root) e.g.

chkfontpath -a directory_where_the _fonts_are

The fonts are then added and Mozilla displays them correctly.


    
    

    
  
Regarding comment #39, my problem turned out to be the following.  My LaTeX to
MathML parser (itex2MML) marked greek letters as <mi>&pi;</mi> and this caused
the font to be selected incorrectly.  Changing the translator to mark greek
letters as <mo>&pi;<mo> worked correctly.  I suppose this may point to a problem
in the selection of the glyphs for greek letters in italic.

    
    

    
  
Regarding comment #40, my problem turned out to be the following:

Type 1 support was disabled in the X server's modules configuration. In the file
/etc/X11/XF86Config-4, in the "Module loading section" -- "type1" was commented
out. Uncommenting this line and restarting the X server now makes "xset fp+ " work.

    
    

    
  
For the record, I can't get mozilla(1.4) to recognize the PS Type1 versions of 
cmsy10 and cmex10, despite: 
> xlsfonts | grep cm 
-ams-cmex10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific 
-ams-cmsy10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific 
mozilla still says I need to install CMEX10 and CMSY10 when opening a MathML 
page. 
I've got the Mathematica fonts installed as well, but they don't seem to work 
well either, as MathML comes out distorted: ie, sqrt's are chopped, text after 
sub/super-scripts is printed at the sub/super script location. 

    
  
Flags: blocking1.5+

    
    

    
  
only drivers can set (+) block flags.  you can request them (?), but blocking
1.5 release is highly unrealistic.
Flags: blocking1.5+

    
    

    
  
This was really fixed by 127063 for FreeType 2.
Mozilla no longer uses X core fonts.
The BaKoMa TrueType CMSY10 and CMEX10 fonts no longer work since the change to cairo-based font engines for Gecko 1.9.0.
Gecko 1.9.0 and later uses Unicode fonts from bug 400938.
Restoring support for these fonts would probably be WONTFIX for reasons mentioned in comment 23 and bug 400938 comment 0.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 14 years ago
Resolution: --- → DUPLICATE

          You need to log in
          before you can comment on or make changes to this bug.