Re: recommed upgrading to Xalan 2.5 when using document() regularly
Quoting Joerg Heinicke [EMAIL PROTECTED]: Hello Bruce, I upgraded Xalan to 2.5.1 and Xerces to 2.4.0 in the Cocoon 2.0 CVS, so they should be in the next Cocoon 2.0.x release - I guess the 5 comes after the 4 ;-) Joerg It's an indication of Cocoon 2.0.x's excellence that I'm delighted to hear there will be continued releases of it! After a few days of traffic, including a Freshmeat announcement which generates a fair number of hits, the problem I described in the parent post has not recurred and no nasties have appeared in its place. Xalan 2.5 looks like a winner, and I'm glad it will be stock in future releases. Yrs, -- Bruce Robertson, Dept. of Classics, Mount Allison University http://heml.mta.ca - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A Gzipped XML Serializer component for Cocoon
Quoting Joerg Heinicke [EMAIL PROTECTED]: There were some threads about on the developers list. IIRC they came to the conclusion to add such things to the pipeline. But after 2.1 release. One point in the discussion was, whether this is the task of Cocoon and not of Tomcat or Apache (mod_gzip). Joerg Michael Riedel wrote: Hi Bruce! I'm pretty sure this is something that eventually should be rolled into Cocoon itself, but as I note in the page, my code is a hack on the XMLSerializer, and shouldn't be ci'd as-is. Though I don't need it at this time, I agree, that gzip compression is a quite usefull. It should be included in the cocoon distribution. But I'm not sure, if compression should be handled by a serializer. What, if someone wants to compress something else than XML data. Then he'd have to rewrite another serializer to support gzip... Michael, Joerg: On the issue of if this being handled by mod_gzip or mod_deflate, Apache's own Batik Squiggle does not, in my experience, receive compressed SVG if compression is handled this way. Nor do I see why it should send a Accept-Encoding: gzip header to get *.svgz, since they are not a compressed form of the original (like html that has been gzipped by the above), but rather a proper manifestation of the document, like jpg compression. Secondly, there is the issue of sparing your cache. See the introduction to my http://wiki.cocoondev.org/Wiki.jsp?page=Gzip_XML_Serializer (I would post this to the dev group, but I never seem to be able to get subscribed to that.) I can see Michael's argument for a reader-based implementation, but efficient caching is a sine qua non for me. Could something be done with a view? I'm glad to hear this is on the radar of the developers', for whose hard work I am most grateful. Yrs, -- Bruce Robertson, Dept. of Classics, Mount Allison University http://heml.mta.ca - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
A Gzipped XML Serializer component for Cocoon
I have posted a Wiki page describing a serializer component I'm using which produces gzipped XML output. This is especially useful for those serving complex SVG and would rather send it off as a svgz file. I'm pretty sure this is something that eventually should be rolled into Cocoon itself, but as I note in the page, my code is a hack on the XMLSerializer, and shouldn't be ci'd as-is. Details at: http://wiki.cocoondev.org/Wiki.jsp?page=Gzip_XML_Serializer Yrs, -- Bruce Robertson, Dept. of Classics, Mount Allison University http://heml.mta.ca - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SVG Font Embedder for Cocoon
[This is an abridged version of a HOWTO posted at the Cocoon Wiki: http://wiki.cocoondev.org/Wiki.jsp?page=Embedding_SVG_Fonts] *Introduction* Using server-generated SVG in a multi-lingual or with complex layout inevitably leads to frustration over fonts. A map with multi-lingual text carefully layed out using the Bitstream Cyberbit font will be riddled with 'missing character' squares when rendered on a client's machine that lacks Cyberbit. The SVG specification does offer a solution to this problem: scalable font glyphs can be described within an svg:font element. With these, the client renders text using the appropriate SVG glyphs, not relying on font descriptions from the client's operating environment. But it would be completely impractical to render the entire, e.g., Cyberbit font as an SVG font and expect the client machine to upload this with each view. What is needed is a mechanism that appends to an SVG document only those glyphs necessary for it to be rendered. As it turns out, the marvellous Batik SVG Graphics2D environment has just this ability. I've tapped into it to make an xslt transformation (extended with xalan/java) which takes any SVG document and adds to it the glyphs necessary for its viewing. The result is a somewhat heavier document, but one that is completely portable. An example: http://heml.mta.ca/heml-cocoon/map.svgz? url=docs/source/heml/newton.xmlmapName=britainfontName=Melmo *Use* To use the SVGFontEmbedder, you'll need to ensure that: 1. Your Cocoon environment has the Batik jar file. Check WEB-INF/libs for a file called something like batik-all.jar. (I've tested this with Cocoon 2.0.4, which comes with the 1.5b2 Batik code.) 2. You can process an xslt file with Xalan. Xalan is the default xslt processor in Cocoon, but some people have patched in support for Saxon because of its superior speed. (It should be noted that, at present, its speed comes at the cost of being able to pass off its elements to java processes as DOM objects, a deal-breaker for me.) You'll also need to download two files: 1. heml-cocoon.jar from any Heml release v.0_5.4 or greater, found at http://heml.mta.ca/releases 2. svgEmbedFonts.xsl, the latest version of which is easiest to aquire at its view cvs page Install heml-cocoon.jar in your $COCOON_HOME/WEB-INF/libs directory, and put svgEmbedFonts.xsl wherever your xsl files usually reside. Emend your sitemap to transform your SVG files just before they are serialized as svg+xml. (Incidentally, there is no point in using this transformation before rasterizing SVG to jpg or png, since your server will have access to its own fonts when rasterizing.) For instance, an appropriate part of my sitemap looks like this: map:transform src=xslt/util/svgEmbedFonts.xsl/ Once Cocoon is duly restarted, etc., your SVG should now have the necessary svg:glyph elements automagically added. *Caveats* 1. This code will only recognize fonts specified with the font-family=MY_FONT attribute notation. You can't use style=font-family: MY_FONT and expect this process to assign the right font to your text. On the positive side, the font-family can be specified on the svg:text element or any of its ancestors, just like in any honest SVG document. -- Bruce Robertson, Dept. of Classics, Mount Allison University http://heml.mta.ca -- Bruce Robertson, Dept. of Classics, Mount Allison University http://heml.mta.ca - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Embedding SVG Fonts
The list may be interested in a Xalan/xslt/java/batik process that adds embedded font descriptions to SVG documents, making them portable. HOWTO posted at the Cocoon Wiki: http://wiki.cocoondev.org/Wiki.jsp? page=Embedding_SVG_Fonts Sample document at: http://heml.mta.ca/heml-cocoon/map.svgz? url=docs/source/heml/newton.xmlmapName=britainfontName=Melmo Yrs, -- Bruce Robertson, Dept. of Classics, Mount Allison University http://heml.mta.ca - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SVG Font Embedder for Cocoon
[This is an abridged version of a HOWTO posted at the Cocoon Wiki: http://wiki.cocoondev.org/Wiki.jsp?page=Embedding_SVG_Fonts] *Introduction* Using server-generated SVG in a multi-lingual or with complex layout inevitably leads to frustration over fonts. A map with multi-lingual text carefully layed out using the Bitstream Cyberbit font will be riddled with 'missing character' squares when rendered on a client's machine that lacks Cyberbit. The SVG specification does offer a solution to this problem: scalable font glyphs can be described within an svg:font element. With these, the client renders text using the appropriate SVG glyphs, not relying on font descriptions from the client's operating environment. But it would be completely impractical to render the entire, e.g., Cyberbit font as an SVG font and expect the client machine to upload this with each view. What is needed is a mechanism that appends to an SVG document only those glyphs necessary for it to be rendered. As it turns out, the marvellous Batik SVG Graphics2D environment has just this ability. I've tapped into it to make an xslt transformation (extended with xalan/java) which takes any SVG document and adds to it the glyphs necessary for its viewing. The result is a somewhat heavier document, but one that is completely portable. An example: http://heml.mta.ca/heml-cocoon/map.svgz? url=docs/source/heml/newton.xmlmapName=britainfontName=Melmo *Use* To use the SVGFontEmbedder, you'll need to ensure that: 1. Your Cocoon environment has the Batik jar file. Check WEB-INF/libs for a file called something like batik-all.jar. (I've tested this with Cocoon 2.0.4, which comes with the 1.5b2 Batik code.) 2. You can process an xslt file with Xalan. Xalan is the default xslt processor in Cocoon, but some people have patched in support for Saxon because of its superior speed. (It should be noted that, at present, its speed comes at the cost of being able to pass off its elements to java processes as DOM objects, a deal-breaker for me.) You'll also need to download two files: 1. heml-cocoon.jar from any Heml release v.0_5.4 or greater, found at http://heml.mta.ca/releases 2. svgEmbedFonts.xsl, the latest version of which is easiest to aquire at its view cvs page Install heml-cocoon.jar in your $COCOON_HOME/WEB-INF/libs directory, and put svgEmbedFonts.xsl wherever your xsl files usually reside. Emend your sitemap to transform your SVG files just before they are serialized as svg+xml. (Incidentally, there is no point in using this transformation before rasterizing SVG to jpg or png, since your server will have access to its own fonts when rasterizing.) For instance, an appropriate part of my sitemap looks like this: map:transform src=xslt/util/svgEmbedFonts.xsl/ Once Cocoon is duly restarted, etc., your SVG should now have the necessary svg:glyph elements automagically added. *Caveats* 1. This code will only recognize fonts specified with the font-family=MY_FONT attribute notation. You can't use style=font-family: MY_FONT and expect this process to assign the right font to your text. On the positive side, the font-family can be specified on the svg:text element or any of its ancestors, just like in any honest SVG document. -- Bruce Robertson, Dept. of Classics, Mount Allison University http://heml.mta.ca - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HOWTO: Cocoon 2.0.4 + Apache client-side caching
Quoting SAXESS - Hussayn Dabbous [EMAIL PROTECTED]: Wouldn't it be great to place this HOWTO into the cocon wiki ? regards, hussayn The HOWTO, with some additional notes from the weekend's experience, can now be found at: http://wiki.cocoondev.org/Wiki.jsp?page=CocoonAndApacheModRequest Thanks to you and Tony for kindly suggesting this. Yrs, -- Bruce Robertson, Dept. of Classics, Mount Allison University http://heml.mta.ca - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HOWTO: Cocoon 2.0.4 + Apache client-side caching
The expires function in cocoon 2.1 looks very exciting, though despite it being currently documented, I couldn't get expire to work in the 2.0 series. This was too bad, since my webapp comprises some static content, like css files and generated jpg title files, that really don't need to be passed over with each hit. Furthermore, even my cocoon-generated xhtml and svg derives from static xml documents, so a client-side cache of, say, an hour or so, would ensure that the user wouldn't hit my cocoon server again as she's navigating over a previously viewed document. This is good for my server, but it also can appreciably improve the user's experience of the site. As it happens, I'm serving cocoon through Apache, and *its* Expires module will do the job for cocoon if the setup is well-configured. (I'm using Cocoon 2.0.4 under Tomcat 4.1.15 on RH Linux 7.3 with a Apache 1.3, but I don't think that should matter much for these instructions.) 1. Make sure your Apache http.conf has: LoadModule expires_module modules/mod_expires.so and AddModule mod_expires.c somewhere in it. Mine did out of the box. 2. Make sure your mime-type configuring file has definitions for each mime-type you plan to cache on the client with Expire. On RH Linux, this would be /etc/mime.types, and I had to add a line to define svgs: image/svg+xml svg svgz 3. Append the appropriate commands to your Apache httpd.conf, thus: ExpiresActive On ExpiresByType image/svg+xml A3600 ExpiresByType text/css A3600 ExpiresByType image/jpegA3600 ExpiresByType image/png A3600 The 'Axxx' means cache the content for xxx seconds after access. I'm using a rather conservative single hour. Mod_expires has other functions. Read about them at: http://httpd.apache.org/docs/mod/mod_expires.html 4. Restart Apache, and test. I used the 'wget' utility under Linux to ensure that the 'Expire' header was being passed to the client. 'wget -S' includes the header nicely, so wget -S http://localhost/heml-cocoon/site/style/international_names.css gives: --11:12:54-- http://localhost/heml-cocoon/site/style/international_names.css = `international_names.css.4' Resolving localhost... done. Connecting to localhost[127.0.0.1]:80... connected. HTTP request sent, awaiting response... 1 HTTP/1.1 200 OK 2 Date: Fri, 10 Jan 2003 15:12:54 GMT 3 Server: Apache/1.3.23 (Unix) (Red-Hat/Linux) PHP/4.1.2 mod_gzip/1.3.19.1a mod_webapp/1.2.0-dev 4 Cache-Control: max-age=3600 5 Expires: Fri, 10 Jan 2003 16:12:54 GMT 6 Content-Type: text/css 7 Content-Length: 89 8 X-Cocoon-Version: 2.0.4 9 Connection: close 100%[] 8986.91K/sETA 00:00 11:12:54 (86.91 KB/s) - `international_names.css.4' saved [89/89] Hooray, we're caching this css file on the client for a few hours! This approach has one advantage over setting the expire within cocoon itself. Client-side caching gets in the way of development, where one wishes immediately to see the results of changes in code. As it stands, my webapp is distibuted without c-s caching, so interested parties can fiddle with it, but once installed in the project's main server the webapp's content is automagically client-side cached. Hope this helps someone, -- Bruce Robertson, Dept. of Classics, Mount Allison University http://heml.mta.ca - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Progress at and ideas from heml.mta.ca
List members may be interested in our progress at the Historical Event Markup and Linking project, which uses Cocoon to transform XML documents into historical timelines, tables maps and animations in SVG. Links to the eye-candy are just off the home page: http://heml.mta.ca (Be sure to have the latest SVG viewer from Adobe.) Since heml is a reasonably complex site, its sitemap and innards might interest those who are planning their own cocoon-based work. I can't claim it's anything like best practices, but it works. .war files tested against tomcat are available at http://heml.mta.ca/releases As well, our build process might interest those who wish to keep their Cocoon-based project current with Cocoon's libraries. Our build.xml calls the one from Cocoon, and copies over its jar files, then compiles and moves our java, xslt and xml. Upgrading to 2.0.4 was thus a matter of changing an env. variable. ViewCVS for browsing is at: http://heml.mta.ca/cgi-bin/viewcvs.cgi/heml_cvs/ Anonymous cvs: cvs -d :pserver:[EMAIL PROTECTED]:/home/heml/cvsroot checkout heml_cvs password: anoncvs Finally, a giant thank-you to those who toil at making Cocoon better and better with each release. More than two years ago, I decided to base this project in Cocoon2. Since then, I've felt as if I have a team of experts working on the nitty-gritty while I get to work on the big picture. Yrs, -- Bruce Robertson, Dept. of Classics, Mount Allison University http://heml.mta.ca - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
