87285 - MathML broken in Xlib-toolkit and Xprint

Status: RESOLVED FIXED

(Core :: MathML, defect)

Description

[Roland Mainz]

Some MathML pages like http://www.mozilla.org/projects/mathml/demo/texvsmml.xml
look weired in Xlib-toolkit (mozilla/gfx/src/xlib) and Xprint print jobs (Xprint
uses parts of Xlib-toolkit for it's work).

I am going to attach an example screenshot from my Solaris 7 2001-06-21-08-trunk
Zilla build with "configure --enable-toolkit=xlib --enable-mathml" (Xprint is
now enabled by default on platforms which have libXp.so)...

CC:'ing some Xlib-toolkit and Xprint people...

Comment 1

[Roland Mainz]

Attachment: GIF image from 2001-06-21-08-trunk Xlib-toolkit Mozilla5 (Solaris 7 SPARC+gcc2.95.1)

Comment 2

[rbs]

You don't have the fonts -- that's the problem Number 1 with deploying MathML.
This causes so much perplexity that the basic fonts really should be auto -
installed for the adoption of Mozilla's MathML in the mainstream - see bug 15391
http://www/mozilla.org/projects/mathml/fonts

Comment 3

[rbs]

Correct URL: http://www.mozilla.org/projects/mathml/fonts

Comment 4

[Roland Mainz]

OK... I've downloaded
http://support.wolfram.com/Systems/Unix/FE/Fonts/Type1.tar.gz and installed it:
-- snip --
% xlsfonts | fgrep math
-wri-math1-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
-wri-math1-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
-wri-math1mono-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
-wri-math1mono-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
-wri-math2-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
-wri-math2-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
-wri-math2mono-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
-wri-math2mono-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
-wri-math3-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
-wri-math3-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
-wri-math3mono-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
-wri-math3mono-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
-wri-math4-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
-wri-math4-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
-wri-math4mono-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
-wri-math4mono-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
-wri-math5-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
-wri-math5-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
-wri-math5mono-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
-wri-math5mono-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
-- snip --

Unfortunately I do not see any changes except that the two vertical lines are
"gone" - that's all (yes... both Xsun and Sun's Xprt support Type1 fonts).

Any ideas ?

Comment 5

[rbs]

Do you also have the TeX fonts?
ftp://ftp.ams.org/pub/tex/psfonts/cm/cmps-unix.tar.gz

Comment 6

[Roland Mainz]

Uhm... OK... I've unpacked the dir - but how can I add them to the Xserver's
font path ? I do not see any fonts.dir/fonts.scale ... ;-(

Comment 7

[rbs]

There is some useful information of Paul Gartside on bug 35236.

This bug is a dup of bug 27860. From the attachements on that bug,
if the fonts are correctly installed, you get this: 
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=7200
if the fonts are missing you instead get this:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=7210

Comment 8

[Roland Mainz]

OK... looks I am missing fonts. I've installed th Mathematica(Wolfram) fonts -
but I can't install the TeX fonts due missing fonts.dir/fonts.scale

Any hints ?

Comment 9

[rbs]

Reproducing Paul Gartside comments. Notice his first remark that fonts.dir
and fonts.scale were also missing. (Yes, MathML without fonts is just a pain
as you are experiencing.)

------- Additional Comments From Paul Gartside 2000-04-09 11:18 -------

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.

Comment 10

[Roland Mainz]

Ok... I did the described "torture installation"... =:-)

On Solaris 7 I needed "pfbtops" (in the groff distribution,
ftp://ftp.informatik.rwth-aachen.de/pub/gnu/groff/groff-1.17.tar.gz) and
"type1inst"
(ftp://ftp.metalab.unc.edu/pub/Linux/X11/xutils/type1inst-0.6.1.tar.gz).
I build it, "type1inst" created font.scale, "mkfontdir" created "font.dir" from
"font.scale". xset fp+ ..., xset fp rehash; ./mozilla

I am going to attach a new screenshot - it does not look very healthy... ;-(

Maybe I am doing something wrong - looking at the generated fonts.dir:
-- snip --
% cat fonts.dir 
94
cmb10.pfb -unknown-cmb10-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmbsy10.pfb -unknown-cmbsy10-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmbx10.pfb -unknown-cmbx10-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmbx12.pfb -unknown-cmbx12-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmbx5.pfb -unknown-cmbx5-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmbx6.pfb -unknown-cmbx6-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmbx7.pfb -unknown-cmbx7-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmbx8.pfb -unknown-cmbx8-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmbx9.pfb -unknown-cmbx9-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmbxsl10.pfb -unknown-cmbxsl10-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmbxti10.pfb -unknown-cmbxti10-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmcsc10.pfb -unknown-cmcsc10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmdunh10.pfb -unknown-cmdunh10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmex10.pfb -unknown-cmex10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmff10.pfb -unknown-cmff10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmfi10.pfb -unknown-cmfi10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmfib8.pfb -unknown-cmfib8-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
cminch.pfb -unknown-cminch-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmitt10.pfb -unknown-cmitt10-medium-r-normal--0-0-0-0-m-0-adobe-fontspecific
cmmi10.pfb -unknown-cmmi10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmmi12.pfb -unknown-cmmi12-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmmi5.pfb -unknown-cmmi5-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmmi6.pfb -unknown-cmmi6-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmmi7.pfb -unknown-cmmi7-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmmi8.pfb -unknown-cmmi8-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmmi9.pfb -unknown-cmmi9-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmmib10.pfb -unknown-cmmib10-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmr10.pfb -unknown-cmr10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmr12.pfb -unknown-cmr12-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmr17.pfb -unknown-cmr17-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmr5.pfb -unknown-cmr5-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmr6.pfb -unknown-cmr6-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmr7.pfb -unknown-cmr7-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmr8.pfb -unknown-cmr8-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmr9.pfb -unknown-cmr9-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmsl10.pfb -unknown-cmsl10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmsl12.pfb -unknown-cmsl12-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmsl8.pfb -unknown-cmsl8-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmsl9.pfb -unknown-cmsl9-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmsltt10.pfb -unknown-cmsltt10-medium-r-normal--0-0-0-0-m-0-adobe-fontspecific
cmss10.pfb -unknown-cmss10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmss12.pfb -unknown-cmss12-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmss17.pfb -unknown-cmss17-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmss8.pfb -unknown-cmss8-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmss9.pfb -unknown-cmss9-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmssbx10.pfb -unknown-cmssbx10-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmssdc10.pfb -unknown-cmssdc10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmssi10.pfb -unknown-cmssi10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmssi12.pfb -unknown-cmssi12-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmssi17.pfb -unknown-cmssi17-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmssi8.pfb -unknown-cmssi8-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmssi9.pfb -unknown-cmssi9-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmssq8.pfb -unknown-cmssq8-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmssqi8.pfb -unknown-cmssqi8-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmsy10.pfb -unknown-cmsy10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmsy5.pfb -unknown-cmsy5-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmsy6.pfb -unknown-cmsy6-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmsy7.pfb -unknown-cmsy7-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmsy8.pfb -unknown-cmsy8-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmsy9.pfb -unknown-cmsy9-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmtcsc10.pfb -unknown-cmtcsc10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmtex10.pfb -unknown-cmtex10-medium-r-normal--0-0-0-0-m-0-adobe-fontspecific
cmtex8.pfb -unknown-cmtex8-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmtex9.pfb -unknown-cmtex9-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmti10.pfb -unknown-cmti10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmti12.pfb -unknown-cmti12-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmti7.pfb -unknown-cmti7-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmti8.pfb -unknown-cmti8-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmti9.pfb -unknown-cmti9-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmtt10.pfb -unknown-cmtt10-medium-r-normal--0-0-0-0-m-0-adobe-fontspecific
cmtt12.pfb -unknown-cmtt12-medium-r-normal--0-0-0-0-m-0-adobe-fontspecific
cmtt8.pfb -unknown-cmtt8-medium-r-normal--0-0-0-0-m-0-adobe-fontspecific
cmtt9.pfb -unknown-cmtt9-medium-r-normal--0-0-0-0-m-0-adobe-fontspecific
cmu10.pfb -unknown-cmu10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
cmvtt10.pfb -unknown-cmvtt10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
lasy10.pfb -unknown-lasy10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
lasy5.pfb -unknown-lasy5-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
lasy6.pfb -unknown-lasy6-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
lasy7.pfb -unknown-lasy7-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
lasy8.pfb -unknown-lasy8-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
lasy9.pfb -unknown-lasy9-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
lasyb10.pfb -unknown-lasyb10-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
lcircle1.pfb -unknown-lcircle10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
lcirclew.pfb -unknown-lcirclew10-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
lcmss8.pfb -unknown-lcmss8-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
lcmssb8.pfb -unknown-lcmssb8-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
lcmssi8.pfb -unknown-lcmssi8-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
line10.pfb -unknown-line10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
linew10.pfb -unknown-linew10-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
logo10.pfb -unknown-logo10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
logo8.pfb -unknown-logo8-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
logo9.pfb -unknown-logo9-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
logobf10.pfb -unknown-logobf10-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
logosl10.pfb -unknown-logosl10-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
-- snip --

Does the "-unknown" affect the results in any way ? I assume yes... Xprt rants
about font problems (and does not download them to printer either):
-- snip --
AUDIT: Fri Jun 22 18:17:51 2001: 27758 Xprt: client 1 connected from local host
CMEX10 not found, using Courier.
CMSY10 not found, using Courier.
-- snip --

Any ideas ?

Comment 11

[Roland Mainz]

Attachment: GIF image from 2001-06-21-08-trunk Xlib-toolkit Mozilla5 using "more" fonts in fontpath

Comment 12

[rbs]

The 'unknown' foundry shouldn't matter.

Your dump shows that the fonts are still not used:
---
CMEX10 not found, using Courier.
CMSY10 not found, using Courier.

I am wondering if it is case-sensitive?

Do you see any difference if you add the following line to nsMathMLChar.cpp:

1270 // Put aFamily in the first position of aFont to guarantee that our
1271 // desired font is the one that the GFX font sub-system will use
1272 inline void
1273 SetFirstFamily(nsFont& aFont, const nsString& aFamily)
1274 {
1275   // overwrite the old value of font-family:
1276   aFont.name.Assign(aFamily);
+      aFont.name.ToLowerCase();
1277 }

Comment 13

[rbs]

I am going off-line at the moment. Hope the problem turns out to have a
solution.

Comment 14

[Roland Mainz]

No... sorry... that patch does not help. Still the same warning... even the same
case (uppercase)... ;-(

Comment 15

[Roland Mainz]

Attachment: Debug log (stderr+stdout) from 2001-06-21-08-trunk Mozilla

Comment 16

[Roland Mainz]

Attached debug log while printing via Xprint module. Screen output looks the
same (except page 3 - but that's another bug in platform-independent table print
API).

rbs - do you see any hint in that logfile why Xlib+Xprint MathML stuff looks
that weired ?

----

BTW: Xsun in Solaris supports *.ttf fonts - in theory I could use
http://www.mozilla.org/projects/mathml/fonts/bakoma/cmex10-ttf.zip and
http://www.mozilla.org/projects/mathml/fonts/bakoma/cmsy10-ttf.zip - but I do
not have ttmkfontdir - and building this tool is a horror story (you need
Freetype and so on...)... ;-(
Does anyone have a fonts.scale file for these two *.ttf files ?

Comment 17

[Roland Mainz]

More Unix font fun: 
"MT Extra fonts" (http://www.mathtype.com/support/fonts/) are only available as
*.exe files (http://www.mathtype.com/dl/MTW4_PostScript.exe). Are there any
*.zip/*.tar.gz archives with the same content+fonts.dir/fonts.scale files ?

Comment 18

[Roland Mainz]

Less pain, more fun (!? :-)
Download&&install http://ttf2pt1.sourceforge.net/ and use it to convert both 
http://www.mozilla.org/projects/mathml/fonts/bakoma/cmex10-ttf.zip and
http://www.mozilla.org/projects/mathml/fonts/bakoma/cmsy10-ttf.zip info *.pfb
files (% ttf2pt1 -b cmsy10.ttf), then use "type1inst" to create
fonts.dir/fonts.scale

Xprt is still ranting about missing fonts - but take a look at the _mixed_ case
of the names:
-- snip --
AUDIT: Fri Jun 22 21:16:31 2001: 1749 Xprt: client 1 connected from local host
Cmex10 not found, using Courier.
Cmsy10 not found, using Courier.
AUDIT: Fri Jun 22 21:16:56 2001: 1749 Xprt: client 1 disconnected
-- snip --

I assume something with the font lookup stuff is wrong/broken... looks like a
uppercase vs. lowercase issue - or do we hunt two totally unrelated issues here
!?

Question to jay hobson:
What does this Xprt warning/error message really mean ?

Comment 19

[rbs]

Unfortunately, the .TrueType fonts are not good for MathML on Unix. The reason 
is because MathML fonts are 'symbolic' fonts. This means that a symbol, says 
'alpha' can be in position p1 in fontname.TrueType, and in a _different_ 
position p2 in the _same_ fontname.Type1. When the MathML is looking up a 
symbol, it passes the position of the glyph down to GFX so that GFX can get hold 
of the desired physical glyph and return the metrics needed for the placements. 
On Windows, it passes p1, and on Unix, it passes p2. All the positions of the 
expected glyphs are derived from the MathFont Property Files. See
http://www.mozilla.org/projects/mathml/fonts/encoding/

There is no way in GFX to know if the font is TrueType or Type1. Had that be 
possible, the MathML engine could have passed the TrueType position p1 or the 
Type1 position p2 depending on the selected font. Consequently, don't bother 
with the TrueType versions. The Type1 fonts are known to work (c.f. Paul 
Gartside's examples). Just concentrate on the Type1 ones. Also don't bother with 
'MT Extra'. The glyphs that are there exist in the other fonts (just like the 
letter 'a' can be found in several fonts).

BTW, seeing your output, the repeated CheckForExistence() is because the result 
isn't remembered. I used to cache the fact that a font was missing, but there 
were a bug that newly installed fonts aren't detected, meaning you got to check 
every time, which is a kinda waste in normal situations. That was the price to 
pay the fix the bug. Hopefully I could add custom font lists for each platform, 
and could then completely disable 'MT Extra' on Unix.

Summary: Just concentrate on getting the existing Type1 versions to work.

Comment 20

[rbs]

Attachment: patch for intl/uconv/ucvmath

Comment 21

[rbs]

Attachment: patch for layout/mathml/base/src

Comment 22

[rbs]

I attached changes to allow:

1) customized default MathFonts for each platform. This is a good change which
allows 'MT Extra' to be removed from the Unix list. Hence the noise & cost 
related to its non-existence will disappear.

2) lower-case names everywhere... This is just to see if that makes any 
difference.

Let me know how it goes.

Comment 23

[Roland Mainz]

BAD. No real change. I am sure either I am doing something wrong or my computer
does something wrong.... ;-((

Xprt still tells me:
-- snip --
AUDIT: Mon Jun 25 19:22:44 2001: 8637 Xprt: client 1 connected from local host
CMEX10 not found, using Courier.
CMSY10 not found, using Courier.
-- snip --

rbs... wanna tar.gz all the required PS fonts+fonts.{dir|scale} for Unix and put
them somewhere into a download area. Maybe I am too dumb and my font setup is
simply broken... ;-((

Comment 24

[rbs]

Paul, hope you don't mind helping to sort out this conundrum of font
installation. Thanks.

Comment 25

[Roland Mainz]

Thanks to fix in bug 86368 ("MathML-enabled build crashes in
nsFontMetricsGTK::PickASizeAndLoad()") I can use GTK+-toolkit for comparisation.
The output looks nearly the same as in Xlib-toolkit - I am assuming it's a
misconfiguration (fonts !!) on my side... ;-((

Comment 26

[Roland Mainz]

Thanks to your and bstell's help am getting how a correct MathML view of 
http://www.mozilla.org/projects/mathml/demo/texvsmml.xml
Seems my problem was to get rid of all other crap extra fonts from my
/home/gisburn/mathml_fonts dir, pull the Wolfram fonts again and _only_ add
those one - no other fonts... :-)

I'll add a GIF image as "reference" and a GIF image from my Xlib-toolkit build
(both 2001-06-25-08-trunk+patch from bug 86368 running on Solaris 7 SPARC using
the Wolfram fonts)...

...the Xlib-toolkit stuff still looks weired... ;-((

Comment 27

[Roland Mainz]

Attachment: GIF image from GTK+-toolkit build (2001-06-25-08-trunk+patch from bug bug 86368)

Comment 28

[Roland Mainz]

Attachment: GIF image from Xlib-toolkit build (2001-06-25-08-trunk)

Comment 29

[Roland Mainz]

Can anyone explain the differences ? Same build, same Xsun, same fonts - only
two different toolkits...

blizzard/rbs/pocemit... any ideas ?

Comment 30

[rbs]

For attachment 40253 [details] -- all the MathML fonts are missing.
For attachment 40252 [details] -- some fonts are picked, other are missings, other last 
resort, low quality fonts are picked (e.g., as seen on the rendering for 
UnderBrace & OverBrace).

What happens when you put the TeX fonts (cmex10 and friends) in their own
dir like you did with the Mathematica fonts in bug 86368?

Comment 31

[Roland Mainz]

> For attachment 40253 [details] -- all the MathML fonts are missing.

This is the Xlib-toolkit screenshot...

> What happens when you put the TeX fonts (cmex10 and friends) in their own
> dir like you did with the Mathematica fonts in bug 86368?

When I add /home/gisburn/mathml_fonts/tex/cmpsfont/pfb to my fontpath I get the
same results as http://bugzilla.mozilla.org/showattachment.cgi?attach_id=39683

Comment 32

[Roland Mainz]

jay hobson: PING! - some questions for you in this bug...


pocemit: Any ideas ?

Comment 33

[Roland Mainz]

rbs: I'll attach a console output log from my 2001-06-29-08-trunk... output
looks "interesting". Maybe it "explains" why MathML does not work...

Comment 34

[Roland Mainz]

Attachment: Console log of 2001-06-29-08-trunk Xlib-toolkit build browsing http://www.mozilla.org/ (start page), http://bugzilla.mozilla.org/show_bug.cgi?id=87285 and finally http://www.mozilla.org/projects/mathml/demo/texvsmml.xml

Comment 35

[rbs]

I seem to recollect Erik saying that these missing lang groups shouldn't matter
and that special charsets such as that used by MathML don't have to be listed
in the resource:/res/langGroups.properties file.

Comment 36

[Roland Mainz]

OK... any other idea where it may fail ?

Comment 37

[rbs]

Sorry, I have no idea so far as to what is happening.

Comment 38

[Roland Mainz]

Wanna hook-up your own Xlib-toolkit build and take a look into it, please ?
Details on demand...

Comment 39

[rbs]

Yeah, I might like to do that at some stage. But sorry, I cannot commit to that
now. Let's hope for some help from the Unix gurus cc:ed on the bug.

Comment 40

[Roland Mainz]

Is there anything in the MathML code or Makefile.in stuff which may rely on some
GTK+ features or defines from configure.in (like "#ifdef using_gtk") ?

Comment 41

[rbs]

No - The MathML layout code (apart from from the GFX bits) is fully XP, like the 
rest of layout. It is just that the lack of fonts or the difference between 
font metrics entail different renderings.

Comment 42

[Roland Mainz]

Thanks... assuming the bug it not in layout code nor in nsFontMetricsXlib.* -
then (in theory) it can only hide in nsRenderingContextXlib.cpp ...

rbs... wanna look at the following code parts... please ? 
Can you verify that this code is correct ? The functionality of both methods
looks slightly different:
http://lxr.mozilla.org/seamonkey/source/gfx/src/xlib/nsRenderingContextXlib.cpp#1552
http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsRenderingContextGTK.cpp#1832

Comment 43

[Roland Mainz]

It looks like nsFontmetricsXlib stuff does not implemement GetBoundingMetrics()
... is it possible that this is the root of this evil issue ?

Comment 44

[Roland Mainz]

I'll try to get the code in sync with GTK+ code, both nsRenderIngContentXlib.cpp
and nsFontmetricsXlib.cpp miss some stuff which may cause this issue. 
Adding dependicies...

Comment 45

[Roland Mainz]

rbs:
Is it possible that the code is doing everything correct (including using the
right font) - but some unicode-->font converter stuff selects the wrong chars ?

Comment 46

[Roland Mainz]

Fixing subject, adding "helpwanted" keyword...

Comment 47

[Roland Mainz]

This bug may be related (or a DUPLICATE !?) of bug 85417 ("[Xlib] Xlib/Xprint do
not display/print em-dash & co. correctly...") ...

Comment 48

[Roland Mainz]

rbs:
Is it possible to set the milestone to "0.9.5" or "0.9.6" ?

Comment 49

[rbs]

I could have already attempted to check-in attachment 39888 [details] and attachment 39889 [details] 
but they don't help (except to cut the noise of "MT Extra"), so...

It is the same XP stretching code (attachment 40252 [details] vs attachment 40253 [details]) that is 
involved on all platforms (Win32, GTK, Xlib, etc). Differences are only in the 
GetBoundingMetrics() and the availability and local handling of fonts. I have 
the feeling of filling the bug repeating that so far, I sincerely have no idea 
as to what is happening.

Comment 50

[rbs]

Attachment: on Win32 with TeX&Mathematica fonts (note: need to disable Mathematica fonts to get closer to reference)

Comment 51

[Roland Mainz]

I found the bug... :-)
Fix follows ...

Comment 52

[Roland Mainz]

Attachment: Patch for 2001-09-14-08-trunk

Comment 53

[Roland Mainz]

Filed patch, requesting r=/sr= ...

Comment 54

[Roland Mainz]

Stealing this bug from rbs (hopefully you do not kill me for that... =:-) ...

Comment 55

[Roland Mainz]

Accepting bug ...

----

rbs/bstell:
Wanna r= this (attachment 49458 [details] [diff] [review]) patch, please ?

Comment 56

[kill this account]

I do not understand what this patch is doing.

Even so, does this code actually call exit?

+    if (!dpy)
+    {
+      NS_ERROR("Obtaining font information without having a |Display *|");
+      abort(); /* DIE!! */
+    }
+  

Comment 57

[Roland Mainz]

bstell wrote:
> I do not understand what this patch is doing.

Erm... the patch fixes rendering of special chars incl. MathML glyphs...

> Even so, does this code actually call exit?
>
> +    if (!dpy)
> +    {
> +      NS_ERROR("Obtaining font information without having a |Display *|");
> +      abort(); /* DIE!! */
> +    }

|abort()| does not call |exit()| - it triggers a SIGABORT which usually ends in
a coredump for analysis. This code path should _never_ be called... but if it is
called I want at least a stack trace for analysis.

Comment 58

[Roland Mainz]

Comment on attachment 49458 [details] [diff] [review]
Patch for 2001-09-14-08-trunk

new patch follows...

Comment 59

[Roland Mainz]

Attachment: better patch for 2001-09-14-08-trunk per rbs's comments

Comment 60

[Roland Mainz]

OK... filed new patch... this one fixes bug 99801, too.

Comment 61

[rbs]

The following can be moved into InitGlobals(aDevice) and removed from Init(); 
This way, InitGlobals() stays the centralized location where critical global
variables are initialized, and it is easy to track problems down.

+  if (!gXlibRgbHandle) <--- this |if| won't be needed if moved to InitGlobals()
+  {
+#ifdef USE_XPRINT 
+    if (mPrinterMode)
+      gXlibRgbHandle =  NS_STATIC_CAST(nsDeviceContextXp   
*,aDevice)->GetXlibRgbHandle();
+    else  
+#endif /* USE_XPRINT */  
+      gXlibRgbHandle =  NS_STATIC_CAST(nsDeviceContextXlib 
*,aDevice)->GetXlibRgbHandle();
+  }   

Comment 62

[rbs]

*** Bug 99801 has been marked as a duplicate of this bug. ***

Comment 63

[Roland Mainz]

Comment on attachment 49840 [details] [diff] [review]
better patch for 2001-09-14-08-trunk per rbs's comments

OK, working on it... new patch follows...

Comment 64

[Roland Mainz]

Attachment: Better patch for 2001-09-14-08-trunk

Comment 65

[Roland Mainz]

Filed new patch, requesting r=/sr= ...

Comment 66

[Hixie (not reading bugmail)]

abort() should never be in production code. Please use a better, more user friendly
way of handling that unusual situation, or don't check for it in the first place.

Comment 67

[Roland Mainz]

> abort() should never be in production code. Please use a better, more user 
> friendly way of handling that unusual situation, or don't check for it in the 
> first place.

Sorry, but |abort()| allowed in such cases. I want a stack trace from customers
for anasysis if this happens (we already had such fatal issues without having a
stack trace nor a way to reproduce. WE NEED THIS.) - which should never happen.
But _IF_ it happens I want to know _why_... and not to wait a month until I
found a way to hunt this issue down...

Comment 68

[Hixie (not reading bugmail)]

Here's a UI spec for you: exit with a printf() explaining the problem, and
stating the following: 1. what the problem may be caused by, 2. how to solve the
problem in the typical scenario, 3. where to find more information on this, and
4. what environment variable to set in order to get a stack trace.

You still get your stack trace if the user expects it, but you don't get it in
the much more likely case where the user hasn't the foggiest clue what just
happened. Plus, the user actually gets some help, instead of getting more
evidence that "Mozilla sucks and is for geeks only".

Comment 69

[Roland Mainz]

We discussed this on IRC. And I still disagree with you. If this happens the
code is already dead... last option failed. Then we need a simple, portable and
quick way for analysis.

Comment 70

[rbs]

There is something that is bugging me a little about the patch.
mPrinterMode is something that can be toggled on/off on the flight, right?
If so, what happens when gXlibRgbHandle is initialized with |...Xp|, and the
next minute, a new font is created with its mPrinterMode=false. Would there be 
a problem, or is the code safe no matter what?

+    if (mPrinterMode)
+      gXlibRgbHandle =  NS_STATIC_CAST(nsDeviceContextXp   
*,aDevice)->GetXlibRgbHandle();
+    else  
+#endif /* USE_XPRINT */  
+      gXlibRgbHandle =  NS_STATIC_CAST(nsDeviceContextXlib 

Comment 71

[Roland Mainz]

rbs:
No problem here.
|mPrintermode| is PR_FALSE for Xlib toolkit and PR_TRUE for Xprint module.

Comment 72

[Hixie (not reading bugmail)]

regarding abort():

There are 4 possible scenarios here.

  1. It works fine every time.
  2. It fails once and only once.
  3. It fails when out of memory.
  4. It fails multiple times, cause unknown.

1 is not a problem. For 2, whether or not we have a stack trace doesn't matter.
For 3, a stack trace won't help as the code in question is not trying to
malloc() at that point anyway. For 4, a stack trace might help, but can be
obtained by running the process again with the environment variable set, maybe
in ones profile configuration so that any future such error is caught.

In any case, when the error occurs the user is going to be much happier getting
useful information (what happened, how to potentially solve it, where to get
more help, how to force a stack trace) than he is getting the simple message
"Core dumped."

Comment 73

[Roland Mainz]

Comment on attachment 49845 [details] [diff] [review]
Better patch for 2001-09-14-08-trunk

hixie:
I still disagree here, I explained that in IRC #mozilla. Guess why |abort();| is not affected by the |NDEBUG| CPP sybol like it is done for |abort();|.
But to stop this discussion here... I'll file a new bug where the |abort();| calls are quoted by |#ifdef DEBUG| ...

Comment 74

[kill this account]

Perhaps you might consider doing something like the NS_FONT_DEBUG printfs. If 
these are placed in a reasonable number of locations then users that see the 
problem and want to help can collect the output and send it in.

Comment 75

[Roland Mainz]

Attachment: New patch for 2001-09-14-08-trunk to make hixie happy

Comment 76

[Roland Mainz]

Comment on attachment 49863 [details] [diff] [review]
New patch for 2001-09-14-08-trunk to make hixie happy

I forgot something... sorry... ;-(

Comment 77

[Hixie (not reading bugmail)]

That doesn't solve the problem. The problem is we have a potential error situation
here, and we should handle it gracefully. Crashing, or abort()ing, (same thing, to
all intents and purposes) is the worst we can do. The best we can do is abort
the printing, and gracefully recover -- not print, but otherwise do everything.
We do
this in lots of other parts of the code -- it is possible. We should do that here.

There is never any excuse for crashing and losing people's work.

Comment 78

[Roland Mainz]

Attachment: patch for 2001-09-14-08-trunk

Comment 79

[Roland Mainz]

Requesting r=/sr= for that patch ...

Comment 80

[rbs]

r=rbs

For the record, this curious bug was caused by the following gem:

+      nsFontXlib *oldFont = mCurrentFont;
+      mCurrentFont = prevFont;
       UpdateGC(); <----- this function uses/expects |mCurrentFont| to be set!
[...]
+      mCurrentFont = oldFont;

UpdateGC() also exists in the GTK port, but the above mistake isn't present in 
the pattern over there. It was exposed by MathML because MathML handling is a
good exercise of the font-switching code.

Comment 81

[kinmoz]

Comment on attachment 49864 [details] [diff] [review]
patch for 2001-09-14-08-trunk

Can you add a short comment to the parts that swap in prevFont, explaining why it's necessary?

sr=[e-mail]

Comment 82

[Roland Mainz]

Comment on attachment 49864 [details] [diff] [review]
patch for 2001-09-14-08-trunk

I am going to file a new patch for checkin incl. the requested comments...

Comment 83

[Roland Mainz]

Attachment: New patch for 2001-09-19-08-trunk per kin's comments

Comment 84

[Roland Mainz]

CC:'ing [e-mail] for checkin, please ...

Comment 85

[Johnny Stenback (:jst)]

Patch checked in on the trunk, mark this fixed if that's all there is to this bug.

Comment 86

[Roland Mainz]

Marking bug as FIXED - both Xlib toolkit and Xprint module handle MathML now
correctly... :-)

Comment 87

[rbs]

To close the curtain, you got to attach replacement screenshots for the famous
attachment 40253 [details] and attachment 40252 [details] ...

Comment 88

[Roland Mainz]

Mhhh, I forgot to attach the screenshots... ;-(
Sorry...

Comment 89

[Roland Mainz]

Attachment: http://www.mozilla.org/projects/mathml/start.xml printed with 2002-01-19-08-trunk using Xprint module

MathML printed with Xprint module (all fonts are downloaded to the printer).

Solaris Xservers (both Xsun and Xprt) are very alergic against the
CMEX10/CMSY10 fonts, therefore I didn't use them here (that's bug 120560) ...

Comment 90

[Roland Mainz]

Attachment: Screenshot of 2002-01-19-08-trunk Xlib toolkit Mozilla viewing http://www.mozilla.org/projects/mathml/start.xml

Comment 91

[rbs]

bad sqrt symbol -> means missing CMEX10/CMSY10.
bad right parenthesis (misalignment of partial glyphs) -> means bad Symbol font.
The default bitmap version from Adobe has bad metrics. If users were not having
that much trouble finding another version, and installing other fonts in
general, I would disable the use of the Symbol font for stretching.

Comment 92

[Roland Mainz]

rbs wrote:
> bad sqrt symbol -> means missing CMEX10/CMSY10.
See comment #89 ... Solaris Xservers are highly alergic against these fonts...
;-(

> bad right parenthesis (misalignment of partial glyphs) -> means bad Symbol 
> font.
> The default bitmap version from Adobe has bad metrics.

I see, the screenshot shows it - but the printed version (from PS job attachment
65913 [details] - Xprt has downloaded a Type1-version of the "Symbol" font) looks OK for
me...

> If users were not having
> that much trouble finding another version, and installing other fonts in
> general, I would disable the use of the Symbol font for stretching.

What about forcing the use of a scaleable version of the "Symbol" font and
throw-up the "You're-missing-mathml-fonts" dialog when the bitmap version is the
only available one ?

Comment 93

[rbs]

re: scalable type-1 symbol.
Problem is: there is no way (API) to know (higher up) if the font is bitmap or
not, or if the font has been aliased to something better or not.

Comment 94

[Roland Mainz]

Well... that isn't really the whole truth on X11 systems: You can force
scaleable fonts (% xlsfonts | fgrep "0-0-0-0-" # should list you only scaleable
fonts) ...

Comment 95

[rbs]

Need to hack the query string used in nsFontMetricsGTK::FindFamily() then.
Will you be willing to do that? Basically, the change would be to slightly
extend nsIDeviceContext::CheckFontExistence() to pass a boolean, say
aScalableOnly, and in nsFontMetricsGTK::FindFamily(aFamily, aScalableOnly), add
  if (aScalableOnly)
    // use sprintf( with the zero '0' )
  else
    // retain the current sprintf( with the stars '*')

This way, the mode could be set higher up. [The aliasing remains a separate
issue]

Comment 96

[rbs]

s/PRBool aScalableOnly/PRUint32 aFlags/ for other possible tweaks that may be
needed one day, who knows. (Passing aFlags as 0 to mean the default behavior.)

Comment 97

[Roland Mainz]

rbs wrote:
> Will you be willing to do that?
File a new bug, assign it to me and CC: bstell... :)

Comment 98

[Roland Mainz]

Attachment: http://www.mozilla.org/projects/mathml/start.xml printed with 2002-04-09-08-trunk using Xprint module (300DPI, ISO A4)

Fixed bug 120560 ("Solaris Xsun does not like CMEX10/CMSY10 Type1 fonts"), now
the CMEX10/CMSY10 are working on Solaris (Xsun+Xprt), too... :)

Comment 99

[Roland Mainz]

Attachment: http://www.mozilla.org/projects/mathml/start.xml printed with 2002-04-09-08-trunk using Xprint module (600DPI, ISO A4)

Comment 100

[Roland Mainz]

Attachment: Screenshot of 2002-04-09-08-trunk Xlib toolkit Mozilla viewing http://www.mozilla.org/projects/mathml/start.xml