http://my.opera.com/desktopteam/blog/2007/11/16/even-more-work
In this build, we added MathML support out of the box
http://my.opera.com/desktopteam/blog/2007/11/16/even-more-work
In this build, we added MathML support out of the box
After a wait of many years the STIX fonts have finally been released as public beta! These offer the promise of much better, more portable support for scientific documents on the web and elsewhere. The STIX fonts provide a uniform set of fonts that provide the glyphs for almost all the mathematical characters that have been added to unicode in recent years.
Initial testing suggests there may still be some problems with plane 1 characters (I just submitted the following comment to the stix beta test comment form...
I tested browser support (windows XP: Firefox, IE 7, Opera) with similar results in all three browsers. The quadruple integral displayed in all three browsers. The plane 1 alphabetic character did not display at all, FF displays 2 missing glyph boxes, IE shows 1 missing glyph box, and opera just shows white space..
I am not able to tell at this stage whether this is user error (I have not specified a sufficiently large set of the STIX fonts in CSS ?) or if this is due to lack of plane 1 support in the browsers, or if there is a problem with the unicode tables in the stix fonts, so I supply the small test file below, which I expect to render as as
QUADRUPLE INTEGRAL OPERATOR
MATHEMATICAL BOLD CAPITAL A
<html> <head> <title>stix</title> <style> p { font-family: STIXGeneral, STIXGeneral-Italic, STIXGeneral-Bold, STIXGeneral-BoldItalic; } </style> </head> <body> <p>x2a0c ⨌</p> <p>x1d400 𝐀</p> </body> </html>
There was a thread a while ago on xsl-list discussing when was a good time to switch from XSLT1 to XSLT2. The consensus seemed to be, "it depends...."
For NAG, the answer is NOW!
After a lot of regression testing, staring at diff files and crossing of fingers, we just switched the processor for our main stylesheets over from saxon 6 to saxon 8.
This is quite a large (set of) stylesheets (around 26K lines of XSLT) so is quite a substantial test of XSLT2's compatibility with XSLT1. The results were pretty good, although it's not exactly surprising as an earlier version of these stylesheets were used to request improvements to backward compatibility mode as defined in an earlier draft, all the main changes requested in that report were made.
We are taking a multi-stage process to switching to version 2:
This is far from being the first use of XSLT2 at NAG, but it's the first time we've switched a stylesheet collection from version 1 to version 2, so far things have gone pretty smoothly...
Following on from a thread on xsl-list which turned to the question of support for the useful xx:node-set() extension function in the XSLT engines used by popular browsers.
Using XPath extension functions in a cross-browser environment is greatly simplified if all the XSLT engines use the same extension namespace. This was one of the motivating reasons behind the community initiative to standardise on the EXSLT extension namespaces.
Opera's XSLT engine supports exslt:node-set, Mozilla/Firefox's XSLT engine doesn't in the current release, but does in the "Gran Paradiso" alpha tests for Firefox 3. Internet Explorer (6 and 7) don't support EXSLT, but do support the functionally identical msxsl:node-set function in the usual msxsl extension namespace.
The usual way to handle exslt:node-set and msxsl:node-set in the same document is to use xsl:choose blocks, with tests on function-available('exslt:node-set') but that is often inconvenient if you want to use xx:node-set in the middle of an XPath.
In the above XSL-List thread I casually suggested that an alternative would be to just always use exslt:node-set in the body of the stylesheet and use the msxsl:script extension to define exslt:node-set for IE. That turned out not to be as easy as I thought as node-set isn't a valid function name in either of the supported extension languages in msxsl (JScript or VBScript). However Julian Reschke came up with the construct needed, use associative array syntax so you can use ['node-set'] to define the function. A complete stylesheet using this technique is shown below
<xsl:stylesheet
version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:exslt="http://exslt.org/common"
xmlns:msxsl="urn:schemas-microsoft-com:xslt"
exclude-result-prefixes="exslt msxsl">
<msxsl:script language="JScript" implements-prefix="exslt">
this['node-set'] = function (x) {
return x;
}
</msxsl:script>
<xsl:variable name="x">
<y/>
</xsl:variable>
<xsl:template match="x">
<html>
<head><title>test exslt node set</title></head>
<body>
<xsl:apply-templates select="exslt:node-set($x)/*"/>
</body>
</html>
</xsl:template>
<xsl:template match="y">
<p>node set!</p>
</xsl:template>
</xsl:stylesheet>
The same stylesheet is online together with a test file which just consists of a stylesheet reference and an empty element <x/>.
If your browser supports EXSLT (either natively or using the technique above) viewing the test file link should show "node set!". This appears to work in Firefox Gran paradiso, Internet Explorer 7, Opera 9.21. It doesn't work in Firefox 2 (you get an error message about an unsupported extension function). Users of other browsers that support XSLT (Safari?) feel free to report any results in the comments!
Updated 2008-08-06 to move test file to a different server.
Updated 2009-12-17 to move to google code server. The file now reports that Safari 3.2 supports node-set