DOCBOOK-APPS: DSSSL to get section and chapter title in header
Hi, I'm looking for ways to generate a header using the DSSSL style sheets (openjade/pdfjadetex), that is like: PageNo ChapterTitle | SectionTitle Page No --|- | R H Page | L H page | ie. with page number, chapter and section titles on left and right pages all with a rule underneath. Some questions: 1) How do you refer to both the chapter and section (sect1) title when producing a header? 2) How do you build a header line that has the first part quadded left and the last part quadded right with a rule underneath? My attempts so far have resulted in: Outer Inner by defining page-outer-header, page-inner-header and a rule as page-center-header. The problem now is that I want the rule underneath the text. Setting space-before or space-after appears to makes no difference. The secret lies somewhere with the rule. By not having a rule I can get: Outer Center Inner Or a rule above the centered text: Outer Center Inner Having centered text and with a rule underneath results in: Center Outer Inner and rules above and below the centered text results in: Having centered text and with a rule underneath results in: Center Outer Inner In other words the rule is forcing the other headers down. By drawing rules on all footers (outer, center and inner) I start to get what I'm after, although there appears to be some problem with getting the baselines lined up. I'm sure there must be a cleaner way. Thanks. Dave Brooks
Re: DOCBOOK-APPS: preface page numbering
Hi, Great! After applying both patches twosidestartonright.patch.bz2 features.patch.bz2 I get really neat output. For those interested, I put the following packages in Mandrake Cooker: jadetex-3.11-1mdk openjade-1.3-15mdk docbook-style-dsssl-1.72-1mdk Thanks Ian, Camille. Note: unexpectedly, I had to change the %top-margin% when using the patched openjade. Ian Castle a écrit : On Thu, 23 Aug 2001, camille wrote: Ian Castle a écrit : On Thu, 23 Aug 2001, camille wrote: You need to upgrade to the latest jadetex which has support for roman numerals. OK, it works nice for me with the following: jadetex-3.11-1mdk openjade-1.3-14mdk docbook-style-dsssl-1.72-1mdk You might also want to apply some patches to openjade which enable it to work correctly with the two sided printing support in the newer versions of jadetex. * Your patch posted at http://sourceforge.net/tracker/?group_id=2115atid=302115 does not apply to the openjade-1.3 source tree: patching file jade/TeXFOTBuilder.cxx Hunk #1 FAILED at 387. Hunk #2 succeeded at 1731 (offset -204 lines). Hunk #3 FAILED at 4577. Thanks, Camille. You're missing Francis J. Lacoste's features patch. That must be applied first. I've just tested them both with your openjade-1.3-14mdk.src.rpm from Cooker and they apply fine. I'll send them to you! Francis' patch improves time/date handling and adds the page-two-side extension. It also has some improvements for tables. This patch is in CVS (HEAD). My patch from sourceforge is against CVS. To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: DSSSL to get section and chapter title in header
I've answered my first question - (element-title-string (current-node)) and (element-title-string (parent (current-node))) when producing sect1 headers do the job nicely. Now to sort out the rules underneath... Some questions: 1) How do you refer to both the chapter and section (sect1) title when producing a header? To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
RE: DOCBOOK-APPS: Best tool for DocBook
A pointer to an introduction to emacs/psgml and some psgml tips that you might find useful: The Emacs/PSGML chapter from SGML CD: Free SGML Software and How to Use It, Bob DuCharme: http://www.snee.com/bob/sgmlfree/emcspsgm.zip Various PSGML Tricks: http://www.snee.com/bob/sgmlfree/emcspsgm.html I find the introduction useful both for complete novices and for seasoned emacs hackers (with emacs, the sky is the limit, so there's *always* more to learn). Kind regards Peter Ring -Original Message- From: Dennis Grace [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 22, 2001 9:55 PM To: [EMAIL PROTECTED] Subject: DOCBOOK-APPS: Best tool for DocBook snip Here's one tiny example (I can offer dozens), of the kind of problems I see with Emacs. We put a new author on Emacs/psgml a few weeks ago, and after going through the tutorial she couldn't figure out how to open a new document. She's young, and she has very little UNIX experience, but she's an intelligent woman. I grant that she may have gone through the tutorial too quickly, but the Emacs help system is a disorganized mess. She pulled down the *Help* menu, and she simply could not find anything that said, To start a new document in Emacs, What the tutorial actually says is, You can also find a file which does not already exist. This is the way to create a file with Emacs; For a vi user, this makes perfect sense, to a Windows or Mac user, it's gibberish. I'm sure this information is also available elsewhere, but it's not clearly or readily available. (Please don't send me notes telling me all the places I might find this datum--that's not my point). I admit also that I'm spoiled by GUIs. I want a button or a menu item that clearly says *New*. I also want a Help menu that offers help. Emacs offers neither. snip To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Re: DOCBOOK: Minutes: DocBook Technical CommitteeMeeting: 21 Aug 2001
On Fri, Aug 24, 2001 at 10:20:35AM +0200, Jirka Kosek wrote: Daniel Veillard wrote: Hum, assuming DocBook 5.0 is XML only, did you evaluate XLink ? I assume you at least looked at it, and if yes do you have an archive of pros/cons available ? Using XLink would mean to use XML namespaces in DocBook documents. There are not many XML editors which are able to deal with namespaced documents. If you want to use editors like XMetaL, Epic, Emacs+PSGML to edit DocBook documents with namespace you must create single DTD which incorporates DocBook + XLink + whatever else (XInclude, MathML, SVG, I don't fully understand the problem from an editor point of view, they just have names with ':' in them, they should not have to worry about this, those are of course perfectly acceptable XML Names per the XML spec. Do you mean that XMetaL, Epic and Emacs+PSGML don't support names with ':' ? ...). It is not easy to merge DTDs. Agreed but it's a 1 step effort, once done people should not have to worry about what spec the given element or attribute came from. On the other hand the semantic has already been defined etc, and that's supposed to be better for users. Daniel -- Daniel Veillard | Red Hat Network http://redhat.com/products/network/ [EMAIL PROTECTED] | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: DSSSL to get section and chapter title in header
You can use a line-field AFTER each item, and force its lenght as the width paper. Then the whole rule INSIDE this line-field will wrap to the next line and all the three will get mixed as one. HTH. Juan R. Migoya SPAIN Dave Brooks, BCS Systems wrote: I've answered my first question - (element-title-string (current-node)) and (element-title-string (parent (current-node))) when producing sect1 headers do the job nicely. Now to sort out the rules underneath... Some questions: 1) How do you refer to both the chapter and section (sect1) title when producing a header? To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Re: DOCBOOK: Minutes: DocBook Technical CommitteeMeeting: 21 Aug 2001
Daniel Veillard wrote: I don't fully understand the problem from an editor point of view, they just have names with ':' in them, they should not have to worry about this, those are of course perfectly acceptable XML Names per the XML spec. Do you mean that XMetaL, Epic and Emacs+PSGML don't support names with ':' ? They support it, but they don't support XSD or other schema language which is able to handle namespaces. Without schema definition for your document instances your editor cann't guide you while editing and cann't check validity of your documents on the fly. Today's well supported schema language is only DTD - no namespace support, no easy way to integrate with other DTDs. It possible to merge DTD, but you must fix namespace prefixes, which is not what all users want. If you want to mix two DTD they must be well parametrized and even if they are parametrized it is not easy as with some schema language with built-in NS support. Jirka - Jirka Kosek e-mail: [EMAIL PROTECTED] http://www.kosek.cz To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: DSSSL to get section and chapter title in header
Thanks Juan. I put: (make line-field field-width: %page-width% inhibit-line-breaks?: #t (empty-sosofo) ) after each item and it makes no difference. Putting rules on each of the headers (outer, center, inner) does do the job except that the rule is too high up. I can tweak this via jadetex.dtx but would rather do it all in DSSSL. Dave At 12:30 24/08/01 +0200, Juan R. Migoya wrote: You can use a line-field AFTER each item, and force its lenght as the width paper. Then the whole rule INSIDE this line-field will wrap to the next line and all the three will get mixed as one. To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Re: DOCBOOK: Minutes: DocBook Technical CommitteeMeeting: 21 Aug 2001
On Fri, Aug 24, 2001 at 12:52:55PM +0200, Jirka Kosek wrote: Daniel Veillard wrote: I don't fully understand the problem from an editor point of view, they just have names with ':' in them, they should not have to worry about this, those are of course perfectly acceptable XML Names per the XML spec. Do you mean that XMetaL, Epic and Emacs+PSGML don't support names with ':' ? They support it, but they don't support XSD or other schema language which is able to handle namespaces. Without schema definition for your document instances your editor cann't guide you while editing and cann't check validity of your documents on the fly. Today's well supported Yes, you can use DtD for this if you accept to have a predefined prefix for the namespace. Using xlink:href in the DTD is IMHO perfectly acceptable, and will work with those tools. schema language is only DTD - no namespace support, no easy way to integrate with other DTDs. You don't need Schemas to validate a document made of multiple namespaces. You do only if you absolutely require the need to have any possible prefix for a given namespace. I don't think this constraint is needed in the DocBook framework. It possible to merge DTD, but you must fix namespace prefixes, which is not what all users want. If you want to mix two DTD they must be well I do think it's a perfectly acceptable solution until tools get updated to Schemas if they ever are. If you use DtDs only, then you have to use predefined prefixes, with the namespace declarations possibly defaulted from the DTD. If your tools are upgraded to Schemas, then you will be able to map those namespace to any value. Sounds a simple and clear upgrade path. I think that not reusing other specifications under the argument that in that case you want to be able to map the associated namespace prefix to any values would be a really hard position to defend. I hope that's not what you are suggesting. But I understand that the initial work of merging DTDs is not very fun nor easy. Daniel -- Daniel Veillard | Red Hat Network http://redhat.com/products/network/ [EMAIL PROTECTED] | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Re: DOCBOOK: Minutes: DocBook TechnicalCommitteeMeeting: 21 Aug 2001
Daniel Veillard wrote: I think that not reusing other specifications under the argument that in that case you want to be able to map the associated namespace prefix to any values would be a really hard position to defend. I hope that's not what you are suggesting. But I understand that the initial work of merging DTDs is not very fun nor easy. But if we stay with DTDs how many variants we should produce? DocBook + XLink or DocBook + MathML or DocBook + SVG or DocBook + XLink + SVG or DocBook + SVG + myOwnML or ... There are too many possibilites. As far as merging of DTDs cann't be automated, going DTDs way to support other markup schemes than DocBook in DocBook documents is not long term solution (but may be used if you need MathML or SVG in your document right now). My personal opinion about DocBook future is to let it be single DTD, doing linking and inclusion by DocBook's elements. When there will be more tools supporting namespaces and validation of document against schemas for more than one namespace, everyone can use DocBook with all additional namespaces he/she wants without need to do costly manual merge of DTDs. This would be first time we can start thinking of using XLink instead of ulink and possibly other elements. (I am looking forward for outputs about NS support from following DocBook TC meetings.) Jirka - Jirka Kosek e-mail: [EMAIL PROTECTED] http://www.kosek.cz To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Re: DOCBOOK: Minutes: DocBook TechnicalCommitteeMeeting: 21 Aug 2001
On Fri, Aug 24, 2001 at 01:35:34PM +0200, Jirka Kosek wrote: There are too many possibilites. As far as merging of DTDs cann't be automated, going DTDs way to support other markup schemes than DocBook in DocBook documents is not long term solution (but may be used if you need MathML or SVG in your document right now). My personal opinion about DocBook future is to let it be single DTD, doing linking and inclusion by DocBook's elements. When there will be more tools Then you're gonna create a legacy problem that you will NEVER be able to get rid of. If you start adding DocBook linking specific construct, this mean in practice you will never get your user base to switch to a more standard solution. Been there, done that, fighted for 2.5 years with the HTML WG at W3C, not fun at all, I don't intend to do the same here, which also mean that if you don't want to use XLink I won't make any mess. But you go this way you should clearly state that you don't care reusing those standards, that would be more frank. If you want XLink support add it in the default DTD, period. If you start adding customization layer, it's just that customization, and those should not go in the standard IMHO. Stay focused and avoid fragmentation of your user base. Be also clear about your objectives. Daniel -- Daniel Veillard | Red Hat Network http://redhat.com/products/network/ [EMAIL PROTECTED] | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: best tool for docbook?
On Thu, Aug 23, 2001 at 05:21:34PM +0100, [EMAIL PROTECTED] wrote: But they need at least approximation of visual appearance during editing. They aren't able edit text without some level of WYSIWYG. If they have this problem, then they have not completely internalized the philosophy behind DocBook. I agree with the statement but not sentiment. Don't the vast majority of users who author content want an easy life when it comes their editor? Why should they do battle with their editor (remembering Emacs keystrokes, Docbook syntax, symantics structure, constantly customising stylesheets upgrading their toolchains for example) when all they really want to concentrate on is the content of the document they're authoring? Remember, the semantic information that DocBook allows you to encode with its elements can be a significant and very useful part of the content of a document. I remember my growing pains when I first started using Docbook XML. I constantly see clients in the field who would benefit from using Docbook but I don't recommend it to them because I know what a headache I'd get supporting them. That's because it looks like all the tools available for processing DocBook are immature to some degree. Arguably, this includes even the stylesheets. Don't get me wrong. The current open-source solutions are great. They do Are you kidding? Current open-source DocBook tools are in varying degrees of immaturity. We have the DSSSL toolchain, which is stuck with just a single tool (OpenJade). We have the XSL toolchain, which builds on top of a standard which has yet to become a W3C Recommendation, and currently consists of two FO processors that can't yet produce proper output for a lot of the cases the draft standard defines. the job and there's an army of motivated users, experts developers work on improvements all the time (how many commercial software vendors can say the same for their software?) but in my opinion there is a vast market out there for some sort of GUI tool to aid the content authors. Perhaps, but not one that would give them any sort of WYSIWYG editing capability. To me, that tool would be a mixture of a Plain Text Editor (Emacs, Notepad, whatever), the Delphi/Kylix Code Editor (colour coded tags, code-completion etc.) and XMetal (for their XML support and XML tag Context support). Features like drag drop would help and also a ^^^ What for? I'm not sure what you would drag and drop. Dragging and dropping XML elements into a document is an extremely cumbersome way of doing business, especially when you have the hundreds of elements in DocBook. dedicated Docbook parsing compiling engine that works straight off the shelf and supporting all the usual formats - RTF/DOC, HTML (chunked unchunked), PDF. Among the XML tools I've used the xslide mode under Emacs has come the closest to this; it's FAR, FAR better for editing XSL stylesheets than PSGML will ever be. Unfortunately, it's XSL only, and while I believe Norm once tried to convert it to use the DocBook tagset (dbide), the attempt didn't seem to work. It acted very funny under XEmacs/Linux, nothing at all the way xslide works. At the very least we need a better Emacs major mode for editing DocBook, one comparable in functionality to AucTeX for TeX/LaTeX. I don't think it would be too hard to make such a creature... I think another useful thing that content authors might want will be a way to interactively customize the stylesheets. The first step has already begun with the CGI scripts Norm has on his page that create custom XSL stylesheets, but they don't go far enough in what they allow you to customize. The non-trivial customizations I've had to make to cause my documents to conform to my company's standards for internal documents required that I learn XSLT and XSL Formatting Objects; it took me about a month of studying the standards, looking for tutorials on XSLT and XSL-FO (thanks Norm!), understanding the idiosyncrasies of the various tools for processing formatting objects, and studying the stylesheet code before I could do it (fortunately Norm's coding style is very clear, thanks again!). This sort of editing however, is not something an average joe can do, and I believe a lot of the skill needed is beyond that of even some members of this list. I think this is a bad thing. It should not be necessary to learn XSL (or DSSSL) just to be able to customize the stylesheets more than superficially. (In my case it was ok as part of my job required that I learn these technologies anyway, for projects completely unrelated to DocBook.) Any tools that can allow you to make more than
Re: DOCBOOK-APPS: best tool for docbook?
/ Dennis Grace [EMAIL PROTECTED] was heard to say: | I actually prefer writing and editing in markup, but emacs--even with | psgmlx and the Windows settings--is a drag. I agree that emacs+psgml (or | psgmlx) offers a solution, especially for those who can't or don't want to | work in Windows, but I certainly wouldn't classify the combination as one | of the best tools for DocBook. Which emphasizes the point that the choice of authoring environments depends greatly on the style of documentation being produced and the authoring population. I do think Emacs/PSGML is one of the best tools for editing XML (DocBook or otherwise). In fact, I never use anything else. OTOH, when I was at Arbortext, I routinely annoyed sales and marketing folks by demoing Epic with tags turned on. And stumbling around like I was looking for a black cat in a coal mine when I turned them off. So I'm weird. Sue me. :-) Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | A man can believe a considerable http://www.oasis-open.org/docbook/ | deal of rubbish, and yet go about Chair, DocBook Technical Committee | his daily work in a rational and | cheerful manner.--Norman Douglas To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Re: DOCBOOK: Minutes: DocBook TechnicalCommitteeMeeting: 21 Aug 2001
Daniel Veillard wrote: On Fri, Aug 24, 2001 at 01:35:34PM +0200, Jirka Kosek wrote: There are too many possibilites. As far as merging of DTDs cann't be automated, going DTDs way to support other markup schemes than DocBook in DocBook documents is not long term solution (but may be used if you need MathML or SVG in your document right now). My personal opinion about DocBook future is to let it be single DTD, doing linking and inclusion by DocBook's elements. When there will be more tools Then you're gonna create a legacy problem that you will NEVER be able to get rid of. If you start adding DocBook linking specific construct, this mean in practice you will never get your user base to switch to a more standard solution. I don't want to add new linking elements to DocBook. Linking in DocBook is there from start of 90s, XLink is a new standard, I don't think that every application should switch to XLink from its own linking mechanism. This is true especially for DocBook - DocBook sources are often processed to HTML or FO before viewing. IMHO there is no benefit from using some sort of XLink processor or XML browser with XLink support for DocBook users. Been there, done that, fighted for 2.5 years with the HTML WG at W3C, not fun at all, I don't intend to do the same here, which also mean that if you don't want to use XLink I won't make any mess. XLink has its own place. If I will have a lot of smaller XML document and want to create links between them, I will use XLink. If I will need to create external database of anotations I will use XLink or RDF. I think that XLink is very important especially when we want to display XML directly to end-users. Without XLink and browser with XLink support you weren't be able to do linking. For this purpose XLink is good technology. But in DocBook you often create in-document links. Yes, you can create them with XLink and XPointer. But for me it is easier to write: xred linkend="chapter3"/ than xref href="#chapter3"/ and in that case I'm using as much defaulting as is possible. If I want to blame XLink I would write it as xlink:xref xlink:href="#xpointer(id(chapter3))" xmlns:xlink="..."/ Current method used in DocBook also has advantage of validation of links. They are defined as ID/IDREFs and thus are automatically checked when doing validation. I'm not sure if this is possible with XLink and current tools. XLink might bring some new features when creating inter-document links. But big problem which I see there is not syntax used to create links, but non-existence of some name resolving mechanism. If you have two DocBook document and want to create links between them, these links should look diferrent in HTML and PDF versions of documents. In HTML you link should target HTML file, in PDF second PDF file. Without name resolution mechanism you can effectively create links only between XML documents and do all rendering on-the-fly. Even there is a big progress in performance of XSLT (thanks for libxslt;), on-the-fly approach is not appropriate in all situations. But you go this way you should clearly state that you don't care reusing those standards, that would be more frank. Reuse is good, but I'm not sure (see above) if DocBook will benefit from XLink for now and in the near future. Jirka - Jirka Kosek e-mail: [EMAIL PROTECTED] http://www.kosek.cz To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Cover Art
/ Bob Stayton [EMAIL PROTECTED] was heard to say: | Looking at the titlepage templates in XSL 1.42, it | appears there is no template for mediaobject or graphic. | So you aren't doing anything wrong, it just doesn't | work yet. See http://nwalsh.com/docs/articles/dbdesign/ Almost everyone wants something different on the titlepage. Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | To enjoy yourself and make others http://www.oasis-open.org/docbook/ | enjoy themselves, without harming Chair, DocBook Technical Committee | yourself or any other; that, to my | mind, is the whole of | ethics.--Chamfort To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Best tool for DocBook
/ Dennis Grace [EMAIL PROTECTED] was heard to say: | I apologize if I've insulted anyone's preferred software tool set. Gosh, I hope not. I certainly wasn't insulted. And I apologize if my reply might have lead you to think I was. Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | If someone tells you he is going http://www.oasis-open.org/docbook/ | to make 'a realistic decision', Chair, DocBook Technical Committee | you immediately understand that he | has resolved to do something | bad.--Mary McCarthy To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Catalog dor DocBook and URI for the XSL stylesheets
/ Daniel Veillard [EMAIL PROTECTED] was heard to say:
| I'm integrating XML Catalog into libxml and libxslt, and I would
Woo hoo! Thanks, Daniel!
| So basically I'm wondering:
|- if there is a default XML Catalog template for DocBook XML Dtds
| (preferably based on 4.1.2)
|- if there is a default XML Catalog template for DocBook XSLT stylesheets
The idea of a default catalog is sort of odd to me. The point of a catalog
is to map from public/system identifiers and URIs to local copies of the
resources. If there was a standard local place we could have a standard
catalog. Uh, but we also wouldn't need the catalog :-)
So perhaps I misunderstand?
| I can relatively easilly produce the former, but for the latter
| I don't even know of URIs associated to the DocBook XSLT stylesheets,
| it seems they don't have a standard location in the Web.
They do now, actually,
http://docbook.sourceforge.net/release/xsl/{$VERSION}/...
Where $VERSION=snapshot is a pointer to some working stuff.
Be seeing you,
norm
--
Norman Walsh [EMAIL PROTECTED] | The important thing is not what
http://www.oasis-open.org/docbook/ | the author, or any artist, had in
Chair, DocBook Technical Committee | mind to begin with but at what
| point he decided to stop.--D. W.
| Harding
To subscribe or unsubscribe from this elist use the subscription
manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Re: DOCBOOK: Minutes: DocBook Technical CommitteeMeeting: 21 Aug 2001
/ Daniel Veillard [EMAIL PROTECTED] was heard to say: | Yes, you can use DtD for this if you accept to have a predefined | prefix for the namespace. Using xlink:href in the DTD is IMHO perfectly | acceptable, and will work with those tools. Actually, with proper parameterization, you can have any-single-prefix-you-want:href But you can't have two-different-prefixes:href in the same document. Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | Many ideas grow better when http://www.oasis-open.org/docbook/ | transplanted to another mind than Chair, DocBook Technical Committee | in the one where they sprang | up.--Oliver Wendell Holmes To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Re: DOCBOOK: Minutes: DocBook TechnicalCommitteeMeeting: 21 Aug 2001
/ Jirka Kosek [EMAIL PROTECTED] was heard to say: | But if we stay with DTDs how many variants we should produce? When the TC adopts a linking proposal, we will have DocBook+Linking. Then MathML, SVG, etc. will just be bolt-on modules. It'll all work more-or-less OK. (The caveat being mixed prefixes for the same namespace.) Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | Words--so innocent and powerless http://www.oasis-open.org/docbook/ | they are, as standing in a Chair, DocBook Technical Committee | dictionary, how potent for good | and evil they become, in the hands | of one who knows how to use | them!--Nathaniel Hawthorne To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Re: DOCBOOK: Minutes: DocBookTechnicalCommitteeMeeting: 21 Aug 2001
Norman Walsh wrote: / Jirka Kosek [EMAIL PROTECTED] was heard to say: | But if we stay with DTDs how many variants we should produce? When the TC adopts a linking proposal, we will have DocBook+Linking. Then MathML, SVG, etc. will just be bolt-on modules. It'll all work more-or-less OK. (The caveat being mixed prefixes for the same namespace.) OK. Sounds reasonably. But if I would want use both MathML and SVG with DocBook, I will need to combine these two customizations manually and create new one. Right? - Jirka Kosek e-mail: [EMAIL PROTECTED] http://www.kosek.cz To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Re: DOCBOOK: Minutes: DocBookTechnicalCommitteeMeeting: 21 Aug 2001
/ Jirka Kosek [EMAIL PROTECTED] was heard to say: | OK. Sounds reasonably. But if I would want use both MathML and SVG with | DocBook, I will need to combine these two customizations manually and | create new one. Right? Yes, but it's as simple as turning on two PEs. Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | To what excesses will men not go http://www.oasis-open.org/docbook/ | for the sake of a religion in Chair, DocBook Technical Committee | which they believe so little and | which they practice so | imperfectly!--La Bruy\`ere To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Catalog dor DocBook and URI for the XSL stylesheets
On Fri, Aug 24, 2001 at 09:12:15AM -0400, Norman Walsh wrote:
/ Daniel Veillard [EMAIL PROTECTED] was heard to say:
| I'm integrating XML Catalog into libxml and libxslt, and I would
Woo hoo! Thanks, Daniel!
| So basically I'm wondering:
|- if there is a default XML Catalog template for DocBook XML Dtds
| (preferably based on 4.1.2)
|- if there is a default XML Catalog template for DocBook XSLT stylesheets
The idea of a default catalog is sort of odd to me. The point of a catalog
is to map from public/system identifiers and URIs to local copies of the
resources. If there was a standard local place we could have a standard
catalog. Uh, but we also wouldn't need the catalog :-)
So perhaps I misunderstand?
that's why I said template :-), basically if you take the approach
that the local tree is very much like a mirror of the web hosting the
canonical system identifiers, then you have a single invariant which
is the root of that tree in the local filesystem.
And since catalogs uses URI-References, making them relative solves
the problem :-) ...
If you look at
ftp://xmlsoft.org/test/dbk412catalog.tar.gz
the usr/share/docbook/catalog gives an idea of the kind of thing I'm
looking at, very similar to the SGML catalog in the distribution,
and with rewriteSystem and rewriteURI maintenance can be really minimal.
Now how this catalog is actually consulted is just a matter of agreeing
on a common root like /etc/xml/catalog on Unices (or killing anybody who
disagree and refuses to use an environment variable), and selecting wisely
the set of delegatePublic delegateSystem and delegateURI for that catalog
taht should be placed in one of the super-catalogs.
So there is just 2 things really needed:
- a generic catalog like the SGML one
- the set of delegate to use for DocBook-x.y.z
| I can relatively easilly produce the former, but for the latter
| I don't even know of URIs associated to the DocBook XSLT stylesheets,
| it seems they don't have a standard location in the Web.
They do now, actually,
http://docbook.sourceforge.net/release/xsl/{$VERSION}/...
Where $VERSION=snapshot is a pointer to some working stuff.
Fantastic, do you bless using them in stylesheet PIs , xsl:include and
xsl:import constructs ?
Daniel
--
Daniel Veillard | Red Hat Network http://redhat.com/products/network/
[EMAIL PROTECTED] | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
To subscribe or unsubscribe from this elist use the subscription
manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Cover Art
From: Norman Walsh [EMAIL PROTECTED] / Bob Stayton [EMAIL PROTECTED] was heard to say: | Looking at the titlepage templates in XSL 1.42, it | appears there is no template for mediaobject or graphic. | So you aren't doing anything wrong, it just doesn't | work yet. See http://nwalsh.com/docs/articles/dbdesign/ Almost everyone wants something different on the titlepage. I presume you are pointing to the section Self-Customizing Stylesheets in this document, which describes building a titlepage stylesheet from an XML specification file using a special XSL transformation. But the paper describes it at the architectural level, not a practical level. In the distribution, the template/README file says there is rudimentary support for this feature. Is the implementation incomplete, or is it complete but just in need of some documentation describing how to use it? If it is the latter, I could take a stab at it. If it is the former, I'll leave it to you. 8^) bobs Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 Caldera International, Inc. fax: (831) 429-1887 email: [EMAIL PROTECTED] . To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Re: DOCBOOK: Minutes: DocBook Technical CommitteeMeeting: 21 Aug 2001
At 05:54 24/08/2001 -0400, Daniel Veillard wrote: I don't fully understand the problem from an editor point of view, they just have names with ':' in them, they should not have to worry about this, those are of course perfectly acceptable XML Names per the XML spec. Do you mean that XMetaL, Epic and Emacs+PSGML don't support names with ':' ? ...). It is not easy to merge DTDs. Agreed but it's a 1 step effort, once done people should not have to worry about what spec the given element or attribute came from. On the other hand the semantic has already been defined etc, and that's supposed to be better for users. Sooner or later docbook must move to a namespaced version, possibly with its own schema. I'm led to believe Norm has been having nightmares over it for some time ;-) Full namespace support is a little different from db:title type of DTD naming. I'm more than ready for it except that I can't find a usable editor that is namespace+schema aware:-) Regards DaveP To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Catalog dor DocBook and URI for the XSL stylesheets
At 09:12 24/08/2001 -0400, Norman Walsh wrote: The idea of a default catalog is sort of odd to me. The point of a catalog is to map from public/system identifiers and URIs to local copies of the resources. If there was a standard local place we could have a standard catalog. Uh, but we also wouldn't need the catalog :-) How about a 'relative' local place? No idea how, but if I could tell the catalog manager that my 'home' was /user/local/docbook, for instance, could the manager work from that? something like xml:base for catalogs? Then all the stylesheet versions could be linked relative to that, the sgml and xml DTD's and so on. Doable? That would probably be as close to a 'default' catalog as is reasonable without raising hackles. Regards DaveP To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Catalog dor DocBook and URI for the XSL stylesheets
On Fri, 24 Aug 2001, Norman Walsh wrote:
They do now, actually,
http://docbook.sourceforge.net/release/xsl/{$VERSION}/...
Please consider using another site. Sourceforge uses a strange
port-redirection scheme that doesn't work well with corporate firewalls.
For example, I'm only able to see Web pages on ports 80 and 8080 at work.
I doubt I'm the only person who has problems with SourceForge...
=== Kevin Conder, [EMAIL PROTECTED]
To subscribe or unsubscribe from this elist use the subscription
manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Catalog dor DocBook and URI for the XSL stylesheets
On Fri, Aug 24, 2001 at 06:16:49PM +0100, Dave Pawson wrote: How about a 'relative' local place? It's already the case :-). XML Catalog points to entities using URI-References, moreover it does support xml:base. http://www.oasis-open.org/committees/entity/spec-2001-08-06.html#s.terminology Daniel -- Daniel Veillard | Red Hat Network http://redhat.com/products/network/ [EMAIL PROTECTED] | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Catalog dor DocBook and URI for the XSL stylesheets
At 11:26 24/08/2001 -0500, you wrote:
On Fri, 24 Aug 2001, Norman Walsh wrote:
They do now, actually,
http://docbook.sourceforge.net/release/xsl/{$VERSION}/...
Since they are 'yours' Norm, why not have an nwalsh.com url?
Regards DaveP
To subscribe or unsubscribe from this elist use the subscription
manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Catalog dor DocBook and URI for the XSL stylesheets
/ Dave Pawson [EMAIL PROTECTED] was heard to say:
| At 11:26 24/08/2001 -0500, you wrote:
| On Fri, 24 Aug 2001, Norman Walsh wrote:
|
| They do now, actually,
|
| http://docbook.sourceforge.net/release/xsl/{$VERSION}/...
|
| Since they are 'yours' Norm, why not have an nwalsh.com url?
Because they're ours now. Adam Di Carlo, Jirka Kosek, Jorge Godoy,
Leonard Muellner, Mark Johnson, Michael Smith, Nik Clayton, and Robert
Stayton are all contributing.
Be seeing you,
norm
--
Norman Walsh [EMAIL PROTECTED] | Pleasure is seldom found where it
http://www.oasis-open.org/docbook/ | is sought; our brightest blazes of
Chair, DocBook Technical Committee | gladness are commonly kindled by
| unexpected sparks.--Dr. Johnson
To subscribe or unsubscribe from this elist use the subscription
manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Re: DOCBOOK: Minutes: DocBook Technical CommitteeMeeting: 21 Aug 2001
/ Togan Muftuoglu [EMAIL PROTECTED] was heard to say: | Excuse me but I thought this whole thread belongs to DOCBOOK list, as it | started with DOCBOOK Minutes send by Norm , not to DOCBOOK-APPS. | | Sorry if I misunderstand the lists That's a good point, I'm not sure how it wandered over here. Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | When told of a man who had http://www.oasis-open.org/docbook/ | acquired great wealth, a sage Chair, DocBook Technical Committee | replied, 'Has he also acquired the | days in which to spend | it?'--Solomon Ibn Gabirol To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Catalog dor DocBook and URI for the XSL stylesheets
At 14:57 24/08/2001 -0400, Norman Walsh wrote: / Dave Pawson [EMAIL PROTECTED] was heard to say: | Since they are 'yours' Norm, why not have an nwalsh.com url? Because they're ours now. Adam Di Carlo, Jirka Kosek, Jorge Godoy, Leonard Muellner, Mark Johnson, Michael Smith, Nik Clayton, and Robert Stayton are all contributing. Hence the quotes Norm. No offence meant gentlemen. Regards DaveP To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
DOCBOOK-APPS: Xalan Big Files Chunking...
Okay, I searched the archives and found stuff about Xalan and Chunking, but nothing that looked like this. So... I'm using: * xalan-j_2_2_D9 * docbook-xsl-1.42 * docbkx412 I have some huge XML files that I'm processing (3mb) and discovered that Xalan tends to blow up if I process the entire file at once. So I broke it up into three smaller files, that I can successfully process with the autoidx.xsl to produce three large HTML files. I would rather Chunk it, so I tried substituting the chunk.xsl file for my autoidx.xsl on the command line, and now it just, uh, twiddles it's thumbs? Xalan fires up and sucks up CPU memory, but never exits (I waited an hour, when I processed w/ autoidx it took about one minute) and doesn't produce any output files... CMDLINE: java org.apache.xalan.xslt.Process -in file.xml -xsl xsl\html\chunk.xsl -out html\file.htm -PARAM use.extensions 1 Any help / suggestions would be greatly appreciated... -- Mike To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
Re: DOCBOOK-APPS: Trying to find a DocBook solution that simply works
At 04:17 PM 8/22/01 -0700, Tom Epperly wrote: I am part of a project where were are able to start writing perhaps 200 pages of documentation. We were interested in using DocBook because it seemed like an up and coming standard that could deliver the document in several formats. We were considering using the DocBook XML definition. I use Jade and the DSSSL Modular style sheets. Works pretty well for HTML and RTF, although most of the documents I write are shorter than what you describe. I don't routinely produce PDF from SGML; I've made a couple of desultory attempts to get PDFJadeTeX running, and not had much success. But PDF from RTF via Adobe Exchange works OK if you're not too concerned about making it rich (hyperlinks etc). Mark B. Wroth [EMAIL PROTECTED] To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
DOCBOOK-APPS: DSSSL Tutorials
Hi, I've managed to find a couple of DSSSL tutorials, whose links should be added to the FAQ. One is by Daniel Germán at http://csgrs6k1.uwaterloo.ca/~dmg/dsssl/tutorial/tutorial.html and the other is by Paul Prescod, a copy of which is at http://wwwai.cs.uni-magdeburg.de/lehre/ws-00-01/DokVer/DSSSL/dsssl-tutorial.html (the original location, referred to by Daniel Germán, has gone). Regards, Dave To subscribe or unsubscribe from this elist use the subscription manager: http://lists.oasis-open.org/ob/adm.pl
