RE: [docbook-apps] programlisting page breaks
Hi Dick, It sounds like what would happen if you have a keep-together on a fo:block around the code listing. I'd check for that. I also did a quick test with a document that has long code listings: Using XEP and our customization layer which is based on the 1.72.0 xsls, everything is fine. However, using FOP and the 1.76.1 xsls included in the latest version of Oxygen, the long code listings are pretty messed up (even worse than what you describe). David -Original Message- From: hamil...@xmlpress.net [mailto:hamil...@xmlpress.net] Sent: Monday, February 14, 2011 10:54 AM To: docbook-apps@lists.oasis-open.org Subject: [docbook-apps] programlisting page breaks I ran into a curious behavior with programlistings, and I wonder if anyone knows how to work around it. I have some programlistings that are longer than one page and will need to break. That's fine, but what's strange is that regardless of where the programlisting would naturally start, there is always a page break before the listing starts. Even if the text that precedes the programlisting extends only a few lines down a page, there will be a page break before the programlisting begins. That can lead to there being 2/3 or more of a page blank for no good reason. I'll dive into the code at some point, but if anyone has already handled this, I'd appreciate pointers, suggestions, or solutions. Best Regards, Dick Hamilton - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
RE: [docbook-apps] Ideas for GSoC 2011
Indeed, that's on the list for WebHelp: Add an option to use Lucene for server-side searches with table of contents state persisted on the server. http://wiki.docbook.org/topic/WebHelpGsoc2011 It would be good for situations where running Eclipse as a war is too heavy and presumably simpler to get working in a variety of app servers than an eclipse.war is. David -Original Message- From: Rowland, Larry [mailto:larry.rowl...@hp.com] Sent: Thursday, February 10, 2011 5:12 PM To: Jirka Kosek; denis.bradf...@verizon.net Cc: docbook-apps@lists.oasis-open.org Subject: RE: [docbook-apps] Ideas for GSoC 2011 I think that's a great idea. It would also be helpful to extend it to work as a component in a TomCat environment where Lucene could replace the search engine (for larger help environments). Larry Rowland -Original Message- From: Jirka Kosek [mailto:ji...@kosek.cz] Sent: Thursday, February 10, 2011 8:46 AM To: denis.bradf...@verizon.net Cc: docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] Ideas for GSoC 2011 Denis Bradford wrote: That said, Help 3 seems likely to eventually take hold. And since the outputs will be mostly straight XHTML, maybe it's not too risky to get started on the DocBook stylesheets. Or we can decide not to wait for MS and build just packaging to Web Widgets, or Air, or iPad, or Android application, or... of WebHelp output. Almost any platform now supports applications written purely in HTML, CSS and Javascript and packaged for easy installation. This is something worth to explore. And it is more sexy then boring VisualStudio help ;-) Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz 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 --
RE: [docbook-apps] Cascading Stylesheet for DocBook XML
Hi Sanjaya, Also, please don’t feel limited to the ideas posted. As you explore the DocBook tools and the features it has and doesn’t you may come up with your own idea for a project. According to Google, those are often the most successful. David From: Sanjaya Liyanage [mailto:sanjay...@gmail.com] Sent: Thursday, January 27, 2011 10:16 AM To: Kasun Gajasinghe Cc: Docbook Apps Subject: Re: [docbook-apps] Cascading Stylesheet for DocBook XML Hi Kasun, Thank you very much for your reply.I am following the DocBook: The Definitive Guide and haven't yet touched the DocBook XSL: The Complete Guide.DocBook community seems to be very friendly and helpful and thus I am encouraged.Again thank you for sharing your ideas with me. Regards Sanjaya On Thu, Jan 27, 2011 at 6:05 PM, Kasun Gajasinghe kasun.gajasin...@gmail.commailto:kasun.gajasin...@gmail.com wrote: Hi Sanjaya, It's nice to see that you are interested in DocBook. As a start to DocBook, you may refer the following two great books DocBook: The Definitive Guide and DocBook XSL: The Complete Guide [1] [2]. The first book covers the DocBook schema and is a good reference book. The second book covers almost all the things you need to know about DocBook XSL styling. I think you will need these two books a lot for this project! :) Further, I hope you went through this year's GSoC ideas list and the last year's ideas list? [3] [4] Some of the last year's ideas were already implemented (4 successful project IIRC!), and I'm not sure whether those ideas will be eligible for this year. Probably they will! Regards, --Kasun [1] http://www.docbook.org/tdg5/en/html/docbook.html [2] http://www.sagehill.net/docbookxsl/ [3] http://wiki.docbook.org/topic/GSoC2011Ideas [4] http://docbook.xmlpress.net/tiki-index.php?page=Ideas On Thu, Jan 27, 2011 at 4:20 PM, Sanjaya Liyanage sanjay...@gmail.commailto:sanjay...@gmail.com wrote: Hi dev, I'm Sanjaya Liyanage and a final year undergraduate student of faculty of Computer Science Engineering,University of Moratuwa,Sri Lanka.I would like to hold the Cascading Stylesheet for DocBook XML project as my this year gsoc project.These days I'm getting familiarised on DocBook and CSS.I will be pleased if anyone can share anything regards this idea as I don't have a clear idea on what are the expectations of this idea and what are the goals I must achieve. Thank you very much,
[docbook-apps] GSoC 2011 ideas page
Hi there, Towards the end of last year's Google Summer of Code, I started a wiki page [1] with some possible projects for 2011 in case we decide to participate again and are accepted as a mentoring org. I've recently gotten a couple of questions from students who are thinking ahead and doing some research (Good for them!). So we should start thinking now if we do intend to apply to be a mentoring org and if so, who is willing to mentor. I'm thinking I should remove any ideas on that page for which we will not have anybody willing to mentor to avoid having a student work on a proposal which we wouldn't be able to accept. If students are looking at the page already, then we can expect to have more and better applications this year, but we cannot accept any for which we don't have a committed mentor. Also, let me know if there are problems with any of the ideas I posted (aside from needing mentors). For example, for implementing the transclusion proposal, 1) it's only a draft proposal, and 2) I know Jirka has a prototype implementation of the proposal, so between those two things I don't know if it's a viable project. Is the remaining work too small for a GSoC project? Likewise with the programmatically create a DTD/XSD from the RelaxNG proposal, is that the appropriate size for a GSoC project? Please post your own ideas to that page and indicate if you're willing to mentor for any of the projects. If you want to know what mentoring was like, there are several of us here who can share our experiences from last year. Thanks, David [1] http://wiki.docbook.org/topic/GSoC2011Ideas - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
RE: [docbook-apps] Manually forcing line breaks?
Perhaps you could programmatically process the input file somewhere along the way (e.g. the fo file before rendering the pdf) to change the space(s) after le, la, and les to #160; (a non-breaking space). David -Original Message- From: Faehndrich Philippe [mailto:phfaehndr...@bluewin.ch] Sent: Friday, December 17, 2010 1:10 PM To: docbook-apps@lists.oasis-open.org Subject: [docbook-apps] Manually forcing line breaks? Good evening, Please excuse me if I'm not on the right mailing list. In my document, at different levels (chapter, sect1), I have sometimes very long lines as titles. The docbook xsl-fo stylesheet break these lines, but don't follow the rules of a «nice» french typography (articles like «le», «la», «les» shouldn't stay at the end of a line, but should be pushed at the beginning of the following line - of course only for the PDF output, it doesn't matter for the HTML output). In the final version of my document, I'm ready to take a few time to have a «nicer» result. Is there a way to force line breaks in my docbook source document? I can't find anything about this topic in the documentation. Philippe Faehndrich - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
RE: [docbook-apps] db5 svg images
I haven't gotten around to trying out svgweb [1] with DocBook content yet, but it looks to me like the most promising solution to the problem. David [1] http://code.google.com/p/svgweb/ -Original Message- From: Steve Johnson [mailto:ste...@caringo.com] Sent: Thursday, December 16, 2010 10:44 AM To: Dave Pawson Cc: docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] db5 svg images SVG viewer is EOL: http://www.adobe.com/svg/viewer/install/ There could likely be more to it, such as what exact format you do your SVG in. Adobe Illustrator has 9 or 10 different combinations of options, at least. On 12/16/2010 10:11 AM, Dave Pawson wrote: On Thu, 16 Dec 2010 09:33:31 -0600 Steve Johnsonste...@caringo.com wrote: If you're outputting to HTML you should consider doing it like this: mediaobject imageobject role=fo imagedata format=SVG scale=75 fileref=Graphics/cluster-general.svg align=center scalefit=1//imageobject imageobject role=html imagedata format=PNG scale=90 fileref=Graphics/cluster-general.png align=center//imageobject /mediaobject I found that IE8 doesn't render SVG at all and Chrome puts a box around each one such that you have horizontal and vertical scroll bars .. but that could be due to the fact our HTML must fit into a 600 pixel horizontal space. You will find the above if you search Stayton's book for svg. I can create the png form if needed, but I'm concerned about the error (if it is such). I'm wondering if Bobs pages are out of date here? http://www.sagehill.net/docbookxsl/SVGimages.html I do recall 'prompting' the IE user to get/install the svg viewer from Adobe. Not sure if that's still available. Then the reader would know something was amiss. SVG is so much better than bit-mapped though. regards -- Steve Johnson, Senior Content Developer Caringo ste...@caringo.com - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] RE: Problem with cover
This is probably a hack, but have you tried using negative margin values on the
region-body? Here’s what I do (works with xep):
fo:region-body
margin-bottom=-.02in
margin-top=-.02in
margin-left=-.02in
margin-right=-.02in
background-repeat=no-repeat
background-image=url({$motive.component.cover.path})
In addition, if you use a background image like that and are using xep, there
are some extensions you can use to control the size of the background image:
xsl:if
test=$xep.extensions != '0'
xsl:attribute name=rx:background-content-width8.54in!-- xsl:value-of
select=$page.width/ --/xsl:attribute
xsl:attribute name=rx:background-content-height!-- xsl:value-of
select=$page.height/ --11.04in/xsl:attribute
/xsl:if
/fo:region-body
…
David
From: williamflawre...@eaton.com [mailto:williamflawre...@eaton.com]
Sent: Friday, December 10, 2010 2:33 PM
To: docbook-apps@lists.oasis-open.org
Subject: [docbook-apps] Problem with cover
Hi All,
I’m having a bit of trouble with custom covers. I’ve trying to display an 8.5”
x 11” graphic on the cover that essentially takes up the entire page. It
displays with the top and bottom aligned, but it’s indented to the right. The
following is in my customization layer.
xsl:template name=front.cover
xsl:call-template name=page.sequence
xsl:with-param name=master-referencefront-cover/xsl:with-param
xsl:with-param name=content
fo:block alignment-adjust=before-edge
fo:external-graphic src=url(book_cover_deploy.png)/
/fo:block
/xsl:with-param
/xsl:call-template
/xsl:template
xsl:template name=user.pagemasters
fo:simple-page-master master-name=front-cover
page-width={$page.width}
page-height={$page.height}
margin-top=0pt
margin-bottom=0pt
margin-left=0pt
margin-right=0pt
fo:region-body
margin-top=0pt
margin-bottom=0pt
margin-left=0pt
margin-right=0pt/
/fo:simple-page-master
/xsl:template
Thanks in advance.
Bill Lawrence
[docbook-apps] RE: 'WebHelp' from from DocBook: Browsers and operating systems; translation of UI; performance; authoring of DocBook files
Hi Christian, I'm posting this to the docbook-apps mailing list so we can continue the thread there since your questions pertain to DocBook generally. Also, other members of the community might have things to contribute. Yes, you can produce WebHelp from simplified DocBook. WebHelp is based on the DocBook xslts which handle the full DocBook DTD/schema. Simplified DocBook is limited to a subset of the DocBook elements but has all the constructs you would need to write a document you wish to transform into WebHelp. Currently, the DocBook xslts can handle most versions of DocBook certainly back to 4.4. I don't know how far back though. If you're starting a new project, then go with 5.0 and find an editor that understands RelaxNG schemas. If you end up needing to customize the schema, RelaxNG is a joy to work with compared to DTDs. There's a transition guide [1] with some information about DocBook 4.x v. 5.x I've worked some with MoinMoin's DocBook support and gotten it to work. Mostly we did small pages (e.g. release notes) without much hyperlinking. I believe it worked if you included several other pages into a wrapper page and converted the wrapper to DocBook. MoinMoin is written in Python so if that's a language you like, you can probably make it do what you want. In general I think a wiki2docbook solution is an ok idea for light documentation needs, such as release notes, whitepapers, and such, but if you plan to do anything sophisticated, then a wiki as authoring tool may not be the right choice. Wikis are good at making easy things easy. DocBook/XML has the semantic richness to make hard things possible. The lightweight markup of a wiki inherently limits what you can do on the DocBook/XML side. David [1] http://www.docbook.org/docs/howto/ Simplified DocBook I have found out that tools which generate DocBook files out of other formats (e.g. OpenOffice, moinmoin wiki, mediaWiki) often use Simplified DocBook instead of DocBook. One of its biggest limitations seems to be: This subset for single documents (articles, white papers, etc.), so there's no need for books or sets, just 'articles'. Would DocBook still be a usable input for WebHelp, i.e. would all the features of WebHelp be available? DocBook Versions I have also found out that tools which generate DocBook files out of other formats generate DocBook files in a variety of versions, e.g. 4.4, 4.5, 5.0. Are documents in all of those versions a usable input for WebHelp, i.e. would all the features of WebHelp be available when using any of those versions? moinmoin wiki (or other wikis) Have you got any experience with exporting several linked wiki pages (starting from one 'landing' page, then all other pages by traversing all links from that page recursively) from moinmoin wiki (or other wiki) into DocBook and using that as an input for WebHelp? If so, were the page nesting/traversing structure, links and images preserved? We are currently using mediaWiki and in my experiments with tools for creating DocBook files out of it those were the things that didn't work!
RE: [docbook-apps] acronyms, abbreviations, definitions
On Tue, 16 Nov 2010 19:38:51 + Rowland, Larry larry.rowl...@hp.com wrote: Actually, if you read the entire message, I was not suggesting that the rendered document have the content in a different location, I was suggesting that there was already markup available to represent the binding of the expansion to the acronym or abbreviation. I am well aware that the rendered content has to have the expansion information attached to the element itself. I still feel that centrally locating the association is preferable in a modern document that is potentially delivered via the Web with entry points that may be based on search results or other non-narrative paths through a document. Centrally locating the associated expansion reduces redundant coding. But this isn't a glossary entry Larry? It's semantically wrong IMHO. DaveP Really? You come across glosstermacronymTLA/acronym/glossterm in a document and don't know what TLA means...so you look to the glossary and find glossentryglosstermacronymTLA/acronym/glosstermglossseeThree Letter Acronym/glosssee/glossentry (and then to a separate entry for Three Letter Acronym which defines it). What could be more semantically pure than that? Larry is just suggesting that the OP do some stylesheet customization to leverage the existing DocBook markup and meet usability needs. There's probably room for enhancements to the schema (an otherterm attribute on acronym and abbrev?), but there's something to work with now including a nifty feature for maintaining a centralized glossary. David - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
RE: [docbook-apps] acronyms, abbreviations, definitions
But this isn't a glossary entry Larry? It's semantically wrong IMHO. DaveP Really? You come across glosstermacronymTLA/acronym/glossterm in a document and don't know what TLA means... OK, I'll play dumb. I want to use acronym, with an expansion, in a para David. The fact that it's an acronym in a glossary is of little use to me and any blind user having the text read to him/her? OK. RFE submitted. My understanding of Larry's suggestion is that the OP customize the stylesheets so that acronyms and abbreviations (only the first instance in a book or the first instance in a chunk in html) contain the appropriate stuff in the result. The data regarding the expanded form is stored in the master glossary. The stylesheets do the work of looking it up and supplying the appropriate markup in the output. In pdf, the stylesheets expand the first occurrence of glossterm linkend=tla.glossaryabbrevTLA/abbrev/glossterm to TLA (Three Letter Abbreviation) (maybe with a hyperlink to the glossary for online users) and add the term to the glossary. In chunked html, the stylesheets do whatever is going to make screen readers happy or is going to meet your needs for a given context (e.g. tooltip definitions for sighted users). The main suggestion is that instead of storing the expanded form in each abbrev/acronym in the source, you store it in one place. Ideally, in your authoring environment you would also provide a convenient way for writers to add entries from the master glossary. So I don't think there's really any disagreement. This is more a suggestion of how to manage the information on the source side, not anything about the details of what you should do on the output side. David - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
RE: [docbook-apps] Docbook Webhelp: saxparser problem
Hi David, What version of ant are you using? I've just discovered that the webhelp build.xml fails with ant 1.8.1 (and I know it works with 1.6.5 to 1.8.0), however it fails at a different point and with a different error than you're seeing. David -Original Message- From: David Priest [mailto:d...@davidpriest.ca] Sent: Wednesday, November 17, 2010 2:27 PM To: docbook-apps@lists.oasis-open.org Subject: [docbook-apps] Docbook Webhelp: saxparser problem I've been trying to implement in Ant the indexer part of the Docbook Webhelp transformation. I have this error: [major snippage] [xslt] JAXP: find factoryId =javax.xml.parsers.SAXParserFactory [xslt] JAXP: loaded from fallback value: com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl [xslt] JAXP: created new instance of class com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl using ClassLoader: null [echo] Indexing html files in /Users/davidp/dev/release-docs/Admin_Guide-webhelp/content [indexertask] JAXP: find factoryId =javax.xml.parsers.SAXParserFactory [indexertask] JAXP: found system property, value=org.apache.xerces.jaxp.SAXParserFactoryImpl BUILD FAILED /Users/davidp/dev/davidpriest/ant/publish.xml:420: javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.SAXParserFactoryImpl not found at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:13 4) at com.nexwave.nquindexer.SaxDocFileParser.parseDocument(SaxDocFileParser. java:67) [snip] There are a nigh-infinite number of debug messages where JAXP loads from fallback. And *immediately* before the indexer is fired-up, JAXP does exactly the same thing as had worked for every other step of the transformation process. But then, whack, nquindexer craps out when it tries to execute its indexer task. I have tried to point it directly at xerces by including it in the indexer's classpath. I've tried eliminating classes that I think might contain a sax parser of their own (but, then, if those were interfering, I'd expect the other debug messages to indicate that). I should note that my Ant indexertask is copied directly from the script provided with Docbook's Webhelp. Does anyone have any hints on how I can resolve this issue? Thanks in advance david - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
RE: [docbook-apps] Docbook Webhelp: saxparser problem
Hi David, Btw., I got webhelp to work with 1.8.1 by adding the following to my CLASSPATH: xercesImpl.jar xml-apis.jar saxon.jar I did a diff of the ant 1.8.0 and 1.8.1 distribution and noticed that xercesImpl.jar and xml-apis.jar are no longer in the lib dir. David -Original Message- From: Cramer, David W (David) Sent: Wednesday, November 17, 2010 3:28 PM To: 'David Priest'; docbook-apps@lists.oasis-open.org Subject: RE: [docbook-apps] Docbook Webhelp: saxparser problem Hi David, What version of ant are you using? I've just discovered that the webhelp build.xml fails with ant 1.8.1 (and I know it works with 1.6.5 to 1.8.0), however it fails at a different point and with a different error than you're seeing. David -Original Message- From: David Priest [mailto:d...@davidpriest.ca] Sent: Wednesday, November 17, 2010 2:27 PM To: docbook-apps@lists.oasis-open.org Subject: [docbook-apps] Docbook Webhelp: saxparser problem I've been trying to implement in Ant the indexer part of the Docbook Webhelp transformation. I have this error: [major snippage] [xslt] JAXP: find factoryId =javax.xml.parsers.SAXParserFactory [xslt] JAXP: loaded from fallback value: com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl [xslt] JAXP: created new instance of class com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl using ClassLoader: null [echo] Indexing html files in /Users/davidp/dev/release-docs/Admin_Guide-webhelp/content [indexertask] JAXP: find factoryId =javax.xml.parsers.SAXParserFactory [indexertask] JAXP: found system property, value=org.apache.xerces.jaxp.SAXParserFactoryImpl BUILD FAILED /Users/davidp/dev/davidpriest/ant/publish.xml:420: javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.SAXParserFactoryImpl not found at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:13 4) at com.nexwave.nquindexer.SaxDocFileParser.parseDocument(SaxDocFileParser. java:67) [snip] There are a nigh-infinite number of debug messages where JAXP loads from fallback. And *immediately* before the indexer is fired-up, JAXP does exactly the same thing as had worked for every other step of the transformation process. But then, whack, nquindexer craps out when it tries to execute its indexer task. I have tried to point it directly at xerces by including it in the indexer's classpath. I've tried eliminating classes that I think might contain a sax parser of their own (but, then, if those were interfering, I'd expect the other debug messages to indicate that). I should note that my Ant indexertask is copied directly from the script provided with Docbook's Webhelp. Does anyone have any hints on how I can resolve this issue? Thanks in advance david - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis- open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
RE: [docbook-apps] svgweb and DocBook
Actually there's some goo you have to add in the markup as well. Not much though...I'll give it a try. Maybe it's something worth supporting with a use.svgweb parameter. The downside is that you can't serve the content off the file system. David -Original Message- From: Jirka Kosek [mailto:ji...@kosek.cz] Sent: Saturday, November 13, 2010 10:50 AM To: Cramer, David W (David) Cc: DocBook Apps ML Subject: Re: [docbook-apps] svgweb and DocBook Cramer, David W (David) wrote: Hi there, Has anybody incorporated svgweb into their DocBook-produced html? As I understand it, it's some JavaScript goo that uses Flash to render the SVG in primitive browsers that don't support SVG or in cases where you want more consistent rendering of the SVG. http://code.google.com/p/svgweb/ I've been meaning to look into it but thought I'd see if anyone else has already. It seems that only thing necessary is to put one script element into produced HTML. This can be easily done by modifying user.head.content template. Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz 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 --
[docbook-apps] svgweb and DocBook
Hi there, Has anybody incorporated svgweb into their DocBook-produced html? As I understand it, it's some JavaScript goo that uses Flash to render the SVG in primitive browsers that don't support SVG or in cases where you want more consistent rendering of the SVG. http://code.google.com/p/svgweb/ I've been meaning to look into it but thought I'd see if anyone else has already. David
RE: [docbook-apps] Handling individual document attributes when publishing with Ant
Yes, you can have a master build.xml file that contains a series of ant/ tasks invoking each document's build.xml. Each can build the doc in one or more formats and you can pass in properties at this point to override those set in the document's build.xml: project ant antfile=path/to/build.xml target name=pdf/ target name=webhelp/ property name=profile.security value=reviewer/ /ant ... /project When building several documents, you may not want the whole build to fail if one doc fails. We use the trycatch[1] task from antcontrib[2]. So it will try to build a doc, if that one fails then the catch uses the mail/ task to send an email to the writer that owns that doc. However, having individual writers think about ant and concepts like try/catch is inconvenient, so I have a module.xml file that lists the docs to be built and whether the build should break if the doc fails. So the build runs an xslt that generates a build.xml from that module.xml file and then runs the generated build file. The generated build file in turn calls each doc's build.xml file. This way the writer can just manage a simple format like: module document buildfile=path/to/build.xml notification emailsome...@motive.com/email emailsomeonee...@motive.com/email /notification format name=pdf reviewer failonerror=false/ internal failonerror=true/ /format format name=eclipse reviewer publish=true infocenter=hsd/ /format ... Then the xslt sees failonerror=false and so wraps that one in a try/catch block and puts all the try/catches before the others so it will do those first then try the ones that could kill the build. In our system, for eclipse formats, if publish=true then I invoke the target that pushes the result out to an infocenter. David [1] http://ant-contrib.sourceforge.net/tasks/tasks/trycatch.html [2] http://sourceforge.net/projects/ant-contrib/files/ -Original Message- From: Peter Desjardins [mailto:peter.desjardins...@gmail.com] Sent: Tuesday, November 09, 2010 11:06 PM To: Cramer, David W (David) Cc: DocBook Apps Subject: Re: [docbook-apps] Handling individual document attributes when publishing with Ant Those sound like excellent solutions. Is there a way to have Ant build the 40 individual build.xml files from a central build file? I'd like to invoke Ant once, have it build 40 documents based on their individual build XML files, and then move on to other targets such as packaging in Eclipse WAR files. Thanks for your help. Peter On Tue, Nov 9, 2010 at 3:00 PM, Cramer, David W (David) dcra...@motive.com wrote: Hi Peter, You could have a build.xml for each top-level/buildable source file that: 1. Declares properties like current.docid etc. 2. Imports your main build.xml that contains your build logic import file=path/to/main-build.xml/ Optionally, you could store the key/value pairs in a properties file and pull them into the doc's build.xml via propertyfile file=build.properties/. That can be convenient if you have a group of properties that are common to a set of docs. Just put them in a properties file and have the build files for all those docs pull it in. When you pass the properties in to the xslts using the xslt/ task, you can use the if attribute on nested params so that the params are only set if the property is declared. That way, your xslts will still use their defaults if the property happened not to have been set in the build.xml. David -Original Message- From: Peter Desjardins [mailto:peter.desjardins...@gmail.com] Sent: Tuesday, November 09, 2010 1:41 PM To: DocBook Apps Subject: [docbook-apps] Handling individual document attributes when publishing with Ant Hi, I'm getting started with Apache Ant and DocBook publishing. I have figured out how to use Ant to transform DocBook files with the stylesheets. Now I'm trying to find an efficient, maintainable, and scalable way to handle the sets of attributes that are unique to documents. I am dealing with about 40 documents and each one has a set of values that I need to pass in when they are published. For example, each document has a docid for olinking, a document title that appears in Eclipse output, an output filename, and similar details that I need to control while publishing. In the past, I've stored all these details in a crude database that I read with my publishing shell scripts. I'm moving to Ant in an effort to make the publishing process more easily understandable and maintainable. Can you point me to a good way to handle these document attributes when DocBook publishing with Ant? I didn't see the way this is handled in the DocBook/Ant examples I've found on the web. Thanks for your help. Peter - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis- open.org For additional commands
RE: [docbook-apps] acronyms, abbreviations, definitions
Hi Nathalie, I once started to implement an acronym expanding xslt with the idea that I could write acronymTLA/acronym and have the first occurrence automatically be expanded to TLA (Three Letter Acronym). Things were going fine till I hit GNU and ended up with GNU (GNU (GNU (...) is not Unix) is not Unix) ;-) You might check out the Glossary database feature: http://www.sagehill.net/docbookxsl/GlossDatabase.html Then you could do glosstermUN/glossterm and have the xslts automatically add a glossentry defining United Nations David -Original Message- From: Nathalie Sequeira [mailto:n...@n-faktor.net] Sent: Wednesday, November 10, 2010 1:00 AM To: docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] acronyms, abbreviations, definitions Hello again, since no one has replied: should I be asking this question somewhere else? I have also searched the archives, but have not found any relevant info. One thread in Nov.2006 dealt with the usefulness of acronyms (personally, I really need these to meet accessibility requirements!), but unfortunately did not mention how to include their expansions in docBook. So thanks for any pointers on how to go about finding a solution to this! Nathalie Nathalie Sequeira wrote: Hello list! 1. I'm a bit insecure on how to mark up inline acronyms abbbreviations in docBook. Coming from XHTML, I was expecting an attribute that can contain their written-out counterparts, somewhat like abbr title=United NationsUN/abbr but cannot find a similar mechanism in the docBook 5 online reference. Is there any standard way of including this essential information? Or should we do something like abbreviationUNphraseUnited Nations/phrase/abbreviation and let XSL transformation deal with the phrase/ (or is another element semantically more adequate?), either setting it in parentheses inline, creating a linked list of glossary terms at the end of the text (e.g. for PDF output) or transforming into HTML attributes in HTML output? 2. Is there an element that is suited for inline definitions (I haven't found any obvious choice and am quite lost on how to get this done...)? Thanks for any thoughts on this! Nathalie Sequeira - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis- open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
RE: [docbook-apps] removing elements and attrs from title
Hi Mike,
Interesting idea about removing xml:id from titles. Try the following:
include href=docbookxi.rng
define name=db.title.attlist
interleave
optional
ref name=db.title.role.attribute/
/optional
interleave
ref name=db.common.base.attributes/
optional
ref
name=db.annotations.attribute/
/optional
/interleave
ref name=db.common.linking.attributes/
/interleave
/define
/include
That seems to work...not sure if it's the best/easiest way. I just copied
db.title.attlist into the include and then copied db.common.attributes
replacing the ref name=db.common.attributes/ and then deleted the reference
to db.xml.id.attribute from my copy of db.common.attributes.
I think to remove remark you just add the following inside your include:
define name=db.remark
notAllowed/
/define
You might also check out: http://www.docbook.org/docs/howto
David
-Original Message-
From: Mike Maxwell [mailto:maxw...@umiacs.umd.edu]
Sent: Wednesday, November 10, 2010 8:19 PM
To: DocBook Apps ML
Subject: [docbook-apps] removing elements and attrs from title
I want to customize my DocBook schema by removing one element
(remark)
and one attribute (xml:id) from the title element. I'm trying to
follow the customization instructions for DocBook 5.0
(http://www.docbook.org/tdg5/en/html/ch05.html#ch05-layers), but I'm
apparently doing something wrong. I'm using the XML form of the RelaxNG
schema, whereas the instructions show the RNC form; but I think I've
done the conversion right.
I have the following:
include href=xxe-config:docbook5/rng/V5.0/docbook.rng
...
define name=db.title
!--Replace the DocBook standard db.title--
element name=title
ref name=db.MyTitle.attlist/
zeroOrMore
ref name=db.MyTitle.inlines/
/zeroOrMore
/element
/define
/include
define name=db.MyTitle.attlist.../define
define name=db.MyTitle.inlines.../define
('xxe-config' in the first line points to a place in the file system)
The code for define name=db.title is copied over from the DB5
schema
included with XXE, except I substituted db.MyTitle.attlist for
db.title.attlist, and db.MyTitle.inlines for
db.all.inlines (and omitted the a:documentation element).
However, validation gives me the following error:
overlapping element names in operands of interleave
pointing to line 1262 of the docbook.rng. Line 1262 is the second line
in this definition:
define name=db.titleonlyreq.info
element name=info
a:documentationA wrapper for information about a component
or
other block with only a required title/a:documentation
ref name=db.titleonlyreq.info.attlist/
interleave
ref name=db._title.onlyreq/
zeroOrMore
ref name=db.info.elements/
/zeroOrMore
/interleave
/element
/define
At this point, I get lost tracing things backwards. I just don't see
how db.titleonlyreq.info (or db.titleonlyreq.info.attlist) gets called
from my re-definition of db.title, nor what the error is.
Commenting out parts of my modifications doesn't help, either; in fact,
I still get the error msg if I reduce my modifications to this:
include href=xxe-config:docbook5/rng/V5.0/docbook.rng
...
define name=db.title
!--Replace the DocBook standard db.title--
element name=title
text/
/element
/define
/include
What am I doing wrong?
--
Mike Maxwell
maxw...@umiacs.umd.edu
A library is the best possible imitation, by human beings,
of a divine mind, where the whole universe is viewed and
understood at the same time... we have invented libraries
because we know that we do not have divine powers, but we
try to do our best to imitate them. --Umberto Eco
-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
RE: [docbook-apps] Handling individual document attributes when publishing with Ant
Hi Peter, You could have a build.xml for each top-level/buildable source file that: 1. Declares properties like current.docid etc. 2. Imports your main build.xml that contains your build logic import file=path/to/main-build.xml/ Optionally, you could store the key/value pairs in a properties file and pull them into the doc's build.xml via propertyfile file=build.properties/. That can be convenient if you have a group of properties that are common to a set of docs. Just put them in a properties file and have the build files for all those docs pull it in. When you pass the properties in to the xslts using the xslt/ task, you can use the if attribute on nested params so that the params are only set if the property is declared. That way, your xslts will still use their defaults if the property happened not to have been set in the build.xml. David -Original Message- From: Peter Desjardins [mailto:peter.desjardins...@gmail.com] Sent: Tuesday, November 09, 2010 1:41 PM To: DocBook Apps Subject: [docbook-apps] Handling individual document attributes when publishing with Ant Hi, I'm getting started with Apache Ant and DocBook publishing. I have figured out how to use Ant to transform DocBook files with the stylesheets. Now I'm trying to find an efficient, maintainable, and scalable way to handle the sets of attributes that are unique to documents. I am dealing with about 40 documents and each one has a set of values that I need to pass in when they are published. For example, each document has a docid for olinking, a document title that appears in Eclipse output, an output filename, and similar details that I need to control while publishing. In the past, I've stored all these details in a crude database that I read with my publishing shell scripts. I'm moving to Ant in an effort to make the publishing process more easily understandable and maintainable. Can you point me to a good way to handle these document attributes when DocBook publishing with Ant? I didn't see the way this is handled in the DocBook/Ant examples I've found on the web. Thanks for your help. Peter - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
RE: [docbook-apps] Re: qanda listings in html output
-Original Message- From: Tom Browder [mailto:tom.brow...@gmail.com] Sent: Thursday, October 28, 2010 1:59 PM To: Bob Stayton Cc: Docbook Apps Help list Subject: Re: [docbook-apps] Re: qanda listings in html output On Thu, Oct 28, 2010 at 13:07, Bob Stayton b...@sagehill.net wrote: Hi, I think this is more of a browser problem than an HTML coding problem. Using p inside a table cell is commonly done, and should not create extra space at the top of the table cell. Only Firefox pushes the qanda number down to the second line. Neither Internet Explorer or Chrome do that. Does anyone know of any other browsers that have this problem? Bob, I don't have any complaint now that I went to the xhtml--the label problem doesn't exist. Hmm, my guess is that Firefox is rendering the html output in quirks mode[1] and the xhtml in standards mode. Staying out of quirks mode is a good thing if you want to keep your sanity while writing css. David [1] http://en.wikipedia.org/wiki/Quirks_mode - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
RE: [docbook-apps] Re: DocBook-XSL 1.76.1 release schedule
On Tue, Oct 5, 2010 at 2:08 AM, Mimil Mimil mimilo...@gmail.com wrote: The java code is now extracted has a library (as saxon and xalan extensions) named xsl-webhelpindexer, we now have something near to work, the only thing missing is concerning the VERSION file which seems to be a generated file. You want the VERSION to be similar to the one in xsl-saxon/VERSION, for example? Are you not able to copy and modify that one? Thanks Keith, that did the trick. I'll commit the new stuff in a bit. Thanks, David - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
RE: [docbook-apps] translated indexes
Correct. When the translators translate your document, instruct them to add sortas attributes with the term transliterated in hiragana/katakana. This applies to your glossentrys as well. David -Original Message- From: Jean-Christophe Helary [mailto:jean.christophe.hel...@gmail.com] Sent: Saturday, September 25, 2010 10:02 AM To: DocBook Apps Subject: Re: [docbook-apps] translated indexes On 25 sept. 10, at 12:49, Cramer, David W (David) wrote: Typically you just translate the indexterms in place in the document and let the xslts generate a new index. For Japanese, you add sortas attributes to your primary, secondary, and tertiary elements with the term transliterated into a phonetic script (katakana or hiragana). Ok, so you need to add that code to the Japanese DocBook file, right ? Jean-Christophe Helary fun: http://mac4translators.blogspot.com work: http://www.doublet.jp (ja/en fr) tweets: http://twitter.com/brandelune - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
RE: [docbook-apps] Use of xincludes vs. entities
Hi Sam and Jim, You might be interested in Jirka's proposal for transclusions in DocBook. It notes the problems with xincludes for the very use case you bring up: http://lists.oasis-open.org/archives/docbook-tc/201007/msg00041.html David -Original Message- From: Sam Fischmann [mailto:sam.fischm...@gmail.com] Sent: Saturday, September 25, 2010 3:10 PM To: Jim Campbell; docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] Use of xincludes vs. entities Hi Jim, I say pick the right tool for the job. I think that the two cases you outline above are completely reasonable uses for entities. I'm also a bit sheepish about using XInclude with XPointer because of the differing levels of support for XPointer in different XSL processors. I don't think it's Bad with a captial B to use entities in places where they are a simple, elegant solution. Another way to look at it... While editing, a lot of the XInclude junk doesn't seem helpful for a small bit of text replacement: paraThe ball is product_color;./para paraThe ball is xi:include href=product_info.xml xpointer=color/./para I think product_info.xml is just going to be a weird file to maintain, too, but that could be personal preference. However, if it were a file, xi:include provides valuable information: paraSee the following table: uh_what_file;/para paraSee the following table: xi:include href=../tables/product_table.xml/para [ I am going to rant slightly off-topic now, but you might find some of this interesting and related to your question ] I am in a situation right now where I have a very large base of existing DocBook material that uses entities extensively. I would like to use XPointer for including chunks of text, but I run into all sorts of problems when those chunks of text themselves contain entities. Consider two books: Book1 and Book2. Book1 defines foo; as 1 and Book2 defines foo; as 2. I have a file inc.xml that's included in each book via entities. It has the content: paraMy number is foo;/para. It works great. When I view either book in an editor, the entity resolves nicely to 1 in Book1 and 2 in Book2. Unfortunately, most editors don't allow me to edit the contents of inc.xml, or as soon as they do, foo; doesn't resolve because it's not aware of the parent book that defines it because it's in another file. Now I change to XInclude. If I simply add a DOCTYPE tag to inc.xml and include it, foo; won't resolve at all, because it needs to be declared inside inc.xml. But this file is included by two books which would each define the entity differently. What do I do? To solve the general case, somebody might tell me that I could define foo; in two different entity files, then create two XML catalogs, one for use with each book, that define the same public identifier for each respective entity file. I would then use the public identifier to declare the entity file in the subset of inc.xml and conditionally specify one or the other catalog when building each book. That's an awful lot of infrastructure, not to mention that I'm going to be hard-pressed to find an editor which could elegantly handle the catalog situation. Somebody else might respond: but clearly there's some ill-conceived organization here. Why aren't you using profiling to get the 1 and 2? Surely then, you could define a couple profiled phrases for foo;, then specify the profile when making the book. Well, consider what might happen if I had 15 books that each required a unique definition? Now every time that entity is used and I'm editing a book, I've got to look at a massive chunk of profiled phrases. Still, I'm considering this to be the only reasonable route to take; if you name your entities well enough you can hide their text values when editing material in a nice full-featured editor. -Sam On Sat, Sep 25, 2010 at 8:25 AM, Jim Campbell jwcampb...@gmail.com wrote: Hi All, As I understand it, the xincludes feature provides a number of advantages over use of entities, but are there some situations where entities are still relevant and recommended? For example, I'm considering the use of click-paths for guimenu guisubmenu chains. In the past, we have used an entity file to house all of the guimenu click-paths for our documentation. If the guimenu click-path changed, we would just update it in our entities file, and it would be updated throughout the documentation. It seems that using xinclude + xpointer to perform the same feature would be overkill for in performing the same task. Similarly, in the past we have used entities to handle updates to version numbering, and it seems that xinclude + xpointer would be overkill there, as well. Much of how I've seen xinclude being used seems to be relevant for including entire chapters or otherwise large chunks of text, and I do see the relevance there. Is xinclude helpful and manageable for smaller textual insertions, too, or are entities still a reasonable way to go for these types
RE: [docbook-apps] translated indexes
Typically you just translate the indexterms in place in the document and let the xslts generate a new index. For Japanese, you add sortas attributes to your primary, secondary, and tertiary elements with the term transliterated into a phonetic script (katakana or hiragana). Another problem is having terms divided into indexdivs correctly. For your options, see: http://www.sagehill.net/docbookxsl/IndexIntl.html David -Original Message- From: Jean-Christophe Helary [mailto:jean.christophe.hel...@gmail.com] Sent: Friday, September 24, 2010 9:33 PM To: DocBook Apps Subject: [docbook-apps] translated indexes I never tried that but I was wondering what was the best way to sort an index after translation of the file set ? Especially in the case of languages that do not use the same character set (for ex English vs Japanese) ? What would be the best way to establish an easy to translate index ? Jean-Christophe Helary fun: http://mac4translators.blogspot.com work: http://www.doublet.jp (ja/en fr) tweets: http://twitter.com/brandelune - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] RE: [docbook-dev] DocBook-XSL 1.76.0-RC1 for preliminary testing
Hi Cedric, In xsl/webhelp/Makefile I just call ant and have it build the indexer: build-indexer: $(ANT) build-indexer That's the same way xsl-saxon does it (I just copied it). The build-indexer ant target just compiles the indexer and jars it up. But to break out the indexer correctly, we'll need the lucene jars like you said. I should really also split out some documentation for it as well and licensing information. For the VERSION file and other release-related activities, I don't know how all that works. I can see that xsl-saxon has a VERSION file that's an xslt which seems to generate announcement(s) for freshmeat and sourceforge. Sorry I haven't had time to look into all this yet. Thanks, David From: Mimil Mimil [mailto:mimilo...@gmail.com] Sent: Tuesday, September 21, 2010 7:47 AM To: Cramer, David W (David); Keith Fahlgren; Docbook Apps; docbook-developers Subject: Re: [docbook-dev] DocBook-XSL 1.76.0-RC1 for preliminary testing Hello, I am giving a try to make the xsl-webhelpindexer extension and I have some questions: - can someone tell me how the VERSION file is created? (like in xsl-xalan or xsl-saxon) - is there any external actions to do? (like in the scm, the bug tracker, ...) - in Makefile, is webhelpindexer.jar: $(wildcard src/) correct? (I am not familiar with makefiles) Regards, Cedric, On Mon, Sep 20, 2010 at 3:06 PM, Mimil Mimil mimilo...@gmail.commailto:mimilo...@gmail.com wrote: I didn't yet made the webhelp docbkx plugin but the plugin will mimic what your are doing in your ant file. I am not sure it is a long task, I think about 3 steps: - you guess you just need to split your ant file in 2 by extracting the compilation part into a top directory (like xsl-webhelpindexer?) - I guess the Makefile in xsl/extensions have to be modified too to copy the jar you built + the lucen dependencies - modify the your ant to take care of this new classpath As I do not have the docbook building toolchain, I cannot make the test. Regards, Cedric, On Fri, Sep 17, 2010 at 10:38 PM, Cramer, David W (David) dcra...@motive.commailto:dcra...@motive.com wrote: I also have some comments on the webhelp/indexer content, I wonder if it can be refactored: - isn't the indexer should be seen as a separate module as the xsl-saxon and xsl-xalan are? - and then the binaries located in extensions/ directory? Yes, that make sense. Not sure how soon I'll get around to breaking it out though. I'd also like to understand how to build webhelp using the docbkx maven plugin, but I'm new to maven. David
RE: [docbook-apps] draft.mode default to no?
I also agree that draft mode as currently implemented should have a default of no. The problem I have with the current, image-based draft watermark mechanism is that if the image is dark enough to appear when printed (on all printers...different printers yield different results), then it's so dark that it interferes with the legibility of the text. I instead have a fo:leader rotated 90 degrees with the appropriate text DRAFT - INTERNAL ONLY repeated and running in the inner margin. That way I can have the text dark enough to appear when printed without interfering with the body text. For html I put the same text in the header and footer. Perhaps the stock xsls could use a similar mechanism and then the DRAFT could be populated from the gentext strings. I do think the functionality is very useful. You really need a way to mark clearly that a document is a pre-release version. David -Original Message- From: Ron Catterall [mailto:r...@catterall.net] Sent: Monday, September 20, 2010 6:18 AM To: Bob Stayton; docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] draft.mode default to no? Agreed, draft mode should be an option you request, not the default. Set draft.mode parameter to 'no' by default and then if the user decides he wants draft mode, he will ask for it and the draft page masters will be loaded. I wonder how many people actually use draft mode. On 9/20/10 3:44 AM, Bob Stayton wrote: The stylesheet parameter draft.mode's default value has been set to 'maybe' for quite awhile. That kind of worked, because the url for the draft.watermark.image was a URL. Users requested that it not be a URL, because it created problems for offline people, and delayed processing to fetch it over the internet. It required either changing the value or using a catalog to redirect the URL to a local location. In version 1.76.0, we changed the draft.watermark.image to a local value like other docbook images. However, when FOP creates the draft page-masters, it tries (and generally fails) to load that image, even if the draft page-masters are not used. I don't think that is correct behavior, as it should only try to open that image if it is going to be used. So I'm asking the mailing list if we should change the default value of the draft.mode param to 'no', so that the draft page-masters are not even used. Personally, I think setting it to 'no' by default is a good thing. If you want to use draft pages, then set the url to the watermark image and turn on the feature. Bob Stayton Sagehill Enterprises b...@sagehill.net - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org -- Ron Catterall Ph.D. D.Sc. r...@catterall.net http://catterall.net - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
RE: [docbook-apps] Docbook for industrial usage
This thread makes me wonder if we should all update and add details to http://wiki.docbook.org/topic/WhoUsesDocBook David -Original Message- From: Ruediger Landmann [mailto:r.landm...@redhat.com] Sent: Tuesday, September 07, 2010 6:25 PM To: docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] Docbook for industrial usage On 09/07/2010 07:45 PM, Sabine Cretella wrote: Hi, yesterday I talked with Camille on IRC about getting docbook used more in industry. I am searching for companies that already use it and that could give a good example about what they do with docbook and why they use it. And I also got one first contact I am going to write to. In Red Hat and the Fedora Project, we produce all of our documentation in Docbook: http://docs.redhat.com http://docs.fedoraproject.org We transform the XML into single-page HTML, multi-page HTML, PDF, and EPUB using Publican, a tool developed in-house and released as free, open-source software: http://docs.redhat.com/docs/en-US/Site_Tech.html Red Hat manuals are published in those four formats in 22 languages, and the Fedora project publishes a smaller selection of manuals in anywhere up to 42 languages. Authoring in DocBook as opposed to a word processor allows us to maintain a single source for each document, regardless of how many different formats and languages we publish. One of my colleagues, Ryan Lerch, explained the why in a short comic: http://fossdocs.files.wordpress.com/2010/03/what_is_publican.png Although it's Publican-centric, the reasoning applies to DocBook more generally, regardless of the tool you use. One side I never did myself, but would like to try out on my own is to convert a docbook file to pdf - all I found on the web seems to be rather old and from before docbook 5 - is there any new documentation on this? You know one thing is having just read it's possible and another is having it done at least once. (I am on OpenSuse btw. In Publican, it would be (for example): publican build --formats=pdf --languages=en-US You can find the spec file and source tarball here (the current version is 2.1): https://fedorahosted.org/releases/p/u/publican/ The spec file is designed for Fedora, and would need some adaptation for openSUSE to account for different packaging for dependencies. If you get Publican working on openSUSE, we'd be happy to add installation instructions to our documentation. Cheers Rudi - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
RE: [docbook-apps] CHM Index Problem
Hi Sam, Maybe try building it using an hhk file instead of the activex goo put in place of each indexterm by default. See: http://docbook.sourceforge.net/release/xsl/current/doc/html/htmlhelp.use.hhk.html and http://www.sagehill.net/docbookxsl/HtmlHelp.html#HHGenIndex David From: Sam Fischmann [mailto:sam.fischm...@gmail.com] Sent: Monday, September 06, 2010 7:18 PM To: docbook-apps@lists.oasis-open.org Subject: [docbook-apps] CHM Index Problem Hello, Due to some specific requirements, I need to compile CHM files from the htmlhelp stylesheets under WINE in Linux. While my project compiles without errors under both windows and linux, the final .chm index compiled in linux is unsorted and the index entries are not consolidated. Everything else appears normal. I realize this has nothing to do with the stylesheets directly, but I figure there's some slim chance somebody here has encountered this problem so I thought I'd ask if anybody has any insight. I'm already using native versions of itss.dll, itircl.dll, and hhctrl.ocx to no avail. Thanks, -Sam
RE: [docbook-apps] Avoiding hot links in olinks to other docs
Thanks Bob, I got it working in my customization layer and have added a feature request: https://sourceforge.net/tracker/?func=detailaid=3059394group_id=21935atid=373750 David From: Bob Stayton [mailto:b...@sagehill.net] Sent: Friday, September 03, 2010 11:52 AM To: Cramer, David W (David); DocBook Apps Subject: Re: [docbook-apps] Avoiding hot links in olinks to other docs Hi David, No, there is no parameter for that. Seems like a good idea, though. In the current stylesheets, you would need to customize the template named 'make.olink.href', which generates the href value. If the value from this template comes back empty, then you just get the olink text without a hot link. You would need to make the output of the template conditional on $targetdoc = $current.docid. Bob Stayton Sagehill Enterprises b...@sagehill.netmailto:b...@sagehill.net - Original Message - From: Cramer, David W (David)mailto:dcra...@motive.com To: DocBook Appsmailto:docbook-apps@lists.oasis-open.org Sent: Friday, September 03, 2010 7:39 AM Subject: [docbook-apps] Avoiding hot links in olinks to other docs Hi there, I would like to set up olinking so that when I generate certain output formats (pdf, webhelp) olinks to the same document are hyperlinks (just as if they were xrefs) but olinks to other documents only show the title of the section and document name, but are not hyperlinks. For these formats, the user won't have the target doc in a predictable place. I looked around and couldn't find a parameter to disable hyperlinks to external olinks. Is this something that's already supported? Thanks, David
[docbook-apps] Avoiding hot links in olinks to other docs
Hi there, I would like to set up olinking so that when I generate certain output formats (pdf, webhelp) olinks to the same document are hyperlinks (just as if they were xrefs) but olinks to other documents only show the title of the section and document name, but are not hyperlinks. For these formats, the user won't have the target doc in a predictable place. I looked around and couldn't find a parameter to disable hyperlinks to external olinks. Is this something that's already supported? Thanks, David
RE: [docbook-apps] [PDF] Bookmarks - add index groups
Thanks for posting the details Jan. I've added a feature request linking back
to this post. I think it would be a nice addition to the base xsls:
https://sourceforge.net/tracker/index.php?func=detailaid=3057673group_id=21935atid=373750
David
-Original Message-
From: honyk [mailto:j.tosov...@email.cz]
Sent: Wednesday, September 01, 2010 1:10 PM
To: 'Jirka Kosek'; 'Bob Stayton'
Cc: docbook-apps@lists.oasis-open.org
Subject: RE: [docbook-apps] [PDF] Bookmarks - add index groups
Hello Guys,
thanks for your useful hints, it is working now!
Some details for future followers...
I've modified templates which match 'indexterm' in modes 'index-div-basic' and
'index-symbol-div' placing the id attribute on the block element (to create an
anchor):
fo:block id=id{$key}
Into the bookmark processing code (mode=xep.outline) I've added another
branching:
xsl:when test=self::index
rx:bookmark internal-destination={$id}
rx:bookmark-label
xsl:value-of select=normalize-space($bookmark-label)/
/rx:bookmark-label
xsl:apply-templates select=. mode=xep.outline.index/
/rx:bookmark
/xsl:when
which calls the following template
xsl:template match=index mode=xep.outline.index
xsl:param name=scope select=(ancestor::book|/)[last()]/
xsl:variable name=role
xsl:if test=$index.on.role != 0
xsl:value-of select=@role/
/xsl:if
/xsl:variable
xsl:variable name=type
xsl:if test=$index.on.type != 0
xsl:value-of select=@type/
/xsl:if
/xsl:variable
xsl:variable name=terms
select=//indexterm
[count(.|key('letter',
translate(substring(primary;, 1, 1),
lowercase;,
uppercase;))
[scope;][1]) = 1
and not(@class = 'endofrange')]/
xsl:variable name=alphabetical
select=$terms[contains(concat(lowercase;, uppercase;),
substring(primary;, 1, 1))]/
xsl:for-each select=$alphabetical
xsl:sort select=substring(primary;, 1, 1)/
xsl:variable name=label
xsl:call-template name=string.upper
xsl:with-param name=string
select=substring(primary;, 1, 1)/
/xsl:call-template
/xsl:variable
rx:bookmark internal-destination=id{$label}
rx:bookmark-label
xsl:value-of select=$label/
/rx:bookmark-label
/rx:bookmark
/xsl:for-each
/xsl:template
The latter code requires placing special entities (/common/entities.ent) into
the XSLT file:
!DOCTYPE xsl:stylesheet [
!ENTITY % common.entities SYSTEM path to common entities
%common.entities;
]
That's it.
Thanks once again.
Jan
Bob Stayton wrote:
The tricky part is determining which letters actually have entries in
the current index, so you don't create bookmark links to non-existant
index sections. I don't have a quick solution for that one.
I think that code from autoidx.xsl can be reused, namely from
generate-basic-template. For example following code will populate
variable $alphabetical with exactly one indexterm for each letter.
xsl:variable name=terms
select=//indexterm
[count(.|key('letter',
translate(substring(primary;, 1, 1),
lowercase;,
uppercase;))
[scope;][1]) = 1
and not(@class = 'endofrange')]/
xsl:variable name=alphabetical
select=$terms[contains(concat(lowercase;,
uppercase;),
substring(primary;, 1, 1))]/
So in order to get just letters something like the following code could
be used:
xsl:for-each select=$alphabetical
rx:bookmark-label
xsl:value-of select=substring(primary;, 1, 1)/
/rx:bookmark-label
/xsl:for-each
Jirka
-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] RE: [docbook-dev] DocBook-XSL 1.76.0-RC1 for preliminary testing
Hi Keith, Please also mention the addition of webhelp as a newly supported output format in the release notes :-) Thanks, David -Original Message- From: Keith Fahlgren [mailto:abdela...@gmail.com] Sent: Tuesday, August 31, 2010 2:56 AM To: docbook-developers Cc: Docbook Apps Subject: [docbook-dev] DocBook-XSL 1.76.0-RC1 for preliminary testing Hi, A release candidate for DocBook-XSL 1.76.0 is ready for you to test. Please review the release notes (below) and give it a whirl and let me know if we should release it on Friday, 3 Sept 2010. Files: http://kfahlgren.com/docbook-xsl/ Reminder: titleAbout dot-zero releases/title paraDocBook Project “dot zero” releases should be considered emphasisexperimental/emphasis and are always followed by stable “dot one plus” releases, usually within two or three weeks. Please help to ensure the stability of “dot one plus” releases by carefully testing each “dot zero” release and reporting back about any problems you find. /para paraIt is not recommended that you use a “dot zero” release in a production system. Instead, you should wait for the “dot one” or greater versions./para Release Notes: 1.76.0 This release includes important bug fixes and adds the following significant feature changes: Gentext Many updates and additions to translation/locales thanks to Red Hat, the Fedora Project, and other contributors. Common Faster localization support, as language files are loaded on demand. FO Support for SVG content in imagedata added. HTML Output improved when using 'make.clean.html' and a stock CSS file is now provided. EPUB A number of improvements to NCX, cover and image selection, and XHTML 1.1 element choices The following is a list of changes that have been made since the 1.75.2 release. Gentext The following changes have been made to the gentext code since the 1.75.2 release. rlandmann: locale/fa.xml Update to Persian translation from the Fedora Project rlandmann: locale/nds.xml Locale for Low German Mauritz Jeanson: locale/ka.xml; Makefile Added support for Georgian based on patch #2917147. rlandmann: locale/nl.xml; locale/ja.xml Updated translations from Red Hat and the Fedora Project rlandmann: locale/bs.xml; locale/ru.xml; locale/hr.xml Updated locales from Red Hat and the Fedora Project rlandmann: locale/pt.xml; locale/cs.xml; locale/es.xml; locale/bg.xml; locale/nl.xml; loca⋯ Updated translations from Red Hat and the Fedora Project rlandmann: locale/as.xml; locale/bn_IN.xml; locale/ast.xml; locale/ml.xml; locale/te.xml; ⋯ New translations from Red Hat and the Fedora Project rlandmann: locale/pt.xml; locale/ca.xml; locale/da.xml; locale/sr.xml; locale/ru.xml; loca⋯ Updated translations from Red Hat and the Fedora Project Common The following changes have been made to the common code since the 1.75.2 release. Mauritz Jeanson: common.xsl Fixed bug in output-orderedlist-starting-number template (@startingnumber did not work for FO). Mauritz Jeanson: gentext.xsl Added fix to catch ID also of descendants of listitem. Closes bug #2955077. Jirka Kosek: l10n.xsl Stripped down, faster version of gentext.template is used when there is no localization customization. Mauritz Jeanson: stripns.xsl Added fix that preserves link/@role (makes links in the reference documentation with @role=tcg work). Mauritz Jeanson: l10n.xsl Fixed bugs related to manpages and L10n. Jirka Kosek: entities.ent; autoidx-kosek.xsl Upgraded to use common entities. Fixed bug when some code used @sortas and some not for grouping/sorting of indexterms. Jirka Kosek: l10n.xsl; l10n.dtd; l10n.xml; autoidx-kosek.xsl Refactored localization support. Language files are loaded on demand. Speedup is about 30%. Jirka Kosek: l10n.xsl Added xsl:keys for improved performance of localization texts look up. Performance gain around 15%. Mauritz Jeanson: titles.xsl Fixed bug #2912677 (error with xref in title). Robert Stayton: olink.xsl Fix bug in xrefstyle title handling introduced with the 'insert.targetdb.data' template. Robert Stayton: gentext.xsl Fix bug in xref to equation without title to use context=xref-number instead of xref-number-and-title. Robert Stayton: labels.xsl Number all equations in one sequence, with or without title. Robert Stayton: entities.ent Fix bug #2896909 where duplicate @sortas on indexterms caused some indexterms to drop out of index. Robert Stayton: stripns.xsl Expand the Stripping namespace ... message to advise users to use the namespaced stylesheets. Robert Stayton: stripns.xsl need a local version of $exsl.node.set.available variable because this module imported many places. Mauritz Jeanson: olink.xsl
[docbook-apps] RE: [docbook-dev] DocBook-XSL 1.76.0-RC1 for preliminary testing
Sure thing: Webhelp A new browser-based, cross-platform help format with full-text search and other features typically found in help systems. See webhelp/docs/content/ch01.html for more information and a demo. Thanks, David -Original Message- From: Keith Fahlgren [mailto:abdela...@gmail.com] Sent: Tuesday, August 31, 2010 10:39 AM To: Cramer, David W (David) Cc: docbook-developers; Docbook Apps Subject: Re: [docbook-dev] DocBook-XSL 1.76.0-RC1 for preliminary testing Ok. I'll ad something to look for that in the notes. Would you please provide the text? -- Typed with thumbs On Aug 31, 2010, at 6:07 AM, Cramer, David W (David) dcra...@motive.com wrote: Hi Keith, Please also mention the addition of webhelp as a newly supported output format in the release notes :-) Thanks, David -Original Message- From: Keith Fahlgren [mailto:abdela...@gmail.com] Sent: Tuesday, August 31, 2010 2:56 AM To: docbook-developers Cc: Docbook Apps Subject: [docbook-dev] DocBook-XSL 1.76.0-RC1 for preliminary testing Hi, A release candidate for DocBook-XSL 1.76.0 is ready for you to test. Please review the release notes (below) and give it a whirl and let me know if we should release it on Friday, 3 Sept 2010. Files: http://kfahlgren.com/docbook-xsl/ Reminder: titleAbout dot-zero releases/title paraDocBook Project “dot zero” releases should be considered emphasisexperimental/emphasis and are always followed by stable “dot one plus” releases, usually within two or three weeks. Please help to ensure the stability of “dot one plus” releases by carefully testing each “dot zero” release and reporting back about any problems you find. /para paraIt is not recommended that you use a “dot zero” release in a production system. Instead, you should wait for the “dot one” or greater versions./para Release Notes: 1.76.0 This release includes important bug fixes and adds the following significant feature changes: Gentext Many updates and additions to translation/locales thanks to Red Hat, the Fedora Project, and other contributors. Common Faster localization support, as language files are loaded on demand. FO Support for SVG content in imagedata added. HTML Output improved when using 'make.clean.html' and a stock CSS file is now provided. EPUB A number of improvements to NCX, cover and image selection, and XHTML 1.1 element choices The following is a list of changes that have been made since the 1.75.2 release. Gentext The following changes have been made to the gentext code since the 1.75.2 release. rlandmann: locale/fa.xml Update to Persian translation from the Fedora Project rlandmann: locale/nds.xml Locale for Low German Mauritz Jeanson: locale/ka.xml; Makefile Added support for Georgian based on patch #2917147. rlandmann: locale/nl.xml; locale/ja.xml Updated translations from Red Hat and the Fedora Project rlandmann: locale/bs.xml; locale/ru.xml; locale/hr.xml Updated locales from Red Hat and the Fedora Project rlandmann: locale/pt.xml; locale/cs.xml; locale/es.xml; locale/bg.xml; locale/nl.xml; loca⋯ Updated translations from Red Hat and the Fedora Project rlandmann: locale/as.xml; locale/bn_IN.xml; locale/ast.xml; locale/ml.xml; locale/te.xml; ⋯ New translations from Red Hat and the Fedora Project rlandmann: locale/pt.xml; locale/ca.xml; locale/da.xml; locale/sr.xml; locale/ru.xml; loca⋯ Updated translations from Red Hat and the Fedora Project Common The following changes have been made to the common code since the 1.75.2 release. Mauritz Jeanson: common.xsl Fixed bug in output-orderedlist-starting-number template (@startingnumber did not work for FO). Mauritz Jeanson: gentext.xsl Added fix to catch ID also of descendants of listitem. Closes bug #2955077. Jirka Kosek: l10n.xsl Stripped down, faster version of gentext.template is used when there is no localization customization. Mauritz Jeanson: stripns.xsl Added fix that preserves link/@role (makes links in the reference documentation with @role=tcg work). Mauritz Jeanson: l10n.xsl Fixed bugs related to manpages and L10n. Jirka Kosek: entities.ent; autoidx-kosek.xsl Upgraded to use common entities. Fixed bug when some code used @sortas and some not for grouping/sorting of indexterms. Jirka Kosek: l10n.xsl; l10n.dtd; l10n.xml; autoidx-kosek.xsl Refactored localization support. Language files are loaded on demand. Speedup is about 30%. Jirka Kosek: l10n.xsl Added xsl:keys for improved performance of localization texts look up. Performance gain around 15%. Mauritz Jeanson: titles.xsl Fixed bug #2912677 (error with xref in title). Robert Stayton: olink.xsl Fix bug in xrefstyle title handling
RE: [docbook-apps] Changing default olink behavior
Thanks Bob, It occurs to me that I preprocess before generating straight DocBook too, so I should be ok interoperability-wise if I just strip the link text in my preprocess.xsl. My thinking in doing it this way is that generally I want olinks to behave like xrefs so the link text is always fresh, but that it's nice to have the title of the target there when you're editing, even if the title text is potentially stale if the target has changed since you inserted the olink. Another option would be to have the editor's olink insertion mechanism by default insert the olink link text as a comment, so it would be visible in the editor but not used in rendering. Anyway, the high-level goal is to have olinks that behave like xrefs, but still give the writer some information about the what the target is (beyond the targetdoc and targetptr values). I'll have to ponder more what the ideal way to achieve that would actually be. Thanks, David From: Bob Stayton [mailto:b...@sagehill.net] Sent: Monday, August 30, 2010 10:28 PM To: Cramer, David W (David); DocBook Apps Subject: Re: [docbook-apps] Changing default olink behavior Hi, There is no parameter option to do that. You could customize the template named olink.hottext in common/olink.xsl, which generates the link text. That template has grown to be quite large to handle all the options for generating the link text, so you would be copying a big template to your customization layer. In that template is a big xsl:choose, with the first option being to process the content: xsl:choose !-- If it has elements or text (not just PI or comment) -- xsl:when test=child::text() or child::* xsl:apply-templates/ /xsl:when ... You would need to add a condition to that xsl:when's test attribute to get finer control. Bob Stayton Sagehill Enterprises b...@sagehill.netmailto:b...@sagehill.net - Original Message - From: Cramer, David W (David)mailto:dcra...@motive.com To: DocBook Appsmailto:docbook-apps@lists.oasis-open.org Sent: Sunday, August 29, 2010 10:53 AM Subject: [docbook-apps] Changing default olink behavior Hi there, I would like to change the behavior of olinks so that by default the default olink text from the olink database is used instead of the link text (the contents of the olink element). However, I would like the writer to be able to specify individual cases that the link text should be used. I can think of easy ways to do this (e.g. I already preprocess the source, so I could just prune the link text unless it has some flag like xrefstyle=use.olink.text), but I was wondering if there's a supported or better way. Thanks, David
[docbook-apps] Changing default olink behavior
Hi there, I would like to change the behavior of olinks so that by default the default olink text from the olink database is used instead of the link text (the contents of the olink element). However, I would like the writer to be able to specify individual cases that the link text should be used. I can think of easy ways to do this (e.g. I already preprocess the source, so I could just prune the link text unless it has some flag like xrefstyle=use.olink.text), but I was wondering if there's a supported or better way. Thanks, David
RE: [docbook-apps] Controlling the publishing process - shell scripts, Ant, other tools
Hi Peter,
I also use Ant for our build process and would add a couple of points to those
others have made:
The xslt task [1] allows you to pass in parameters if they have been
specified. This is very convenient since you want to use the default values
from the xslts unless you pass in a value. I.e. you don't want to pass in an
empty string and override the default in the xslts. So in the following
example, if=webhelp.include.search.tab tells the xslt task only to pass in
this param if the property webhelp.include.search.tab has been set.
xslt
in=${input-xml}
out=${output-dir}/dummy.html
style=${stylesheet-path}
scanincludeddirectories=false
classpath=${xslt-processor-classpath}
param name=webhelp.include.search.tab
expression=${webhelp.include.search.tab}
if=webhelp.include.search.tab/
param name=webhelp.base.dir expression=${output-dir}
if=output-dir/
param name=webhelp.indexer.language
expression=${webhelp.indexer.language} if=webhelp.indexer.language/
/xslt
I only use the xslt task with Saxon 6 and 9 and can use the classpath attribute
to pick the one I need, BUT it won't work if Saxon 6 is in the CLASSPATH when
you run Ant. If you get a mysterious error, try invoking ant with a clean
classpath.
Ant has a baby version of XML catalogs but can also use a real catalog
resolver. Sometimes the baby version is convenient if your needs are limited.
A limitation of Ant compared to shell scripts or make is that it lacks common
scripting constructs like if/then and try/catch. If you need things like this,
then you can use the ant-contrib extensions ([2] and [3]). I was reluctant to
use extensions, but ultimately found I needed the functionality.
To collect images for the output directory after assembling transclusions,
filtering, and so on, I run an xslt over the processed document and generate an
ant script, then run that ant script from the main ant script. I have it check
to see if any images are missing so it can fail if they are. To catch common
images (callouts, admon graphics) you need either to run the xslt on the output
or code the xslt so it knows what DcoBook constructs require what graphics.
As Pavel mentions, Ant is good at making war files etc. In fact, globbing is a
particular strength. By default, when making a zip of some kind, it excludes
obvious cruft like svn or cvs directories.
I've looked a little at xproc, which seems designed for this situation, but
haven't gotten far yet. I can tell that it would make certain parts very easy,
but one point I'm confused on is how chunked output is treated. Is each chunk a
separate pipeline that I can process further? How would I handle the image
case? Or perhaps I should invoke xproc from ant and each for certain tasks?
Btw., the webhelp gsoc project [5] has a sample ant build file that could give
some ideas (though very simple-minded wrt how it handles images). The idea is
that the user makes a small build.xml that declares a couple of properties
(input doc file name, desired output dir, and any xslt params to pass in), then
imports the main build.xml included with webhelp which contains the logic.
Hope that helps,
David
[1] http://ant.apache.org/manual/Tasks/style.html
[2] http://ant-contrib.sourceforge.net/
[3] http://ant-contrib.sourceforge.net/tasks/tasks/
[4] http://en.wikipedia.org/wiki/XProc
[5] http://www.thingbag.net/docbook/gsoc2010/doc/content/ch02s01.html
-Original Message-
From: Peter Desjardins [mailto:peter.desjardins...@gmail.com]
Sent: Wednesday, August 25, 2010 9:56 PM
To: DocBook Apps
Subject: [docbook-apps] Controlling the publishing process - shell scripts,
Ant, other tools
Hi. I've been publishing DocBook for a few years and I've always used
shell scripts to control the process. This has worked well for me but
I'm starting a new publishing system from scratch and I'd like to
improve the maintainability and scalability of the process if I can.
Although I could do anything I needed to do with my publishing system
when it was based on shell scripts, it really wasn't something that
could be easily maintained by someone else. I tried to comment and
otherwise document my scripts but realistically, it would have been
frustrating for someone else to pick through the logic.
For my new publishing system, I'm considering using Apache Ant. I see
that other people seem happy publishing XML with Ant and the software
developers I work with use it for their build process. So I've started
experimenting with Ant, starting with the examples at
http://www.dpawson.co.uk/docbook/ant.html. It's not coming easily in
the first few hours I've spent with it.
Here are some of the questions I have. Any input will be very helpful.
* What are some advantages an Ant-based publishing system has over a
shell script system? Clearly Ant is cross-platform, what else?
* Is there a typical Ant
RE: [docbook-apps] The next formal DocBook-XSL release
Hi Keith, On the webhelp branch, I have it working so that it builds the java indexer and generates the webhelp docs (which also serve to demonstrate what webhelp output looks like). The one thing I still need to figure out is why the html files in the doc directory are excluded from the distribution (everything else makes it in). If you happen to know that off the top of your head, I'd appreciate any hints! Anyway, assuming I can get that figured out, I'll merge it into the trunk in time to do some testing with the output of the snapshot builds. Thanks, David -Original Message- From: Keith Fahlgren [mailto:abdela...@gmail.com] Sent: Monday, August 23, 2010 12:33 AM To: Cramer, David W (David) Cc: Bob Stayton; Docbook Apps Subject: Re: [docbook-apps] The next formal DocBook-XSL release Hi, On Sun, Aug 1, 2010 at 6:43 PM, Cramer, David W (David) dcra...@motive.com wrote: I'm confident Kasun will have things ready to go by pencils down (August 16), but I don't know what we need to do to be integrated into the build. Let me figure that out and get back to you on when we'll be ready. We're approaching the deadlines for our tentative 1.76.0 release schedule and I'd like to know if we should shift things around. Our previous timeline was: * 27 August 2010: All changes in SVN (code freeze) * 31 August 2010: 1.76.0 released * 1 Sept-24 Sept 2010: 1.76.0 bugfixes (only) * 28 Sept 2010: 1.76.1 released I'm not able to contribute more than a naive release the current SVN trunk at the agreed-upon time (sadly the process still consumes many hours), assuming I can get all of the new outputs to build. Open questions: * Have the Summer of Code contributes been merged back into trunk? * Are there open bugs that must be resolved before 1.76.0 is released? * Are there significant contributions that people were planning on making before the end of August that should temporarily delay 1.76.0? Thanks, Keith - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] RE: [docbook] para customization affects footnote numbers
Hi Sharon, I had the very same problem long ago and was helped by Bob Stayton on the docbook-apps mailing list: This is one of the gotchas of XSL import precedence. This template in fo/footnote.xsl: xsl:template match=footnote/para[1] |footnote/simpara[1] |footnote/formalpara[1] priority=2 which generates the superscript in the para fo:block is being overridden by your customization of para. A template match with a higher import precedence will always be used before a template of lower import precedence, even if that has a better match and higher priority. So you need to copy this template to your customization layer to raise its import precedence, or change your match attribute in your customization to exclude footnote parents: match=para[not(parent::footnote)] So you'll want to change: xsl:template match=para To xsl:template match=para[not(parent::footnote)] And all should be well. Btw., I've replied to the docbook-apps list. The docbook list is for questions about what markup to use and the DocBook schema while docbook-apps is for questions about the stylesheets and other matters of DocBook processing. I'm getting a blank page for that oasis list guidelines page as well. No idea what's up with that. David From: Sharon Lifshitz [mailto:sharon.l.m...@gmail.com] Sent: Sunday, August 22, 2010 6:06 AM To: docb...@lists.oasis-open.org Subject: [docbook] para customization affects footnote numbers Hello, After redefining the para template from nwalsh/fo/block.xsl, in order to support and additional attribute, I noticed that this affected the usage of para within footnote tags -- the footnote number in the print (PDF) output no longer appeared in the footnotes section (i.e., the footnote appeared without its number); the number did appear in the footnote reference within the text. For test purposes, I tried copying the original para template definition, as-is, into my print style sheet, and the result was the same. (None of the footnote formatting parameters are set in my style sheets -- i.e., I'm using the default formatting.) The copied para template: xsl:template match=para xsl:variable name=keep.together xsl:call-template name=pi.dbfo_keep-together/ /xsl:variable fo:block xsl:use-attribute-sets=normal.para.spacing xsl:if test=$keep.together != '' xsl:attribute name=keep-together.within-columnxsl:value-of select=$keep.together//xsl:attribute /xsl:if xsl:call-template name=anchor/ xsl:apply-templates/ /fo:block /xsl:template What am I missing? P.S. I tried to read the mailing list guidelines at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=docbookguidelines.html (linked from http://wiki.docbook.org/topic/DocBookMailingList) but the page was not found? Thanks, Sharon
RE: [docbook-apps] Help needed testing CJK search support in webhelp
Perfect! I'll spin some of those as examples for testing. Thanks, David From: Camille Bégnis [mailto:cami...@allende.neodoc.biz] Sent: Friday, August 13, 2010 2:16 AM To: docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] Help needed testing CJK search support in webhelp Hi all, you can find DocBook files in many languages in the Mandriva Linux Documentation SVN at http://svn.mandriva.com/cgi-bin/viewvc.cgi/doc/MandrivaLinux/trunk/validated/content/Distrib/ HTH. Camille. On 12/08/2010 20:20, Ann-Marie Horcher wrote: I am bi-lingual, and would be able to test the German. I do not have large docbook files to provide, and would not have time to produce them before deadline. (Still completing my documentation and cleaning up final bugs) I read French, but my Chinese is only conversational. On Thu, Aug 12, 2010 at 1:53 PM, Kasun Gajasinghe kasun.gajasin...@gmail.commailto:kasun.gajasin...@gmail.com wrote: On 12 Aug 2010, at 09:17 PM, Ann-Marie Horcher horche...@gmail.commailto:horche...@gmail.com wrote: I am one of the other GSOC students. I would be happy to help my compatriot with testing. Hi Ann, Thank you very much for your kindness. Mainly we are in need of verifying the search results for languages other than English. Currently webhelp has extensive support for English, French, German and CJK languages. As both David and I not familiar with these languages, it is little hard to verify the search output. And we need to verify that build process we specified in the doc is precise, and easy to follow. If you can try to build the webhelp and make sure it works perfectly with one of *your* docbook XML file, it is greatly appreciated. And if you are familiar with one of these languages I stated above, and have docbook files to test them, it would be great. Any feedback about this is welcome! Ann, I hope you did a great work for this summer, and best of luck for your project! :) David, if you can find some docbook files which doesn't have any confidential issues, please send them to the list. Regards, Kasun Gajasinghe On Thu, Aug 12, 2010 at 10:56 AM, Cramer, David W (David) dcra...@motive.commailto:dcra...@motive.com wrote: Hi Robert, Kasun knows more about the details of the stemmer, but I can point you to the documentation for the porter stemmer we used: http://snowball.tartarus.org/algorithms/porter/stemmer.html Currently, English, French, and German are supported. You are correct search does not support wildcards in searches, and I don't believe that the algorithm would return results with the same base but different prefixes (i.e. searching for inhibit won't show pages with exhibit), but I think that's normal for any search engine. I'll add Support wildcards in query string to the list of future features. I thought I had added it there already but I see now that it's not listed. Thanks, David -Original Message- From: Robert Fekete [mailto:frob...@balabit.commailto:frob...@balabit.com] Sent: Thursday, August 12, 2010 7:14 AM To: docbook-apps@lists.oasis-open.orgmailto:docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] Help needed testing CJK search support in webhelp Hi David, First of all, thank you for both of you for your work, it looks very promising! I have a few questions about how search and stemming works: - Is it possible to add partial matches to the search results? For example, now if you search for install, installing, or installed, the same results are returned (correctly), because these words all come from install. But if you don't type the entire word (say, only 'inst'), there aren't any results. - Am I right that the search engine does prefix-only matches? (nstall, *nstall, etc. does not work) Regards, Robert - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.orgmailto:docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.orgmailto:docbook-apps-h...@lists.oasis-open.org -- Ann-Marie Horcher -- Ann-Marie Horcher
RE: [docbook-apps] Help needed testing CJK search support in webhelp
Hi Róbert, Partial matches may lead to too much noise in the search results, but I think supporting wildcards would be an excellent feature for just the situation you mention. In fact, I kind of wish I'd put it on the original list of requirements for the summer, but I didn't think of it back then :-) If Kasun thinks it's easy to add, that would be great, but he still has some other bugs to chase down and some documentation to work on before the deadline this summer, so for now I've added it to the Future enhancements (GSOC 2011?) section in the document. Thanks, David -Original Message- From: Fekete Róbert [mailto:frob...@balabit.com] Sent: Friday, August 13, 2010 2:01 AM To: Kasun Gajasinghe Cc: =?utf-8?q?cra...@mail.balabit.hu; Cramer, David W (David); docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] Help needed testing CJK search support in webhelp Hi David and Kasun, Thank you very much for your response. I admit that partial matches might not be needed for everyone. The reason I am asking about them is because I maintain extensive technical documentations (for example, http://www.balabit.com/dl/html/syslog-ng-ose-v3.1-guide-admin-en.html/bk01-toc.html) that are often loaded with parameter and option names that can be similar, or have similar endings, and it would be useful for my users to be able to search for them. We publish our docs in PDF and chunked HTML, and recently also as single-page HTML so that the internal search engine of the browser can scan the whole document, but still I get repeatedly asked for adding search to the chunked html version as well, because this version is much faster to open and navigate, and easier to send links to the relevant sections. Though now that I think of it, adding the TOC page from your work to the single-chunk version could make this easier - I'll give it a try sometime and get back to you. Thanks again! Robert On Thursday, August 12, 2010 17:50 CEST, Kasun Gajasinghe kasun.gajasin...@gmail.com wrote: Hi Robert, Currently, partial query match is not supported. Our main concern was displaying search results for the root worss in the query(installing - install), because that support is highly needed for a search engine. But a little thinking about partial matching suggested that this *might* be possible to do it by some JavaScripting. Have to think it through! Wildcard searching is just a extended version of this. It's fine if David plans to put in to the next year, but I'll see what I can do for it. And does supporting for searches like 'nstall' is really needed? I think usage of that kind of feature is very less and would not worth the effort we put in to it! Regards, --Kasun Sent from my iPhone On 12 Aug 2010, at 08:26 PM, Cramer, David W (David) dcra...@motive.com wrote: Hi Robert, Kasun knows more about the details of the stemmer, but I can point you to the documentation for the porter stemmer we used: http://snowball.tartarus.org/algorithms/porter/stemmer.html Currently, English, French, and German are supported. You are correct search does not support wildcards in searches, and I don't believe that the algorithm would return results with the same base but different prefixes (i.e. searching for inhibit won't show pages with exhibit), but I think that's normal for any search engine. I'll add Support wildcards in query string to the list of future features. I thought I had added it there already but I see now that it's not listed. Thanks, David -Original Message- From: Robert Fekete [mailto:frob...@balabit.com] Sent: Thursday, August 12, 2010 7:14 AM To: docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] Help needed testing CJK search support in webhelp Hi David, First of all, thank you for both of you for your work, it looks very promising! I have a few questions about how search and stemming works: - Is it possible to add partial matches to the search results? For example, now if you search for install, installing, or installed, the same results are returned (correctly), because these words all come from install. But if you don't type the entire word (say, only 'inst'), there aren't any results. - Am I right that the search engine does prefix-only matches? (nstall, *nstall, etc. does not work) Regards, Robert - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis- open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
RE: [docbook-apps] Help needed testing CJK search support in webhelp
Hi Ann-Marie and other interested DocBook users, I've posted some sample content in German, French, and Chinese from the Madriva documentation that Camille suggested: http://www.thingbag.net/docbook/gsoc2010/sample-de/content/ch01.html http://www.thingbag.net/docbook/gsoc2010/sample-fr/content/ch01.html http://www.thingbag.net/docbook/gsoc2010/sample-zh/content/ch01.html (Chinese content is beneath the headings) The stemming and tokenization appears to me to be working. The one quirk I notice is in CJK content: if less than the full query string is matched, then search highlighting doesn't work for those hits. This is a fairly minor annoyance. Please take a looks and let me know if you see any problems. We still need to demo the case where we don't have a stemmer but we're working on a bug related to that situation. Thanks, David From: Camille Bégnis [mailto:cami...@allende.neodoc.biz] Sent: Friday, August 13, 2010 2:16 AM To: docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] Help needed testing CJK search support in webhelp Hi all, you can find DocBook files in many languages in the Mandriva Linux Documentation SVN at http://svn.mandriva.com/cgi-bin/viewvc.cgi/doc/MandrivaLinux/trunk/validated/content/Distrib/ HTH. Camille. On 12/08/2010 20:20, Ann-Marie Horcher wrote: I am bi-lingual, and would be able to test the German. I do not have large docbook files to provide, and would not have time to produce them before deadline. (Still completing my documentation and cleaning up final bugs) I read French, but my Chinese is only conversational. On Thu, Aug 12, 2010 at 1:53 PM, Kasun Gajasinghe kasun.gajasin...@gmail.commailto:kasun.gajasin...@gmail.com wrote: On 12 Aug 2010, at 09:17 PM, Ann-Marie Horcher horche...@gmail.commailto:horche...@gmail.com wrote: I am one of the other GSOC students. I would be happy to help my compatriot with testing. Hi Ann, Thank you very much for your kindness. Mainly we are in need of verifying the search results for languages other than English. Currently webhelp has extensive support for English, French, German and CJK languages. As both David and I not familiar with these languages, it is little hard to verify the search output. And we need to verify that build process we specified in the doc is precise, and easy to follow. If you can try to build the webhelp and make sure it works perfectly with one of *your* docbook XML file, it is greatly appreciated. And if you are familiar with one of these languages I stated above, and have docbook files to test them, it would be great. Any feedback about this is welcome! Ann, I hope you did a great work for this summer, and best of luck for your project! :) David, if you can find some docbook files which doesn't have any confidential issues, please send them to the list. Regards, Kasun Gajasinghe On Thu, Aug 12, 2010 at 10:56 AM, Cramer, David W (David) dcra...@motive.commailto:dcra...@motive.com wrote: Hi Robert, Kasun knows more about the details of the stemmer, but I can point you to the documentation for the porter stemmer we used: http://snowball.tartarus.org/algorithms/porter/stemmer.html Currently, English, French, and German are supported. You are correct search does not support wildcards in searches, and I don't believe that the algorithm would return results with the same base but different prefixes (i.e. searching for inhibit won't show pages with exhibit), but I think that's normal for any search engine. I'll add Support wildcards in query string to the list of future features. I thought I had added it there already but I see now that it's not listed. Thanks, David -Original Message- From: Robert Fekete [mailto:frob...@balabit.commailto:frob...@balabit.com] Sent: Thursday, August 12, 2010 7:14 AM To: docbook-apps@lists.oasis-open.orgmailto:docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] Help needed testing CJK search support in webhelp Hi David, First of all, thank you for both of you for your work, it looks very promising! I have a few questions about how search and stemming works: - Is it possible to add partial matches to the search results? For example, now if you search for install, installing, or installed, the same results are returned (correctly), because these words all come from install. But if you don't type the entire word (say, only 'inst'), there aren't any results. - Am I right that the search engine does prefix-only matches? (nstall, *nstall, etc. does not work) Regards, Robert - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.orgmailto:docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.orgmailto:docbook-apps-h...@lists.oasis-open.org -- Ann-Marie Horcher -- Ann-Marie Horcher
RE: [docbook-apps] Help needed testing CJK search support in webhelp
Hi Robert, Kasun knows more about the details of the stemmer, but I can point you to the documentation for the porter stemmer we used: http://snowball.tartarus.org/algorithms/porter/stemmer.html Currently, English, French, and German are supported. You are correct search does not support wildcards in searches, and I don't believe that the algorithm would return results with the same base but different prefixes (i.e. searching for inhibit won't show pages with exhibit), but I think that's normal for any search engine. I'll add Support wildcards in query string to the list of future features. I thought I had added it there already but I see now that it's not listed. Thanks, David -Original Message- From: Robert Fekete [mailto:frob...@balabit.com] Sent: Thursday, August 12, 2010 7:14 AM To: docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] Help needed testing CJK search support in webhelp Hi David, First of all, thank you for both of you for your work, it looks very promising! I have a few questions about how search and stemming works: - Is it possible to add partial matches to the search results? For example, now if you search for install, installing, or installed, the same results are returned (correctly), because these words all come from install. But if you don't type the entire word (say, only 'inst'), there aren't any results. - Am I right that the search engine does prefix-only matches? (nstall, *nstall, etc. does not work) Regards, Robert - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
RE: [docbook-apps] The next formal DocBook-XSL release
We should also plan for a post-GSOC release that incorporates the work of our students this summer. David -Original Message- From: Bob Stayton [mailto:b...@sagehill.net] Sent: Sunday, August 01, 2010 5:33 PM To: Keith Fahlgren; Docbook Apps Subject: Re: [docbook-apps] The next formal DocBook-XSL release Hi Keith, I agree it has been too long, and we should do a release per your schedule. I'll take a look at the bug list. Bob Stayton Sagehill Enterprises b...@sagehill.net - Original Message - From: Keith Fahlgren abdela...@gmail.com To: Docbook Apps docbook-apps@lists.oasis-open.org Sent: Sunday, August 01, 2010 11:48 AM Subject: [docbook-apps] The next formal DocBook-XSL release Hi, It has been an extremely long time since the last release. I think that users of DocBook-XSL are underserved by the rarity of releases. Should we plan on consolidating the Google SoC work and other bugfixes some time late this month? If so, what are the 5 most critical open bugs that we should be sure to resolve? I'd say we get all the changes in by the 27th, release 1.76.0 the following week, do three weeks of bugfixes, then 1.76.1 in mid-Sept. Thanks, Keith -- Typed with thumbs - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
RE: [docbook-apps] The next formal DocBook-XSL release
Oh, just saw you mentioned already gsoc in your original post :-) I'm confident Kasun will have things ready to go by pencils down (August 16), but I don't know what we need to do to be integrated into the build. Let me figure that out and get back to you on when we'll be ready. Thanks, David -Original Message- From: Keith Fahlgren [mailto:abdela...@gmail.com] Sent: Sunday, August 01, 2010 8:12 PM To: Cramer, David W (David) Cc: Bob Stayton; Docbook Apps Subject: Re: [docbook-apps] The next formal DocBook-XSL release What do you think would be the best time for that release? Should we wait and combine? -- Typed with thumbs On Aug 1, 2010, at 5:09 PM, Cramer, David W (David) dcra...@motive.com wrote: We should also plan for a post-GSOC release that incorporates the work of our students this summer. David -Original Message- From: Bob Stayton [mailto:b...@sagehill.net] Sent: Sunday, August 01, 2010 5:33 PM To: Keith Fahlgren; Docbook Apps Subject: Re: [docbook-apps] The next formal DocBook-XSL release Hi Keith, I agree it has been too long, and we should do a release per your schedule. I'll take a look at the bug list. Bob Stayton Sagehill Enterprises b...@sagehill.net - Original Message - From: Keith Fahlgren abdela...@gmail.com To: Docbook Apps docbook-apps@lists.oasis-open.org Sent: Sunday, August 01, 2010 11:48 AM Subject: [docbook-apps] The next formal DocBook-XSL release Hi, It has been an extremely long time since the last release. I think that users of DocBook-XSL are underserved by the rarity of releases. Should we plan on consolidating the Google SoC work and other bugfixes some time late this month? If so, what are the 5 most critical open bugs that we should be sure to resolve? I'd say we get all the changes in by the 27th, release 1.76.0 the following week, do three weeks of bugfixes, then 1.76.1 in mid-Sept. Thanks, Keith -- Typed with thumbs - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis- open.org - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] Importing titlepage.xsl breaks section heading level in html
Hi there, I've notice some odd behavior in the DocBook xsls: If you import your titlepage xsl after importing the main docbook.xsl file, then all the headings for any section level are h1. However if you import the titlepage xsl first, then the headings are h1, h2, etc as you expect. I've put a minimal demo below. I'm mentioning it because the example customization layer here http://www.sagehill.net/docbookxsl/TitlePageGraphics.html has the titlepage imported after the docbook.xsl file and I've never seen instructions that you should import your titlepage before docbook.xsl. Is this by design or a bug? Given the following test document: book titleFoo/title chapter titleChap/title section titlesect1/title section titlesect2/title section titlesect3/title section titlesect4/title paraFoo/para /section /section /section /section /chapter /book With the following customization layer: xsl:stylesheet xmlns=http://www.w3.org/1999/xhtml; xmlns:xsl=http://www.w3.org/1999/XSL/Transform; version=1.0 xsl:import href=http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl/ xsl:import href=http://docbook.sourceforge.net/release/xsl/current/xhtml/titlepage.xsl/ !-- indent=yes is just for the readability of the output and has no effect on test. -- xsl:output indent=yes/ /xsl:stylesheet I get the the following output (notice that all the section headings are h1 (e.g. h1 class=titlea id=d0e16/sect4/h1): ?xml version=1.0 encoding=UTF-8? !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; head titleFoo/title meta name=generator content=DocBook XSL Stylesheets V1.75.2/ /head body div class=book title=Foo div class=titlepage div div h1 class=title a id=d0e1/Foo/h1 /div /div hr/ /div div class=toc p bTable of Contents/b /p dl dt span class=chapter a href=#d0e41. Chap/a /span /dt dd dl dt span class=section a href=#d0e7sect1/a /span /dt dd dl dt span class=section a href=#d0e10sect2/a /span /dt /dl /dd /dl /dd /dl /div div class=chapter title=Chapter 1. Chap div class=titlepage div div h1 class=title a id=d0e4/Chap/h1 /div /div /div div class=toc p bTable of Contents/b /p dl dt span class=section a href=#d0e7sect1/a /span /dt dd dl dt span class=section a href=#d0e10sect2/a /span /dt /dl /dd /dl /div div class=section title=sect1 div class=titlepage div div h1 class=title a id=d0e7/sect1/h1 /div /div /div div class=section title=sect2 div class=titlepage div div h1 class=title a id=d0e10/sect2/h1 /div /div /div div class=section title=sect3 div class=titlepage div div h1 class=title a id=d0e13/sect3/h1 /div /div /div div class=section title=sect4 div class=titlepage div div h1
