jsMath and local servers

  • David A Oliver

    David A Oliver - 2009-04-02

    It is desirable to develop with jsMath on a local server before posting to a remote server. But security models make this difficult because they prohibit loading data from a file to the local server http localhost address even if that file is in the site directory.

    Can anyone who is successfully developing with jsMath on  a local server discuss useful configuration strategies.


    • Davide P. Cervone

      I'm a little confused about the exact setup you are trying to use.  Can you explain what you mean by "loading data from a file to the local server http localhost address"?

      I certainly use jsMath for local development before uploading to a server.  If the URL used to load jsMath.js (or jsMath/easy/load.js) is a relative one, then if you maintain the same directory structure locally as you do on the server, you should not have any trouble.  JsMath should handle the the same-origin security policy properly even when loaded locally.

      If you could be more specific about your setup and the problem you are having, perhaps I could help.


      • David A Oliver

        David A Oliver - 2009-04-03

        The problem appears to lie with Dreamweaver which I am using as a development environment with MAMP as the local server.

        When previewing a file in the browser from the development environment, Dreamweaver loads the file testfile.html in the browser with its file address, eg file://Applications/MAMP/htdocs/jsMath/test/testfile.html. However, the local website address  of this file is http://localhost:8888/jsMath/test/testfile.html.

        jsMath fails to work because of the following security error:

        Security Error: Content at file:///Applications/MAMP/htdocs/jsMath/test/testfile.html may not load data from http://localhost:8888/jsMath/plugins/autoload.js.

        The problem can be circumvented by avoiding the Dreamweaver preview and hand-loading the file directly as


        but of course this is not as convenient as using the preview feature within the Dreamweaver development environment.


        • Davide P. Cervone

          OK, thanks for clearing up the situation.  It looks like Dreamweaver is setting the URL for jsMath/easy/load.js to be an http:// URL to the localhost server rather than a file:// URL to the local file system, and that makes jsMath try to load its components from the http:// URL.  As you point out, that means that jsMath is trying to load from a different domain than the page itself, and that causes the same-origin security policy to deny access to jsMath's components.

          One way around his might be the following.  Create a new file in jsMath/easy, say jsMath/easy/jsMath.js that contains something like:

          if (document.location.protocol == 'file:') {
            document.write('<SCRIPT SRC="file:///Applications/MAMP/htdocs/jsMath/easy/load.js"></SCRIPT>');
          } else {
            document.write('<SCRIPT SRC="http://[yourhost]/jsMath/easy/load.js"></SCRIPT>');

          where you have replaced [yourhost] by the actual host where your pages will be deployed.  That way, when the page loads locally via a file:// URL, it will load the easy/load.js file locally, and when loaded from a server, it will load the easy/load.js file from the server.  It would be possible to construct the "http://[yourhost]" from the document.location data (like the server and port), but I didn't get that fancy here.

          Your document would then load jsMath/easy/jsMath.js rather than jsMath/easy/load.js.

          Something like that might work for you.


        • David A Oliver

          David A Oliver - 2009-04-03

          Thank you Davide,

          A procedure to overcome the limitation along the lines you suggest occurred to me, but I felt one should first diagnose the problem on Dreamweaver since the preview feature is so central. As I suspected, the problem can be solved by reconfiguring the testing server.

          I'm not wedded to Dreamweaver, though I am tentatively using it because there is more to the pages I am working on than mathematics. As I mentioned in my original post, I'm interested in  development strategies  including testing people find useful. If you have an effective system you are pleased with, perhaps you can say something about it.

          This is a moment to say "thank you" for jsMath. Of the many implementations of TeX on the web, jsMath far outstrips them all in achieving high quality typography, not simply legibility, a quality that solved a major stumbling block in my desire to publish on the web. There's still another mountain to cross in seeing how people without teX fonts can handle and view the pages with ease and over the various browsers and whether they can be persuaded to install fonts if they become regular readers. But I am a way off from that point of publication.

          Thanks again,


          • Davide P. Cervone

            It sounds like you have been able to solve the problem without a special file like the one I recommended.  Is that right?  Can you say what reconfiguration was required to do that?

            For my own development, I just hand-code the HTML.  I'm afraid I'm an old coot who is stuck in his ways.  (You can tell when I learned any particular technology because I learn a lot abut it at the time, and then stick with that forever; once I know how to do what I need, I tend not to update unless I have to.)  So I still hand code HTML because I  know how and never got around to learning a specialized editor; when I learned HTML back in 1993, there wasn't any other way.

            Thank you for your kinds words about jsMath.  It is messages like that that keep me going.  As for fonts, if you have installed the image fonts, users without the fonts should be OK (unless coloring of the mathematics is an important part of your site), though there are some printing issues for some browsers under Windows.  My experience with getting people to install the fonts is that they simply won't do it, despite the warning messages and the printing problems.  I have been investigating the @font-face CSS situation, and it looks like the latest versions (some in alpha or beta testing) of the major browsers all support it, so it should be possible to use web-based fonts in the future, which should solve this vexing problem for jsMath.  But it will take a while for those browsers to be in wide use, so jsMath's other fallback methods will need to remain in use for now.



Log in to post a comment.