Closed Bug 109826 Opened 23 years ago Closed 23 years ago

Turn on MathML in default builds

Categories

(Core :: MathML, defect)

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

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: rbs, Assigned: rbs)

Details

Attachments

(5 files, 3 obsolete files)

raw file sizes for 0.9.7-linux with --disable-elf-dynstr-gc
2.01 KB, text/plain
Details
file size diffs, with --disable-elf-dynstr-gc
1.22 KB, text/plain
Details
same - with s|dtd/mathml.dtd|dtd/*|
5.22 KB, patch
netscape
: review+
Details | Diff | Splinter Review
For the record - the saved tinderbox stats before & after --enable-mathml
119.88 KB, text/html
Details
updated patch for configure.in
886 bytes, patch
Details | Diff | Splinter Review 
Filing this bug to stage the enabling of MathML in default builds, and to 
address and clarify the associated impact:
- size
- speed
- integration review
-> targetting m0.9.8
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.8
No. See the note in that bug.

Gerv
These numbers have been collected on a SuSE 7.2 machine with gtk 1.2.10, glib
1.2.10, libIDL 0.6.5, --disable-debug --enable-optimize --disable-elf-dynstr-gc


Without --disable-elf-dynstr-gc, elf-dynstr-gc consistently segfaults when
trying to process a mailnews library. As a consequence, the resulting numbers
are probably different from what is actually shipped. :-( But it may serve as a
list of files to look at when doing further size comparisons.

Lines beginning with "<" are from a build without mathml, lines beginning with
">" are from a build with --enable-mathml.
disk usage (du -s -k):

39831 KB  mozilla
40347 KB  mozilla-mathml
--------
 +516 KB

tarball sizes:

13,760,936 Bytes mozilla.tgz
13,891,430 Bytes mozilla-mathml.tgz
----------------
  +130,494 Bytes
I have been exhausting myself bringing the code in ready to turn-on state in the 
hope that the sooner it is enabled in the nightly builds, the quicker loose ends 
could be tightened before the looming 1.0.

The elimination of the non-standard DOCTYPE is the last hickcup as it requires 
an #ifdef MOZ_MATHML deep inside the XML code (bug 113400).

With respect to the availability of fonts (the complaint number #1 with MathML), 
one of my last checkins has been to provide users with a feedback (an alert box) 
when some of the critical MathML fonts are missing. So the alert message could 
be customized to include an URL (e.g., on the mozilla.org's MathML project page) 
where users could read more and find links to download the available free fonts.
Hopefully, this will cut down on the frustration of the general audience who 
will visit MathML pages out of curiosity and wonder what is going on.

I am now happy with the code as it is now, and would give my thumb up for it to 
be enabled, pending resolution of issues that may arise.
What about hacking the Installer to download the required fonts from the Wolfram
site (URL goes to mozilla.org which directs the request to the real download
site) ? =:-)
I used to dream of such things myself. But the XP issues are a mightmare.
I am awake now, and might be content with just having the Alert! missing
mathfonts message point to an "about:fonts" that provides a kinda easily
modifiable/localizable helpdesk with a list of URLs where people can
point'n-click to download and install the fonts by themselves. 
I just checked in a fix for bug 113400. So the non-standard DOCTYPE is now gone. 
The fix ended up without an #ifdef, for it has consisted in adding a miniature 
catalog struct to remap known public IDs to local DTDs (see bug 98413 for 
details about the XML catalog spec). Thus XHTML+MathML documents with the 
standard DOCTYPE "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN" will get the 
desired local DTD.
Just wondering:
Can't we setup a public font server for Unix/X11 machines which serves the
MathML fonts ?
That may be a solution for quick testing (e.g. dialog "you are missing important
fonts for viewing MathML. Options: "view 'download mathml fonts instructions'",
"get MathML fonts from public X11 font server", "ignore") ...
Do you want to sign up to do that? I have come to have very low expectations of
seeing such things happen. So I am going along with the thinking that the first
version doesn't have to be perfect, knowing that for Windows users it is trivial
to install fonts. As for Linux/Unix users, since they like to hack so much by
themselves, installing the fonts might appear as something that they may enjoy
to chew upon.
rbs wrote:
> Do you want to sign up to do that? I have come to have very low expectations 
> of seeing such things happen.

Well... I could provide such a service (... but I would prefer if someone at
mozilla.org does it, I cannot gurantee a permanent address for such a server for
more than one year) if someone says that such a "service" is legal (it would
only send images (bitmaps) of the fonts around, not the font itself. I doubt
such kind of "screen shots" are illegal... =:-) ...
So, let's leave that out for now then. Plus, it is too late in the game. The
impediment of fonts has been sung for too long without something happening.
Time to move on. Iterations can always come later, especially if you have a
working demo...

    
    

    
  


  

        Attachment #65196 -
        Attachment is obsolete: true

    
    

    
  
Filed bug 120494 for about:fonts.

    
    

    
  


  
A clobber-build showed that I had forgotten all about ucvmath for the mathfont
encoding tables.

        Attachment #65386 -
        Attachment is obsolete: true

    
    

    
  


  
I substituted 'dtd/mathml.dtd' to 'dtd/*' given that heikki is now planning to
provide a fallback to bug 44458 for now by setting a xhtml11.dtd and listing
"-//W3C//DTD XHTML 1.0 Strict//EN" and "-//W3C//DTD XHTML 1.1//EN" in the
catalog table added in bug 113400. So with the substitution, no need to
re-invent the (xpinstall) wheel everytime a DTD file is added in the special
DTD directory.

        Attachment #65405 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 65863 [details] [diff] [review]
same - with s|dtd/mathml.dtd|dtd/*|

The makefile.win changes that just add the include for config.mak are not
needed as far as I can tell.  Remove those changes and 
r=cls pending staff@mozilla.org approval.

    
    

    
  
Got a=endico on behalf of staff@mozilla.org and a=shaver on behalf of 
drivers@mozilla.org.

I am currently re-building a blank directory in which I checked out afresh from 
CVS and turned the switch on. Will checkin upon veryfying that it doesn't break 
the fresh build.
Target Milestone: mozilla0.9.8 → mozilla0.9.9

    
    

    
  
... reportedly, recent testing of load-times by Asa has shown no perceptible 
differences between a MathML-enabled build and a non-MathML-enabled build.

    
    

    
  
cls, the build aborted without the "include". I am restarting again after adding 
back the "include".

    
    

    
  
The error was that the !ifdef MOZ_MATHML here and there in the makefiles were
not picked, causing some files not not be built/included, and chaos followed
afterwards.

I just checked in the patch. Marking as FIXED.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
Did you skip configure.in and config.mak? The part of the patch dealing with
those files wasn't checked in (yet) as far as i can tell.

    
    

    
  
Oops... now completed.

    
    

    
  
rbs backed out the unix stuff. Looking at my build, MOZ_MATHML wasn't defined in
config-defs.h, so while the makefiles picked up the change, none of the ifdefs
were triggered.

I think you want:

dnl ========================================================
dnl MATHML on by default
dnl ========================================================
MOZ_MATHML=1
MOZ_ARG_DISABLE_BOOL(mathml,
[  --disable-mathml      Disable MathML],
    MOZ_MATHML= )
if test "$MOZ_MATHML"; then
  AC_DEFINE(MOZ_MATHML)
fi

instead. cls?

    
    

    
  
I agree that this is probably a config problem. I downloaded
mozilla-source.tar.gz from latest, ran cvs update, and ran configure
--enable-mathml --disable-mailnews and then gmake. Now it's already past the
mathml stuff. And I saw a 
#define MOZ_MATHML 1
during the configure run.

    
    

    
  
And yes, my build completed, and it runs fine. So there's nothing wrong with the
mathml code itself. It's just configure.


    
    

    
  
Thanks for chasing up. I had a few hours sleep (3 AM here now). But now the tree 
is closed :-(  It remained enabled on Windows, though. 

    
    

    
  


  
Patch following bbaetz comments. Will checkin when the opportunity arises.

    
    

    
  
Checked in and all went well this time around.

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: