RE: [docbook-apps] Image manipulation via XSLT extensions
We do what you propose, but use our build system (an ant script) to call batik http://xmlgraphics.apache.org/batik/ and rasterize the images when going to html. The way we have it set up, when you insert the svg image in XMetaL, a macro sees it's an svg and pops up a dialog asking if you want it rasterized. If so, it converts it to a png and displays the png (since XMetaL can't display svg !?!). The system also runs an xslt on svgs that come from Visio to workaround a Visio bug that causes arrowheads not to appear in pngs rasterized from Visio svg source. I understand that Inkscape http://www.inkscape.org/ http://www.inkscape.org/ can also convert svgs to other formats from the command line, but I haven't tried it. David From: Colin Shapiro [mailto:[EMAIL PROTECTED] Sent: Friday, August 17, 2007 10:24 AM To: docbook-apps@lists.oasis-open.org Subject: [docbook-apps] Image manipulation via XSLT extensions Hello, Unfortunately, there is no single graphics file format that meets all needs. - Bob Bob is right. One of the biggest annoyances I have when writing documents is that, when I want to insert a graphic, I must reference and maintain multiple versions of the image file in order to accommodate the various types of output I am producing: mediaobject imageobject role=fo imagedata format=SVG fileref=figure.svg/ /imageobject imageobject role=html imagedata format=PNG fileref=figure.png/ /imageobject /mediaobject Let's say I created a figure in SVG, as in the above example. This SVG is my original image source, and in a perfect world, it would be all I'd need to carry around. But, since we can't trust SVGs with our web browsers, I must convert it to PNG and carry around another version of the file for HTML output. What if I actually could only keep the SVG, and have the stylesheet somehow convert the image to alternate formats as needed? If I run the HTML stylesheet, it sees an SVG, and calls an external program--say, ImageMagick--to convert the file to a PNG. This leads me to my question. I know that with processors like Saxon and Xalan, you can write extensions in Java/JavaScript. It seems to me that one would be able to write an extension to call ImageMagick as needed. However, I have absolutely no experience with XSLT extensions, and don't really know where to start. I do know where to find resources on the subject. However, I thought I would first post here to see if anyone has done anything similar, or thought about anything like this before. - Colin
Re: [docbook-apps] Image manipulation via XSLT extensions
Yes, I considered using my build system as well (in my case, a makefile) to run ImageMagick commands before running the XSLT processor. This is definitely the easiest way I could run external programs. However, the locations of the images (as given by the fileref attributes in the XML document) are not known until processing time. So, if I want to run another command on these images before XSLT time, I would need to first parse the XML document for the image locations with something like XMLStarlet (or even just grep and sed), run the commands, then finally run the XSLT processor. That would work, but not as nicely as doing everything at XSLT processing time. Perhaps Ant might be a better build solution than make, however. I will look into it. Colin On 8/17/07, David Cramer [EMAIL PROTECTED] wrote: We do what you propose, but use our build system (an ant script) to call batik http://xmlgraphics.apache.org/batik/ and rasterize the images when going to html. The way we have it set up, when you insert the svg image in XMetaL, a macro sees it's an svg and pops up a dialog asking if you want it rasterized. If so, it converts it to a png and displays the png (since XMetaL can't display svg !?!). The system also runs an xslt on svgs that come from Visio to workaround a Visio bug that causes arrowheads not to appear in pngs rasterized from Visio svg source. I understand that Inkscape http://www.inkscape.org/ can also convert svgs to other formats from the command line, but I haven't tried it. David -- *From:* Colin Shapiro [mailto:[EMAIL PROTECTED] *Sent:* Friday, August 17, 2007 10:24 AM *To:* docbook-apps@lists.oasis-open.org *Subject:* [docbook-apps] Image manipulation via XSLT extensions Hello, Unfortunately, there is no single graphics file format that meets all needs. - Bob Bob is right. One of the biggest annoyances I have when writing documents is that, when I want to insert a graphic, I must reference and maintain multiple versions of the image file in order to accommodate the various types of output I am producing: mediaobject imageobject role=fo imagedata format=SVG fileref=figure.svg/ /imageobject imageobject role=html imagedata format=PNG fileref=figure.png/ /imageobject /mediaobject Let's say I created a figure in SVG, as in the above example. This SVG is my original image source, and in a perfect world, it would be all I'd need to carry around. But, since we can't trust SVGs with our web browsers, I must convert it to PNG and carry around another version of the file for HTML output. What if I actually could only keep the SVG, and have the stylesheet somehow convert the image to alternate formats as needed? If I run the HTML stylesheet, it sees an SVG, and calls an external program--say, ImageMagick--to convert the file to a PNG. This leads me to my question. I know that with processors like Saxon and Xalan, you can write extensions in Java/JavaScript. It seems to me that one would be able to write an extension to call ImageMagick as needed. However, I have absolutely no experience with XSLT extensions, and don't really know where to start. I do know where to find resources on the subject. However, I thought I would first post here to see if anyone has done anything similar, or thought about anything like this before. - Colin
Re: [docbook-apps] Image manipulation via XSLT extensions
On Fri, Aug 17 2007 18:36:28 +0100, [EMAIL PROTECTED] wrote: ... However, the locations of the images (as given by the fileref attributes in the XML document) are not known until processing time. So, if I want to run another command on these images before XSLT time, I would need to first parse the XML document for the image locations with something like XMLStarlet (or even just grep and sed), run the commands, then finally run the XSLT processor. That would work, but not as nicely as doing everything at XSLT processing time. An XSLT transform to read XML and generate a batch file or shell script is probably a common occurrence: I do it quite often. You could also generate a subordinate Makefile with a target for each PNG (and an 'all' target that depends on all of them) so images are re-rasterised only when their SVG has changed (and the Makefile itself regenerated only when the XML source has changed). Perhaps Ant might be a better build solution than make, however. I will look into it. Ant's xslt/style target does make it easy to run transforms (and really pays off compared to shell scripts if you're trying to use Saxon with XML catalogs) but I would hesitate to recommend changing from Make to Ant just so Ant can run external programs, since both do that. Regards, Tony Graham. == [EMAIL PROTECTED] http://www.menteithconsulting.com Menteith Consulting Ltd Registered in Ireland - No. 428599 Registered Office: 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland -- Menteith Consulting -- Understanding how markup works == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] Image manipulation via XSLT extensions
On 8/17/07, Tony Graham [EMAIL PROTECTED] wrote: An XSLT transform to read XML and generate a batch file or shell script is probably a common occurrence: I do it quite often. You know, that's something I've never actually thought of before. Just have a stylesheet generate a shell script... Here I am trying to come up with elaborate workarounds, and this is much simpler. Just match imagedata elements, and produce a line using the value of @fileref. Thanks, you gave me some good ideas to work with. Colin
