The following are known bugs in jsMath. Workarounds are included when they are available. Known Bugs in jsMath
- Opera 9.5 has a number of bugs that affect jsMath's ability to render mathematics properly. In partcular, if the page is scrolled while jsMath is processing, Opera can place the mathematics at the wrong location on the page. Also, opera seems to think that the page size is longer than it should be. This all worked properly in Opera 9.26, and so represent a degradation of performance in this later version of Opera. It may not be possible to work around these problems. It helps not to scroll the page while jsMath is processing the mathematics, and if the page is to be refreshed, you should scroll back to the top of the page before doing so.
- The Page Zoom feature in MSIE7 is extremely buggy, and although jsMath tries hard to work around this, the results are not perfect. One work-around is to add
letter-spacing:0
to a block-level element containing the mathematics (say theBODY
element itself), but this can cause the letter spacing to be lett attractive than the default spacing, and so may not be appropriate in all cases.
- Firefox 1.5.0.1 on the PC crashes when the compressed version of jsMath v3.1 through v3.1c are used. Version 3.1d works around the problem, so you are encouraged to update your sites to this or a later version as soon as you can. The folks at Mozilla should fix this in a future release (it is not just jsMath that is suffering from this, so I'm sure they won't let it go for long), but there will always be some 1.5.0.1 stragglers, so you want to be using a version of jsMath that works with FF 1.5.0.1. The Macintosh version of Firefox 1.5.0.1 does not exhibit the problem; I don't know about the unix version.
- In MSIE on the PC, if the browser's encoding is set to certain non-western encodings (notably the Chinese encodings), then some character positions within the TeX fonts are no longer accessible. One solution is to use the jsMath control panel to select image fonts instead. (This error may no longer be a problem with the new jsMath versions of the TeX fonts, which use a different encoding than the BaKoMa versions.)
- MSIE and Firefox on the PC do not print images with alpha-channel transparency properly (they appear as solid black boxes), so pages that use image fonts will not print properly in these browsers when alpha-channels are used. To avoid this, either use the "Hi-Res Fonts for Printing" button on the jsMath control panel (this will turn off alpha fonts automatically), or uncheck the "Use image alpha channels" button on the Options page of the jsMath control panel.
- In MSIE on the PC, with screen resolutions in excess of 1600 at 120dpi, images are rescaled automatically by the browser. JsMath does not fully compensate for this when image fonts are used. Images with alpha channels also do not work properly in this case, and jsMath turns them off automatically.
- There are an enourmous number of display bugs in MSIE on the PC. JsMath tries hard to work around these, but this makes it run somewhat slower in MSIE than in other browsers (actually, more like an order of magnitude slower). If jsMath is sluggish for you, it would help to install the TeX fonts if you haven't already. If you are using image fonts, you might try turning off alpha channels (the MSIE solution for this is quite awkward), and try using full image mode rather than symbols-only mode. Sprite-based image fonts can be extremely slow. Finally, unicode mode may be faster than either of the image modes. One of the most serious display bugs causes characters to disappear entirely under some circumstances if they are repositioned from their natural locations. Since jsMath does a lot of positioning to lay out the mathematics, it can fall prey to this bug. I have tried hard to work around this, but there still appear to be situations where it can occur.
- Because MSIE on the PC does not implement the
position:fixed
CSS attribute, jsMath must simulate it in order to have the jsMath control panel button stay at the lower right of the window. It does so by trapping the JavaScript scroll event for the browser window, so if you trap this event yourself, you will disable that feature of jsMath in MSIE (though you could call the jsMath method in addition to your own code). Because of this lack of support for the CSS standard, jsMath's control panel button may not always appear at the proper location.
- In MSIE on the PC, when a TeX source window (produced by double-clicking on an equation) is dragged and the mouse moves outside the viewing window, text within the window can be selected. When you move back within the window, it should become unselected again. I'll look for a solution, but it is not high priority.
- JsMath in MSIE on the Mac is rather unstable, and it can crash unpredictably. On pages with lots of mathematics or complicated formulas, MSIE can get confused about the font being used -- the math is typeset correctly initially, but when the next equation is typeset, the characters in the earlier one can end up changed; weird. Also, MSIE/Mac has lots of CSS bugs, so adding styles to your page may really mess up jsMath. I'm not sure how much longer I can keep jsMath running on MSIE/Mac as new features are added to jsMath.
- In non-TeX-font fallback modes, MSIE on the Mac gets slower and slower each page that is viewed, when the compressed versions of jsMath and the fallback methods are used.
- When jsMath is used in Microsoft's help viewer, some actions may cause
hh.exe
to not exit and consume 100% of the available CPU time when the help viewer is closed. The conditions within jsMath that seem to trigger this have been eliminated, but there are still some ways that it can happen. In particular, clicking in the table of contents pane at the left will cause this to occur (and will also lose the cache and control panel settings), so it is best to disable the table of contents and provide your own HTML-based one.
- In Firefox 1.5 on the PC, the print preview does not always accurately represent what you will see in the printed output. The mathematics may seem to be incorrectly placed on the page, and the contents of <NOSCRIPT> tags may show up in the printed output for no good reason. These problems do not occur in the actual printed output, only the preview. Pretty strange.
- In Firefox 1.5 on the PC, some extra fonts may not load even if the user has them installed. This occurs when the font does not contain a full set of 128 character glyphs (as in lasy10 for example). In this case, jsMath will produce the "extra font not found" message and use the image fonts instead.
- In Firefox (version 1.0.x and lower), if the
autoload
plugin is used, or if "force asynchronous processing" is checked in the control panel, then the browser's BACK button will contain multiple copies of the current page. So pressing BACK will just redraw the current page (and add more copies of the page to the back menu). The work-around is to use the back menu to select the earlier page by hand. Version 1.5 does not seem to have this problem.
- In Firefox when
global
mode is used, the BACK and FORWARD buttons may not work as properly. The history list seems not to be properly maintained for the frame that is used to show that main page. There is no current work-around for this problem.
- In Safari on the Mac, the default print settings cause pages containing mathematics to print improperly (white backgrounds for the mathematical characters can overlap text lower down on the page, making it "disappear"). The work-around is to select the "Print Backgrounds" checkbox on the "Safari" pane in the print dialog box.
- In Safari on the Mac using the image fonts, the first time a character is loaded, it may not display properly on screen (you may just get an empty frame with no character inside). If you resize the window slightly (or reload it), the characters should show up properly. As of v2.1, jsMath tries to overcome this by "joggling" the window slightly after the page is loaded, but the timing of this might not be appropriate for all situations, and you may need to resize the window yourself.
- In the Opera browser, some mathematics will not display properly when unicode fonts are selected. Opera does not seem to be able to access all the unicode characters needed for mathematics, even when they are available in fonts installed on your system. The solution is to install the TeX fonts, or to select image fonts.
- In Opera, an attempt to autoload a file that does not exist on the server can cause the browser to hang. I have not found a way around this.
- In Opera, the sprite-based image fonts can not be scaled (see the spriteImageFonts plugin page for details), so these features are disabled in the jsMath control panel. This means you can not select "Hi-res fonts for printing". Also, you will need to turn on background printing in order to print sprite-based image fonts, and on the PC, these will not print correctly even if you do. There is no workaround known for this.
- In Opera, the frequent switches between global and non-global modes can cause the browser to crash.
- Entering global mode causes OmniWeb to crash, so going global is disabled for this browser in all versions.
- When the image fonts are used, if the mathematics doesn't print properly, you may need to select "Print backgrounds" if there is an option for you to do so. Some browsers do not respect the transparency of the images used for the characters in the font unless background printing is specified.
- When using image fonts, if the print quality seem slow, use the jsMath Control Panel and press the "Hi-Res Fonts for Printing" button to have jsMath load higher-resolution versions of the images that will provide for better print quality. Reload the page to get the original screen fonts again. As of version 3.2b, jsMath includes a warning on printed pages if you are printing with low-resolution fonts. You can disable that warning on the Options pane of the jsMath control panel. You can also force jsMath to use the hi-resolution fonts all the time (ueful if you have to print many pages); this may look poor on screen, but should print better.
- When using image fonts with alpha transparency, some browsers on the PC (MSIE and Firefox) will print these as solid black blocks. To work around this, open the jsMath Control Panel and press the "Hi-Res Fonts for Printing" button, or go to the Options panel and turn off alpha channel transparency.
- Because jsMath's global mode uses frames to implement the persisten equation cache, the usual issues pertaining to printing an reloading the page pertain. See the documentation on global mode for more details.
- The
\color
extension will not change the color of characters taken from the image fonts. It is best to use image fonts for symbols only in this case, as some of the non-symbol characters will be colored, at least.
- Because "<" and ">" are used in HTML to delimit the HTML tags, you have to be careful when using these symbols within mathematics. For example, if you used
<SPAN CLASS="math"> x<a </SPAN>
, the browser would read "<a
" as the start of an HTML anchor tag and jsMath would not be able to process the mathematics (the browser interprets tags long before jsMath gets access to the page, so there is nothing jsMath can do about this). It is often sufficient to put a space after the "<" or ">", but it is better to use "<" or ">" instead. For example,<SPAN CLASS="math"> x < a </SPAN>
.
- Text within an
\hbox{}
is not processed by jsMath, but is treated as plain text and is formatted by the browser directly. This means that TeX commands within the text are not evaluated (except that jsMath looks for$...$
and\(...\)
for math to process within the\hbox
), so you can't use things like \it to form italics. Instead, you need to use HTML tags to format the text. The problem is that HTML tags are removed from the mathematics before jsMath starts to process it. JsMath will process "@(...)
" as an HTML tag in the text of an\hbox
; for example,\hbox{an @(I)italic@(/I) word}
will produce "an italic word". Not as nice as actual tags within the\hbox
, but it works.
- In some situations (particularly when the mathematics scaling factor is large), the browser may think the bounding box for the mathematics is larger than its visual extent. JsMath hides this from the browser so that it will not effect the line separation (when it can), but the box may extend over top of the lines below the mathematics, and this can interfere with the browser's mouse-click processing. For example, the browser may think that links on the line below some mathematics are "covered up" by the mathematics (even when this is not visually the case), and you may not be able to select those links. The solution will be to use clipping regions to force the browser to reconsider the bounding box of the mathematics, but this has not yet been implemented. A temporary solution in some cases is to use CSS to set the z-index of the mathematics to -1, so that it is displayed "behind" the main text rather than cover it up. This only works if the mathematics appears within an element that doesn't itself cover something else. For example, if the math is in a block with a background color, setting the z-index would cause the math to fall "behind" the background color, so it would seem to disappear.
To set the z-index globally, insert
<STYLE> .typeset {z-index: -1; position:relative} </STYLE>in your document.An alternative is to make links and other interative content be at a higher z-index:
<STYLE> a, input, textarea {z-index: 2; position:relative} </STYLE>Note that this will affect ALL anchor and input tags on the page; you may wish to use classes to alter only the specific ones that are likely to be subject to the overlap problem. You may need to add other tags to this list as well, if there is other content that requires mouse clicks.
- Although TeX will process something like
x^\frac{1}{2}
, jsMath will not. This is beacuse TeX expands macos until it comes to a primitive command when it processes super- and subscripts, but jsMath does not implement the complete TeX macro language, and does not have the same idea of primitives (most of jsMath is implemented as "primitives" rather than macros). The solution is to use braces around the exponent:x^{\frac{1}{2}}
. Update: as of jsMath v3.2, jsMath now handlesx^\frac{1}{2}
as a special case (along with several other macros).
- The TeX commands
\eqalignno
and\leqalignno
do not place the line numbers flush right or flush left, but instead puts them in a separate column separated from the rest of the mathematics. Due to limitations within jsMath, both put the line numbers at the right. (This may be fixed in a future release.)
- The
\noalign{}
command only processes\vskip
and\vspace
commands, so can only be used to insert space within an array or alignment, not arbitrary content. (This may be fixed in a future release.)
|
|