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?

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.

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)

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.

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

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.