DOCBOOK-APPS: Jade MIF builds
Toolchain: SGML DocBook 3.1/Jade/DSSSL At the moment, we create our printed output by building RTF files as per the above toolchain, and formatting in MSWord. Unfortunately, MSWord misbehaves very badly with very long (200 pg) documents, refusing to recognise images. I've found that StarOffice is somewhat better here: images get recognised, but a whole bunch of other problems are introduced. Oversized images are scaled non-uniformly, tables of contents are trashed, and margins are screwy. Pardon my high-falutin' tech talk. The problems that StarOffice introduces can all be fixed, but the end result is a very labour-intensive process. So we're looking for alternatives. One of our sysadmins is currently investigating PDF builds via jadetex, but he's finding that tables are giving him no end of grief. Another potential route to long-document nirvana is to build to MIF, and put the finishing touches on in Framemaker. (Note that this approach sidesteps the SGML side of FM, essentially using it as a souped-up word processor.) But we don't use FM at the moment, so I would like to know if the list-members think that this approach is likely to bear fruit. Any comments? Thanks, Andrew Westcombe Documentation Manager Gaming and Entertainment Technology (GET) www.getsystems.com ph. +61-2-9419-2000 email: [EMAIL PROTECTED] Philosophy aims at the logical clarification of thoughts. Philosophy is not a body of doctrine but an activity. A philosophical work consists essentially of elucidations. Philosophy does not result in philosophical propositions', but rather in the clarification of propositions. Without philosophy thoughts are, as it were, cloudy and indistinct: its task is to make them clear and to give them sharp boundaries. Ludwig Wittgenstein --Tractatus Logico-Philosophicus
DOCBOOK-APPS: prohibit to chunk
Hi Can somebody help me about, how can I prohibit to chunk some sections of my doc. I use xsl stylesheet 1.50EXP Thanks Szazo
DOCBOOK-APPS: Removing the box for notes for PDF
How can I remove the box in the notes section? Ever better, is there a way to move the note to be in the margin area? I am using DSSSL. Thanks in advance. Christopher Graham [EMAIL PROTECTED] PGP Fingerprint: F765 CCB5 B9CF 1285 7E3E 8CB0 0B1B 8454 9D66 D411
RE: DOCBOOK-APPS: prohibit to chunk
Not sure if this is what you need, but with parameters, you can control the depth of chunking: http://docbook.sourceforge.net/release/xsl/current/doc/html/chunk.sectio n.depth.html and whether the first section chunks: http://docbook.sourceforge.net/release/xsl/current/doc/html/chunk.first. sections.html David -Original Message- From: Szarvas Zoltn [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 02, 2002 8:12 AM To: DocBook-Apps Subject: DOCBOOK-APPS: prohibit to chunk Hi Can somebody help me about, how can I prohibit to chunk some sections of my doc. I use xsl stylesheet 1.50EXP Thanks Szazo
DOCBOOK-APPS: Keeping entities in a transformation
Im working an an XSL script to clean up my DocBook XML. Im running into problems because all of the entities are declared in a top-level driver file, and the content resides in about 3,000 external entities, which do not include DOCTYPE declarations. I need to maintain our current file structure and naming scheme (which unfortunately does not correspond directly to the XML.). How can I get the XSL process to ignore undeclared entities and copy the reference through to the result tree? Jeff Beal Ansys, Inc. (724)514-3150 [EMAIL PROTECTED]
DOCBOOK-APPS: FOP images formats
I used xalan, FOP (both from apache) and the docbook stylesheet to turn my docbook XML into pdf. This seemed to work fine. I really want to have images in my final pdf which are composed of a photo with text callouts. If possible I would like the callouts and text to be scalable objects rather than bitmappy. In the past I have imported photos into Ms Word docs, used Word to put labels on them and then used Acrobat to make the pdfs. The resulting images are nice and clear and the labels scale up nicely when magnified. I can search on the text of the callouts etc. I notice that docbook supports wmf format for imagedata, which i think would do the trick. However, I wonder, is it possible for FOP to render these kind of images into the final pdf? When I try it, the images don't appear. I think maybe FOP can only do bitmap style images (like jpeg and gif). Has anyone else tried to do what I am trying to do? Any result? ta V
RE: DOCBOOK-APPS: Keeping entities in a transformation
I've always wanted to know if there's a right way to do that myself. I've resorted to using sed to obfuscate the entities before processing, then unobfuscating them afterwards. For each file, sed "s/\(\w*\.*\w*\);/%%\1%%/g" $file $file.tmp1.xml the run the xsl on the file, then sed "s/%%\(\w*\.*\w*\)%%/\\1;/g" $file.tmp2.xml $file It seems like such a hack--there must be a better way. David -Original Message-From: Jeff Beal [mailto:[EMAIL PROTECTED]]Sent: Thursday, May 02, 2002 10:48 AMTo: DocBook Mailing List (E-mail)Subject: DOCBOOK-APPS: Keeping entities in a transformation Im working an an XSL script to clean up my DocBook XML. Im running into problems because all of the entities are declared in a top-level driver file, and the content resides in about 3,000 external entities, which do not include DOCTYPE declarations. I need to maintain our current file structure and naming scheme (which unfortunately does not correspond directly to the XML.). How can I get the XSL process to ignore undeclared entities and copy the reference through to the result tree? Jeff Beal Ansys, Inc. (724)514-3150 [EMAIL PROTECTED]
Re: DOCBOOK-APPS: Keeping entities in a transformation
Hi Jeff, Jeff Beal wrote: I?m working an an XSL script to clean up my DocBook XML. I?m running into problems because all of the entities are declared in a top-level driver file, and the content resides in about 3,000 external entities, which do not include DOCTYPE declarations. I need to maintain our current file structure and naming scheme (which unfortunately does not correspond directly to the XML.). How can I get the XSL process to ?ignore? undeclared entities and copy the reference through to the result tree? The easier is to preprocess your files simply replacing all by amp; Camille.
Re: DOCBOOK-APPS: Keeping entities in a transformation
At 11:47 02/05/2002 -0400, Jeff Beal wrote: I m working an an XSL script to clean up my DocBook XML. I m running into problems because all of the entities are declared in a top-level driver file, and the content resides in about 3,000 external entities, which do not include DOCTYPE declarations. I need to maintain our current file structure and naming scheme (which unfortunately does not correspond directly to the XML.). How can I get the XSL process to ignore undeclared entities and copy the reference through to the result tree? AFAIK you can't Jeff. By the time the file is in the hands of the xslt engine, its been through the parser and the entities expanded. DC solution is to preprocess ; to Y;, i.e. get rid of the sensitive bit and then re-insert it later. I'm told *nix has some tools that do this :-) I use msub on my lowly win2k machine (but it does the job :-) HTH DaveP
RE: DOCBOOK-APPS: Keeping entities in a transformation
At 11:16 02/05/2002 -0500, David Cramer wrote: urn:schemas-microsoft-com:office:office xmlns:w = urn:schemas-microsoft-com:office:word I've always wanted to know if there's a right way to do that myself. I've resorted to using sed to obfuscate the entities before processing, then unobfuscating them afterwards. For each file, sed s/\(\w*\.*\w*\);/%%\1%%/g $file $file.tmp1.xml the run the xsl on the file, then sed s/%%\(\w*\.*\w*\)%%/\\1;/g $file.tmp2.xml $file It seems like such a hack--there must be a better way. See what I mean Jeff grin/ I think David Cramer (the DC I was talking about was David Carlisle) has a bad case of line noise, but there is a fair chance if you mumble Abracadabra over your pc whilst running this script it may just well work! Regards DaveP (Highly amused)
RE: DOCBOOK-APPS: FOP images formats
The only vector graphics format supported by FOP is SVG. I don't have any specific recommendations for you, but you may find the following somewhat helpful (with an emphasis on Visio-produced graphics): http://sources.redhat.com/ml/docbook-apps/2002-q2/msg00082.html HTH. -Original Message- From: O'Donnell, Vincent [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 02, 2002 9:53 AM To: '[EMAIL PROTECTED]' Subject: DOCBOOK-APPS: FOP images formats I used xalan, FOP (both from apache) and the docbook stylesheet to turn my docbook XML into pdf. This seemed to work fine. I really want to have images in my final pdf which are composed of a photo with text callouts. If possible I would like the callouts and text to be scalable objects rather than bitmappy. In the past I have imported photos into Ms Word docs, used Word to put labels on them and then used Acrobat to make the pdfs. The resulting images are nice and clear and the labels scale up nicely when magnified. I can search on the text of the callouts etc. I notice that docbook supports wmf format for imagedata, which i think would do the trick. However, I wonder, is it possible for FOP to render these kind of images into the final pdf? When I try it, the images don't appear. I think maybe FOP can only do bitmap style images (like jpeg and gif). Has anyone else tried to do what I am trying to do? Any result? ta V
FW: DOCBOOK-APPS: FOP images formats
Oops - hit 'Reply' Jeff Beal Ansys, Inc. (724)514-3150 [EMAIL PROTECTED] -Original Message- From: Jeff Beal Sent: Thursday, May 02, 2002 1:16 PM To: 'O'Donnell, Vincent' Subject: RE: DOCBOOK-APPS: FOP images formats The only vector graphic format FOP supports is SVG. Mayura Draw is a cheap drawing program ($25) that has good SVG support (and you can copy-n-paste from Word drawing into Mayura with a reasonable amount of success). (see www.mayura.com). For the record, we're using neither SVG graphics nor FOP and I've never tried this myself. Jeff Beal Ansys, Inc. (724)514-3150 [EMAIL PROTECTED] -Original Message- From: O'Donnell, Vincent [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 02, 2002 11:53 AM To: '[EMAIL PROTECTED]' Subject: DOCBOOK-APPS: FOP images formats I used xalan, FOP (both from apache) and the docbook stylesheet to turn my docbook XML into pdf. This seemed to work fine. I really want to have images in my final pdf which are composed of a photo with text callouts. If possible I would like the callouts and text to be scalable objects rather than bitmappy. In the past I have imported photos into Ms Word docs, used Word to put labels on them and then used Acrobat to make the pdfs. The resulting images are nice and clear and the labels scale up nicely when magnified. I can search on the text of the callouts etc. I notice that docbook supports wmf format for imagedata, which i think would do the trick. However, I wonder, is it possible for FOP to render these kind of images into the final pdf? When I try it, the images don't appear. I think maybe FOP can only do bitmap style images (like jpeg and gif). Has anyone else tried to do what I am trying to do? Any result? ta V
DOCBOOK-APPS: ant, resolver and catalogs
I've posted a new page, describing ant and . I'd appreciate comments/improvements from 'seasoned' resolver class users if you have the time please. http://www.dpawson.co.uk/docbook/ant.html TIA, DaveP
DOCBOOK-APPS: RE: Need TOC Example Best Method for Rendering html/pdf
Title: RE: Need TOC Example Best Method for Rendering html/pdf Docbook html and fo XSL stylesheets with fop is the methodology I'm using. Below is bare-bones example out of many scenarios I've tried. HTML as well as PDF comes up with all expected content except for the toc. I thought that the toc was automatically generated and I have tried with and without the toc tags. I sure wish I could find a simple example that will render a toc to both html and pdf. Must be something simple... ?xml version='1.0' encoding='UTF-8'? !DOCTYPE book PUBLIC -//OASIS//DTD DocBook XML V4.1.2//EN file:/C:/vendor/docbook/docbookx.dtd book bookinfo titleBook Example/title pubdateApril 5, 2002/pubdatecopyrightyear2002/year/copyright /bookinfo toc tocchaptocentryChapter 1/tocentry/tocchap tocchaptocentryChapter 2/tocentry/tocchap /toc chaptertitleChapter 1/titleparaParagraph /para/chapter chaptertitleChapter2/titleparaParagraph/para/chapter /book I've also tried a variation of the following from the book with no luck: toc tocfront pagenum=iPreface/tocfront tocpart tocentryPart I/tocentry tocchap tocentry pagenum=1Getting Started with SGML/XML/tocentry toclevel1 tocentry pagenum=1HTML and SGML vs. XML/tocentry /toclevel1 toclevel1 tocentry pagenum=3How Does DocBook Fit In?/tocentry toclevel2 tocentry pagenum=3A Short DocBook History/tocentry /toclevel2 /toclevel1 !-- ... -- /tocchap /tocpart !-- ... -- tocback pagenum=305Bibliography/tocback /toc -Original Message- From: Norman Walsh [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 01, 2002 8:34 AM To: STEWARD, Curtis (Jamestown) Cc: '[EMAIL PROTECTED]'@mercury.trw.com Subject: Re: Need TOC Example Best Method for Rendering html/pdf [ Follow-ups to docbook-apps, please ] / STEWARD, Curtis (Jamestown) [EMAIL PROTECTED] was heard to say: | I've struggled way to long to have docbook automatically generate a simple | toc. I must be missing something obvious here, does anyone have a simple | example of a automatically generated toc? I understand this should work | with | the provided docbook stylesheets, I've tried stylesheets with and without | %generate-book-toc% with no luck and wish to render html and pdf. %generate-book-toc% is the name of the DSSSL parameter, but | I'm using: | | Docbook XML 4.12 | Docbook Stylesheets 1.50 These are the XSL stylesheets. | Xerces 2.0.1 | Fop 0.20.3 | Xalan 2.3.1 What is your input document and what results do you get? What are you producing, HTML or print? How? Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | I'm NOT in denial! http://www.oasis-open.org/docbook/ | Chair, DocBook Technical Committee |
Re: DOCBOOK-APPS: Notes on graphics and HTML
At 12:41 2002 05 01 -0700, Norman Walsh wrote:
I spent some time today working on new code to map DocBook V4.2 image
semantics (a superset of previous semantics) to HTML. A number of
compromises were required along the way.
I probably won't be able to post the new code until I get back home,
but here are the notes I wrote as I went. Comments, etc., most welcome.
I find use of the terms like width are ambiguous. I've gotten into
writing things like docbook::graphic.width and html::img.width.
!-- The HTML img element only supports the notion of content-area
scaling; it doesn't support the distinction between a content-area and
a viewport-area, so we have to make some compromises.
Pretty much true, but note that html::img.{width,height}=xx% implies
that the graphic should be scaled to xx% of the available width
(aka of the viewport-area).
One thing I'm confused about is whether docbook allows values of the
form xx% for docbook::graphics.{width,depth} and
docbook::graphics.content-{width,depth} and, if so, what they all mean?
Unless I hear otherwise, I'll assume that docbook::graphics.{width,depth}
values can only be lengths with units being one of the following and
nothing else: cm, mm, in, pt, pc, px.
1. If only the content-area is specified, everything is fine.
(If you ask for a three inch image, that's what you'll get.)
Yep (as long as the XSL-HTML stylesheets convert 3in to pixels, since
the value of an html::img.{width,height} attribute has to be a unitless
number of pixels).
2. If only the viewport-area is provided:
- If scalefit=1, treat it as both the content-area and
the viewport-area. (If you ask for an image in a five inch
area scaled to fit, we'll make the image five inches to fill
that area.)
- If scalefit=0, ignore it.
Note: this is not quite the right semantic and has the additional
problem that it can result in anamorphic scaling,
Why should this have to result in anamorphic scaling? Can't we define the
semantic so that anamorphic scaling doesn't occur?
which scalefit
should never cause.
True.
3. If both the content-area and the viewport-area is specified
on a graphic element, ignore the viewport-area.
(If you ask for a three inch image in a five inch area, we'll assume
it's better to give you a three inch image in an unspecified area
than a five inch image in a five inch area.
This is reasonable. I assume one could wrap the 3in image in a 5in block,
but I suspect what you suggest above is more likely to make the user happy.
Relative units also cause problems. As a general rule, the stylesheets
are operating too early and too loosely coupled with the rendering engine
to know things like the current font size or the actual dimensions of
an image. Therefore:
1. We use a fixed size for pixels, $pixels.per.inch
2. We use a fixed size for ems, $points.per.em
Or just say that it is an error for docbook::graphics.{width,depth} to be
assigned a value whose unit is em.
Percentages are problematic. In the following discussion, we speak
of width and contentwidth, but the same issues apply to depth and
contentdepth
1. A width of 50% means half of the available space for the image.
That's fine. But note that in HTML, this is a dynamic property and
the image size will vary if the browser window is resized.
2. A contentwidth of 50% means half of the actual image width. But
the stylesheets have no way to assess the image's actual size. Treating
this as a width of 50% is one possibility, but it produces behavior
(dynamic scaling) that seems entirely out of character with the
meaning.
Worse, mapping docbook::graphics.width=200% to html::img.width=200%
guarantees that the graphic will be twice as large as the window which
is almost never what the user wants to see.
Instead, the stylesheets define a $nominal.image.width.in.points
and convert percentages to actual values based on that nominal size.
While I can't see a good solution, I also can't imagine this working too well
either. What kind of value do you choose for $nominal.image.width.in.points
that works more often than it doesn't?
Scale can be problematic. Scale applies to the contentwidth, so
a scale of 50 when a contentwidth is not specified is analagous to a
width of 50%.
This is confused/confusing. You are talking about contentwidth and width
in the same sentence without making it clear if you are talking about
docbook::graphic.content-width or docbook::graphic.width or html::img.width.
I think you're talking about docbook::graphics.scale=50. I think you're
saying that this is equivalent to docbook::graphics.content-width=50%. (It
sure isn't equivalent to
DOCBOOK-APPS: FOP images formats
I used xalan, FOP (both from apache) and the docbook stylesheet to turn my docbook XML into pdf. This seemed to work fine. I really want to have images in my final pdf which are composed of a photo with text callouts. If possible I would like the callouts and text to be scalable objects rather than bitmappy. In the past I have imported photos into Ms Word docs, used Word to put labels on them and then used Acrobat to make the pdfs. The resulting images are nice and clear and the labels scale up nicely when magnified. I can search on the text of the callouts etc. I notice that docbook supports wmf format for imagedata, which i think would do the trick. However, I wonder, is it possible for FOP to render these kind of images into the final pdf? When I try it, the images don't appear. I think maybe FOP can only do bitmap style images (like jpeg and gif). Has anyone else tried to do what I am trying to do? Any result? ta V
DOCBOOK-APPS: D'oh!
Answered my own question before I could post. Whenever I ran jade on my DocBook XML document it would hit the net to retrieve my DTD. I couldn't work with it with an unconnected laptop in a cafe, so I hardwired in the pathname of the DTD as the system identifier. This broke when I moved from my Slackware laptop to my Debian server. Can you see what was wrong? Here is my original DOCTYPE declaration: !DOCTYPE book PUBLIC -//OASIS/DTD DocBook XML V4.1.2//EN http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd; [ Later I had the path where http... goes. This broke when I switched linux distros. Here's the correct one: !DOCTYPE book PUBLIC -//OASIS//DTD DocBook XML V4.1.2//EN http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd; [ See the difference? and to tell that it really was correct, it still worked when I deleted the system identifier entirely. I was really confused because I checked out all the catalog files and everything looked correct, but it wasn't using the PUBLIC identifier to find my DTD. Yers, Mike -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ [EMAIL PROTECTED] Subscribe to the GoingWare Newsletter at http://www.goingware.com/newsletter/ Tilting at Windmills for a Better Tomorrow.
DOCBOOK-APPS: Newbie troubles with Docbook/XML + XHTML
moz xhtml 286 xsltproc --version Using libxml 20413, libxslt 10010 and libexslt 703 xsl-stylesheets-1.48-3 installed at /usr/share/sgml/docbook xsltproc http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl in.xml I get a couple of problems : 1) dt xmlns=http://www.w3.org/1999/xhtml; All tags have xmlns specified. validator.w3.org does not like this at all. Where does this come from and how can I fix it ? 2) using chunk.xsl instead of docbook.xsl, I don't get doctype declarations in the XHTML files. How can I fix it ? 3) using chunk.xsl, the file names are not very readable. This seems to be because the chunk.xsl at docbook.sf.net does not specify this option : xsl:param name=use.id.as.filename select=1/ Is there any reason this is not on by default ? I do not know XSLT at all, and would like to avoid using hand-crafted .xsl files I would have to maintain (but it will do as a solution). Ideally the released files at docbook.sf.net would not have any of the three problems above (I am sure I am missing some good reason why these problems exist for me). As it is, the machine-generated pages are the only part of my website which don't validate ... can somebody help ? thanks john -- ken kesey wrote 'one flew over the center of the cuckolded lizard man, who strayed from his mistakes when he is a madeup word.' - Mega HAL
RE: DOCBOOK-APPS: Newbie troubles with Docbook/XML + XHTML
John, I don't know about #1--doesn't seem like the xmlns should be a problem, but you can satisfy #2 and #3 with a simple customization layer. In order to get the output you want, you pretty much have to have an xsl where you change some parameters, but it's easy to maintain--just change the path in the xsl:import statement when newer xsls are released. Until the middle digit changes, there will be no changes in the interface (i.e. no parameter names will change or behave in a different way). It's not so much writing your own xsl, as maintiaining a list of preferences. As for use.id.as.filename being off by default--don't know if it's the reason, but problem mentioned in the Red Hat Network Alert below is something to consider. Good luck, David cut here= ?xml version=1.0 encoding=US-ASCII? xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:doc=http://nwalsh.com/xsl/documentation/1.0; version=1.0 !-- this pulls in the docbook.xsls. Note that import statements must come before anything else -- xsl:import href=path/to/xhtml/chunk.xsl/ !-- this will give you the doctype on your chunks -- xsl:output method=xml encoding=ISO-8859-1 indent=no doctype-public=-//W3C//DTD XHTML 1.0 Transitional//EN doctype-system=http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; / !-- Here you can set the filename parameter, and any others you like -- xsl:param name=use.id.as.filename select=1/ /xsl:stylesheet ==cut here= Date: Wed, 1 May 2002 17:33:30 -0500 From: Red Hat Network Alert [EMAIL PROTECTED] | Block Address | Add to Address Book Subject: RHN Errata Alert: Insecure DocBook stylesheet option To: dwcramer [EMAIL PROTECTED] Red Hat Network has determined that the following advisory is applicable to one or more of the systems you have registered: Complete information about this errata can be found at the following location: https://rhn.redhat.com/network/errata/errata_details.pxt?eid=1065 Security Advisory - RHSA-2002:062-08 -- Summary: Insecure DocBook stylesheet option DocBook is a document markup language that can be transformed into other formats using a stylesheet. The default stylesheet provided with Red Hat Linux has an insecure option enabled. Description: The default stylesheet used when converting a DocBook document to multiple HTML files allows an untrusted document to write files outside of the current directory. This is because element identifiers (specified in the document) are used to form the names of the output files. If an untrusted document uses a full pathname as an identifier, it can cause that file to be written to -- as long as the user performing the conversion has write access. Updated docbook-utils packages are available that disable this feature and enable filenames to be generated based on the type of the element rather than its identifier. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0169 to this issue. snip -Original Message- From: John Levon [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 02, 2002 9:18 PM To: [EMAIL PROTECTED] Subject: DOCBOOK-APPS: Newbie troubles with Docbook/XML + XHTML moz xhtml 286 xsltproc --version Using libxml 20413, libxslt 10010 and libexslt 703 xsl-stylesheets-1.48-3 installed at /usr/share/sgml/docbook xsltproc http://docbook.sourceforge.net/release/xsl/current/xhtml/docbo ok.xsl in.xml I get a couple of problems : 1) dt xmlns=http://www.w3.org/1999/xhtml; All tags have xmlns specified. validator.w3.org does not like this at all. Where does this come from and how can I fix it ? 2) using chunk.xsl instead of docbook.xsl, I don't get doctype declarations in the XHTML files. How can I fix it ? 3) using chunk.xsl, the file names are not very readable. This seems to be because the chunk.xsl at docbook.sf.net does not specify this option : xsl:param name=use.id.as.filename select=1/ Is there any reason this is not on by default ? I do not know XSLT at all, and would like to avoid using hand-crafted .xsl files I would have to maintain (but it will do as a solution). Ideally the released files at docbook.sf.net would not have any of the three problems above (I am sure I am missing some good reason why these problems exist for me). As it is, the machine-generated pages are the only part of my website which don't validate ... can somebody help ?
Re: DOCBOOK-APPS: Newbie troubles with Docbook/XML + XHTML
On Thu, May 02, 2002 at 10:37:42PM -0500, David Cramer wrote: I don't know about #1--doesn't seem like the xmlns should be a problem, Well for one it bloats the filesize. Is validator.w3.org incorrect in rejecting it as valid XHTML ? Note that I /don't/ get the xmlns on every tag with chunk.xsl (only on div, html etc.) (i.e. no parameter names will change or behave in a different way). It's not so much writing your own xsl, as maintiaining a list of preferences. Mmm, true. As for use.id.as.filename being off by default--don't know if it's the reason, but problem mentioned in the Red Hat Network Alert below is something to consider. Well I guess a proper fix for that would just somehow make sure the path is safe (not exactly a new problem ;) !-- this will give you the doctype on your chunks -- This doesn't seem to make any difference. My entire xsl : ?xml version='1.0'? xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:doc=http://nwalsh.com/xsl/documentation/1.0; version=1.0 xsl:import href=/usr/share/sgml/docbook/xsl-stylesheets/xhtml/chunk.xsl/ xsl:param name=use.id.as.filename select=1/ xsl:output method=xml encoding=ISO-8859-1 indent=no doctype-public=-//W3C//DTD XHTML 1.0 Transitional//EN doctype-system=http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; / /xsl:stylesheet Another thing: is there a simple way to get human-readable XHTML output ? regards john -- ken kesey wrote 'one flew over the center of the cuckolded lizard man, who strayed from his mistakes when he is a madeup word.' - Mega HAL
