DOCBOOK-APPS: Cannot create intensional node-set error from Saxonwith make.index.markup
When I turn on make.index.markup I get this error from saxon: Making portrait pages on USletter paper (8.5inx11in) java.lang.UnsupportedOperationException: Cannot create intensional node-set with context dependencies: class com.icl.saxon.expr.PathExpression:128 at com.icl.saxon.expr.NodeSetIntent.init(NodeSetIntent.java:26) at com.icl.saxon.expr.PathExpression.reduce(PathExpression.java:186) ... Googling I find this bug logged against Saxon: http://sourceforge.net/tracker/index.php?func=detailaid=601804group_id =29872atid=397617 So I gather you can't use make.index.markup with Saxon? Or perhaps someone knows a way to tweak the index.xsl code to avoid Saxon's bug? Thanks, David
DOCBOOK-APPS: Table title alignment
Hi, What do I have to do to have my table titles centered instead of left aligned? My figure titles are centered without any special treatment. I have searched through the .dsl files without finding the setting or code section for this. I'm using DocBook v4.1, DocBook DSSSL v1.77, OpenJade v1.3.1, OpenSP v1.3.4, JadeTex v3.12 and sgml2x v0.11 on a Linux Mandrake system. Regards, Markus
DOCBOOK-APPS: writing a condensed form of docbook
while i know there are numerous XML editors to make one's life easier, one of my issues is that, in the end, the docbook that is produced is virtually impossible to scan (although i'm sure numerous people will tell me that that's not the point, you're not *supposed* to be able to scan it, just its transformed output.) i like to write my documents and manuals in condensed form, and it would be nice to quickly to go from that to final docbook. to that end, one of my techniques was to find 2-letter abbreviations for almost all of the docbook elements i used, and create a corresponding emacs abbreviations file. that made typing easier, but still left me with unreadable docbook, so i'm considering writing my stuff in what i'll call pidgin docbook, and having a post-processor (sed or perl) turn it into real docbook. as an example, instead of writing itemizedlist listitem para blah blah /para /listitem listitem para woof woof /para /listitem /itemizedlist i would just write il li blah blah /li li woof woof /li /il or possibly condense it even further, who knows? it would be nice to be able to write my docbook sort of stream of consciousness, throwing out lists and so on, knowing that, when i was done, i could just run it all thru my post-processor to get the real thing. i'm sure several people here are gagging at this point, but i found that using the emacs abbreviations worked pretty well since, given the subset of docbook elements i was using frequently, i could assign an intuitive and unique 2-letter abbreviation to almost all of them, like il = itemizedlist ol = orderedlist li = listitem em = emphasis vn = varname fn = filename pl = programlisting sc = screen and so on. is there anyone who's tried this? and maybe even wants to share their post-processor or something i can hack to get this? it certainly can't be hard -- perl would make short work of this, don't you think? comments? rday
Re: DOCBOOK-APPS: Breaking a document into smaller pieces
Rune Enggaard Lausen wrote: At the end of each subdocument, you put a comment similar to !-- Local Variables: mode: xml sgml-parent-document: (master-file.xml) End: -- Substitute the name of your file containing the DOCTYPE for master-file.xml. The next time you load the subdocument PSGML knows where to find the reference to the DTD and everything is great again. I still have problems with psgml and/or xmllint and German special characters: If I don't start my chunk-files, say chapter1.xml, with an XML-declaration like ?xml version=1.0 encoding=ISO-8859-1? I get the following error from xmllint. xmllint -valid --noout LEDATutorium.xml chapter1.xml:5: error: Input is not proper UTF-8, indicate encoding ! titleAuf die Plätze - fertig - los!/title Bit if I do so, psgml refuses to read the DTD and says everywehre no valid element at thsi point. (I'm using XEmacs; maybe that's the problem?) Greetings, Joachim
Re: DOCBOOK-APPS: writing a condensed form of docbook
I was interested to see this item come by last week: http://www-106.ibm.com/developerworks/library/x-matters24/index.html Here's a quote from the Abstract: The document format called reStructuredText has been adopted as one of the official source formats for Python documentation, but is also useful for other types of documentation. reStructuredText is an interesting hybrid of technologies -- in syntax and appearance it is similar to other almost-plaintext formats, but in semantics and API it is very close to XML. David takes a look at this format and shows you how existing tools can transform reStructuredText into several XML dialects (docutils, DocBook, OpenOffice), along with other useful formats like LaTeX, HTML, and PDF. It might be worth some of your time. Regards....edN Robert P. J. Day wrote: while i know there are numerous XML editors to make one's life easier, one of my issues is that, in the end, the docbook that is produced is virtually impossible to scan (although i'm sure numerous people will tell me that that's not the point, you're not *supposed* to be able to scan it, just its transformed output.) i like to write my documents and manuals in condensed form, and it would be nice to quickly to go from that to final docbook. to that end, one of my techniques was to find 2-letter abbreviations for almost all of the docbook elements i used, and create a corresponding emacs abbreviations file. that made typing easier, but still left me with unreadable docbook, so i'm considering writing my stuff in what i'll call pidgin docbook, and having a post-processor (sed or perl) turn it into real docbook. as an example, instead of writing itemizedlist listitem para blah blah /para /listitem listitem para woof woof /para /listitem /itemizedlist i would just write il li blah blah /li li woof woof /li /il or possibly condense it even further, who knows? it would be nice to be able to write my docbook sort of stream of consciousness, throwing out lists and so on, knowing that, when i was done, i could just run it all thru my post-processor to get the real thing. i'm sure several people here are gagging at this point, but i found that using the emacs abbreviations worked pretty well since, given the subset of docbook elements i was using frequently, i could assign an intuitive and unique 2-letter abbreviation to almost all of them, like il = itemizedlist ol = orderedlist li = listitem em = emphasis vn = varname fn = filename pl = programlisting sc = screen and so on. is there anyone who's tried this? and maybe even wants to share their post-processor or something i can hack to get this? it certainly can't be hard -- perl would make short work of this, don't you think? comments? rday
Re: DOCBOOK-APPS: writing a condensed form of docbook
Have you seen this? http://www.xmlmind.com/aptconvert.html It looks like it has a similar goal. comments? Cheerio! Bob --- Robert McIlvride ([EMAIL PROTECTED]) Cogent Real-Time Systems (www.cogent.ca)
DOCBOOK-APPS: DocBook XSL-FO: content-width=scale-to-fit
Hello there, recently, we have started to use the DocBook XSL stylesheets together with the RenderX XEP formatter. Since we have documents with quite large images, we would like to have them rescaled in the final pdf output according to the available space. The XEP Renderer can do this with the following declaration: fo:external-graphic src=url(img/large-image.gif) content-width=scale-to-fit content-height=100% width=100%/ This scales the image if it is wider than the currently available width. With the current distribution of the XSL Stylesheets, it is not possible at all to set content-width=scale-to-fit. It seems that in until rev 1.14 of fo/graphics.xsl, the scalefit attribute of imagedata etc. set the content-width and content-height to scale-to-fit, but this was removed when the graphics support was redone http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/docbook/xsl/fo/graphics.xsl.diff?r1=1.14r2=1.15. What are your opinions on this matter? I think that the scalefit attribute should be considered in some way. For XEP, it would be best if scalefit would set content-width and content-height to scale-to-fit only if contentdepth and contentwidth are not explicitely set. But I have no idea about what implications this does make for other FO processors, so I would be thankful if some people here could enlighten me. I have also filed a RFE at http://sourceforge.net/tracker/?func=detailaid=685806group_id=21935atid=373750, so you might comment there as well. Thanks for any comments Bernd
Re: DOCBOOK-APPS: Cannot create intensional node-set error fromSaxon with make.index.markup
On Mon, Feb 17, 2003 at 02:51:51AM -0600, David Cramer wrote: When I turn on make.index.markup I get this error from saxon: Making portrait pages on USletter paper (8.5inx11in) java.lang.UnsupportedOperationException: Cannot create intensional node-set with context dependencies: class com.icl.saxon.expr.PathExpression:128 at com.icl.saxon.expr.NodeSetIntent.init(NodeSetIntent.java:26) at com.icl.saxon.expr.PathExpression.reduce(PathExpression.java:186) ... Googling I find this bug logged against Saxon: http://sourceforge.net/tracker/index.php?func=detailaid=601804group_id =29872atid=397617 So I gather you can't use make.index.markup with Saxon? Or perhaps someone knows a way to tweak the index.xsl code to avoid Saxon's bug? The index code in DocBook XSL is complex, to say the least. Every time I try to work with it I have to review my five pages of notes so I understand what the complex expressions are doing. In this case, since there is no indication of the line number causing the problem, finding the cause of this error would not be easy. I did notice, however, that the saxon bug report includes a patch for Saxon. You might try that. -- Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 The SCO Group fax: (831) 429-1887 email: [EMAIL PROTECTED]
Re: DOCBOOK-APPS: writing a condensed form of docbook
Robert P. J. Day wrote: i like to write my documents and manuals in condensed form, and it would be nice to quickly to go from that to final docbook. Since you stay with the xml-syntax anyway I'd say XSLT would be a convenient way; all you need is a styl3sheet containing an identity template and templates matching your abbreviations ( xsl:template match=@* | node() xsl:copyxsl:apply-templates select=@* | node() //xsl:copy /xsl:template xsl:template match=li listitemparaxsl:apply-templates //para/listitem /xsl:template ... ) markus
Re: DOCBOOK-APPS: DocBook XSL-FO: content-width=scale-to-fit
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/docbook/xsl/fo/graphics.xsl.diff?r1=1.14r2=1.15. What are your opinions on this matter? I think that the scalefit attribute should be considered in some way. For XEP, it would be best if scalefit would set content-width and content-height to scale-to-fit only if contentdepth and contentwidth are not explicitely set. But I have no idea about what implications this does make for other FO processors, so I would be thankful if some people here could enlighten me. Wouldn't it be the right approach to just supply a custom template for process.image in xep.xsl (customization level for XEP) and leave it as is for other processors? David Tolpin
DOCBOOK-APPS: docbook fo - page breaks
hi, is there a way to customize the docbook fo stylesheets so that page breaks are enforced at certain sect1 elements - e.g. for doctype article, if less than 3 lines of text would be displayed on the page? i know that i can set the break.before attribute in the section.title.level1.properties attribute set, but this would affect all sect1 elements. thanks for any hints or suggestions, markus
Re: DOCBOOK-APPS: writing a condensed form of docbook
On Mon, 17 Feb 2003, Markus Spath wrote: Robert P. J. Day wrote: i like to write my documents and manuals in condensed form, and it would be nice to quickly to go from that to final docbook. Since you stay with the xml-syntax anyway I'd say XSLT would be a convenient way; all you need is a styl3sheet containing an identity template and templates matching your abbreviations ( xsl:template match=@* | node() xsl:copyxsl:apply-templates select=@* | node() //xsl:copy /xsl:template xsl:template match=li listitemparaxsl:apply-templates //para/listitem /xsl:template ... ) dang. why didn't *i* think of that? thanks. rday
Re: DOCBOOK-APPS: blockinfo support missing
* Bob Stayton [EMAIL PROTECTED] [030216 22:01]: I think it is an oversight. Could you file a bug report on http://sourceforge.net/projects/docbook/ ? Done. Michael -- [EMAIL PROTECTED] http://www.miwie.org [EMAIL PROTECTED]
DOCBOOK-APPS: Re: xref to image
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [Follow-ups to docbook-apps, please] / Daniel Moellenbeck [EMAIL PROTECTED] was heard to say: | i do a xref to the figure with xref linkend=fg-template /. | In my convertet pdf document i get Abbildung 1.1 Template-Engine | with a link to my image. How can i format this xref-link, that the | link is only Abbildung 1.1? You need to change the cross-reference template for figures. Bob's got it covered beautifully: http://www.sagehill.net/xml/docbookxsl/CustomMethods.html#CustomGentext Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | Logical consequences are the http://www.oasis-open.org/docbook/ | scarecrows of fools and the Chair, DocBook Technical Committee | beacons of wise men.--Thomas Henry | Huxley -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+UVnFOyltUcwYWjsRAteRAKClRpPSh1MrbeexfVA+gTYMD+Q9qACglLjc cK4pJBQcozqOqUOX19FSrzI= =pxQt -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Additional XEP extensions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Paul A. Hoadley [EMAIL PROTECTED] was heard to say: | I can file an RFE at SourceForge if anyone else thinks this is useful, | though my current approach is fairly crude. Please file this as a patch or enhancement and I'll get it into the distro asap. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | A lie is an abomination unto the http://www.oasis-open.org/docbook/ | Lord and a very present help in Chair, DocBook Technical Committee | time of trouble.--Adlai Stevenson -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+UVqLOyltUcwYWjsRAnzjAJ4k9lLl+6fo0N3SpjTIOZYa9N4jgwCdE5rE HfR5CQMOiAMPjszDRx0KrgQ= =zXqX -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Open ebook conversions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Bill Lawrence [EMAIL PROTECTED] was heard to say: | Does anyone know of existing conversion scripts to transform Docbook | into Open eBook? No. Open eBook is a subset of XHTML, right? The XHTML stylesheets will probably get you most of the way there. If you have suggestions for improvements, please let us know. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | When we reduce our own liberties http://www.oasis-open.org/docbook/ | to stop terrorism, the terrorists Chair, DocBook Technical Committee | have already won.--Reverius -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+UVsIOyltUcwYWjsRAvm1AJ4h8A1hLjY8/7cKtQMwjgB3ZJqi5QCfSTy5 AnCY1PjFXANL+bCE6wzBY68= =T64g -END PGP SIGNATURE-
RE: DOCBOOK-APPS: Cannot create intensional node-set error fromSaxon with make.index.markup
Patching saxon did the trick. Thanks, David -Original Message- From: Bob Stayton [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 11:16 AM To: David Cramer Cc: [EMAIL PROTECTED] Subject: Re: DOCBOOK-APPS: Cannot create intensional node-set error from Saxon with make.index.markup On Mon, Feb 17, 2003 at 02:51:51AM -0600, David Cramer wrote: When I turn on make.index.markup I get this error from saxon: Making portrait pages on USletter paper (8.5inx11in) java.lang.UnsupportedOperationException: Cannot create intensional node-set with context dependencies: class com.icl.saxon.expr.PathExpression:128 at com.icl.saxon.expr.NodeSetIntent.init(NodeSetIntent.java:26) at com.icl.saxon.expr.PathExpression.reduce(PathExpression.java:186) ... Googling I find this bug logged against Saxon: http://sourceforge.net/tracker/index.php?func=detailaid=601804group_id =29872atid=397617 So I gather you can't use make.index.markup with Saxon? Or perhaps someone knows a way to tweak the index.xsl code to avoid Saxon's bug? The index code in DocBook XSL is complex, to say the least. Every time I try to work with it I have to review my five pages of notes so I understand what the complex expressions are doing. In this case, since there is no indication of the line number causing the problem, finding the cause of this error would not be easy. I did notice, however, that the saxon bug report includes a patch for Saxon. You might try that. -- Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 The SCO Group fax: (831) 429-1887 email: [EMAIL PROTECTED]
DOCBOOK-APPS: Re: Website and catalog.xml from distro
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Vitaly Ostanin [EMAIL PROTECTED] was heard to say: | I'm use website-2.4.0 and original catalog.xml from distribution | and have some questions: | | 1. | It's possible to make long names for resolving location of XSL | styles ? | | uri name=autolayout.xsl | uri=autolayout.xsl/ I'm not sure I understand what you mean. | Name from this example may be not uniq and this not worked for | import styles by full URL: | http://docbook.sourceforge.net/release/website/2.4.0/xsl/autolayout.xsl Right. I probably do need to make sure the full release URIs are in there. | BTW, | http://docbook.sourceforge.net/release/website/current | points to old website version. The current version never points to x.y.0 releases. Snapshot should, but I may have forgotten to do that. | 2. | In catalog.xml missing chunk-common.xsl - it can be used for | customization layers (for example, for my :)) Thanks. | 3 (offtopic :)). | Can XSL styles have a PUBLIC id ? Sigh. No. Though the urn:publicid: scheme could be used, it'd break for everyone not using a catalog. Yes, I kick myself for not getting this fixed in XSLT 1.0. Kick, kick, kick, ... Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | Sarchasm: The gulf between the http://www.oasis-open.org/docbook/ | author of sarcastic wit and the Chair, DocBook Technical Committee | person who doesn't get it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+UVx5OyltUcwYWjsRAthDAJ9tSy61cU0/3v4i+/NiGu0Xfz7cPQCfcysL fKuSXHqZ5j2ryBix8FKfDgM= =9+/x -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Docbook xsl stylesheets and accessibilityrequirements?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Billard, Trish [EMAIL PROTECTED] was heard to say: [...] | Is there any documentation out there about how these transformations | meet or don't meet these requirements? I'll need to create | configurations or customizations to ensure the requriements are met. I'm not aware of any comprehensive studies, but I've tried to make sure the transformations are accessible. If you find cases where they aren't, I'll make sure it gets fixed promptly. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | Science is like sex: sometimes http://www.oasis-open.org/docbook/ | something useful comes out, but Chair, DocBook Technical Committee | that is not the reason we are | doing it.--Richard Feynman -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+UVzdOyltUcwYWjsRArsVAJ9EWFEIFWQ8m/OPchXwsbjs14j8AgCfZGGV Aysi+1DUwMiQsPd99sBoTmA= =qhkd -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Docbook xsl stylesheets and accessibilityrequirements?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / [EMAIL PROTECTED] was heard to say: | A general question for folks. If one is stylesheet agnostic, would DSSSL or | XSL be a better choice for a start toward producing XHTML Strict? I was a | LISP hacker in a previous life, and so find DSSSL appealing. Sigh. The easiest way to get XHTML strict out of the stylesheets is almost certainly to run tidy. I appreciate that people would like to be able to get strict output from the stylesheets for arbitrary DocBook, but it would be very, very hard. However, if you exercise some control in your DocBook sources, it should be fairly easy to get strict XHTML. If you find otherwise, I'd be interested in seeing the examples. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | They that can give up essential http://www.oasis-open.org/docbook/ | liberty to obtain a little Chair, DocBook Technical Committee | temporary safety deserve neither | liberty nor safety.--Benjamin | Franklink -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+UV2QOyltUcwYWjsRAgokAJ4kFCwdiAAChXer0QgGO7t5unrfnwCdHALj fuBy3cr/4MlxlZCfU8Hnqo4= =03Me -END PGP SIGNATURE-
DOCBOOK-APPS: Re: Docbook xsl stylesheets and accessibilityrequirements?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Billard, Trish [EMAIL PROTECTED] was heard to say: | Wow, this started quite the thread. | But what I was really looking for is for the HTML (rather than the XHTML), what |things to meet accessibility requirements do Norm's stylesheets already provide? |Examples might be always supporting putting an alt attribute for all images, allowing |resizing of point sizes. That sort of thing. DocBook meets those requirements, I believe. Last time I reviewed the W3C XML Accessibility Guidelines, I thought DocBook passed. Dave Pawson might know better than I. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | There are only 10 types of people http://www.oasis-open.org/docbook/ | in this world: those who Chair, DocBook Technical Committee | understand binary and those who | don't. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+UV3lOyltUcwYWjsRAvtgAJ978XeWNHYsHXAuk8m/kMvNTene1gCbBiIb LsOFGrZjq/qLzlZRHC6xGjI= =MQXV -END PGP SIGNATURE-
DOCBOOK-APPS: more make.index.markup
Ok, I've used make.index.markup, run pdf2index (with a small test doc, it ran directly on the pdf, with a larger doc, I had to run it on the .ps file), and put the munged index back in my doc. When I process it, I get: WorkFlows/Reference/StandardInstallMaster/Win32/Workflow/Extra Making portrait pages on USletter paper (8.5inx11in) No template for /book/index/indexdiv/title (or any of its leaves) exists in the context named title in the en localization. No template for /book/index/indexdiv/title (or any of its leaves) exists in the context named title in the en localization. No template for /book/index/indexdiv/title (or any of its leaves) exists in the context named title in the en localization. No template for /book/index/indexdiv/title (or any of its leaves) exists in the context named title in the en localization. No template for /book/index/indexdiv/title (or any of its leaves) exists in the context named title in the en localization. ... In the resulting pdf, there are no indexdiv titles and no title for the index itself. Did I forget something or is this a bug? Thanks, David
DOCBOOK-APPS: Re: Additional XEP extensions
On Mon, Feb 17, 2003 at 04:56:27PM -0500, Norman Walsh wrote: / Paul A. Hoadley [EMAIL PROTECTED] was heard to say: | I can file an RFE at SourceForge if anyone else thinks this is useful, | though my current approach is fairly crude. Please file this as a patch or enhancement and I'll get it into the distro asap. Thanks Norm. RFE #684561. -- Paul. mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
DOCBOOK-APPS: DOCBOOK: 1.60.1 xsl-stylesheets are overfull by exactly5.96419pt?
This just seems too suspicious not to be something configurable that I have either missed or messed up in my config: Every page of my document, when passed through the xsl-stylesheets and into the current pdfxmltex, reports being always and /precisely/ 5.96419pt vertically overfull ... sure enough if there's a header on the page, the font clearly overwrites the underscore line under the doc-title by just that tiny shade of a font size (ok, I can't be /certain/, but it /looks/ to be at least 5.9pts ;) it's a tiny amount, but it's a rock steady amount. What's causing it? Any recommendations on how I can fix it? Also, the params.xml file blows up my teTeX pool size (even at 75) Is a generated HTML format of this file online anywhere? I didn't find it in the XSL documentation on the website. -- Gary Lawrence Murphy - [EMAIL PROTECTED] - TeleDynamics Communications - blog: http://www.teledyn.com/mt/ - biz: http://teledyn.com/ - Computers are useless. They can only give you answers. (Picasso)
DOCBOOK-APPS: admon.graphics in docbook-xsl/fo
Using the xsl-stylesheets (1.60.1) and PassiveTeX, I added xsl:param name=admon.graphics select=1/ to my customization layer, and now I get the following crash; if I take that admon.graphics out, it compiles. Is there something else required? I have the graphics dir linked as ./images the current (I had tried specifying the path in the xsl with the same results; btw, http://www.sagehill.net/xml/docbookxsl/ is ambiguous about the admon.graphics.path syntax; an example there might help ;) Here's the crash error: ! LaTeX Error: Something's wrong--perhaps a missing \item. See the LaTeX manual or LaTeX Companion for explanation. Type H return for immediate help. ... l.323 ...te.png//fo:block/fo:list-item-label fo:list-item-body start-i... ? ! Emergency stop. -- Gary Lawrence Murphy - [EMAIL PROTECTED] - TeleDynamics Communications - blog: http://www.teledyn.com/mt/ - biz: http://teledyn.com/ - Computers are useless. They can only give you answers. (Picasso)
DOCBOOK-APPS: dsssl1.77 html TOC linkage problem
The manual I am trying to adapt to docbook is split into two chapters, control lines/commands for several programs (one program per sect1) and descriptions of those programs, again one program per sect1 element. I have tried to set up links between the sections of each chapter as follows chapter id=controls TitleProgram Controls /Title sect1 id=ABSORB-cont Title id=ABSORB-cont-longXRef LinkEnd=ABSORB-desc endterm=ABSORB-desc-short: Absorption corrections/Title titleabbrev id=ABSORB-cont-shortABSORB /titleabbrev para /para /sect1 /chapter chapter id=descriptions TitleReference Manual/Title sect1 id=ABSORB-desc Title id=ABSORB-desc-longXRef LinkEnd=ABSORB-cont endterm=ABSORB-cont-short: Absorption corrections/Title titleabbrev id=ABSORB-desc-shortABSORB/titleabbrev para/para /sect1 /chapter Although this provides the desired functionality of switching back and forth between the control lists and the descriptive sections by selecting the title link/xref, sadly it breaks the TOC linkage, as well as the next/prev links on each html page. The resultant html for those items is rendered as hrefhrefxreftext/hreftitletext/href with only the innermost href active (tested with Mozilla and Konqueror). I am not sure if this is a dsssl (stylesheets 1.77) bug, or just tag misuse on my part. TIA for any pointers. Doug
RE: DOCBOOK-APPS: DocBook to man pages XSL
Hi Bob, The output from links is very nice with two exceptions: 1) there's a line break after each bullet/number in listitems (liptext/p/li doesn't go over well with links). 2) there's a character that shows up as ^@ in more/less or as a box in notepad before each step number in a procedure. I was wondering if you were seeing the same thing and how you get around it. Same result with Elinks 0.3 and 0.96. Thanks, David -Original Message- From: Bob Stayton [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 20, 2001 11:05 AM Are you using one of the text-based web browsers to convert HTML to text? I'm currently using links (no, not lynx) from http://artax.karlin.mff.cuni.cz/~mikulas/links/ and it handles tables nicely. It even does frames! And then there is the venerable lynx which I think handles tables now, and another called w3m from Japan http://ei5nazha.yz.yamagata-u.ac.jp/~aito/w3m/eng/ All of these have a dump option to let you save the generated text into a file.
RE: DOCBOOK-APPS: docbook fo - page breaks
is there a way to customize the docbook fo stylesheets so that page breaks are enforced at certain sect1 elements - e.g. for doctype article, if less than 3 lines of text would be displayed on the page? i know that i can set the break.before attribute in the section.title.level1.properties attribute set, but this would affect all sect1 elements. As far as I know the FO stylesheets cannot see wether there'll be less than three lines of text remaining on the page. It's the task of the FO processor to portion the textflow onto certain pages. Regards Gisbert Amm
