Re: [docbook-apps] Custom css with webhelp

[Denis Bradford]

If you have a custom xsl file, you can add a webhelp.head.content template for 
this purpose. For example: 






This template adds your content at the end of the html  element,
in this case a link to your CSS file: 

   ...
   
   
 

 Since it comes after the stock links, it overrides their default CSS rules.

hth,
Denis  

On 04/16/2013 09:04 AM, David Goss wrote:


> I want to use a custom CSS file with webhelp output. I'm using Oxygen. I set 
> the html.stylesheet parameter and pointed it to a custom CSS file.
> 
> In my output, however, the CSS is not linked. I only see one  for css 
> in the output, which is for tocWDiv.css.
> 
> Does the html.stylesheet parameter not work the way I'm expecting it to with 
> webhelp?
> 
> ---
> David Goss, M.A.
> Technical Writer, Laboratory Division
> Frontier Science & Technology Research Foundation
> 4033 Maple Road
> Amherst, NY 14226
> (716) 834-0900 x7218
> 
> 
> -
> To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
> 
> 


-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

[docbook-apps] In webhelp 1.78.1, local links don't work

[Denis Bradford]

I've been unable to implement 1.78.1 webhelp because fragment hrefs 
(generated from local links and olinks) don't seem to work. For example, 
clicking this link does nothing when the target is in the same chunk:


Test local link

Local links like this do work in my 1.77.1 implementation.

To reproduce, add a target and a link to it in the same chunk. For 
example, I added this to the Intro chapter of the stock ns 1.78.1 
webhelp/readme.xml:


Test local link
...


Then run ant webhelp to build the readme: it generates the expected link 
but clicking the link does nothing.


When I do the same test in in 1.77.1, the link works. I tested the 
non-ns stylesheets with the same results.


Interestingly, if you paste the same link into another chunk (so it's 
not local to the same output file), it works. To diagnose, I replaced 
the whole head element in the generated 1.78.1 HTML file with the one in 
the 1.77.1 file.


That fixed the link, so I suspect a problem in the referenced JS files 
(jquery, etc). That's as far as I've taken it -- not sure how to debug 
those suckers.



-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

[docbook-apps] webhelp sample build.xml: missing Xerces config?

[Denis Bradford]

In docbook-xsl-ns-1.78.1 (and going back to 1.77.1, I think), I've found 
a possible bug in the sample webhelp/build.xml Ant file.


In the chunk target, the first xslt task, which generates a profiled 
version of the document, specifies the Xerces XML parser:


value="org.apache.xerces.parsers.XIncludeParserConfiguration"/>


A second xslt task processes the profiled document to generate the final 
output, but it has no Xerces key. I find that this causes my olinks to 
fail to resolve - haven't looked for any other side effects.


When I copied this sysproperty task to the second xslt task, the olinks 
resolved.


-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] [xhtml-1_1][header.navigation] An unallowed attribute

[Denis Bradford]

Hi Devine,

afaik, copying the template to your customization is the right way to 
go, as described in http://sagehill.net/docbookxsl/CustomizingPart.html.

It's certainly better than directly editing the stock templates.

If it's a bug and the template gets fixed in a future release, you can 
simply delete the copy of the template from your customization after you 
install that release. That's the theory anyway.


hth,
Denis

On 06/22/2012 07:04 PM, Divine Dandelion℠ wrote:

Hi,

Here is an old issue in the _xhtml-1_1/chunk-common.xsl_ file:



**  




The <*th* /width>/ attribute isn't allowed in XHTML 1.1, and pages
produced don't pass validation, e.g. with W3.org Validator.

I have copied the whole template into my customization layer and deleted
the wrong attribute. I don't like this way, however, because hiding the
original template from possible changes in the future. Is there any
better solution? Playing with the make.valid.html, html.cleanup, and
make.clean.html parameters was completely unsuccessful. Now I think
about post-processing.

And more, isn't that attribute needed in the original template at all?
Deleting it had no significant visual effect in IE / FF / Chrome.

--
Regards,
Ivan Zaporozhets
Divine Dandelion℠ Online Publishing Service
http://divinedandelion.blogspot.com/ 






-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] Webhelp questions: catalogs and xpointers

[Denis Bradford]

Hi Jeff,

I gave up trying to get catalogs to work with the ANT xslt task, 
probably because I don't know ANT well enough. But it did get things  to 
work after ditching the xslt task and just using the java task. Attached 
are my current build and properties files (note, i haven't upgraded it 
to 1.77 yet).


Don't know if this is at all helpful for your purposes (it does use 
Xerces, for example), but at least it demonstrates one more possible 
customization to the stock build.


Denis

On 06/21/2012 12:08 AM, David Cramer wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Jeff,
Yes, you'd have to modify the supplied build.xml to use catalogs. Last
time I used catalogs with ant, you had to have the resolver jar
available (in the classpath? or ant lib dir?) to make it work. There
was also a simpler catalog format you could use inside your ant
build.xml that didn't require an extra library. Things may have
changed since then, but that's what I recall. The docs are here:

https://ant.apache.org/manual/Types/xmlcatalog.html

However, it sounds as if you'd prefer to exec xsltproc instead of
using Saxon. If you stick with Ant, you could exec xsltproc (and xmllint):

https://ant.apache.org/manual/Tasks/exec.html

As part of this summer's GSoC project, one of the students is creating
a Makefile to build webhelp using xsltproc. You could use that as a
starting point too.

It's difficult to provide a build script that covers everyone's needs.
What's there will work for some people and provide inspiration and
guidance to allow others to integrate it into their system.

David

On 06/20/2012 06:55 PM, Jeff Powanda wrote:

I use an XML catalog with Saxon, so I was surprised that the
Webhelp build.xml file does not specify a catalog resolver. I’ve
tried importing the default build.xml file into my project’s build
file (as the documentation recommends), but it fails to resolve the
catalog entries. I’m not sure how to do it, although I did see the
following Ant macro in the Apache Velocity project that seems to do
the trick. Am I on the right track?



Also, for my other HTML projects I use xmllint to preprocess the
XML source files into one file to resolve xincludes that use
xpointers, something Xerces doesn’t currently support. I assume
I’ll need to do the same to generate Webhelp, but wonder if anyone
has found another solution for dealing with xpointers.



Regards,

Jeff Powanda

Vocera Communications

























































-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP4p5SAAoJEMHeSXG7afUhp4wIAIt3vx884Y4o6vpphGQLXv9Y
gRdOdvdU9GdmcYdzVi7N+JtITBfSPRN7Ul1fJ7XPxx9G40O3jxHik+rJuaejTIOi
EupiU27jSIAQ0aTaBnqT//P0wUd3R4yQi0ERLE5TXv1n271LiMB3Tp8XxdQd8j2/
qy0+6UDvPv/GE2T2GaFuwpgYc/LVydn5sQzhxA48LJmZR3rSXoOZ3Uhkd9Z+B797
FMHg3igbbeJZfhiDALMOClZfm/esLy4XXnZa1IbnkDrLNF7T+wYSWYxctLEfJjOs
IXVnlitg3V7uImKp4l3rZxLeSpSrTbBsoU81aQvpIJ7dvp3kce1GrSDjBEOyjH8=
=1hv7
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org






denis-webhelp-files.tar
Description: Unix tar archive

-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] olink target.db generation problem in 1.77 Webhelp output

[Denis Bradford]

> not sure why Denis did not see it in 1.76.1.

Possibly because I wasn't using the ns version of the stylesheets with 
1.76, as I should have been. Thanks for the info about Saxon and the 
xhtml5 suggestion. I'll let you know if I try it and learn anything.


On 06/19/2012 02:10 PM, Bob Stayton wrote:

Hi,
I can confirm that this problem exists in 1.76.1 when using Saxon 6. I'm
not sure why Denis did not see it in 1.76.1. The problem stems from the
doctype attributes in the xsl:output element in xhtml/docbook.xsl, which
webhelp imports. In Saxon 6, once a doctype has been declared in
xsl:output, there is not way to set it back to blank. I confirmed this
problem with Michael Kay some time ago. So once xhtml/docbook.xsl is
imported, there is no way to output a file without a DOCTYPE when using
Saxon 6.

The xhtml5 stylesheet in 1.77.1 does not have doctype attributes in its
xsl:output elements, and so it should not have this problem. I might
suggest trying to base the webhelp stylesheet on chunk.xsl in xhtml5 in
1.77.1 rather than on xhtml. I don't have time to try it right now, though.

Bob Stayton
Sagehill Enterprises
b...@sagehill.net


- Original Message - From: "David Cramer" 
To: 
Cc: 
Sent: Sunday, June 17, 2012 8:33 PM
Subject: Re: [docbook-apps] olink target.db generation problem in 1.77
Webhelp output



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Denis,
This sounds like that annoying Saxon 6.5 bug where all chunks get the
same DOCTYPE (i.e. you can't change it for one of the chunks you write
out). I'd be surprised if that was not there in 1.76.1. When I've been
faced with that, I've had the build file munch the file to remove the
unwanted DOCTYPE statement. Alternatively, you could modify your ant
script to use xsltproc for the xslt portion.

David

On 06/17/2012 08:44 AM, Denis Bradford wrote:

The problem seems to be the doctype generation in the generated
targetdb


Sorry, I meant The problem seems to be the doctype line in the
generated target.db


On 06/17/2012 09:36 AM, Denis Bradford wrote:

docbook-xsl-ns-1.77.1 appears to break Webhelp olinks. My build
hangs while processing the target database. The problem seems to
be the doctype generation in the generated targetdb, which was
not there in 1.76.1:

http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> 
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org

For additional commands, e-mail:
docbook-apps-h...@lists.oasis-open.org





-



To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org

For additional commands, e-mail:
docbook-apps-h...@lists.oasis-open.org



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP3qGOAAoJEMHeSXG7afUh3/4IAJS2/Euac621ftECTUQ21FXn
+xT4cM9fPhK8iSaKGC467HClfue4W78/UZhpPCqiVm+6zrZbEJxwuktiFAEU1CsV
J3hOghwFHH0kIqSKtMBFwtkcU/OJy9p7c6bS7yYqj5veXRw1x3hpvXVY9UPMcQfT
6M2yConVTGCHozfJvVHB6mL9WgkcFoQ9pAA3OuKffRSsNzzhuqR7i5PdLbZc/+WY
715BpjvAuHL7VajCWmmBujz1bUcWvoinAWrp0h1IaviMhen1PZ7RNNBwgWNcjEQj
ZrLj7WkKXCLea51ETWGMMQJDTcXBuzlzO1Eqm1P7pNYIES/i4GCLTCT/ctns6Hs=
=egfU
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org









-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] olink target.db generation problem in 1.77 Webhelp output

[Denis Bradford]

> The problem seems to be the doctype generation in the generated targetdb

Sorry, I meant
The problem seems to be the doctype line in the generated target.db


On 06/17/2012 09:36 AM, Denis Bradford wrote:
> docbook-xsl-ns-1.77.1 appears to break Webhelp olinks. My build hangs 
> while processing the target database. The problem seems to be the 
> doctype generation in the generated targetdb, which was not there in 
> 1.76.1:
> 
>  PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
>  
> 2. Halt the build, edit target.db and delete the doctype.
> 
> 3. Rebuild using collect.xref.targets="no".
> 
> Thanks,
> Denis
> 
> 
> -
> To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
> 
> 


-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

[docbook-apps] olink target.db generation problem in 1.77 Webhelp output

[Denis Bradford]

docbook-xsl-ns-1.77.1 appears to break Webhelp olinks. My build hangs 
while processing the target database. The problem seems to be the 
doctype generation in the generated targetdb, which was not there in 1.76.1:


  PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>

[docbook-apps] xlink:show="new" support omits link element

[Denis Bradford]

Version 1.77.0 adds support for xlink:show="new", so you can open an 
HTML link in a new window instead of replacing the current window. It 
works for various inline elements, but not for link itself. Is this a 
bug? For example this link


  Audio

... generates XHTML link output with the wrong target value:

  Audio

Changing the element from link to phrase works:
  Audio

Resulting in the target I expect:
   target="_blank">Audio


As far as I can trace it, inline.xsl seems to omit link when it 
enumerates all the supported elements, so simple.xlink doesn't get called.


Thanks,
Denis

-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] webhelp.xsl customizations

[Denis Bradford]

I didn't realize the jquery css file was intended for overrides, either. 
So my solution was to add a link to my custom CSS style sheet at the end 
of the user.head.content template, after all the stock css and js files. 
That way, my CSS rules take precedence.


- Denis

On 01/28/2012 10:35 AM, Kasun Gajasinghe wrote:

(1)

Re: [docbook-apps] Slow TOC tree in webhelp when there are a largenumber of heading entries

[Denis Bradford]

When I ran a medium-size webhelp document on MSIE 8 and clicked a search 
result I also got slow performance. And this error, which even appears 
when I run the small webhelp demo.



Webpage error details

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; 
Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 
3.0.04506.30; .NET CLR 3.0.04506.648; InfoPath.2; .NET CLR 
3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)

Timestamp: Fri, 25 Feb 2011 20:59:29 UTC


Message: Object doesn't support this property or method
Line: 65
Char: 13
Code: 0
URI: file:///C:/webhelp/demo/out/common/main.js


Here's the referenced line in main.js:
  if (style != null && !style.match(/background-color: Background;/)) {

The generated HTML has this line with the background-color style:


Maybe this error explains why expanded TOC trees don't have shaded 
backgrounds in MSIE 8, as they do in other browsers.


Googling on this connection, I read that MSIE 8 doesn't support the 
match function. I tried switching to the search function, with the same 
result.


Too bad you can't just advise people not to use MSIE -- that might solve 
a whole bunch of other problems too ;-)


Cheers,
Denis

On 03/31/2011 06:41 PM, da...@thingbag.net wrote:

Also see the Recommended Apache Configurations section to improve
performance. In fact, those settings are all things Kasun researched
last summer :-) The TDG example on thingbag.net that Kasun pointed to
benefits from those settings:

http://docbook.sourceforge.net/release/xsl/current/webhelp/docs/content/ch02s02.html

The TDG example is a pretty large book and it works ok in webhelp. At
some point, however, you would indeed hit a limit since one of the side
effects of having no frameset is that the toc tree is on every page in a
div.

A possible improvement would be to store the toc tree in a separate js
file, so it could be cached. It's on the list of things we'd like to
improve: http://docbook.xmlpress.net/tiki-index.php?page=WebHelp2011

Thanks,
David




-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] Serializing DB 5 with XOM: wrong encoding

[Denis Bradford]

Thanks for the tip. I downloaded the full xom source, modified 
XIncludeDriver.java, and ran ant java to generate a new xom-samples.jar. 
I copied it to my docbook toolchain, replacing the original 
xom-samples.jar. XOM serialization generates UTF-8 encoding now. Makes 
for much better DocBook processing from there.



P.S. The build wasn't quite that simple: it failed at first, complaining 
that it couldn't find jaxen-1.1.3-src. I downloaded that from 
http://jaxen.codehaus.org/releases.html. Thankfully that made the build 
happy.



On 03/22/2011 02:02 PM, Mauritz Jeanson wrote:

|  -Original Message-
|  From: Denis Bradford
|
|  I've been trying to preprocess xincludes in my DocBook 5
|  build with xom,
|  using the incantation in Bob Stayton's "Complete Guide":
|
|  $ java -cp "xom-1.2.1.jar:xom-samples.jar"
|  nu.xom.samples.XIncludeDriver source.xml>  serialized.xml
|
|  The xincludes resolve just fine, but the serialized doc's
|  encoding comes
|  out as ISO-8859-1, so xom complains about UTF-8 characters in the
|  source. The output doc ends, incomplete, with a cascase of xom
|  Serializer errors.
|
|  According to the XOM api doc, it should be possible to specify the
|  encoding as UTF-8, but I haven't found how to do it from the command
|  line. Anybody know how (or if there's a better solution)?
|  I'm assuming
|  the failure is on account of the encoding problem, since the
|  document
|  seems to process normally otherwise.


I just tried to process a couple of UTF-8 documents with XIncludeDriver
(using XOM 1.2.6), and there were no errors. Unencodable characters were
escaped as numeric character references in the output.

The encoding is hardcoded in XIncludeDriver.java:

  Serializer outputter = new Serializer(System.out, "ISO-8859-1");

This may be a little unfortunate (and not too hard to fix), but
XIncludeDriver is just a sample application after all.

Mauritz






-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

[docbook-apps] Serializing DB 5 with XOM: wrong encoding

[Denis Bradford]

I've been trying to preprocess xincludes in my DocBook 5 build with xom, 
using the incantation in Bob Stayton's "Complete Guide":


$ java -cp "xom-1.2.1.jar:xom-samples.jar"
nu.xom.samples.XIncludeDriver source.xml > serialized.xml

The xincludes resolve just fine, but the serialized doc's encoding comes 
out as ISO-8859-1, so xom complains about UTF-8 characters in the 
source. The output doc ends, incomplete, with a cascase of xom 
Serializer errors.


According to the XOM api doc, it should be possible to specify the 
encoding as UTF-8, but I haven't found how to do it from the command 
line. Anybody know how (or if there's a better solution)? I'm assuming 
the failure is on account of the encoding problem, since the document 
seems to process normally otherwise.


I tried adding a DOCTYPE declaration, in case that might make a 
difference -- it didn't:




http://docbook.org/ns/docbook"; 
xmlns:xi="http://www.w3.org/2001/XInclude"; version="5.0">






-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] Ideas for GSoC 2011

[Denis Bradford]

Amen to that!

On 02/10/2011 10:45 AM, Jirka Kosek wrote:

  or... of WebHelp
 output.Almost any platform now supports applications written purely in
 HTML, CSS and Javascript and packaged for easy installation. This is
 something worth to explore. And it is more "sexy" then boring
 VisualStudio help ;-)





-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] Ideas for GSoC 2011

[Denis Bradford]

I second the motion, but maybe there's not a huge hurry. My 2₵:

Help 3 (official name: Microsoft Help Viewer) is currently used only in 
Visual Studio (and MSDN, in some form) -- MS does not yet consider it a 
general purpose replacement for HTML Help.


Help 3 design is still a moving target. The original design was 
minimalist in the extreme - no keyword index or search, I think. After a 
lot of complaints from the user community, the MS Help 3 team recently 
added many new features (in the latest Visual Studio 2010 Service Pack).


That said, Help 3 seems likely to eventually take hold. And since the 
outputs will be mostly straight XHTML, maybe it's not too risky to get 
started on the DocBook stylesheets.


Cheers,
Denis

On 02/10/2011 06:34 AM, Speights, Scott wrote:

Hi list,

I was checking out the GSoC 2011 Wiki page for upcoming developmentsand
I hadanidea. I think it would also be useful if DB could generate MS
Help 3 Help…Anyone interested in that one.

Greetings,

Scott

Scott Speights

Technical Writer

--

Haufe-Lexware GmbH & Co.KG

Munzinger Str. 9, D-79111 Freiburg

Tel. +49 761 898-5313

E-Mail: scott.speig...@haufe-lexware.com

Internet:_http://www.haufe-lexware.com_

--

Kommanditgesellschaft, Sitz und Registergericht Freiburg, HRA 4408

Komplementäre: Haufe-Lexware Verwaltungs GmbH,

Sitz und Registergericht Freiburg, HRB 5557; MartinLaqua

Geschäftsführung: Isabel Blank, Birte Hackenjos, Jörg Frey,

Matthias Mühe, Markus Reithwiesner, Joachim Rotzinger, Dr. Carsten Thies

Beiratsvorsitzende: Andrea Haufe





-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] Use of xincludes vs. entities

[Denis Bradford]

Also see Bob Stayton's summary of using xincludes in
http://www.sagehill.net/docbookxsl/DuplicateIDs.html.
I've successfully implemented xincludes in place of entity refs, but it 
was tricky, along the lines that Sam describes.


That's why I sat up when David mentioned Jirka's transclusion proposal. 
I sure hope it's adopted by the DocBook committee. I'm not much of a 
DITA fan, but resurrecting transclusions is one thing I do like about 
it. DITA conrefs are almost as verbose as xincludes, but they do avoid 
duplicate ids.


On 09/26/2010 08:10 AM, Sam Fischmann wrote:

Sorry for mailing so much on this topic, but thanks for the link. The
information here is great to see, but I'm curious about the current
status of any work related to this proposal. My situation is difficult
because I'm sitting on a huge amount of material and don't want to
pull the trigger upgrading it until I'm certain I have good support
going forward from editors, parsers, stylesheets, etc. For now, I
wait.

-Sam

On Sat, Sep 25, 2010 at 1:25 PM, Cramer, David W (David)
  wrote:

Hi Sam and Jim,
You might be interested in Jirka's proposal for transclusions in DocBook. It 
notes the problems with xincludes for the very use case you bring up:

http://lists.oasis-open.org/archives/docbook-tc/201007/msg00041.html

David

-Original Message-
From: Sam Fischmann [mailto:sam.fischm...@gmail.com]
Sent: Saturday, September 25, 2010 3:10 PM
To: Jim Campbell; docbook-apps@lists.oasis-open.org
Subject: Re: [docbook-apps] Use of xincludes vs. entities

Hi Jim,

I say pick the right tool for the job. I think that the two cases you
outline above are completely reasonable uses for entities. I'm also a
bit sheepish about using XInclude with XPointer because of the
differing levels of support for XPointer in different XSL processors.
I don't think it's Bad with a captial "B" to use entities in places
where they are a simple, elegant solution.

Another way to look at it... While editing, a lot of the XInclude junk
doesn't seem helpful for a small bit of text replacement:
The ball is&product_color;.
The ball is.

I think product_info.xml is just going to be a weird file to maintain,
too, but that could be personal preference.

However, if it were a file, xi:include provides valuable information:
See the following table:&uh_what_file;
See the following table:


[ I am going to rant slightly off-topic now, but you might find some
of this interesting and related to your question ]

I am in a situation right now where I have a very large base of
existing DocBook material that uses entities extensively. I would like
to use XPointer for including chunks of text, but I run into all sorts
of problems when those chunks of text themselves contain entities.

Consider two books: Book1 and Book2. Book1 defines&foo; as "1" and
Book2 defines&foo; as "2". I have a file "inc.xml" that's included in
each book via entities. It has the content: "My number is
&foo;". It works great. When I view either book in an editor,
the entity resolves nicely to 1 in Book1 and 2 in Book2.
Unfortunately, most editors don't allow me to edit the contents of
"inc.xml", or as soon as they do,&foo; doesn't resolve because it's
not aware of the parent book that defines it because it's in another
file.

Now I change to XInclude. If I simply add a DOCTYPE tag to "inc.xml"
and include it,&foo; won't resolve at all, because it needs to be
declared inside "inc.xml". But this file is included by two books
which would each define the entity differently. What do I do?

To solve the general case, somebody might tell me that I could define
&foo; in two different entity files, then create two XML catalogs, one
for use with each book, that define the same public identifier for
each respective entity file.  I would then use the public identifier
to declare the entity file in the subset of "inc.xml" and
conditionally specify one or the other catalog when building each
book. That's an awful lot of infrastructure, not to mention that I'm
going to be hard-pressed to find an editor which could elegantly
handle the catalog situation.

Somebody else might respond: but clearly there's some ill-conceived
organization here. Why aren't you using profiling to get the "1" and
"2"? Surely then, you could define a couple profiled phrases for
&foo;, then specify the profile when making the book. Well, consider
what might happen if I had 15 books that each required a unique
definition? Now every time that entity is used and I'm editing a book,
I've got to look at a massive chunk of profiled phrases. Still, I'm
considering this to be the only reasonable route to take; if you name
your entities well enough you can hide their text values when editing
material in a nice full-featured editor.

-Sam

On Sat, Sep 25, 2010 at 8:25 AM, Jim Campbell  wrote:

Hi All,

As I understand it, the xincludes feature provides a number of advantages
over use of entities, but are there some situations where entities are still
relevant 

Re: [docbook-apps] Help needed testing CJK search support in webhelp

[Denis Bradford]

>> exclude.search.from.webhelp. Setting this to true will drop the
>> search tab.

You're right, I changed that property -- not sure why. My mistake!

>> Index is already there, as the last link in TOC tab.
>> Did you mean that
>> or adding a separate tab for index, along with 'contents' and 
>>'search' tabs?


Yes, I meant in the TOC tab, not a separate tab. But since your TOC has 
the link (not sure why mine didn't) I doubt it's a WebSite issue.


- Denis

On 08/12/2010 02:37 AM, Kasun Gajasinghe wrote:
>
>> Hello Denis,
>> Thanks for the feedback. Please see the comments inline.
>>
>> --Kasun
>>
>> Sent from my iPhone
>>
>> On 12 Aug 2010, at 07:48 AM, Denis Bradford
>>  wrote:
>>
>>> I've installed and built the new package. It's beautiful! I saw a few
>>> issues:
>>>
>>> 1. Couldn't create Search tab: I assume the Search tab is supposed to
>>> appear somehow when I build the indexer. However, after following
>>> instructions and running both the webhelp build-indexer targets I got
>>> the TOC tab only.
>>
>> The purpose 'build-indexer' target is to compile the java source that
>> is used for indexing the content. For a end- user this target is of
>> less use, unless s/he plans to change java source.
>> Running only 'webhelp' target should create the search tab. But we did
>> made creating the search tab optional. Ie if user doesn't need it,
>> s/he can drop it.
>> It is done by a property in build.properties file called
>> exclude.search.from.webhelp. Setting this to true will drop the search
>> tab.
>>
>> But, I couldn't figure out the reason For your case, assuming you
>> didn't change that property. Can you please pastebin the ant webhelp
>> output as well? Now, I'm not away from my computer I will look in
>> further possible causes for your issue and will update list.
>>
>>> Here's the command output -- not sure if it's completely normal:
>>>
>>> $ ant build-indexer
>>> Buildfile: build.xml
>>>
>>> build-indexer:
>>> [mkdir] Created dir: ~/webhelp/indexer/lib/htmlsearch
>>> [javac] Compiling 9 source files to ~/webhelp/indexer/lib/htmlsearch
>>> [javac] Note:
>>> ~/webhelp/indexer/src/com/nexwave/nquindexer/IndexerTask.java uses
>>> unchecked or unsafe operations.
>>> [javac] Note: Recompile with -Xlint:unchecked for details.
>>> [jar] Building jar: ~/webhelp/indexer/lib/nw-cms.jar
>>> [delete] Deleting directory ~/webhelp-db4/indexer/lib/htmlsearch
>>>
>>> BUILD SUCCESSFUL
>>
>> This is normal, and this has no connection with the issue above.
>>
>>>
>>>
>>> 2. I looked at the Search tab on the online package
>>> (http://www.thingbag.net/docbook/gsoc2010/doc/content/). Verified
>>> that search results are synced with the TOC. However, noticed this
>>> glitch:
>>>
>>> When I enter a search query and click a link in the result, the
>>> target topic has a big, light blue input button with the letter H in
>>> it, just beside the top arrow nav button. The button appears on every
>>> Search target that I open, but is hidden when I open topics from the
>>> TOC instead of Search.
>>
>> It is removed now. That was a intermediatory thing.
>>
>>>
>>> 3. The source has indexterm elements but no index. You might consider
>>> adding an index element to the end of the book, just so the build
>>> generates an index. After, this is one of the advantages of WebHelp
>>> over DocBook Website!
>>
>> Index is already there, as the last link in TOC tab. Did you mean that
>> or adding a separate tab for index, along with 'contents' and 'search'
>> tabs?
>>
>>>
>>> I did verify that the TOC stays synced when I navigate using the index.
>>> (Exception: 'Web-based Help from DocBook XML Readme' has an index
>>> entry but no TOC link. Since this is the bookinfo component, I think
>>> WebHelp effectively syncs to the top of the TOC.)
>>
>> Ok. We missed that. I'll add an link to the bookinfo component.
>>
>>>
>>> Thanks so much for this work, Kasun, I hope this feedback is a little
>>> bit useful.
>>
>> Thanks to you as well for the great feedback! This will help us to
>> make webhelp better. And special thanks should go to my mentor, David
>> Cramer for his great sup

Re: [docbook-apps] Help needed testing CJK search support in webhelp

[Denis Bradford]

I've installed and built the new package. It's beautiful! I saw a few 
issues:


1. Couldn't create Search tab: I assume the Search tab is supposed to 
appear somehow when I build the indexer. However, after following 
instructions and running both the webhelp build-indexer targets I got 
the TOC tab only.


Here's the command output -- not sure if it's completely normal:

$ ant build-indexer
Buildfile: build.xml

build-indexer:
[mkdir] Created dir: ~/webhelp/indexer/lib/htmlsearch
[javac] Compiling 9 source files to ~/webhelp/indexer/lib/htmlsearch
[javac] Note: 
~/webhelp/indexer/src/com/nexwave/nquindexer/IndexerTask.java uses 
unchecked or unsafe operations.

[javac] Note: Recompile with -Xlint:unchecked for details.
  [jar] Building jar: ~/webhelp/indexer/lib/nw-cms.jar
   [delete] Deleting directory ~/webhelp-db4/indexer/lib/htmlsearch

BUILD SUCCESSFUL


2. I looked at the Search tab on the online package 
(http://www.thingbag.net/docbook/gsoc2010/doc/content/). Verified that 
search results are synced with the TOC. However, noticed this glitch:


When I enter a search query and click a link in the result, the target 
topic has a big, light blue input button with the letter H in it, just 
beside the top arrow nav button. The button appears on every Search 
target that I open, but is hidden when I open topics from the TOC 
instead of Search.


3. The source has indexterm elements but no index. You might consider 
adding an index element to the end of the book, just so the build 
generates an index. After, this is one of the advantages of WebHelp over 
DocBook Website!


I did verify that the TOC stays synced when I navigate using the index.
(Exception: 'Web-based Help from DocBook XML Readme' has an index entry 
but no TOC link. Since this is the bookinfo component, I think WebHelp 
effectively syncs to the top of the TOC.)


Thanks so much for this work, Kasun, I hope this feedback is a little 
bit useful.


Denis

P.S. While looking at WebHelp, it suddenly struck me that your frameless 
design makes implementing context-sensitive help a no-brainer. I 
remember all the work Jirka had to do to add support for application 
hooks in the htmlhelp stylesheets, because we had to go through the CHM 
browser's protocol. With WebHelp, F1 from any control just needs a 
simple URL link to an HTML page. That's a major selling point, IMO.


On 08/09/2010 10:04 AM, Cramer, David W (David) wrote:

Hi there,

Kasun Gajasinghe has been hard at work this summer on the webhelp GSoC
project and has implemented all the required features, including
stemming for English and German, highlighting of search results, and
tokenization for Asian (Chinese, Japanese, Korean) languages, freeing
the output from the frameset, and automatic toc synching.

You can see a demo of the results of his efforts and download it to try
things out on your own content from here:
http://www.thingbag.net/docbook/gsoc2010/doc/content/ch02s01.html

The instructions provide links to a version of the package for 4.x and
5.x documents.

Feedback is welcome. Please let us know what bugs you find. In
particular, we need to test the CJK search support. If you have some
demo content in Chinese, Japanese, or Korean that you can share with us
for testing, we’d appreciate it. I had planned to use the Chinese
version of DocBook, The Definitive Guide, but have had some trouble
getting my environment set up so it will build.

We plan to provide instructions for adding stemming support for other
non-CJK languages. For a number of languages
, all
that is required is to port the stemmer from Java to JavaScript so that
it can be used on the client side.

Thanks,

David





-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] article / info / author / address - how do I make it appear?

[Denis Bradford]

Hi Jochen

According to 'DocBook 5: The Definitive Guide' 
(http://www.docbook.org/tdg51/en/html/info.html), article/info is not 
designed to appear in output:


==
Description

The info element contains meta-information about the element that 
contains it.


Processing expectations

Suppressed.
==

So I think you need to use address in a different context if you want it 
displayed. The same DocBook design document /address.html) has this 
example:



Example address

An example of a postal mail address in the United States:

John and Jane Doe
100 Main Street
Anytown, NY 12345
USA





- Denis

On 07/18/2010 07:58 AM, jochen+oasis-o...@hayek.name wrote:

I searched Bob's book for that (paper and online),
but to no success.

I wrote a little document,
and it's necessary, that it shows my address.

Any pointer pls?

Kind regards,
J.

-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org





-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] Website: is there any additional *short* title for use in the TOC / left column?

[Denis Bradford]

Hi Jochen,

In your layout.xml, you can add titles to tocentries, like this:


  Short title


If you add the optional title element a tocentry, it is displayed in the
TOC instead of the title that's in the web page. The tocentry title
doesn't change the title in the web page itself.

HTH,
Denis


On 07/14/2010 10:16 AM, jochen+oasis-o...@hayek.name wrote:
> Hi, there!
> 
> 
> During my rather successful (from my point of view) process of converting a 
> couple of web-sites from "plain DocBook generated HTML" to "DocBook Website 
> (HTML)"
> 
> I now ran into a problem with this site:
> 
>http://Aleph-Soft.com/JHwis/
> 
> Maybe you want to have a quick look at it.
> 
> I know, I got the TITLEs there a "little long":
> 
>TITLE
> 
> … which doesn't really disturb me as headers within those many HTML files,
> but it does hurt within the left column.
> 
> Is there a way of providing a short title for use within the TOC / left 
> column?
> 
> J.
> 
> -
> To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
> 
> 



-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] RESEND: Newbie question

[Denis Bradford]

You can create a file with a collection of text entities, similar to 
the examples in docbook/schema/dtd/4.5/dbgenent.mod, and then reference 
the ones you want in your document.


But I believe XIncludes are intended to replace entities for this 
purpose, and DocBook 5 supports them. An XInclude can reference any 
element (such as phrase) that has an xml:id attribute. See Stayton's 
section on Using XIncludes with DocBook 5 
(http://www.sagehill.net/docbookxsl/ProcesingDb5.html#d0e4843).




-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] New Branch: website5

[Denis Bradford]

Dave,

You and Sina might well be right that DocBook is best kept to a core 
system, instead of being extended to accommodate user demands. It looks 
to me like the Publican and WebHelp and project represent each approach.


Either way I'm glad I asked the question, otherwise I might have missed 
all this very cool development. Thanks to all for your thoughtful responses!


Dave Pawson wrote:

On Thu, 27 May 2010 01:00:47 +1000
Ruediger Landmann  wrote:


On 05/20/2010 11:33 AM, Denis Bradford wrote:

Neat! That ought to prove my point -- both of us can't be wrong.


Feature creep? Don't you just love it.


regards





-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] New Branch: website5

[Denis Bradford]

Hi David,

Sorry I missed the WebHelp project -- you're right, the features I had 
in mind do suggest user assistance.


I'm not sure what should be in the Index tab, but I'll see if I can help.

Thanks,
Denis


David Cramer wrote:

-Original Message-----
From: Denis Bradford [mailto:denis.bradf...@verizon.net] 
Sent: Wednesday, May 19, 2010 4:32 PM

To: DocBook Apps Mailing-List
Subject: Re: [docbook-apps] New Branch: website5



The benefits just might be worth the effort. Making Website a DocBook 
output option, instead of a separate dialect, would increase its value


for technical documentation -- a low-tech, frameless alternative to 
Eclipse infocenters and HTML-based help browsers.


Hi Denis,
Sorry, just catching up on this thread.

You might be interested in Kasun Gajasinghe's WebHelp GSOC project: 
http://docbook.xmlpress.net/tiki-index.php?page=webhelp_proj


This project is turns standard DocBook into user assistance for webapps
and in other situations where you need a crossplatform/crossbrowser help
solution, but is similar to what you want. The index tab is currently a
low-priority item relative to the other features, but is definitely in
the scope. If you've already got some code that creates the content for
an index tab (similar to an the Eclipse or HTML Help index), I'm sure
Kasun would love to see it. 


The project will improve on the prototype here:
http://www.thingbag.net/docbook/docbook-webhelp/index.html

The goal is to do it without a frameset, improve the toc, and improve
the search. Kasun and I have currently deprioritized an index tab in
favor of search highlighting, but if you've already done the work,
perhaps the index tab would make it back in.

David

-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org





-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] New Branch: website5

[Denis Bradford]

Hi Sina, please see my response at the bottom.

Sina K. Heshmati wrote:

"Denis Bradford"  said:

Hello Denis,


Not sure if this the best place to post this, but here goes:


Where better than here?


Sina, I'm so glad to see active development on Website, it's such a
terrific product. As long as you're thinking about its next stage of
development, has anyone suggested folding Website into DocBook? I use
both all the time, and I think each has features that could enhance the
other.

I once implemented a doc set that pulled together a bunch of DocBooks
and some non-DocBook content using an olink sitemap. I was amazed to
learn how powerful sitemaps and generated olink databases are. It
occurred to me that they could be used to do far more than enable
olinks: they contain all the metadata you need to organize and process a
whole doc system -- not unlike Website layouts (and ditamaps, for that
matter). On the company web site we served our doc set as an Eclipse
infocenter, but I couldn't help thinking how much easier it would have
been to post it as a Website.

Another example, on the Website side: why should only books and help
systems have an index? It's a great navigation tool for an informational
web site, too. So, I hacked the Website stylesheets to generate a
DocBook index for the site. Not pretty XSL, but my readers love the index.

I realize this is not a trivial thing. Besides the layout, there doesn't
appear to be much difference between the DocBook and Website (full)
documents -- mostly a few elements at the top. But the big difference is
in the processing, and that would no doubt require a lot of work to bridge.

The benefits just might be worth the effort. Making Website a DocBook
output option, instead of a separate dialect, would increase its value
for technical documentation -- a low-tech, frameless alternative to
Eclipse infocenters and HTML-based help browsers.


Some of these features are indeed useful for both DocBook HTML output and 
DocBook Website but please note the fundamental distinction between DocBook and 
DocBook Website. DocBook helps format documents and publish them anywhere, 
including the Web whereas DocBook Website helps publish *websites* on the Web 
and only on the Web.



That said, DocBook Website can, in theory, support all the features provided by 
the HTML stylesheets for DocBook but it's important to know that DocBook and 
DocBook Website do not share a common goal.


I don't see how the distinction you draw between DocBook and Website is 
 fundamental. The DocBook stylesheets for PDF and HTML Help don't 
represent different goals, they're just different outputs from a single 
source.


That was the point I tried to make in citing my own work experience, 
where it would have been useful to publish not only to help and PDF, but 
also to collection of web pages, all from the same source.


Of course, if the work is beyond the scope of this GSoC project, I 
completely understand.


Thanks,
Denis



SinDoc

I guess the distinction you draw between DocBook and Website doesn't 
seem fundamental to me.



-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org





-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] New Branch: website5

[Denis Bradford]

Dave Pawson wrote:

On Wed, 19 May 2010 17:31:59 -0400
Denis Bradford  wrote:

Another example, on the Website side: why should only books and help 
systems have an index? It's a great navigation tool for an

informational web site, too. So, I hacked the Website stylesheets to
generate a DocBook index for the site. Not pretty XSL, but my readers
love the index.


Do you mean index or Toc Denis?
ws has a toc facility. 


And since an index is available from the docbook stylesheets, which
are utilised by ws, no reason they shouldn't be included, just
that the wrapper should be a page not an appendix.


I do mean an index. Even though the index element is available in 
website-full, it doesn't work above the scope of a webpage.


As Bob Stayton told me:

"As it currently ships, Website can't collect index entries from the set 
of webpage documents and generate a sorted index. "




hth







-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] New Branch: website5

[Denis Bradford]

Neat! That ought to prove my point -- both of us can't be wrong.

Doug wrote:

On Thu, 20 May 2010, Denis Bradford wrote:

Not sure if this the best place to post this, but here goes:

Sina, I'm so glad to see active development on Website, it's such a
terrific product. As long as you're thinking about its next stage of
development, has anyone suggested folding Website into DocBook? I use
both all the time, and I think each has features that could enhance the
other.

I once implemented a doc set that pulled together a bunch of DocBooks
and some non-DocBook content using an olink sitemap. I was amazed to
learn how powerful sitemaps and generated olink databases are. It
occurred to me that they could be used to do far more than enable
olinks: they contain all the metadata you need to organize and process a
whole doc system -- not unlike Website layouts (and ditamaps, for that
matter). On the company web site we served our doc set as an Eclipse
infocenter, but I couldn't help thinking how much easier it would have
been to post it as a Website.

Another example, on the Website side: why should only books and help
systems have an index? It's a great navigation tool for an informational
web site, too. So, I hacked the Website stylesheets to generate a
DocBook index for the site. Not pretty XSL, but my readers love the index.



Sorry for bringing this up again.
I did this myself as a DocBook Website customization/rewrite.
Its called tabular-toc: 
http://docbook.svn.sourceforge.net/viewvc/docbook/trunk/contrib/xsl/tabular-

toc/

It differs from website in that you have to role your own autolayout.xml,
but after, the entire hierarchical web-site table of contents cascades
down into every html page of every webpage, and chunked book, part, article 
across the whole website (using the website "tabular" style).

Only two examples:
http://xtal.sourceforge.net/
http://cima.chem.usyd.edu.au:8080/cif/skunkworks/html/index.html

In addition, you could just feed it a single document, like a book, and 
it would build the books TOC, in website tabular style into every 
chunked page. (theres an example in with the source)


Of course I did it modifying website in XSLT-1.1 and the new project is 
supposed to be XSLT-2, but maybe some of it can be cannibalised?



I realize this is not a trivial thing. Besides the layout, there doesn't
appear to be much difference between the DocBook and Website (full)
documents -- mostly a few elements at the top. But the big difference is
in the processing, and that would no doubt require a lot of work to bridge.


Yeah. It did.


The benefits just might be worth the effort. Making Website a DocBook
output option, instead of a separate dialect, would increase its value
for technical documentation -- a low-tech, frameless alternative to
Eclipse infocenters and HTML-based help browsers.


Well I thought so.






-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] New Branch: website5

[Denis Bradford]

Not sure if this the best place to post this, but here goes:

Sina, I'm so glad to see active development on Website, it's such a 
terrific product. As long as you're thinking about its next stage of 
development, has anyone suggested folding Website into DocBook? I use 
both all the time, and I think each has features that could enhance the 
other.


I once implemented a doc set that pulled together a bunch of DocBooks 
and some non-DocBook content using an olink sitemap. I was amazed to 
learn how powerful sitemaps and generated olink databases are. It 
occurred to me that they could be used to do far more than enable 
olinks: they contain all the metadata you need to organize and process a 
whole doc system -- not unlike Website layouts (and ditamaps, for that 
matter). On the company web site we served our doc set as an Eclipse 
infocenter, but I couldn't help thinking how much easier it would have 
been to post it as a Website.


Another example, on the Website side: why should only books and help 
systems have an index? It's a great navigation tool for an informational 
web site, too. So, I hacked the Website stylesheets to generate a 
DocBook index for the site. Not pretty XSL, but my readers love the index.


I realize this is not a trivial thing. Besides the layout, there doesn't 
appear to be much difference between the DocBook and Website (full) 
documents -- mostly a few elements at the top. But the big difference is 
in the processing, and that would no doubt require a lot of work to bridge.


The benefits just might be worth the effort. Making Website a DocBook 
output option, instead of a separate dialect, would increase its value 
for technical documentation -- a low-tech, frameless alternative to 
Eclipse infocenters and HTML-based help browsers.


Thanks,
Denis


-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] Converting Website to DB5: suppressing version="5.0" attribute on children of root

[Denis Bradford]

As usual, I should have dug a little more before asking for help. Found 
the source of my problem:


In db4-upgrade.xsl, the "*" mode="AddNS" template adds a version 
attribute to the root element, like this:



  5.0


In my customization (maybe because my root is different from what 
db4-upgrade.xsl expects) the test for parent in this template doesn't 
work as expected, so the attribute is applied to some elements under the 
root.


However, my customization explicitly converts webpages to articles, and 
 hardcodes the NS and version attributes on the generated  
element. So I customized the AddNS template in my stylesheet by deleting 
 the lines shown above. It seems to work fine as far as I can tell.


Thanks,
Denis

-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

[docbook-apps] Converting Website to DB5: suppressing version="5.0" attribute on children of root

[Denis Bradford]

I'm working on an XSL 1.0 stylesheet that processes a DocBook Website 
autolayout file, transforming its Website pages into DocBook 5 articles. 
My stylesheet imports Norm's db4-upgrade.xsl, which does most of the 
work. My output is valid, and looks fine except for one nagging detail: 
some elements are transformed with 'version="5.0" attributes.


Sample output:
=
http://docbook.org/ns/docbook"; 
xmlns:xi="http://www.w3.org/2001/XInclude"; 
xmlns:html="http://www.w3.org/1999/xhtml"; 
xmlns:m="http://www.w3.org/1998/Math/MathML"; 
xmlns:svg="http://www.w3.org/2000/svg"; 
xmlns:xlink="http://www.w3.org/1999/xlink"; version="5.0" xml:id="upreview">


  

  Up and other Pixar reviews

  From
  Pixar Gone Too Far This Time: 

  

If the Pixar sensibility seemed strangely locked in to 
a mid-20th century mindset, well, they made it clear they intended to 
inherit the Disney mantle, didn’t they?

   ...




=

Notice that all the children of  (except for , which my 
stylesheet extracts out of context) have the version attribute, while 
their children do not. I'd like the version attribute to be suppressed 
on all elements (except the root article, of course). Any ideas? Here's 
the entire customization:



http://www.w3.org/1999/XSL/Transform";
xmlns:xi="http://www.w3.org/2001/XInclude";
xmlns:html="http://www.w3.org/1999/xhtml";
xmlns:m="http://www.w3.org/1998/Math/MathML";
xmlns:svg="http://www.w3.org/2000/svg";
xmlns:xlink="http://www.w3.org/1999/xlink";
xmlns:saxon="http://icl.com/saxon";
xmlns:exsl="http://exslt.org/common";
extension-element-prefixes="saxon exsl"
version='1.0'>










  




  



  
  
  
  

  

  






 Converted by db4-upgrade version 

 





  http://docbook.org/ns/docbook";
version="5.0" xml:id="{$pageid}">


  filename="
  
  " 
  

dir="

"
  



mode="addNS"/>

  


  













-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

[docbook-apps] RE: DocBook topic element]

[Denis Bradford]

Sorry, posted to wrong list:

 Original Message 
To: docb...@lists.oasis-open.org


... the DocBook model (so far)
has been a "top-down" approach, with documents typically being authored
as entire publications that contain chapters and sections.

Introducing a  into DocBook muddies the waters. Either:

(1) You use s instead of s, in which case why not just use
DITA?; or,


I've never been convinced that DITA is particularly better suited for
topic-based authoring than DocBook. See
http://norman.walsh.name/2005/10/21/dita for a cogent argument on that
point.

As a writer who uses both every day, I would look elsewhere for relative
strengths and weaknesses. For example, in DITA's favor I might point out
its small tag set, reltables, and conrefs; as compared to DocBook's
maturity, abundance of tools, and ease of implementation and customization.

IMO, DocBook's "swiss army knife" flexibility is a Good Thing in a
modular XML publishing system. From this standpoint, adding a
well-considered topic model is one more useful refinement to DocBook.


-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] DocBook Customization

[Denis Bradford]

> In terms of the cost of customization, I have found customizing the
> DocBook 4 DTD to be easier than customizing the DITA DTDs.

Talk about complex transforms: I've been using DITA recently, and the OT 
stylesheets look pretty intimidating to me - and no 'DITA XSL The 
Complete Guide' to help sort them out!



Bob Stayton wrote:

Hi Eric,
My impression is that many groups adopt DITA because they want to work 
in topics rather than chapters. Then they do whatever is needed to use 
DITA to write topics. I have been in contact with more than one group 
that has adopted DITA without any DTD customization.  As you say, people 
often do crazy things.  8^)
 
One common DocBook customization practice is to cut down on the number 
of elements.  There are several reasons why: 
 
a.  When using an XML editor that presents a list of valid tag names, 
the list can be quite long in many contexts (such as inlines).  Many 
such elements are never to be used, so remove them from sight.
 
b.  Reducing ambiguity in choosing among similar elements.
 
c.  Reducing the complexity of a stylesheet customization. If you know 
you are only supporting certain elements you don't need to have 
templates for all elements.
 
d.  Reduce the complexity of the para element by removing block element 
children (making it like simpara).
 
It is possible to make a subset that still produces documents that 
validate with the full DocBook schema. But of course not the other way 
around.
 
In terms of the cost of customization, I have found customizing the 
DocBook 4 DTD to be easier than customizing the DITA DTDs. In DITA's 
DTDs, everything is a twice-removed parameter entity, and it is hard to 
keep track of where an element is actually declared and what children it 
can contain.  DocBook 4 uses parameter entities, but not to such a 
complex degree.  DocBook 5's RelaxNG grammar is even easier to 
customize, once you learn the grammar.
 
Bob Stayton

Sagehill Enterprises
b...@sagehill.net 
 
 


- Original Message -
*From:* Eric Johnson 
*To:* DocBook Apps ML 
*Sent:* Tuesday, May 19, 2009 5:11 AM
*Subject:* [docbook-apps] DocBook Customization

I was talking to someone last night and they mentioned that the
biggest use case, and the one that is causing everyone to flock to
DITA, for using DocBook is to take the schema and then customize it.

My first reaction was to think "That's completely crazy. This person
is obviously just a DITA cultist and seeing the world through tinted
lenses." Then the cynic in me piped up and said "People often do
crazy things."

Is this a big use case in the DocBook world? Do organizations start
with standard DocBook and then tweak it around to make some
customized version of the schema that is no longer DocBook?

Why would an organization customize DocBook instead of adopting DITA
which is built with the (almost) requirement that it be customized?

What is the cost of doing the customization?
One of the reasons my group adopted DocBook was that the schema did
not need to be customized. We had to create a few guidelines around
using certain tags, but that was much easier than modifying the
schema. Perhaps in larger groups using the schema to enforce rules
is more desirable.




-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] DocBook HTML transform with Frames ?

[Denis Bradford]

If you're interested in a tree-view TOC *without* frames, there's
DocBook Website.

http://docbook.sourceforge.net/release/website/example/

Website has a whole chapter in Bob Stayton's "Complete Guide",
and the XSL is part of the basic DocBook distribution.

You'll enjoy customizing the stylesheets at least superficially;
the basic nuts and bolts work out of the box, but they're
pretty plain.


Johan Persson wrote:

Hi,

Before I try to re-invent the wheel I was wondering if anyone new of some 
alternative DocBook XSL that would produce HTML with frames?


What I'm after is to have a tree-view of the TOC in a frame (to the left with 
some javascript) and the actual content in a separate frame to the right.


(Since I'm new to XSL it is probably a good exercise to do this- but I rather 
not be inventing the wheel again)


Thanks !
Johan



-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org





-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

[docbook-apps] Website: Incorrect relative links to offsite docs in toc

[Denis Bradford]

I'm including an offsite document in my Website 2.6.0 layout. However, 
some -generated tocs do not link to it when I specify its location with 
a relative path.


For example, in this layout the second tocentry specifies an offsite 
document that is to be found in the output-root directory.



  


  Sub page



  Non Webpage doc


  


But in generated pages, the navtoc always links to the offsite document 
using href="offsite.html". So the link is correct in home.html, but 
incorrect in page.html (it should have 'href="../offsite.html"'.


Looks to me like the problem is in page.uri (in website-common.xsl) 
where it handles offsite tocentry hrefs:


  

  

  

Replacing the fourth line with this seems to work ok:




Shall I file a bug, or is this user error??

Thanks,
Denis

P.S.: The same problem occurs with Prev and Next buttons if you turn on 
sequential.links. I haven't figured out yet why the fix above doesn't

fix those links too...

-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] Manual chunking with component level toc

[Denis Bradford]

First, shouldn't the dbhtml PIs go in the components, not the toc?
For example:



My Book

  
 Objects

Second, even with a manual toc, you might still need to set chunking 
params like chunk.section.depth. For details, see


"Controlling what gets chunked" in Stayton's "DocBook XSL:The Complete 
Guide"

( http://www.sagehill.net/docbookxsl/Chunking.html#ControllingChunks )

hth,
Denis


j.tosov...@email.cz wrote:

Hello Everybody,

for my quite complex document I'd rather to use manual chunking. The main xml document is splitted into individual files which are placed in nested subfolders according to document tree. Each html file should contain corresponding content of xml file. In default chunking some of the files are unintentionally splitted. Using own XSLT code I can generate appropriate toc specification, but there is one BUT. There is missing top-level content of chapter or section as there is no corresponding xml file. In example below, no html file is created for chapter itself. It would be nice to have in it chapter title with local toc. But how to generate it? 



  
Objects
http://www.w3.org/2001/XInclude"/>
http://www.w3.org/2001/XInclude"/>
  



  
 

  
  
  
  

  


Thanks for any ideas,
Jan




-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Re: [docbook-apps] Website: Problem using olinks across websites

[Denis Bradford]

Following Bob's lead, I've tried to generate a website.database.xml that 
does not contain the offending document elements  - with no luck.


To simplify things, I built the example website that comes with the 
website 2.6 distribution, using the layout and build.xml ant file 
provided. Other than pointing at local resources, I only modified it by 
adding the last argument to this target:


==


  
  
  
  
  
  

[docbook-apps] Website: Problem using olinks across websites

[Denis Bradford]

I maintain a web site as a collection of DocBook websites, each with its 
own layout and its own TOC. I want to replace the old ulinks with 
olinks. The olinks are working fine within each website, but olinks 
across websites fail to resolve. Here's how TDG says to do it:


"Once you have the targets database, you can pass its pathname to the 
XSLT processor using the target.database.document stylesheet parameter. 
This database is in addition to (and separate from) the olink database 
that resolves olinks between webpages in your website. The database of 
internal olinks is identified with the website.database.document 
parameter. When the processor encounters an olink, it first checks the 
website database before consulting the offsite database."


All right, here's how I've been trying to implement it:

1. In my ant script, after building the layouts, I transform each 
website in turn. In addition to setting collect.xref.targets='yes' and 
declaring the current docid, I specify both the website.database and 
target.database documents, like this:


 

  
  
  

 

It seems the

2. Meanwhile, I've created olinksitemap by hand. It includes the 
website.database.document for each website, like this:



  

  


  

  

  ...


3. Finally, the olinks themselves. I've tried a couple of forms. For 
example, here's an olink to a homeSite page from within a scheduleSite 
page:


 
 

The first is the recommended form where 'about' is the id of the 
webpage.  It does not resolve at all. The second is the conventional 
(non-website) form, but seems doomed because there is no book or any 
document with the id "homeSite". Encouragingly, it finds the title - but 
alas, the wrong url:


  About this site

fwiw, here's the corresponding code in the website database:

   
  lang="en">

 About this site


Am I anywhere near the right track, or completely off? Any working 
examples of cross-website olinks?


TIA,
Denis


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [docbook-apps] Expected PDF output of minimal document - total newbie alert!

[Denis Bradford]

FWIW, here's the docbook2.pdf that I generate using docbook-xsl-1.73.2 
and FO 0.20. I don't think the mail list likes attachments, but the PDF 
is small, so I'll just cat the contents below:


a%PDF-1.3
%ª«¬­
4 0 obj
<< /Type /Info
/Producer (FOP 0.20.5) >>
endobj
5 0 obj
<< /Length 122 /Filter [ /ASCII85Decode /FlateDecode ]
 >>
stream
Gao5a\I*j@&4Ouq^>bC^1ldDqC^!8/V\:Si-6h+;qhA;[EMAIL PROTECTED]>[EMAIL 
PROTECTED];J[%tZdD8?(>ukho`H7pJPRY-:6))MEQi\J/c~>
endstream
endobj
6 0 obj
<< /Type /Page
/Parent 1 0 R
/MediaBox [ 0 0 612 792 ]
/Resources 3 0 R
/Contents 5 0 R
>>
endobj
7 0 obj
<< /Length 152 /Filter [ /ASCII85Decode /FlateDecode ]
 >>
stream
Garo8]*cD?&4QKlMH_F#j32+BB`j7F$.Fa%M9Uc_Rf'mXG(SN3'^+8fk]#g[Sipm6_35R2VaugO8MWB*YSjq44I3;>>3oNegukVL[Uh%O(3eDbN^g4u_m^&*"+8=XV:%D6U+6]Hj$h;M5OAo5lQN,~>
endstream
endobj
8 0 obj
<< /Type /Page
/Parent 1 0 R
/MediaBox [ 0 0 612 792 ]
/Resources 3 0 R
/Contents 7 0 R
>>
endobj
9 0 obj
<< /Length 72 /Filter [ /ASCII85Decode /FlateDecode ]
 >>
stream
Garg^iGoCd.c`?]8EV`edPF]R2`9,A
endstream
endobj
10 0 obj
<< /Type /Page
/Parent 1 0 R
/MediaBox [ 0 0 612 792 ]
/Resources 3 0 R
/Contents 9 0 R
>>
endobj
11 0 obj
<< /Length 257 /Filter [ /ASCII85Decode /FlateDecode ]
 >>
stream
Gb"/c_$\%5%#45!MB"S%fQ9]s>[EMAIL 
PROTECTED],)0#`D)$ME/MBDX]%XX&OnG2T8##.J*b^!Q2s!&3VZ3\fII"D*e?,G_:equ(@Xgr-%<2&[EMAIL 
PROTECTED],A)5PNHs=:Y/5HC[d7T(*FVK_>La)M$(p]P+tcF([EMAIL 
PROTECTED](3q:VQG%c$;6=tZhrscVk/52:W+68?:?^DlMU"WB;[a%'O[C8eq)Nf.^`5cs0H>UZbL;E0$CUf+qT\!\gfes4r5
endstream
endobj
12 0 obj
<< /Type /Page
/Parent 1 0 R
/MediaBox [ 0 0 612 792 ]
/Resources 3 0 R
/Contents 11 0 R
/Annots 13 0 R
>>
endobj
13 0 obj
[
14 0 R
]
endobj
14 0 obj
<< /Type /Annot
/Subtype /Link
/Rect [ 120.0 655.001 180.55 645.001 ]
/C [ 0 0 0 ]
/Border [ 0 0 0 ]
/A 15 0 R
/H /I
>>
endobj
16 0 obj
<< /Length 253 /Filter [ /ASCII85Decode /FlateDecode ]
 >>
stream
GarW49b2h0%#46J'g4mXF^scj.t5E]1YL#t0FC."9S(.WmiR:MtJq48jK%(CT:k:(Si%;:a]h'[qk(-DIBc9S4(f'[>;A=:4oq&TA/j:8kll8h%UMdHVodCT_L6Ni:'n'12bNj>-BIhqAQ`i]QGuZdj]!CMOg=s,D,kqPH%=*%#G)%Li:d?G:e't?HJX#LmCju69:[EMAIL
 PROTECTED],rY8LU_ukT~>
endstream
endobj
17 0 obj
<< /Type /Page
/Parent 1 0 R
/MediaBox [ 0 0 612 792 ]
/Resources 3 0 R
/Contents 16 0 R
>>
endobj
18 0 obj
<< /Type /Font
/Subtype /Type1
/Name /F3
/BaseFont /Helvetica-Bold
/Encoding /WinAnsiEncoding >>
endobj
19 0 obj
<< /Type /Font
/Subtype /Type1
/Name /F5
/BaseFont /Times-Roman
/Encoding /WinAnsiEncoding >>
endobj
20 0 obj
<< /Type /Font
/Subtype /Type1
/Name /F1
/BaseFont /Helvetica
/Encoding /WinAnsiEncoding >>
endobj
1 0 obj
<< /Type /Pages
/Count 5
/Kids [6 0 R 8 0 R 10 0 R 12 0 R 17 0 R ] >>
endobj
2 0 obj
<< /Type /Catalog
/Pages 1 0 R
 >>
endobj
3 0 obj
<<
/Font << /F3 18 0 R /F5 19 0 R /F1 20 0 R >>
/ProcSet [ /PDF /ImageC /Text ] >>
endobj
15 0 obj
<<
/S /GoTo
/D [17 0 R /XYZ 67.0 725.0 null]
>>
endobj
xref
0 21
00 65535 f
002427 0 n
002512 0 n
002562 0 n
15 0 n
71 0 n
000284 0 n
000390 0 n
000633 0 n
000739 0 n
000901 0 n
001008 0 n
001357 0 n
001480 0 n
001507 0 n
002663 0 n
001643 0 n
001988 0 n
002096 0 n
002209 0 n
002319 0 n
trailer
<<
/Size 21
/Root 2 0 R
/Info 4 0 R
>>
startxref
2727
%%EOF



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [docbook-apps] Generating a customized TOC & chunking.

[Denis Bradford]

Two possible starting points using the base DocBook stylesheets:

* Olink databases, if you use olinks. To quote 'Target database 
additional uses' in Chapter 24 of Stayton's book:


"You may find additional uses for the target database that keeps track 
of potential olink targets. The database contains structured information 
about a collection of documents. The information includes the hierarchy 
of division and section elements, with enough information to form links 
to them. You could, for example, generate a master table of contents for 
all of your documents."


I use a sitemap to generate HTML breadcrumbs, for example.

* eclipse/eclipse.xsl (Chapter 24) generates an Eclipse toc and 
manifest. Maybe you could customize that stylesheet.


HTH,
Denis



Paul Norton wrote:

Hi,

First, a brief introduction to what I'm trying to do.

Background: Creating ePub from DocBook
**
I'm trying to build on the DocBook XSL an 'ePub' output. 'ePub' is the
nickname for a set of standards for a reflowable ebook format. The
standards build on XHTML 1.1 and CSS for the content. There is
additional XML for navigaiton and a manifest.

I've created a new instance of the html2xhtml.xsl. I have, at least
against one test, validating XHTML 1.1 from a docbook xml document.

Now, I'm starting on what seems to be the hard part. There's a couple of
extra files that I need to create, one is a toc (it's not in XHTML but
in another XML vocabulary.) The other file I need to add is the OPF
file, which is basically a manifest, a set of metadata, and a listing of
the chapters.

Now my question:
**
How do I use the chunking HTML stylesheets but generate a separate TOC
with a different format (not HTML) and have the links work from the TOC
to the targets inside the chunks? Is the answer in "Customized hrefs"
(in chapter 12 of "DocBook XSL: The Complete Guide"), or is that not the
right direction?


Thanks, 


Paul Norton
[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [docbook-apps] DocBook Markup

[Denis Bradford]

By default, the docbook.xsl HTML stylesheets seem to use tables rather 
than css for some header and list elements. Likewise, CSS class 
attributes are not generated by default as you would need to do what you 
want. You can find some discussion about this in the docbook-apps mail. 
For example, this thread:


http://www.ecos.sourceware.org/ml/docbook-apps/2003-q1/msg00684.html

You might also check the HTML Parameter Reference 
(http://docbook.sourceforge.net/release/xsl/current/doc/html/) for 
parameters that control the generation of tables or CSS support. For 
instance, one or more of these might help you.


Looking through HTML Parameter Reference , I find a bu (I haven't used 
'em, so can't say for sure):


  admon.style — CSS style attributes for admonitions

  annotation.css — CSS rules for annotations

  css.decoration — Enable CSS decoration of elements

  callout.list.table — Present callout lists using a table?

  table.borders.with.css — Use CSS to specify table, row, and cell 
borders?


 segmentedlist.as.table — Format segmented lists as tables?

 variablelist.as.table — Format variablelists as tables?

 make.graphic.viewport — Use tables in HTML to make viewports for graphics

Finally, you may choose to customize a few templates. For example, I 
customized the standard blockquote template like this:





  
  
  

  

  
  

  

  
...

  


Russell Seymour wrote:

Denis,

I want to write DIVs instead of Tables ultimately.  This is where web 
pages are going as there are several problems with tables in HTML.


I am aslo having problems assigning 'class' tags to tables which makes 
the layout difficult.  Using DIV allows mcuh more control through the 
use of CSS.


Russell

Denis Bradford wrote:

Where do you want to generate divs?

I haven't noticed a one-to-one mapping in the docbook HTML 
stylesheets: divs seem to be generated to put structure around all 
kinds of things that don't inherently have structure in HTML. For 
example:


  
title
text
  

  might become:

   
 title
 text
   

The other possible answer is that if you have a customization layer, 
you can make divs appear any place you want.



Russell Seymour wrote:
I have been looking around on the web for a while and the excellent 
www.sagehill.net site but I have been unable to work out what DocBook 
markup can be used that will be converted to a DIV in the HTML output.


Is there such an element that I can use for this?

Thanks, Russell









-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [docbook-apps] chunking at book level

[Denis Bradford]

If you want to build the entire set at once, I'm not sure how to chunk 
at the book level, maybe one of the wise heads here knows. But the usual 
way to get one document per book is to build each book separately, using 
docbook.xsl instead of chunk.xsl.


hth,
Denis

Marie Sauvage - EBM WebSourcing wrote:

Hi all !

For my documentation, I have a set of many books, is it possible to make the 
chunk output splitting at book level to have only one page per book, instead of 
splitting at chapter level ?

I've tried to decrease the chunk.section.depth to 1 or 0 but it has no effect.
Maybe can I do this by customizing a template in the xsl stylesheet but I don't 
find which one, could you help me on that point ?


thanks in advance !
Marie.
- To 
unsubscribe, e-mail: [EMAIL PROTECTED] For 
additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [docbook-apps] refentry or section

[Denis Bradford]

Sorry, I meant to say, the analog of a section is a refsection.

Also, I think a reference can be a good choice for an API, for the 
reason that you guessed: it's designed to give you a regular structure 
that makes information easy to up. I think that's what most people do 
with API docs. Non-reference components (chapters, articles), are less 
restrictive, more suitable (I would argue) for more narrative or 
variable content.





Samuel Wright wrote:

Hi All,

I'm documenting some software apis, and was thinking of using sections
(rather than sect1,2, etc due to possible reuse). Have since sound
references and refentries.

Is the main advantage of using references and refentries that you can
format them in a different manner to sections containing other text?
Is that a strong enough reason to use them? What do you all use for
apis in docbook?

Thanks in advance for any thoughts

S

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [docbook-apps] refentry or section

[Denis Bradford]

I think you're dealing with apples and oranges.

A reference is (I think) designed to be used for reference information, 
often presented in a dictionary-style for easy lookup. A reference is a 
collection of refentries, similar to a book comprising a bunch of 
chapters or articles. In addition to the normal kinds of output like 
HTML and PDF, refentries can also be transformed by the standard docbook 
xsl stylesheets to create man pages.


By contrast, sections are general-purpose modules that might contain any 
kind of information (not just reference info). And they are usually 
smaller in scope - for example an article or chapter might be made up of 
sections. The analog of a section in a referentry is a refentry.


For more (and better) info, see Norm Walsh's  book, 
http://www.docbook.org/tdg/en/html/docbook.html - esp. the chapter on 
Creating Docbook Documents.




Samuel Wright wrote:

Hi All,

I'm documenting some software apis, and was thinking of using sections
(rather than sect1,2, etc due to possible reuse). Have since sound
references and refentries.

Is the main advantage of using references and refentries that you can
format them in a different manner to sections containing other text?
Is that a strong enough reason to use them? What do you all use for
apis in docbook?

Thanks in advance for any thoughts

S

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [docbook-apps] RE: Roundtrip stylesheets how-to?

[Denis Bradford]

Ah, OK. I went through and replaced as suggested - progress transforming 
a small article test doc. Next I worked around these errors:


- dbk2wp.xsl calls doc:make-column, which doesn't exist in dbk200.xsl.
- no templates for listitem/simpara and blockquote/para.

Now I'm generating an output file without errors. Don't
know much about the OpenDocument format, but looks like the
xml component of the .sxw package. Will try to figure out
what to do next to complete this leg of the 'trip' (open in OO).

This is really exciting stuff - it will be huge when it's done!


Steve Ball wrote:

Hi Denis,

OK - those are straight-forward bugs.  Fixed in my working copy and will 
be committed to the repository rsn.  In the meantime, change "text" to 
"content", "sum" to "doc:sum".


Now, the dbk2* stylesheets are new and I haven't had time to write up 
some documentation.  The dbk2wp.xsl stylesheet is a module imported by 
the other dbk2* stylesheets.  You should use dbk2wordml.xsl, 
dbk2pages.xsl or dbk2ooo.xsl depending on which word processor you are 
targetting the output for.


BTW, I'm working on a new system for the reverse conversion that will 
handle OpenOffice.


HTHs,
Steve Ball

On 04/03/2007, at 11:38 AM, Denis Bradford wrote:


Sorry, sent the previous before finished. I meant to say, I tried this:

java com.icl.saxon.StyleSheet -r 
org.apache.xml.resolver.tools.CatalogResolver -x 
org.apache.xml.resolver.tools.ResolvingXMLReader

-o hr-resume.sxw
hr-resume-docbook.xml
roundtrip/dbk2wordml.xsl

Got this result:

Error at xsl:value-of on line 688 of 
file:/opt/xml/xsl/docbook-xsl-1.72.0/roundtrip/dbk2wp.xsl:

  Variable text has not been declared
Error at xsl:value-of on line 702 of 
file:/opt/xml/xsl/docbook-xsl-1.72.0/roundtrip/dbk2wp.xsl:

  Variable text has not been declared
Error at xsl:call-template on line 549 of 
file:/opt/xml/xsl/docbook-xsl-1.72.0/roundtrip/dbk2wp.xsl:

  No template exists named sum
Error at xsl:with-param on line 796 of 
file:/opt/xml/xsl/docbook-xsl-1.72.0/roundtrip/dbk2wp.xsl:

  Duplicate parameter name
Transformation failed: Failed to compile stylesheet. 4 errors detected.

I have an idea that I need to do something with one of the templates -
is that what I'm missing?



 Original Message ----
Subject: Roundtrip stylesheets how-to?
Date: Sat, 03 Mar 2007 19:14:08 -0500
From: Denis Bradford <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: docbook-apps@lists.oasis-open.org
References: <[EMAIL PROTECTED]>

Is there a description of the basic usage of the roundtrip stylesheets?
Forgive me if it's there - I have looked.

Failing that, maybe someone who's done it can steer me straight: for
starters, how about transforming a DocBook article to OpenOffice?



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[docbook-apps] RE: Roundtrip stylesheets how-to?

[Denis Bradford]

Sorry, sent the previous before finished. I meant to say, I tried this:

java com.icl.saxon.StyleSheet -r 
org.apache.xml.resolver.tools.CatalogResolver -x 
org.apache.xml.resolver.tools.ResolvingXMLReader

-o hr-resume.sxw
hr-resume-docbook.xml
roundtrip/dbk2wordml.xsl

Got this result:

Error at xsl:value-of on line 688 of 
file:/opt/xml/xsl/docbook-xsl-1.72.0/roundtrip/dbk2wp.xsl:

  Variable text has not been declared
Error at xsl:value-of on line 702 of 
file:/opt/xml/xsl/docbook-xsl-1.72.0/roundtrip/dbk2wp.xsl:

  Variable text has not been declared
Error at xsl:call-template on line 549 of 
file:/opt/xml/xsl/docbook-xsl-1.72.0/roundtrip/dbk2wp.xsl:

  No template exists named sum
Error at xsl:with-param on line 796 of 
file:/opt/xml/xsl/docbook-xsl-1.72.0/roundtrip/dbk2wp.xsl:

  Duplicate parameter name
Transformation failed: Failed to compile stylesheet. 4 errors detected.

I have an idea that I need to do something with one of the templates -
is that what I'm missing?



 Original Message 
Subject: Roundtrip stylesheets how-to?
Date: Sat, 03 Mar 2007 19:14:08 -0500
From: Denis Bradford <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: docbook-apps@lists.oasis-open.org
References: <[EMAIL PROTECTED]>

Is there a description of the basic usage of the roundtrip stylesheets?
Forgive me if it's there - I have looked.

Failing that, maybe someone who's done it can steer me straight: for
starters, how about transforming a DocBook article to OpenOffice?



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]