[docbook-apps] MathML and fo:instream-foreign-object
Hey, In order to get MathML rendered with Antenna House's XSLFormatter, you need to wrap all MathML blocks inside a fo:instream-foreign-object element. If I (very naively) do xsl:template match=mml:* xmlns:mml=http://www.w3.org/1998/Math/MathML; fo:instream-foreign-object xsl:copy xsl:copy-of select=@*/ xsl:apply-templates/ /xsl:copy /fo:instream-foreign-object /xsl:template I get something like this in the FO file fo:instream-foreign-object xmlns:mml=http://www.w3.org/1998/Math/M athMLfo:instream-foreign-objectmml:math overflow=scroll fo:instream-foreign-objectmml:mrow fo:instream-foreign-objectmml:msup etc. All I wanted was to have the outer most MathML wrapped in the fo:instream-foreign-object element. This naturely puts my inane XSL capabilities on display, but I would still be very happy if somebody could point me at a solution. Cuurently, I use a sed command for solving the issue, but would prefer somthing that could go inside my cust. layer. All the best (and happy Easter), Mads +-+-+ | Mads Ipsen | | | Dept. of Chemistry | phone: +45-35320220 | | H.C.Ørsted Institute| fax: +45-35320322 | | Universitetsparken 5| | | DK-2100 Copenhagen Ø, Denmark | [EMAIL PROTECTED] | +-+-+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] MathML and fo:instream-foreign-object
Mads Ipsen wrote: In order to get MathML rendered with Antenna House's XSLFormatter, you need to wrap all MathML blocks inside a fo:instream-foreign-object element. If I (very naively) do Get the latest snapshot from http://docbook.sf.net/snapshots/ I have fixed exactly this week or two ago. -- -- Jirka Kosek e-mail: [EMAIL PROTECTED] http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO/JTC1/SC34 member -- Want to speak at XML Prague 2007 = http://xmlprague.cz/cfp.html signature.asc Description: OpenPGP digital signature
Re: [docbook-apps] MathML and fo:instream-foreign-object
Did you fix this: http://sourceforge.net/tracker/index.php?func=detailaid=1574016group_id=21935atid=373749 [ 1574016 ] docbook 5 imagedata svg and mml support ? Also, in the namespaced version of the xsl 1 stylesheets, is it now possible to create a version that doesn't require MathML elements to have a prefix? On 3/30/07, Jirka Kosek [EMAIL PROTECTED] wrote: Mads Ipsen wrote: In order to get MathML rendered with Antenna House's XSLFormatter, you need to wrap all MathML blocks inside a fo:instream-foreign-object element. If I (very naively) do Get the latest snapshot from http://docbook.sf.net/snapshots/ I have fixed exactly this week or two ago. -- -- Jirka Kosek e-mail: [EMAIL PROTECTED] http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO/JTC1/SC34 member -- Want to speak at XML Prague 2007 = http://xmlprague.cz/cfp.html -- http://chris.chiasson.name/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] MathML and fo:instream-foreign-object
Chris Chiasson wrote: Did you fix this: http://sourceforge.net/tracker/index.php?func=detailaid=1574016group_id=21935atid=373749 [ 1574016 ] docbook 5 imagedata svg and mml support ? No, I will look into this issue later, hopefully during the weekend. Also, in the namespaced version of the xsl 1 stylesheets, is it now possible to create a version that doesn't require MathML elements to have a prefix? XSLT is not prefix aware, so you can use any prefix for your MathML elements, including using no prefix and relying on default namespace, like: article titleMathML test/title paraFraction inlineequationmath xmlns=http://www.w3.org/1998/Math/MathML;mfracmn1/mnmin/mi/mfrac/math/inlineequation/para /article -- -- Jirka Kosek e-mail: [EMAIL PROTECTED] http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO/JTC1/SC34 member -- Want to speak at XML Prague 2007 = http://xmlprague.cz/cfp.html signature.asc Description: OpenPGP digital signature
Re: [docbook-apps] MathML and fo:instream-foreign-object
On 3/30/07, Jirka Kosek [EMAIL PROTECTED] wrote: Also, in the namespaced version of the xsl 1 stylesheets, is it now possible to create a version that doesn't require MathML elements to have a prefix? XSLT is not prefix aware, so you can use any prefix for your MathML elements, including using no prefix and relying on default namespace, like: article titleMathML test/title paraFraction inlineequationmath xmlns=http://www.w3.org/1998/Math/MathML;mfracmn1/mnmin/mi/mfrac/math/inlineequation/para /article Does this work with the current stylesheets, or is it still looking for elements with the mml: (or svg: ) prefix? I think the reason the old stylesheets needed the prefixes was that they did not use namespaces. Is that true? -- http://chris.chiasson.name/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] MathML and fo:instream-foreign-object
Chris Chiasson wrote: Does this work with the current stylesheets, Yes, but at this time you have to download snapshot release. or is it still looking for elements with the mml: (or svg: ) prefix? I think the reason the old stylesheets needed the prefixes was that they did not use namespaces. Is that true? No, stylesheet can use completely different prefixes then instance. Matching is done on namespace name (URI). I'm probably misunderstanding your problem here. -- -- Jirka Kosek e-mail: [EMAIL PROTECTED] http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO/JTC1/SC34 member -- Want to speak at XML Prague 2007 = http://xmlprague.cz/cfp.html signature.asc Description: OpenPGP digital signature
Re: [docbook-apps] MathML and fo:instream-foreign-object
On 3/30/07, Jirka Kosek [EMAIL PROTECTED] wrote: Chris Chiasson wrote: Does this work with the current stylesheets, Yes, but at this time you have to download snapshot release. or is it still looking for elements with the mml: (or svg: ) prefix? I think the reason the old stylesheets needed the prefixes was that they did not use namespaces. Is that true? No, stylesheet can use completely different prefixes then instance. Matching is done on namespace name (URI). I'm probably misunderstanding your problem here. In html/math.xsl, there were some lines like this: !-- Support for MathML -- xsl:template match=mml:* xmlns:mml=http://www.w3.org/1998/Math/MathML; xsl:copy xsl:copy-of select=@*/ xsl:apply-templates/ /xsl:copy /xsl:template As far as I know, this means that MathML was only passed through if it had an mml: prefix. I assume this was done because of the non-namespaced template matching. So, is that a correct assessment? Is the requirement for the prefix still present? -- http://chris.chiasson.name/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [docbook-apps] generating a JavaHelp glossary file
-Original Message- From: Brett Leber I'm wondering if it's possible to generate a JavaHelp glossary file from DocBook source using the existing style sheets. No, it is not possible. This JavaHelp 2.0 feature is currently not supported in the stock JavaHelp stylesheet. /MJ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] generating a JavaHelp glossary file
Thanks. Would be a nice extension to the stock JavaHelp stylesheet. Brett On 3/30/2007 11:07 AM, Mauritz Jeanson wrote: -Original Message- From: Brett Leber I'm wondering if it's possible to generate a JavaHelp glossary file from DocBook source using the existing style sheets. No, it is not possible. This JavaHelp 2.0 feature is currently not supported in the stock JavaHelp stylesheet. /MJ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] MathML and fo:instream-foreign-object
- Original Message - From: Chris Chiasson [EMAIL PROTECTED] To: Jirka Kosek [EMAIL PROTECTED] Cc: Mads Ipsen [EMAIL PROTECTED]; docbook-apps@lists.oasis-open.org Sent: Friday, March 30, 2007 1:56 AM Subject: Re: [docbook-apps] MathML and fo:instream-foreign-object On 3/30/07, Jirka Kosek [EMAIL PROTECTED] wrote: Chris Chiasson wrote: Does this work with the current stylesheets, Yes, but at this time you have to download snapshot release. or is it still looking for elements with the mml: (or svg: ) prefix? I think the reason the old stylesheets needed the prefixes was that they did not use namespaces. Is that true? No, stylesheet can use completely different prefixes then instance. Matching is done on namespace name (URI). I'm probably misunderstanding your problem here. In html/math.xsl, there were some lines like this: !-- Support for MathML -- xsl:template match=mml:* xmlns:mml=http://www.w3.org/1998/Math/MathML; xsl:copy xsl:copy-of select=@*/ xsl:apply-templates/ /xsl:copy /xsl:template As far as I know, this means that MathML was only passed through if it had an mml: prefix. I assume this was done because of the non-namespaced template matching. So, is that a correct assessment? Is the requirement for the prefix still present? Hi Chris, No, that is not the correct assessment. 8^) The prefix string does not matter, all that matters in the stylesheet is that there is a prefix in the match attribute, and it is assigned to the mathml namespace name http://www.w3.org/1998/Math/MathML using the xmlns attribute. That assignment can be done on the root element of the stylesheet so the namespace scope is the entire stylesheet, or in the individual stylesheet elements as is done here. Your document can use a different prefix, or use the default namespace, as long as the namespace name is assigned. The above template will match on all of these elements in your document: m:mml xmlns:m=http://www.w3.org/1998/Math/MathML; math:mml xmlns:math=http://www.w3.org/1998/Math/MathML; bob:mml xmlns:bob=http://www.w3.org/1998/Math/MathML; mml xmlns=http://www.w3.org/1998/Math/MathML; It will *not* match on mml:mml if the namespace prefix mml: is not assigned to the namespace name. Hope that helps. Bob Stayton Sagehill Enterprises DocBook Consulting [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] Carriage Return/Line Feed within informaltable cells on PDF
That's a lot simpler than the way I had done it in the past. Thanks.
Colin
On 3/29/07, Ron Catterall [EMAIL PROTECTED] wrote:
It's very easy to put in an extra fo block to act as a line break
!-- PI to cause a line break - usage ?lb? --
xsl:template match=processing-instruction('lb')
fo:block/
/xsl:template
Does this help?
Ron
I have personally never been able to get any kind of line breaks to work
by attempting to insert them into a source file.
Instead, I have had to do things with a customization layer in XSLT, to
produce separate fo:block elements to break lines.
I can post an example if you'd like, but in the meantime I'd like to know
if anyone else has a better solution.
Colin
On 3/29/07,* D_A_U* [EMAIL PROTECTED] wrote:
Hello,
I am new here and especially new with using Docbook. I want to create
Reports with results of softwaretests.
I used an informaltable. Within the tablecells I have text with includes a
char(10) -- Carriage return.
The PDF result ignores these CR/LF.
Does someone know to solve this? I can also transform the chr(10) to an
other character before converting.
Thanks
--
View this message in context:
http://www.nabble.com/Carriage-Return-Line-Feed-within-informaltable
-cells-on-PDF-tf3488163.html#a9740072
Sent from the docbook apps mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ron Catterall, Phd, DSc email: [EMAIL PROTECTED]
Prolongacion de Hidalgo 140
http://catterall.net/
San Felipe del Aguatel: +52 951
520 1821
Oaxaca 68020 Mexico fax: +1 530 348 8309
Re: [docbook-apps] Stripping comments
You could use XSLT, but you might not like the results. 8^) You start with an identity stylesheet such as the following: ?xml version=1.0? xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; version=1.0 xsl:output indent=no/ xsl:template match=node()|@* xsl:copy xsl:apply-templates select=@*/ xsl:apply-templates/ /xsl:copy /xsl:template /xsl:stylesheet Then you add a template to strip out comments: xsl:template match=comment()/ There are several problems with using XSLT though: 1. Entity references are expanded, not preserved as entity references. You can't hide them in XSLT because the parser expands them before the stylesheet sees them. 2. Any DOCTYPE declaration is removed. You have to copy your doctype public and system identifiers to the xsl:output element's doctype-public and doctype-system attributes. The stylesheet can't do it, because the DOCTYPE is not accessible to XPath. Any internal DTD subset is lost, as there is no way for xsl:output to specify it. 3. Default DocBook attributes are added. You will end up with a lot of moreinfo=none attributes on elements like literal. 4. The output will differ in other ways because the XML is parsed and then re-serialized: attribute order may be different, empty elements may be expressed differently, character references will become native UTF-8 (unless you specify a different output encoding). These differences will show up in a text diff program, but not an XML-aware differencing program. Generally, I use Perl for such filtering. The XML comment string is a well defined regular expression, and Perl doesn't mess with any XML stuff. I read the entire file into a single string, globally replace comments with nothing, and then print the string. Bob Stayton Sagehill Enterprises DocBook Consulting [EMAIL PROTECTED] - Original Message - From: Paul Moloney [EMAIL PROTECTED] To: docbook-apps@lists.oasis-open.org Sent: Thursday, March 29, 2007 6:45 AM Subject: [docbook-apps] Stripping comments One task I have it to package our source XML files for use by integrators; one thing I'd like to do is first strip the comments from these files as they may contain sensitive information. I was thinking that this could be done by processing each file through Saxon using a stylesheet which strips out comments and outputs the XML again. But rather than risk reinventing the wheel, I was wondering if anyone out there has implemented a DocBook comment stripper in their build process? Thanks, P. -- View this message in context: http://www.nabble.com/Stripping-comments-tf3486783.html#a9734912 Sent from the docbook apps mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] Stripping comments
Here's a quick perl solution that doesn't read everything into
memory and seems to handle some of the edge cases. Try it out on a
few things to verify that everything is okay before completely
trusting it, though. :)
Copy the lines between '' into a file (say
strip_xml_comments.pl).
(if on Unix do this step first)
chmod 755 strip_xml_comments.pl
Make a backup copy of any and all files that you'll be using. (The
script should work fine as is, but it's *MUCH* better to be safe than
sorry. :)
Now you should be able to run the script on a copy of your input file.
strip_xml_comments.pl my_xml_input_file.xml
The script will make a backup copy of its own with '.orig' at the
end of the name. (Please don't just rely on this feature -- make your
own backup.)
Verify that everything looks okay and integrate it into your
application stream.
Here's the script
--
#!/usr/bin/perl -w -i.orig
#
# NB: Delete the '.orig' portion if backup copies are not desired
#
#
# Delete XML comments.
#
#
# Go through every file given on the command line
#
$in_comment= 0;
while( ) {
#
# Match inline comments
#
s {
!--# Match the opening delimiter.
.*? # Match a minimal number of characters.
-- # Match the closing delimiter.
} []gsx;
#
# Match multi-line comments
#
if( /!--/ ) {
$in_comment= 1;
next;
}
#
# Find the end of a multi-line comment and remove everything to that point.
# NB: All other in-line comments have already been removed
#
if( /--/ ) {
s/.*--//;
$in_comment= 0;
}
#
# Ignore every line in the comment
#
if( $in_comment ) {
next;
}
print; # Print everything on the current line
}
--
Note that the code is a simple modification of one of the examples
from the perlre man page (http://perldoc.perl.org/perlre.html).
Hopefully this will suit your purposes!
kells
- Original Message -
From: Paul Moloney [EMAIL PROTECTED]
To: docbook-apps@lists.oasis-open.org
Sent: Thursday, March 29, 2007 6:45 AM
Subject: [docbook-apps] Stripping comments
One task I have it to package our source XML files for use by
integrators;
one thing I'd like to do is first strip the comments from these files as
they may contain sensitive information.
I was thinking that this could be done by processing each file through
Saxon
using a stylesheet which strips out comments and outputs the XML again.
But
rather than risk reinventing the wheel, I was wondering if anyone out
there
has implemented a DocBook comment stripper in their build process?
Thanks,
P.
--
View this message in context:
http://www.nabble.com/Stripping-comments-tf3486783.html#a9734912
Sent from the docbook apps mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[docbook-apps] Re: [xep-support] cover pages front and back
Bob Stayton wrote: Hello, The DocBook XSL stylesheets currently don't provide direct support for covers, only front title pages. Covers can come in a variety of configurations, such as single-sheet for front and back, wrap-around with spine, or wrap-around without spine for saddle stitch. Text placement and graphics are highly individual, so it is hard to write a general-purpose stylesheet for all possible designs. Also, cover PDFs are often produced separately because their production process (color, heavier stock) may differ from the process for the book block. While I agree with all that, it would still be very useful if there were some way to automatically stitch a cover provided from another source together with the DocBook XSL output; ideally without mucking up the page counts either. I.e. assume I have one of these: 1. A PDF or other graphic wrap around cover generated from another program 2. Separate graphic covers fro front and back and spine 3. An XML source document along with my own stylesheet to generate the covers in XSL-FO Given one of those three inputs, would it be possible to somehow parameterize the DocBook XSL stylesheets so it could add extra pages for the front and back covers and pull in the external PDF (or GIF/PNG/etc.) to make covers in the PDF? I know we can;t do that now, but would this much be hard to add? Also is there any sort of de facto standard for where the covers appear in pure PDF? e.g. if I buy a Pragmatics or O'Reilly or APress eBook, are the covers in the PDF I buy and if so where? From a quick scan of the few such PDF books I have handy, it seems the front cover is included as a graphic on the first page. The back cover and spine are not included. If nothing else, this is actually quite useful for Finder previews in Mac OS X. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [docbook-apps] Re: [xep-support] cover pages front and back
You can get something pretty cover-like just using titlepages for front covers IMO. You can't do full page covers (e.g. with things that look like bleeds). If you need something fancy like that you need to write some custom stuff at this point. Here's a pretty old and kludgy example http://www.dpawson.co.uk/docbook/styling/titlepage.html#d2587e176 Since covers are so custom, maybe it's just a matter of adding a hook for cover code to the base xsls? David -Original Message- From: Elliotte Harold [mailto:[EMAIL PROTECTED] Sent: Friday, March 30, 2007 1:35 PM To: docbook-apps@lists.oasis-open.org Cc: [EMAIL PROTECTED] Subject: [docbook-apps] Re: [xep-support] cover pages front and back Bob Stayton wrote: Hello, The DocBook XSL stylesheets currently don't provide direct support for covers, only front title pages. Covers can come in a variety of configurations, such as single-sheet for front and back, wrap-around with spine, or wrap-around without spine for saddle stitch. Text placement and graphics are highly individual, so it is hard to write a general-purpose stylesheet for all possible designs. Also, cover PDFs are often produced separately because their production process (color, heavier stock) may differ from the process for the book block. While I agree with all that, it would still be very useful if there were some way to automatically stitch a cover provided from another source together with the DocBook XSL output; ideally without mucking up the page counts either. I.e. assume I have one of these: 1. A PDF or other graphic wrap around cover generated from another program 2. Separate graphic covers fro front and back and spine 3. An XML source document along with my own stylesheet to generate the covers in XSL-FO Given one of those three inputs, would it be possible to somehow parameterize the DocBook XSL stylesheets so it could add extra pages for the front and back covers and pull in the external PDF (or GIF/PNG/etc.) to make covers in the PDF? I know we can;t do that now, but would this much be hard to add? Also is there any sort of de facto standard for where the covers appear in pure PDF? e.g. if I buy a Pragmatics or O'Reilly or APress eBook, are the covers in the PDF I buy and if so where? From a quick scan of the few such PDF books I have handy, it seems the front cover is included as a graphic on the first page. The back cover and spine are not included. If nothing else, this is actually quite useful for Finder previews in Mac OS X. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/ca feaulaitA/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] MathML and fo:instream-foreign-object
On 3/30/07, Bob Stayton [EMAIL PROTECTED] wrote: Hi Chris, No, that is not the correct assessment. 8^) Heh, my apologies :] The prefix string does not matter, all that matters in the stylesheet is that there is a prefix in the match attribute, and it is assigned to the mathml namespace name http://www.w3.org/1998/Math/MathML using the xmlns attribute. That assignment can be done on the root element of the stylesheet so the namespace scope is the entire stylesheet, or in the individual stylesheet elements as is done here. Your document can use a different prefix, or use the default namespace, as long as the namespace name is assigned. The above template will match on all of these elements in your document: m:mml xmlns:m=http://www.w3.org/1998/Math/MathML; math:mml xmlns:math=http://www.w3.org/1998/Math/MathML; bob:mml xmlns:bob=http://www.w3.org/1998/Math/MathML; mml xmlns=http://www.w3.org/1998/Math/MathML; (that last example is the one most like what I am looking to match) Would the old docbook stylesheets template (the one that did the namespace stripping) match on this example? What about the new version that keeps the namespaces? I assume that the new version is able to match because it can use the namespace instead of just the prefix (so it doesn't require a prefix). Example XML: math xmlns=http://www.w3.org/1998/Math/MathML; some math ml elements in here/ /math Sorry for so many questions. If I have more I'll resolve them via experimentation instead of filling up the mailing list :-] -- http://chris.chiasson.name/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
