Re: [docbook-apps] Canonical DocBook

[David Cramer]

On 2/27/22 1:18 PM, Frank Steimke wrote:


/No block Elements within para/

That's in my 80% because neither ODF nor OOXML do allow tables or 
lists in paragraphs. I would see a great benefit when the DocBook 
based structural interchange format would allow easy transformation 
into office Standards, especially ODF.


You potentially lose information by doing that. For example, when 
normalizing, profiling and other attributes on the enclosing table would 
need to be copied to the paras you create before and after the table or 
list and onto the table or list itself as well. But doing so might 
change the author's intent in subtle ways depending on what job those 
attributes are doing.


I guess this is Norm's point about everybody having a different 80%.

Regards,

David

Re: [docbook-apps] DocBook Latin support works

[David Cramer]

Looks like it goes back 19 years (or more). Author is one Pablo Rodriguez:

https://github.com/docbook/xslt10-stylesheets/blob/master/gentext/locale/la.xml

Regards,

David

On 10/25/21 2:59 PM, Pc Thoms wrote:

Don't know who to thank but, I inserted xml:lang="la" as follows:

http://docbook.org/ns/docbook;
        xmlns:xi="http://www.w3.org/2001/XInclude;
        xmlns:xlink="http://www.w3.org/1999/xlink; version="5.0" 
xml:lang="la">


obviously Latin text, and voila, the spelling of the text checks out.
Amazing!
Thanks to whoever! Paul


-
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] Creating Styles for an Attribute

[David Cramer]

On 9/11/21 3:10 AM, Bob Stayton wrote:
>
> It's main limitation is that it only is applied to text nodes in your
> XML document, and so would not color generated text (like "Note" or
> xrefs) or any rule lines.  If you can live with that limitation then
> this is a simple solution.
>
And if you still need to be convinced that this simple solution is the
way to go, study the code that generates tables and contemplate
overriding every template until it does what you want :-)

Bob, would it handle the xrefs too by matching them, wrapping them in
the fo:inline/span, and then doing the apply-imports? Or would that
break the xref mechanism?


  
    
  


Regards,

David


-
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] saxon6:output for running DocBook 1.0 xslts using Saxon 9.9

[David Cramer]

I just stumbled on this (haven't tried it out yet though). It could be
I'm the last to hear about it, but I thought I'd post it just in case.
If you wanted to use your existing customization layer with Calabash,
for example, now you can :-)

https://www.saxonica.com/html/documentation/extensions/instructions/output.html

"The instruction is a synonym for xsl:result-document. Historically,
support for multiple output documents was first introduced as a Saxon
extension to XSLT 1.0 in the form of the saxon:output instruction. Other
vendors followed suit, and the idea was eventually standardized in XSLT
2.0 under the name xsl:result-document. The DocBook 1.0 stylesheets,
however, remain in widespread use, and include calls on saxon:output. It
is often difficult for users to move forwards because they have written
their own DocBook customization layers; as a result, many users have
been locked into Saxon 6.5.5 which is now obsolete and no longer maintained.

Saxon 9.9 reintroduces saxon6:output (in the original Saxon 6.5.5
namespace, which differs from the usual Saxon namespace, so here we use
a different prefix) so that the DocBook 1.0 stylesheets can now be
executed with a modern Saxon release. Note that the specification is not
identical with the Saxon 6.5.5 original, but it serves the purpose in
supporting DocBook. The main difference is that in Saxon 6.5.5, the
attribute saxon:output/@href was interpreted as a filename (not a URI)
relative to the current working directory."

Regards,
David

-
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] Google "Season of Docs"

[David Cramer]

Back when we mentored those Summer of Code projects, I always thought
they should do something similar for docs. Now they are:

https://opensource.googleblog.com/2019/03/introducing-season-of-docs.html

Regards,

David

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

Re: [docbook-apps] DocBook content review process/tools?

[David Cramer]

Hi Peter,

Good question. Here are a few ideas:

* Add a "Log a bug" link to each page that links to your bug tracking
system. It's usually easy to add a few query parameters that prepopulate
the new bug with contextual information (url, version, component, build
date, etc). Then the users only has to fill in a description and title.
With some more effort, you could add some code that queries the bug
tracking system and displays a list of open bugs against a give
chapter/section at the bottom of the page.

* Add some kind of commenting mechanism to the output. That
annotatorjs.org thing that Camille pointed out looks cool. I'm going to
have to check that out. Oxygen has a Webhelp with feedback chunked html
format. If security isn't a concern, then there are solutions like
Disqus that will add commenting to a page with just a little JavaScript.
Or there are open source and commercial commenting systems, usually
php-based, you can host.

* Oxygen XML has a "Content Fusion" product. I've only ever read the web
page and played with their online demo, but it uses a web-based version
of Oxygen to let users enter changes with track changes on. This looks
really cool, but if some of your content is generated programmatically
from more primitive sources, then you'd have to adapt the workflow to
merge changes to that content back into its original source.

* If pdf is your primary output format, Adobe has a feedback collection
system. I believe Acrobat Pro has to be involved. Perhaps this could be
automated if you produce postscript from your fo renderer and generate a
pdf from that using Acrobat Pro?

Regards,
David

On 10/23/18 11:53 AM, Peter Desjardins wrote:
> Hi! Does anyone have a document content review process you can
> recommend? One that allows non-DocBook users to easily provide input
> and see each other's comments?
> 
> My team uses Google docs for content review because reviewers can
> comment easily and see each other's input (this is at a company that
> uses Google email/docs). It's error-prone and tedious to transform
> DocBook content to Google documents though. I would love to find a
> better solution.
> 
> We keep content in GitHub and I love the pull request content review
> tools there. Most of our subject matter experts do not use GitHub
> though, and it's not practical to review all DocBook content by
> reading the source XML.
> 
> The conversion to Google doc format that works the best for us (so
> far) is DocBook > HTML > LibreOffice OpenDocument > Upload to Google
> drive and convert to Google doc format. We lose important formatting
> like bold for guilabel elements and bullet characters for
> itemizedlists disappear. Preparing a document for review is painful.
> 
> Do you have a great DocBook-based review process?
> 
> Thanks!
> 
> Peter
> 
> -
> To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
> 
> 

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

Re: [docbook-apps] Using the DocBook XSLT 2.0 stylesheets with Gradle

[David Cramer]

On 3/5/18 11:33 AM, Dave Pawson wrote:

ant lets me pick / choose bits|all
Am I odd? Minority? Majority?


You are very odd Dave, but don't change the subject ;-)

In my case a couple of toolchain developers (minority) support a large 
number of authors (majority). The tools developer's job is to make it so 
the authors can create content without knowing much about the magic that 
turns that into pdf/html/xml artifacts. A system for managing 
dependencies like gradle+maven artifacts makes it easy to roll out 
changes without breaking existing doc builds and to hide lots of 
complexity from users.


Of course they need to understand enough to create correct markup, but 
few if any of my authors will ever subscribe to this list, but they're 
still DocBook users.


Regards,
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] Using the DocBook XSLT 2.0 stylesheets with Gradle

[David Cramer]

On 3/5/18 10:14 AM, Dave Pawson wrote:

I got as far as ant for builds. I can understand most of that.

Bash script... similar? Maybe

gradle? Wozzat.

Why make it deeper than needs be?


Dave,

The idea is to make it super easy for someone (e.g. an author) who just 
wants to build the doc. They don't want to install a ton of stuff _at 
the right version_ and keep track of it.


From an end-user's perspective, setting up the whole tool chain and 
building the doc at most three steps:


# You only have to do this once (or use apt-get/yum or whatever windows
# users do to install software):
brew install gradle

# Get DocBook xml source from whatever source control system
# it lives in...
git clone  && cd somedoc

# This installs the DocBook toolchain and builds the doc:
gradle somedoc

Even as new versions of the underlying tools come out, "somedoc" 
continues to build because your gradle file indicates what versions it 
depends on. However, you easily can switch to newer versions if you need 
to.


Regards,
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] Specific chunk.section.depth on one section

[David Cramer]

I'm pretty sure webhelp will work like any other chunked output. Even 
for toc generation, I think it relies on hooks that were in the xsls to 
find the file names etc.


Regards,

David


On 1/18/18 12:00 PM, Bob Stayton wrote:
A related approach that uses the same mechanism is to write a custom 
stylehsheet that generates a manual toc file from the document, and by 
setting role attributes or using other match criteria you can handle 
your special cases.  Typically that would add an extra step to your 
processing, but not necessarily.  It is possible to generate such a 
file in your main customization the way the olink database is updated 
before the content is processed.


I'm just not sure if Webhelp will follow the manual toc in all aspects 
of processing.


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

On 1/18/2018 8:44 AM, Mats S. E. Broberg wrote:

Hi,

Thanks. I looked at that one, but as it says,

"... since it requires hand editing of a generated table of contents 
file, it is only useful if done infrequently or with documents that 
have stable structure."


I didn't think it would work well. My doc is updated every other day 
and the content continously expands.


Kind regards,
Mats Broberg


On 01/18/2018 11:26 AM, Kasun Gajasinghe wrote:

Hi Mats,

Webhelp uses the default chunking behavior that comes with Docbook. 
I checked the chunking docs at [1]. It seems your requirement can be 
addressed by a manually edited table of contents file. [1] The 
chunk.section.depth param will be ignored, and the chunking will 
happen with the given toc file.


We however should check how this works with Webhelp though. 
Especially the Table of Contents in the left pane.



[1] http://www.sagehill.net/docbookxsl/Chunking.html#ManualChunking


On Thu, Jan 18, 2018 at 2:46 AM, Mats S. E. Broberg 
> wrote:


    Greetings,

    I have a (frequently updated) document (DocBook 5.0 'article') that
    I publish to WebHelp and PDF. For the WebHelp version
    chunk.section.depth is set to 1.

    However, one particular (top level) section contains subsections
    with so many images that I want that section to have a
    chunk.section.depth set to 3.

    Is this at all possible?

    Thanks in advance.

    Kind regards,
    Mats Broberg

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

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




--
~~~***'***~~~
*Kasun Gajasinghe*
Senior Software Engineer; WSO2 Inc.; http://wso2.com 
,

/Linked-in: /http://lk.linkedin.com/in/gajasinghe/
/
/Blog: //http://blog.kasunbg.org/ 
/
GitHub: //http://github.com/kasunbg/


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





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





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

Re: [docbook-apps] Specific chunk.section.depth on one section

[David Cramer]

Another option (that I don't see mentioned in Bob's book) would be to 
set the chunking depth very deep and then disable it using the stop-chunking?> processing-instruction in most cases:


http://docbook.sourceforge.net/release/xsl/1.79.1/doc/pi/dbhtml_stop-chunking.html

Regards,

David


On 1/18/18 4:26 AM, Kasun Gajasinghe wrote:

Hi Mats,

Webhelp uses the default chunking behavior that comes with Docbook. I 
checked the chunking docs at [1]. It seems your requirement can be 
addressed by a manually edited table of contents file. [1] The 
chunk.section.depth param will be ignored, and the chunking will 
happen with the given toc file.


We however should check how this works with Webhelp though. Especially 
the Table of Contents in the left pane.



[1] http://www.sagehill.net/docbookxsl/Chunking.html#ManualChunking


On Thu, Jan 18, 2018 at 2:46 AM, Mats S. E. Broberg 
> wrote:


Greetings,

I have a (frequently updated) document (DocBook 5.0 'article')
that I publish to WebHelp and PDF. For the WebHelp version
chunk.section.depth is set to 1.

However, one particular (top level) section contains subsections
with so many images that I want that section to have a
chunk.section.depth set to 3.

Is this at all possible?

Thanks in advance.

Kind regards,
Mats Broberg

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

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





--
~~~***'***~~~
*Kasun Gajasinghe*
Senior Software Engineer; WSO2 Inc.; http://wso2.com ,
/Linked-in: /http://lk.linkedin.com/in/gajasinghe/
/
/Blog: //http://blog.kasunbg.org/ 
/
GitHub: //http://github.com/kasunbg/

Re: [docbook-apps] REST API description

[David Cramer]

I don't think DocBook is the right vocabulary for modeling a REST API. 
There's an XML schema, WADL (Web Application Description Language) that 
is designed for that: 
https://en.wikipedia.org/wiki/Web_Application_Description_Language I 
would suggest putting the API specification in WADL and converting it to 
DocBook to combine it with your other content.


WADL includes features that let you reuse content, but all that reuse 
can make it difficult to parse. wadl-tools includes xslts that will 
flatten out the wadl. Do that first and converting it to DocBook will be 
much more straightforward:


https://github.com/rackerlabs/wadl-tools

You can see an example of that approach here:

https://github.com/rackerlabs/clouddocs-maven-plugin

If you need a proxy for your API, check out Repose: 
http://www.openrepose.org/ That wadl-tools stuff was developed in 
support of Repose. For more information, see this Balisage paper:


https://www.balisage.net/Proceedings/vol8/html/Williams01/BalisageVol8-Williams01.html

These days non-xml vocabularies for modeling REST apis are more popular. 
Each has its own strengths and weaknesses, depending on your needs.


https://swagger.io/

https://raml.org/

Regards,

David


On 12/5/17 2:23 PM, Jan Tosovsky wrote:

Dear All,

is there any recommended DocBook tag set for describing REST API?

My current structure is depicted in http://drifted.in/other/docbook/rest.png

I use common elements like sections, simplesects, tables, programlistings,
tips, but not sure what vocabulary use for URL fragments (1) or parameter
descriptions (3, 4).

(1) uri
(2) synopsis
(3, 4) informaltable

I especially don't like (3, 4) as tables are quite heavy/complex objects for
kind of variablelist with headers, which could be even auto-generated using
localized resources.

Any thoughts?

Thanks,

Jan


-
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] Pure JS WebHelp

[David Cramer]

On 4/16/17 9:46 AM, Jan Tosovsky wrote:
> as promised, I've published a demo output
> https://www.bilyujezd.cz/beta/strucna-historie.html 

Wow, that looks great! It was in need of a refresh. Frontend stuff grows
stale quickly.

> Weaknesses:
> - only modern browsers are supported (Chrome, FF, Edge, IE10+)

That's not a weakness ;-)

...

> - no out-of-the-box scripts for copying dependencies to the target
> destination

It was always tricky to maintain those. Everybody needs something
different and there's no clean "customization layer" mechanism like with
xslt. It is nice to provide something that 'just works out of the box',
and at least something that builds sample output as a test for each
build though.

> Should I put related XSL files and resources to my GitHub account or
> directly to some DocBook sandbox?

I'm sure if you do a PR, others will jump in and help you finish the
integration. It sounds like the format still meets a need for several users.

Regards,
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] [WebHelp] Language support for search

[David Cramer]

On 6/22/16 1:31 PM, Jan Tosovsky wrote:
> looking into the language support I can see only en/es/jp stopwords and
> de/en/fr stemmers:
> 
> http://snapshots.docbook.org/xsl/webhelp/template/search/
> 
> Has anybody implemented additional ones?
> 
> In foreseeable future I'd like to cover also pt/it/cs/nl. I have some ideas,
> based on lucene analyzers, but why not use something existing ;-)

Hi Jan,

Your post prompted me to look at the Porter stemmer site to see if other
stemmers had been implemented in JavaScript:
http://snowball.tartarus.org/otherlangs/index.html

While there, I noticed a link to the Urim project which appears to have
a number of stemmers in JavaScript:

https://code.google.com/archive/p/urim/
https://github.com/mazko/jssnowball

Perhaps those could be adapted to work in webhelp.

Regards,
David

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

Re: [docbook-apps] DocBook Wiki

[David Cramer]

We were having problems with bots creating accounts programmatically in
an attempt to spam the wiki. These new accounts couldn't edit pages, but
the mere act of creating the accounts was bringing it to its knees. I
disabled account creation "temporarily". Camille Bégnis generously spent
some time working turning on the captcha mechanism but I never got
around to replacing the existing wiki with the one he modified. I'll try
to do that this evening.

https would be cool. Do we have a wildcard cert for *.docbook.org? Once
letsencrypt.org gets going, we could use that. If someone wants to
migrate to mediawiki, I'm happy to spin up a vm for you to work with.

Regards,
David

On 9/16/15 2:37 PM, Jan Tosovsky wrote:
> Dear All,
> 
> recent discussion touched various parts of DocBook workflow. In my opinion
> it could be helpful to convert some ideas into dedicated wiki articles or
> update current ones.
> 
> http://wiki.docbook.org/
> 
> I've tried to create a new account, but I got an error related to
> 'newaccount' action. Is the access somehow limited or there is some problem
> with the engine itself?
> 
> Thanks, Jan
> 
> Btw, how about running it on https or switching to mediawiki?
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
> 


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

Re: [docbook-apps] DocBook Wiki

[David Cramer]

I attempted switching to the instance that has the text captcha turned
on, but notice that on that instance, I'm unable to log in (the server
never responds when I try). I've asked Camille to take a look since he
was working on it last.

Regards,
David

On 9/16/15 4:07 PM, David Cramer wrote:
> We were having problems with bots creating accounts programmatically in
> an attempt to spam the wiki. These new accounts couldn't edit pages, but
> the mere act of creating the accounts was bringing it to its knees. I
> disabled account creation "temporarily". Camille Bégnis generously spent
> some time working turning on the captcha mechanism but I never got
> around to replacing the existing wiki with the one he modified. I'll try
> to do that this evening.
> 
> https would be cool. Do we have a wildcard cert for *.docbook.org? Once
> letsencrypt.org gets going, we could use that. If someone wants to
> migrate to mediawiki, I'm happy to spin up a vm for you to work with.
> 
> Regards,
> David
> 
> On 9/16/15 2:37 PM, Jan Tosovsky wrote:
>> Dear All,
>>
>> recent discussion touched various parts of DocBook workflow. In my opinion
>> it could be helpful to convert some ideas into dedicated wiki articles or
>> update current ones.
>>
>> http://wiki.docbook.org/
>>
>> I've tried to create a new account, but I got an error related to
>> 'newaccount' action. Is the access somehow limited or there is some problem
>> with the engine itself?
>>
>> Thanks, Jan
>>
>> Btw, how about running it on https or switching to mediawiki?
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
>> For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
>>
> 
> 
> -
> To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
> 


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

Re: [docbook-apps] [WebHelp] Incorrect initial scroll to anchor in Chrome

[David Cramer]

On 10/27/14, 1:04 PM, Jan Tosovsky wrote:
...
 While target offset is -195 in FF, it is 2200 in Chrome. The required anchor
 is not scrolled precisely to its location, but ca 300 px towards the bottom.
 However, on page reload it is sometimes correct, sometimes more or less than
 the initial value. This inconsistency is really weird.
 
 I've found several threads mentioning incorrect Chrome behaviour when
 determining offset top value on StackOverflow, but it is not very clear to
 me if this is our case.
 
 Has anybody any experience with this or fix?

As you've noticed, that code is trying to compensate for the fact that
there's a fixed header and links to anchors in a page would otherwise
appear under the fixed header (i.e. at the top of the window). I've
recently come across a better solution to that problem that uses only
css. It goes something like this (assuming you're linking to a/ tags
and assuming a header-height of 195px):

  a:before {
  display: block;
  content:  ;
  margin-top: -195px;
  height: 195px;
  visibility: hidden;
  z-index: -1;
}

Adjust the selector as needed if the links are to div tags or whatever.
In the case of the DocBook xslts, I think a and div tags that have id
attributes would be the right things to add this rule to.

This strategy is much easier to maintain if you're using sass/scss
because you can use variables, defining $header-height in one place and
then reusing it to define the height of the header and the offests in
rules like this.

My suggestion would be to rip out the javascript and move to a solution
like this.

Regards,
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] Thanks!

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I'd suggest finding common solutions to the major issues and
contributing back to the distribution so you can avoid fixing the same
problems in different ways and having to maintain those in your own forks.

Maybe start with some discussion here and based on your conclusions log
bugs and feature requests in the issue tracker. Patches are welcome and
if you want to be more deeply involved you could become a contributor.

I'm happy that people are finding webhelp useful, but I'm not using it
in my current role so I haven't paid too much attention to it lately.

I think starting off with some general discussion about goals would be a
good place to start. For example, is it important that it work from the
file system? That places some constraints on what you can do (e.g. no
lazy loading of the toc).

What are the main frustrations? One of mine would be that the way the
toc works bloats the pages for large books.

Should other options for search be provided? E.g. you could replace the
javascript search with a Google site search. Believe it or not, all the
books in the API Documentation portion of this site is actually
webhelp (it's my former employer and I was involved in the implementation):

http://docs.rackspace.com/servers/api/v2/cs-gettingstarted/content/overview.html

The header and footer is provided from a single location as a service
and pulled in to each page with some javascript and the search is
powered by a google custom search.

Just to give you ideas of what's possible.

Regards,
David

On 9/5/14, 3:19 AM, Barton Wright wrote:
 Hi Mary,
 
 Ditto what Nat said. 
 
 Thanks!
 ~Barton Wright
 
 
 Hi Mary,

 I'd be interested in your solutions to your webhelp issues. I've currently 
 got webhelp in beta, with HTML and PDF in production. I've come across a 
 number of webhelp issues and I'm not happy with this format yet.

 Nat

 On 5/09/2014, at 1:35 pm, Mary Tabasko taba...@telerama.com wrote:

 Hi, gang.

 I just joined this list, and I wanted to start off by offering
 a HUGE thanks to everyone who maintains the DocBook Stylesheets
 and the related resources.

 (I accidentally sent this message to the docbook list; this is a resend
 to the right address.)

 We have been using them where I work for years, and we would
 not be able to do the things we've done without them! Over the
 years, I've been asked to do some things that I was not sure would
 be possible, but the stylesheets have provided a terrific basis for
 a bunch of crazy things.

 So thanks!

 We are just finishing up a project to move some large documents
 we produced as Microsoft Help (CHM) output to the Webhelp format.
 We've been trying to replace MSHelp (the compiler is getting harder
 and harder to keep running), but were having no luck finding a suitable
 replacement, until we stumbled on the Webhelp transforms.

 We did run into some non-trivial issues and ended up doing a fair
 amount of work to get what we wanted, but we got very close
 to our wishlist, and it wouldn't have been possible without the
 Webhelp transforms. So thanks again.

 I didn't want to dump a long list of the issues we had and
 how we dealt with them, but if anyone is interested, I'd be
 happy to describe them (and send a screen shot of what we
 ended up with). Some of it might be useful or informative
 in relation to a few of the bug/issue reports I've seen on them,
 but I don't want to offer unsolicited input.

 Thanks again! You guys rock!

 -- Mary Tabasko

 -
 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/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJUCdC+AAoJEMHeSXG7afUhp5oIAJpJQ1cia5MjW4rMsJ5LT63U
pHkwHwVnmDVbtR7XYCFEvwhXILrwUpaSXiwj56lgev4ZFv9MeJ4F4I6D1VDJY0bd
XyNxlHS/mgWfCA1xwG8LDNKlAO5a2Gu1b9gitCa36Mgk1sOo/kR4cfaaFrZy/sLp
GpF3j0v7RFjgt+IwUcBHp+r97OVliVLeXKBa9oqb9ULgOemUZVyQ18O9WWZPA+wF
tOxSSud51oO+Mif5zZPg9WR+ZXaCJCx+RTD27ZUPg5hDtELA4ob67ksitDwZEgCm
9vwG+JdNJhQg7z4aNTH54Qkhag1Hq03VSHriADCLNIkze/BHrVXvpcmilFefC0k=
=OCYX
-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

Re: [docbook-apps] Thanks!

[David Cramer]

On 9/5/14, 10:03 AM, David Cramer wrote:
 Should other options for search be provided? E.g. you could replace the
 javascript search with a Google site search. Believe it or not, all the
 books in the API Documentation portion of this site is actually
 webhelp (it's my former employer and I was involved in the implementation):
 
 http://docs.rackspace.com/servers/api/v2/cs-gettingstarted/content/overview.html
 
 The header and footer is provided from a single location as a service
 and pulled in to each page with some javascript and the search is
 powered by a google custom search.

Btw., the webhelp there is generated from the following build
systems/customization layers if you wanted to dig into the code for
inspiration:

https://github.com/stackforge/clouddocs-maven-plugin
https://github.com/rackerlabs/olink-maven-plugin

The header-as-a-service code was never made public, but more due to not
getting around to making it public than an unwillingness to share.

Regards,
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] Fwd: Thanks!

[David Cramer]

On 9/5/14, 4:20 AM, Thomas Schraitle wrote:
 With olinks you don't need a set necessarily and performance issues
 are also not important. I guess Webhelp does support olinks too as it is
 derived from the HTML stylesheets. However, I'm not sure, so you better
 try it out. 

We used olink with webhelp when I was at Rackspace. We weren't
exercising every feature of olink however (and I can't remember the
details).

Regards,
David

-
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] id fixup with prefix

[David Cramer]

I'm adding support for the id fixup mechanism [1, 2] in the
clouddocs-maven-plugin [3]. To my mind, the most common use case (aside
from no fixup at all) will be to specify a prefix with global linkscope:

xi:include
href=foo.xml
db:idfixup=prefix
db:idprefix=second-
db:linkscope=global/

The example xslt already treats global as the default linkscope [1]. If
the user specifies a db:idprefix attribute, it seems redundant to need
to specify db:idfixup=prefix as well. I'd like to make it so that you
can just specify the db:idprefix, omitting db:idfixup since that's
implied already:

xi:include
href=foo.xml
db:idprefix=second-/

Likewise, it should be an error to set db:idfixup to none, strip, or
auto and also to set a db:idprefix. Does that make sense?

Regards,
David

[1] https://github.com/docbook/transclusion-fixup
[2] http://docbook.org/docs/transclusion/2010-12-09/transclusion.html#d6e179
[3] https://github.com/stackforge/clouddocs-maven-plugin

-
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] id fixup with prefix

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 6/17/14, 10:12 AM, Jirka Kosek wrote:
...
 That sounds reasonable. I should update spec and sample code to
 use XInclude 1.1. I was waiting for XInclude 1.1 implementations
 before doing this. I will not be able to attend tomorrow telcon,
 but please feel free to assign my action item to prepare new
 transclusion spec based on XInclude 1.1.

FYI: https://github.com/docbook/transclusion-fixup/pull/3

Regards,
David


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJToP/9AAoJEMHeSXG7afUhLVUH/jYtRDK5AuORjpLnjyJXQoms
t2FooBSRZ/mldcFVE09u8uNIFJIWeUS3bOdWHF/+YnGXJcH8E66/WqtfTUKhO8Vo
oOQdiB6+kQ+7aA7GQNiKBANps83jrzmJmU+k4CN46b0sAzY4yyKqBwx66wgHqEEO
PxypeQxjCNsSOpuXSEnYsxwUtAawB8lyuzprnIDGpFIYysIjwoOc60woExy+xKsB
fAp2ygN/EU4vl/xNFNKgj1dyj3YxbVnzA6QFiglLspuaOmGxbkJgmS3FrkjTWiJ2
oF9/Hw/zk2LekI+wkQjwoXIvA7BxFbXCIT3cS4r7Powxt8LGOoob7J9dW4UsAxo=
=pVuM
-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

Re: [docbook-apps] Profiling with Webhelp

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 4/10/14, 8:13 AM, Jirka Kosek wrote:
 On 10.4.2014 9:54, Fritsch, Michael wrote:
 So, can anyone tell me please which style sheets  I have to
 import and how the import statement has to look??
 
 It might be possible copy content of webhelp.xsl into your
 stylesheets and change imports here to use profiling. But it might
 be necessary to adopt additional templates. I think the easiest is
 to use two pass profiling -- ie. do first separate profiling step
 and then use normal webhelp.

It should work like single pass profiling with chunking but you'll
need to modify profile-chunk.xsl so it imports webhelp.xsl instead of
docbook.xsl.

David


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTRqanAAoJEMHeSXG7afUhwgQH+wSZTCvqb5p5P4RxZ1kCwO7Q
tqL4e3QOQZGolKQ2chzEhFCnaRvs00iOORDtUyBZNCECg4tGVvMeuSI/3bLvhGDp
ZLJ3JDhrPXn18vsgQxYBDDyEhHCWaxx1OGz9IcFp2ZTRH6N4hhRYTvZyvhA5/OeK
3OKG0FryoId5hAosz2gzFC+vkcGlt2PNkLFI3D193OJrzC8vw7VWU65hIZKDPVb6
DESQ7+sJ51/cYWwKPaY6C3qFEYgrBG/8op5bEdVZr+iA2yDyDPusKa/fl7/UgRqv
HqAqOIsJpy16KWSDOYGrowk5fY6een69KIEFTrtLqiazSIFygIM9ggNDwywDmCQ=
=L/j5
-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

Re: [docbook-apps] DocBook-XML, webhelp and no more DTM-Ids available

[David Cramer]

On 03/26/2014 04:56 AM, Volker Bernhard Duetsch wrote:
 can anyone please test the attached files. I'm not sure if it's the setup 
 of the machine or the document structure...
 
   pass.xml - fine result, everything works as expected
 
   failed.xml - won't work. Only one table row more as pass.xml...

Adding that one more row causes the no more DTM-Ids available error?
Strange indeed.

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] Expose profile attributes

[David Cramer]

On 03/18/2014 06:54 PM, Nordlund, Eric wrote:
 Hi, sorry if this is a repeat message, I sent it a few hours ago and I
 still haven’t seen it on the list yet.

Hi Eric,
One approach would be to match text nodes that have an ancestor with the
desired attribute. The following example adds a span class=remark
around all text that has an ancestor element with role=highlight. I
then use css to add the yellow highlight to .remark:

xsl:template match=text()[ ancestor::*/@role = 'highlight' and
not(ancestor::d:programlisting) ] | xref[ ancestor::*/@role =
'highlight' and not(ancestor::d:programlisting)] priority=10span
class=remarkxsl:apply-imports//span/xsl:template

You would add this to your customization layer.

This can add a bunch of spans, but does the job without needing to muck
around in a bunch of templates.

Regards,
David

 — 
 Hello, I have a user guide that I am adding new features to and I want
 to signal the new content with a background color (like a light green or
 something like that).
 
 Since all of the content for this feature is profiled with the
 “revision” attribute, I thought a smart way to do this would be to send
 the revision value through as a class and then add a css rule for the
 class, such as:
 
 .feature-x {
 background-color: green;
 }
 
 I think I should modify this template here:
 
 xsl:template match=* mode=common.html.attributes
 xsl:param name=class select=local-name(.)/
 xsl:param name=inherit select=0/
 xsl:call-template name=generate.html.lang/
 xsl:call-template name=dir
 xsl:with-param name=inherit select=$inherit/
 /xsl:call-template
 xsl:apply-templates select=. mode=class.attribute
 xsl:with-param name=class select=$class/
 /xsl:apply-templates
 xsl:call-template name=generate.html.title/
 /xsl:template
 
 
 But I can’t seem to figure out what to put there that works for profiled
 and non-profiled content without stripping the actual class value that
 should be there.
 
 
 Am I thinking about this the right way, or is there an even easier wa to
 do what I want to accomplish?
 
 
 Thanks a bunch in advance,
 
 
 Eric
 


-
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] wiki.docbook.org down

[David Cramer]

On 03/09/2014 07:59 AM, Peter Eisentraut wrote:
 http://isup.me/wiki.docbook.org
 
 Is anyone looking into this?

I just restarted apache and it seems to be back up (for now).

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] Re: docbook webhelp format: missing image file?

[David Cramer]

Sorry.  Haven't had a chance to look into this. It may well be cruft in the css.

David

Typed wtih thmubs. 

 Original message 
From: natk nkers...@gmail.com 
Date:02/26/2014  6:53 PM  (GMT-06:00) 
To: DocBook Apps docbook-apps@lists.oasis-open.org 
Subject: [docbook-apps] Re: docbook webhelp format: missing image file? 

Just wondering if anyone else is using the webhelp output format, and has 
encountered this problem?

Nat 


On Tue, Feb 25, 2014 at 2:35 PM, natk nkers...@gmail.com wrote:
I am generating webhelp format, and I've noticed that 
breadcrumb-arrow-white.png is missing from the docbook stylesheets (version 
1.78.1 via the docbkx-maven-plugin). Should it be there, or am I missing 
something? (The image is referred to by positioning.css)

Nat 

Re: [docbook-apps] Fitting tall images in PDF

[David Cramer]

Hi Mark,
I'd edit the fo and run it through your fo processor to confirm that
scale-down-to-fit gives the result you want.

For production you'll want to customize the templates from graphics.xsl
to make the right stuff come out in the fo. In particular the templates
xsl:template name=image.content.width and xsl:template
name=image.content.height are important.

Really this should be a feature of the stock xslts though.

Regards,
David

On 01/05/2014 03:58 AM, Mark Craig wrote:
 Thanks Bob and David,
 
 What's the right way to pass the scale-down-to-fit attribute value
 into the FO?
 
 I've tried adding them as attributes on imagedata with some XSL that I
 was using before to handle wide images. Here's the template where
 xmlns:db=http://docbook.org/ns/docbook; exclude-result-prefixes=db:
 
  xsl:template match=db:imagedata
   xsl:element name=imagedata namespace=http://docbook.org/ns/docbook;
xsl:apply-templates select=node()|@*/
xsl:attribute name=contentdepthscale-down-to-fit/xsl:attribute
xsl:attribute name=contentwidthscale-down-to-fit/xsl:attribute
xsl:attribute name=aligncenter/xsl:attribute
   /xsl:element
  /xsl:template
 
 After this transformation and running the stylesheets,
 text-align=center shows up in the resulting .fo, but the others are
 null: content-width= content-height=.
 
 Is there a stylesheet customization I should apply to allow those
 attribute values to pass through to the FO?
 
 Or do I need to edit the FO after it gets generated?
 
 Regards,
 Mark

-
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] Fitting tall images in PDF

[David Cramer]

On 01/06/2014 11:58 AM, Bob Stayton wrote:
 Really this should be a feature of the stock xslts though.
 
 Indeeed, Antenna House also supports it since version 6.  Any
 suggestions about how to fit this feature into the XSL? Here are some
 requirements that I see:
 
 1.  It needs to support scale-up-to-fit values as well, and both
 values supported on either content-height or content-width.

I suppose so for completeness.

 2.  I think we need to be able to specify it for an individual image as
 well as for the global default behavior if no other scaling is specified.

+1, this would be how I plan to use it.

 3.  For an individual image, setting @contentwidth=scale-down-to-fit
 in imagedata could work, since that attribute accepts CDATA (while
 @scalefit in DocBook 5 does not).  Same for contentdepth.  But what
 happens with this value in HTML output?

Ignore it? I think you'd need to use role=fo v. role=html to get
independent scaling. I never scale in html.

 4.  The global setting should be controlled by a param for backwards
 compatibility, but should there be separate params for content-width and
 content-height?  I think so.

I guess, though common use case would be to set both at once. I can't
think of a case where you'd do scale-down-to-fit on one dimension but
not on the other, but perhaps someone needs it.

 5.  For global fallback, we already have an empty $default.image.width
 param which could be set to either value.  We would have to add a
 $default.image.depth.

Ok.

 Any other thoughts or requirements?

I'd be happy to test the changes in fop.

Regards,
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] Fitting tall images in PDF

[David Cramer]

What about setting content-width and content-height in the fo to
scale-down-to-fit? Should be supported in fop and xep; not sure about
antenna house:

http://apache-fop.1065347.n5.nabble.com/scale-image-if-too-large-td14003.html#a14005

Regards,
David

On 01/03/2014 04:35 PM, Bob Stayton wrote:
 Hi Mark,
 I'm not sure you can do that with XSL-FO.  It works for width because an
 image is not competing with other content for width space.  So defining
 width=100% means the dedicated viewport is 100% of the width of the
 page between margins, and the image is located within that viewport,
 sized down to fit if necessary.
 
 If you set depth=100%, you are creating a viewport that is the height
 of the remaining space on the page, not the whole page.  So the height
 of that viewport depends on what precedes the image on the page.


-
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] Storing data within Docbook?

[David Cramer]

Looking at docbook.rng, I see that the xhtml namespace is explicitly
excluded. I don't know why they schema is written that way; perhaps
someone else can explain the rational:

define name=db._any
  element
a:documentationAny element from almost any
namespace/a:documentation
anyName
  except
nsName/
nsName ns=http://www.w3.org/1999/xhtml/
  /except
/anyName
zeroOrMore
  choice
ref name=db._any.attribute/
text/
ref name=db._any/
  /choice
/zeroOrMore
  /element
/define

You could store it in any namespace other than xhtml and convert it back
when you use it downstream.

Regards,
David

On 12/22/2013 07:14 PM, Vadim Peretokin wrote:
 I'm having difficulty embedding elements of the XHTML namespace within
 my metadata. It seems that with either of the approaches above, I cannot
 use the elements in the XHTML namespace - but any other namespace works.
 Quite strange. Here's an annotated snippet:
 
informaltable
   info
   [...]
requirement name=Person identifier
   number=[...]
   ea-id=[...]
   detail
  div
 xmlns=*http://www.w3.org/1999/xhtml-not-really*;!-- works --
 p style=font-family: 'Lucida Sans';
 text-align: leftThe document SHALL contain the individual's [...]./p
  /div
   /detail
   rationale
  *babbah*:div
 xmlns=http://www.omg.org/spec/ReqIF/20110401/reqif.xsd;

 xmlns:configuration=http://eclipse.org/rmf/pror/toolextensions/1.0;

 xmlns:headline=http://pror.org/presentation/headline;

 xmlns:rtf=http://pror.org/presentation/rtf;!-- works --
 babbah:div style=text-align: left;Allows
 interoperability. Eliminates ambiguity. [...]/babbah:div
  /babbah:div
   /rationale
/requirement
requirement name=Person name
   number=[...]
   ea-id=[...]
   detail
  *xhtml*:div
 xmlns=http://www.omg.org/spec/ReqIF/20110401/reqif.xsd;

 xmlns:configuration=http://eclipse.org/rmf/pror/toolextensions/1.0;

 xmlns:headline=http://pror.org/presentation/headline;

 xmlns:rtf=http://pror.org/presentation/rtf;!-- does not work: E
 [Jing] element xhtml:div not allowed anywhere; expected the element
 end-tag or text --
 xhtml:p style=font-family: 'Lucida Sans';
 text-align: leftThe document SHALL contain the given (where
 applicable) and family name of the person the document relates to./xhtml:p
  /xhtml:div
   /detail
 
 Why would the DocBook 5 (http://docbook.org/ns/docbook) schema be
 disallowing xhtml specifically and/or what is the error?


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

Re: [docbook-apps] Re: Syntax highlighting

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/09/2013 10:11 AM, Norman Walsh wrote:
 You can't cut and paste the verbatim display's now either. In
 fact, one reason to go with tables is to make that part work. All
 the numbers go in the first column, the lines in the second, so you
 can, if you're careful, grab just the text.

Ok, I was assuming that examples I saw on your blog [1] were already
using the tables approach. Viewing source, I see now that they aren't.

David

[1] http://norman.walsh.name/2009/03/26/xprocWithXProc


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSpe9CAAoJEMHeSXG7afUhBFcIAKBH5Z0wxGq174/XoROKGcm/
HEdUB5ZpxGOh/kSV4ezkf4NDOVAPxZKYfmGedOPHhbRJyut26FSpq0+1nrf5djiQ
UDYYxKz4W4W0ZUI8sXUbEnmwc3vyh6kOnPJUVyY9U9GxV8/kRoVoY2shx+vHjtRe
N83CphLEkDpBEtRVE3ZHf8RcVoD7AV2Py6wuDNm8eK0C7oNHkLqiT2NM/nzfuouC
tB3BXXoUxxn4qLyRFxt+L9RptB80euJJZv6xSaEt9uk0Sn3kYusSLAVzH7klegzo
CU/V3ffC/bw4GbzTlI4vPI4P4TQeCmQ+FY+Poy2zbAoNhnIE5MT8LyQa67cpzaA=
=08C9
-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

Re: [docbook-apps] Syntax highlighting

[David Cramer]

On 12/09/2013 08:10 AM, Shaun McCance wrote:
 Yelp uses jQuery.Syntax for syntax highlighting, which we've been pretty
 happy with. I've had no problems with it clobbering markup inside code
 blocks, which is something I deal with pretty often.

That looks interesting. I experimented by adding some markup to an
example in the distribution (ex.python.html). Adding b was ignored
(isn't clobbered but doesn't make text bold either). When I added img
src=1.png/ it broke the highlighting. Perhaps I'm doing it wrong?

 http://www.codeotaku.com/projects/jquery-syntax/index.en
 
 Yelp does still do line numbers is XSLT though. Also:
 
 One caveat about using tables for line numbers. It generally makes it
 impossible to cut and paste the code sample without getting all the line
 numbers. One thing I like about the syntax highlighter above is that
 when you click on the code sample, the callouts go away and are not copied.
 
 Yelp puts the line numbers in a single pre that is float: left (or right
 in RTL) next to the code block. It's the best solution I've found.

The jquery-syntax examples have line numbers (added by the js). Is there
a reason not to use that functionality?

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] Syntax highlighting

[David Cramer]

On 12/07/2013 01:38 AM, davep wrote:
 On 06/12/13 21:53, Norman Walsh wrote:
 Hello world,

 A fair bit of effort in the DocBook stylesheets goes into parsing,
 decomposing, annotating, and recomposing program listings for the
 purpose of adding line numbers to them. There's also a bunch of work
 that goes into syntax highlighting them.

 Occasionally, this takes a *long* time.

 It appears that modern systems do this in the JavaScript layer on the
 client. They also use tables to render line numbers.

We use the popular syntax highlighter:
https://github.com/alexgorbatchev/SyntaxHighlighter

But we had to adapt it to support callouts and markup inside the code
sample. Without our modifications, the js highlighter would end up
displaying the html markup from the inline markup and the callouts as if
it were part of the code sample. Here's an example of our version:

http://docs.rackspace.com/servers/api/v2/cs-devguide/content/curl_summary_xml.html

On the downside, it adds weight to the page.


 I'm tempted to move in this direction. Comments?
 
 
 No problem with line numbers. I guess it's the outcome we want
 rather than how it is done?
   Would that work with insertions too? E.g. lines with (6) etc
 which are referred to in commentary?

One caveat about using tables for line numbers. It generally makes it
impossible to cut and paste the code sample without getting all the line
numbers. One thing I like about the syntax highlighter above is that
when you click on the code sample, the callouts go away and are not copied.

Of course for pdf/print output, copy/paste is less of a concern.

Regards,
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] wiki.docbook.org down

[David Cramer]

On 11/27/2013 08:26 PM, Vadim Peretokin wrote:
 Ok, it's back up now. I'd received a notification that the VM was using
 too much RAM and had to be rebooted. I resized the vm. We'll see how it
 goes.

 It seems to work now, albeit /very/ slowly.

Just looking at the access logs, it appears to be the subject to some kind of 
automated attack involving new account creation. Perhaps that's affecting 
performance. I don't know much about how this was set up and configured or what 
steps have been or could be taken to harden it. 

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] Storing data within Docbook?

[David Cramer]

Jirka's suggestion is the best approach. It gives you all the flexiblity 
in the world with no extra work. Here's how it might look:

...
  tr
td
  para
info
vadim:metadata 
xmlns:vadim=http://somedomain-you-own/some-namespace-you-makeup;
  vadim:somefieldsomedata/vadim:somefield
/vadim:metadata
/info
  Ipsum lorem. Stuff readers see goes here.
  /para
/td
...

DocBook's info element and its contents are already ignored by the xslts. 
You can encode your data in xml as complex as it needs to be in a namespace 
of your invention. Here's another way of doing it if you don't like namespace 
prefixes:

  tr
td
  para
info
metadata 
xmlns=http://somedomain-you-own/some-namespace-you-makeup;
  somefieldsomedata/somefield
/metadata
/info
  Ipsum lorem. Stuff readers see goes here.
  /para
/td

Regards,
David

On 11/19/2013 06:36 PM, Vadim Peretokin wrote:
 This sounds really interesting and viable, the second being the
 profiling of the role attribute (which I'd like to avoid if I can due to
 good advice given here
 http://www.sagehill.net/docbookxsl/ProfilingWithRole.html). However it
 seems the schema doesn't allow adding other elements, even from other
 namespaces? Adding an an extradata:info to a row (the ideal
 situation; easiest to deal with then when working with XSLT on it!)
 gives a validation error: E [Jing] element extradata:info not allowed
 here; expected element entry or entrytbl
 
 On 19/11/13 23:19, Jirka Kosek wrote:
 On 19.11.2013 1:34, Vadim Peretokin wrote:
 I'm transforming some data from an XML format into a Docbook table - but 
 not all of the data in the XML is to be displayed in Docbook. I would, 
 however, like to store it in my Docbook XML - because future 
 transformations would like to read my Docbook XML and they'd need all of 
 the data that went into it. I'd rather not introduce a secondary file for 
 storing the extra data - this would bring complications and fragility.
 The easiest way to do this is to add info element to the table and put
 you raw XML data there -- they just must be in different namespace then
 DocBook in order to validate.

  Jirka


 
 -- 
 
 Vadim Peretokin
 Clinical Information Modeller
 *nehta - National E-Health Transition Authority*
 Level 2, 10 Browning St, West End, QLD 4101, Australia
 Phone: (0) 3023 8573
 Email: vadim.pereto...@nehta.gov.au mailto:firstname.lastn...@nehta.gov.au
 Web: www.nehta.gov.au http://www.nehta.gov.au
 
 
 
 The information contained in this e-mail message and any accompanying
 files is or may be privileged or confidential. If you are not the
 intended recipient, any use, dissemination, reliance, forwarding,
 printing or copying of this e-mail or any attached files is
 unauthorised. This e-mail and any attachments may be subject to
 copyright. Copyright material should not be reproduced, adapted or
 communicated without the written consent of the copyright owner. If you
 have received this e-mail in error please advise the sender immediately
 by return e-mail or telephone and delete all copies. NEHTA does not make
 any representations or give any guarantees in respect of the accuracy or
 completeness of any information contained in this e-mail or attached
 files. Internet communications are not secure, therefore NEHTA does not
 accept any liability for the contents of this message or attached files.


-
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] Fop failing with illicit table

[David Cramer]

On 11/15/2013 04:24 AM, Camille Bégnis wrote:
 I am facing the infamous error:
 A table-cell is spanning more rows than available in its parent element.
 When trying to convert DocBook to PDF using FOP.
 It is a big document with many tables, and looking for the culprit is
 tedious.
 
 Has anyone faced this issue, and found a way to detect the issue?
 A simple XPath would do I guess?

If the message comes from fop, open the .fo file in Oxygen and hit
Validate.

Regards,
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] Faster WebHelp XSL

[David Cramer]

On 10/01/2013 09:55 AM, Maxime Bégnis wrote:
...
 the files showing how we did it preserving the highlighting of the
 current tree item. Basically we generated an id attribute for each
 tree item and a javascript variable containing the current id for each
 page. After that the transformation took 45 minutes to finish.
 
 We hope it will be useful.

This sounds great! It should help performance in the browser as well.
I'll give it a shot.

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] how remove dot in orderedlist/listitem?

[David Cramer]

Wow, somehow between the time I read your message and wrote my reply, my
brain completely reinterpreted what you were asking into a different
question.

Ignore me and listen to Bob. Sorry for the noise.

David

On 08/30/2013 10:40 AM, David Cramer wrote:
 IIRC, simplelist is formatted without dots by default.
 
 Also look at the mark attribute on itemizedlist. Try setting that to
 none.
 
 For customizing lists, see Bob Stayton's excellent book on customizing
 the DocBook xsls:
 http://www.sagehill.net/docbookxsl/Itemizedlists.html
 
 Regards,
 David
 
 On 08/30/2013 08:22 AM, Dave Milter wrote:
 Hi,

 I have fragment of docbook like this:

 orderedlist inheritnum=ignore continuation=restarts
 listitemparaFOO/para/listitem
 listitemparaBOO/para/listitem
 /orderedlist

 I convert this list to xsl-fo, and see (I removed tags):
 1. FOO
 2. BOO

 But I want
 1 FOO
 2 BOO

 without dots after numbers.

 Can not find any preference that can change this behaviour.

 Also I try hack fo/list.xsl,

 but I can not find where in
 xsl:template match=d:orderedlist/d:listitem

 dot appear (I am newbie in XSL).


 Any suggestions how to remove dots?
 


-
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] how remove dot in orderedlist/listitem?

[David Cramer]

IIRC, simplelist is formatted without dots by default.

Also look at the mark attribute on itemizedlist. Try setting that to
none.

For customizing lists, see Bob Stayton's excellent book on customizing
the DocBook xsls:
http://www.sagehill.net/docbookxsl/Itemizedlists.html

Regards,
David

On 08/30/2013 08:22 AM, Dave Milter wrote:
 Hi,
 
 I have fragment of docbook like this:
 
 orderedlist inheritnum=ignore continuation=restarts
 listitemparaFOO/para/listitem
 listitemparaBOO/para/listitem
 /orderedlist
 
 I convert this list to xsl-fo, and see (I removed tags):
 1. FOO
 2. BOO
 
 But I want
 1 FOO
 2 BOO
 
 without dots after numbers.
 
 Can not find any preference that can change this behaviour.
 
 Also I try hack fo/list.xsl,
 
 but I can not find where in
 xsl:template match=d:orderedlist/d:listitem
 
 dot appear (I am newbie in XSL).
 
 
 Any suggestions how to remove dots?


-
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] TOC issues with DocBook WebHelp

[David Cramer]

On 08/28/2013 02:02 AM, Tracy Huang wrote:
 If you got a solution for #2, I would really love to know and have a
 try. I am still very curious about why this issue does not exist in
 http://doc.neodoc.biz/user/content/apbs03.html. And from the source file
 it indicates it uses DocBook XSL-NS Stylesheets V1.75.2, but when I
 downloaded V1.75.2 I found there is even no webhelp folder under it
 (another mystery for me). Besides, its performance is much better than
 mine. Any idea why? Is Web server settings the only reason? Or is there
 something else I should pay attention to? Or should I try the latest
 snapshot from http://snapshots.docbook.org/ to see if any difference?

I didn't realize it wasn't happening before and I'm not sure what
changed. I suspect the Neodoc stuff started from some pre-release
version of webhelp

Regarding performance, In general, if you host it on a CDN, it will
perform better. But the stock webhelp served off a modest cloud server
seems fine: http://snapshots.docbook.org/xsl/webhelp/docs/ch01.html

But I know we could clean up the js and css (combine things to reduce
the number of GETs and minimize the js).

Let me know if what you find and if there are changes we should make in
the webhelp.

Regards,
David
  
 Thanks again for your help!
 Tracy
 
 
 2013/8/28 David Cramer da...@thingbag.net mailto:da...@thingbag.net
 
 Hi Tracy,
 Regarding #1, it sounds like this bug (which I haven't looked into yet):
 http://sourceforge.net/p/docbook/bugs/1301/
 
 Regarding #2, I can see why that would happen: while the help system may
 look like a frameset, the toc tree is actually reproduced on every page.
 When you click on a link to go to a new page, we have js that does
 things like open nodes in the toc tree to the same state they were in
 before (based on a cookie) and restore the search term from the previous
 page if you were on the search tab (again from a cookie). We don't have
 any code that would restore the vertical scroll to the same state it
 was. I did experiment with solutions at one point and was going to make
 it so that it scrolls so that the page you landed on is at the top or at
 least visible as a next-best-thing to preserving the scroll state, but I
 got distracted before I finished that.
 
 Let me know if #1 helps and if there are any side effects to removing
 it. I believe it was there to ensure that when you clicked on a link to
 an anchor in a page, the corresponding heading didn't end up under the
 top banner.
 
 Regards,
 David
 
 
 On 08/27/2013 03:02 AM, Tracy Huang wrote:
  Hi All,
 
  I am looking for help with the two TOC issues that I have with my
  DocBook WebHelp, compiled using DocBook xsl ns 1.78.1, Ant 1.8.4, and
  Saxon 6.5.5.
 
 
 
  Issue 1: In my WebHelp TOC, there are several TOC entries (of the same
  level) linking to the different anchors of the same html page (this is
  controlled by the default toc and chunk parameters), but only the
 first
  click from these TOC entries will reload the html page and scroll
 to the
  right anchor of the page, all the subsequent clicks neither reload the
  html page, nor scroll the html page to the right anchor, and the html
  address in the browser address bar don’t change (although a different
  html address can be viewed when hovering on the TOC entry), unless you
  switch to a different html page, and then back to it, and then
 again the
  first click will scroll to the right anchor of the page, the rest
 clicks
  just have no effect at all.
 
 
 
  Issue 2: In WebHelp TOC again, everytime when you click a TOC
 link, the
  TOC pane will refresh and then go to the top of the TOC pane, and will
  not re-locate to the current selected TOC link. If you have a TOC
 which
  is really long, you will have to scroll the TOC to re-locate the TOC
  link every time, which is not user-friendly.
 
 
 
  These two issues could be reproduced on this WebHelp:
 
 
 http://www.appeon.com/support/documents/appeon_online_help_v1.5test/development_guidelines/index.html.
 
  To reproduce issue 1: visit the above address, expand the TOC tree by
  clicking Best Practice - iOS mobile apps vs. PB desktop apps, and
 then
  click any entry under it, for example, Screen Size, the html page
 on the
  right page does not move all.
 
  To reproduce issue 2, visit the above address, expand the TOC tree
 so it
  is longer than one page, scroll to the bottom of the TOC tree, click
  Index. It goes to the top of the TOC tree, instead of staying at the
  bottom where Index is.
 
 
 
  I have googled for solutions but with no luck. But I found another
  DocBook WebHelp sample which has no such TOC issues, what's more, its

Re: [docbook-apps] TOC issues with DocBook WebHelp

[David Cramer]

Hi Tracy,
Regarding #1, it sounds like this bug (which I haven't looked into yet):
http://sourceforge.net/p/docbook/bugs/1301/

Regarding #2, I can see why that would happen: while the help system may
look like a frameset, the toc tree is actually reproduced on every page.
When you click on a link to go to a new page, we have js that does
things like open nodes in the toc tree to the same state they were in
before (based on a cookie) and restore the search term from the previous
page if you were on the search tab (again from a cookie). We don't have
any code that would restore the vertical scroll to the same state it
was. I did experiment with solutions at one point and was going to make
it so that it scrolls so that the page you landed on is at the top or at
least visible as a next-best-thing to preserving the scroll state, but I
got distracted before I finished that.

Let me know if #1 helps and if there are any side effects to removing
it. I believe it was there to ensure that when you clicked on a link to
an anchor in a page, the corresponding heading didn't end up under the
top banner.

Regards,
David


On 08/27/2013 03:02 AM, Tracy Huang wrote:
 Hi All,
 
 I am looking for help with the two TOC issues that I have with my
 DocBook WebHelp, compiled using DocBook xsl ns 1.78.1, Ant 1.8.4, and
 Saxon 6.5.5.
 
  
 
 Issue 1: In my WebHelp TOC, there are several TOC entries (of the same
 level) linking to the different anchors of the same html page (this is
 controlled by the default toc and chunk parameters), but only the first
 click from these TOC entries will reload the html page and scroll to the
 right anchor of the page, all the subsequent clicks neither reload the
 html page, nor scroll the html page to the right anchor, and the html
 address in the browser address bar don’t change (although a different
 html address can be viewed when hovering on the TOC entry), unless you
 switch to a different html page, and then back to it, and then again the
 first click will scroll to the right anchor of the page, the rest clicks
 just have no effect at all.
 
  
 
 Issue 2: In WebHelp TOC again, everytime when you click a TOC link, the
 TOC pane will refresh and then go to the top of the TOC pane, and will
 not re-locate to the current selected TOC link. If you have a TOC which
 is really long, you will have to scroll the TOC to re-locate the TOC
 link every time, which is not user-friendly.
 
  
 
 These two issues could be reproduced on this WebHelp:
 http://www.appeon.com/support/documents/appeon_online_help_v1.5test/development_guidelines/index.html.
 
 To reproduce issue 1: visit the above address, expand the TOC tree by
 clicking Best Practice - iOS mobile apps vs. PB desktop apps, and then
 click any entry under it, for example, Screen Size, the html page on the
 right page does not move all.
 
 To reproduce issue 2, visit the above address, expand the TOC tree so it
 is longer than one page, scroll to the bottom of the TOC tree, click
 Index. It goes to the top of the TOC tree, instead of staying at the
 bottom where Index is.
 
  
 
 I have googled for solutions but with no luck. But I found another
 DocBook WebHelp sample which has no such TOC issues, what's more, its
 performance is much much better (anybody know why?). If you are
 interested, take a look at
 http://doc.neodoc.biz/user/content/apbs03.html#d4e2030.
 
  
 
 I am not sure if these are bugs or configuration issues. Can anybody help?
 
  
 
 Regards
 
 Tracy
 


-
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-maven-plugin

[David Cramer]

Greetings,
I've created a maven plugin to create an olink database in the target
directory of a maven project:

https://github.com/rackerlabs/olink-maven-plugin

The idea is that you bind this plugin to a phase before the phase that
builds you docs, so that the target/olink.db file is available to be
used when building the DocBook docs.

It's not currently designed to be a general-purpose tool supporting all
the features of olink in the DocBook xsls, but instead only serves our
narrow needs. Still, it might provide a starting point if you need
something similar. I do plan to support additional functionality, but
don't know if I'll ever attempt to make it a general-purpose tool. I
mostly wanted to let our writers use oXygen's Insert Olink dialog to
pick items from a toc tree rather than manually adding linkend attrs to
xrefs.

Internally it runs a little xproc pipeline, so it should be easy to
extend in whatever way you need. I based it on Bert Frees'
xproc-maven-plugin.

Regards,
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] Use of XML Catalog with Ant (xslt task) - request for example (using for DocBook/WebHelp)

[David Cramer]

On 08/09/2013 05:19 AM, Kerry, Richard wrote:
 For my other target formats I’m using Saxon 6, via an Ant Java task.  I
 have catalogs working for these as that’s taken care of by parameters
 passed to Saxon.
 For WebHelp I’m using the Xslt task – that’s how the one in the
 stylesheet distribution is written, and it uses attributes like “if” and
 “expression” in its “param” elements, and I don’t know how to convert
 these to Java/Saxon.

Yeah, it would be tough to convert those to use java. The benefit of
the xslt task in this respect is that it doesn't pass in the param if
the variable in the if attr is not set. That way you get to use the
defaults set in the xslt. But you could just most of the params when
converting to a java task and only pass in the params you care
about/intend to set.

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] Using the Maven example project - goals to run customisation

[David Cramer]

On 08/09/2013 05:23 AM, gra...@heliocentrik.net wrote:
 This is exactly the workflow I'd like to replicate. What I'm confused
 about is which goals/targets to run to get it to actually do all this
 stuff. I've tried things like 'xml:transform', 'site' and so on, but it
 always seems to fail to actually download the stylesheets or transform
 the source files.

Try:

mvn clean generate-resources

But as an alternative also see:

http://docs.codehaus.org/display/MAVENUSER/Docbkx+Maven+Plugin

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] Problem with \ in WebHelp Search

[David Cramer]

On 06/05/2013 12:28 PM, Morgan Hayward wrote:
 We’ve been testing this on Firefox 21.0.  However, I just tested this in
 IE9 and found the sidebar disappears when you search for a backslash (/)
 as well.  Very strange.

Indeed, I'm seeing that behavior in the current snapshot build:

http://snapshots.docbook.org/xsl/webhelp/docs/?textToSearch=this+\+that#

Should be easy enough to fix by removing / and \ from the search string.
I'll take a look.

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] Problem with \ in WebHelp Search

[David Cramer]

Yeah, I'd be happy to merge in Peter's changes.

David

On 06/05/2013 02:40 PM, Morgan Hayward wrote:
 Hi Peter,
 
 If you could share with us what you did, even some breadcrumbs, I would 
 certainly appreciate it.  I am far from proficient in Java and would accept 
 any help I can get.
 
 Regards,
 Morgan
 
 -Original Message-
 From: Peter Desjardins [mailto:peter.desjardins...@gmail.com] 
 Sent: June-05-13 3:02 PM
 To: Fekete Róbert
 Cc: docbook-apps@lists.oasis-open.org
 Subject: Re: [docbook-apps] Problem with \ in WebHelp Search
 
 This problem does not occur for me in docbook-xsl-ns-1.78.0. I've tested my 
 own output in Firefox 21.0 and Chrome 27.0.1453.110 m. Seems unlikely that 
 it's a namespace/non-namespace thing.
 
 About technical terms like /var/log, the search indexer will strip most 
 punctuation characters by default, it seems to be stripping / and \ from my 
 search strings. Since I'm almost writing about file paths, code syntax, and 
 other topics in which punctuation is a crucial part of search strings I need 
 the search function to *not* strip punctuation. The solution I've used is to 
 customize the Java indexer so that it indexes all the content twice, once 
 with the default punctuation-stripping behavior, and then again with the 
 punctuation in place. As a result, I can find strings like /var/log by 
 searching for /var/log, var, or log. I think this would make a good 
 feature for webhelp but it does require a corresponding customization to the 
 JavaScript search UI. It's not a quick change.
 
 But I don't want to hijack the discussion here.
 
 Peter
 
 On Wed, Jun 5, 2013 at 2:42 PM, Fekete Róbert frob...@balabit.com wrote:

 On Wednesday, June 5, 2013 20:30 CEST, David Cramer da...@thingbag.net 
 wrote:

 On 06/05/2013 12:28 PM, Morgan Hayward wrote:
 We've been testing this on Firefox 21.0.  However, I just tested 
 this in
 IE9 and found the sidebar disappears when you search for a 
 backslash (/) as well.  Very strange.

 Indeed, I'm seeing that behavior in the current snapshot build:

 http://snapshots.docbook.org/xsl/webhelp/docs/?textToSearch=this+\+th
 at#

 Should be easy enough to fix by removing / and \ from the search string.
 I'll take a look.


 Sorry, but stripping the / and \ characters from the search strings means 
 that it is not possible to search for pathnames (for example, c:\winnt, or 
 /var/log), windows registry keys, and a bunch of other technical terms that 
 use these characters legitimately.

 Is there a way to work around this problem, for example, by using some 
 escaping characters?

 Robert

 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

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


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

Re: [docbook-apps] chunking very slow

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/28/2013 02:06 AM, Jirka Kosek wrote:
 On 28.5.2013 3:38, Peter Eisentraut wrote:
 
 Building with xsltproc and the xhtml/chunkfast.xsl stylesheet
 without customization takes about 18 minutes.  (With
 customizations to match what I had with DSSSL, it takes longer
 still.)
 
 I'm not sure whether chunkfast.xsl is really that faster then
 chunk.xsl. But in your case I would try and benchmark Saxon instead
 of xsltproc. On larger documents and complex transforms it's
 usually much faster.

Maybe try the DocBook xslt 2.0 stylesheets [1] with Saxon 9.x for
comparison as well.

David

[1] https://github.com/docbook/xslt20-stylesheets
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRpYQzAAoJEMHeSXG7afUhsuUIAIpB5HyRLr4XL5Hv9BBP8DSk
yex/QagHKCy0lvNRuMycAYuXy7Ci6pbkMEFRbzNSq+EBCNw12e1nmwsiLHpVnPvO
7NftACaMJYL2+11nKQmu73hTUiehZviDDT/XE/DO9TgABtaBx5XXrkEk09DULGiw
Z3P7aXPeknMFH9F9pZkd5w/d6IsLm8+xSFRHAozJeGnKgEMbUkV3oOR5I4t67sAc
BfHnG18HdyVptekOo6yXtOy7qNMTlK0AaL6lG9hOJBp25RGy4eM5v7/fZ9g4snQY
kJ1znn+FKBkZKKP46YYdATwMlU+jrpuoD0RI1vq6pnLiRSBYPzTIGANVDoMhSnY=
=Ggcb
-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

Re: [docbook-apps] DocBook XSL snapshots are back

[David Cramer]

On 05/08/2013 02:44 AM, Thomas Schraitle wrote:
 * The for revision , text is missing a revision number
 
 * In former times, the Latest Changes part contained the contents of
   the LatestChanges file.

Yeah, I was playing with it last night. Things seem to revert to broken
if the wiki is enabled. If I disable the wiki, things work fine. It may
be that the vm is just too modest to do both. I've emailed asking if we
could have it resized. If not, we could move the wiki.

David


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

Re: [docbook-apps] DocBook snapshot SVN problem

[David Cramer]

On 05/03/2013 02:47 PM, honyk wrote:
 But I don't know if something like this is applicable to this situation.

Now that you mention it, that's probably what happened in this case.

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] Custom css with webhelp

[David Cramer]

Hi David,
All the usual params are supported in the xslts BUT the sample 
Makefile and build.xml don't pass in every supported param. Looking
at it, I see that it supports only the profiling params out of the box. 

So if you're using the supplied build.xml or Makefile as a starting point
you'll need to adapt it so that it also passes in the params you set. 

If that's the case, look for the following lines in the build file and
add html.stylesheet following the pattern you see for the profiling 
params. 

Regards,
David

Sample Makefile:

chunk:
xsltproc  --xinclude --output xincluded-profiled.xml  \
  --stringparam  profile.arch ${PROFILE.ARCH} \
  --stringparam  profile.audience ${PROFILE.AUDIENCE} \
  --stringparam  profile.condition ${PROFILE.CONDITION} \
  --stringparam  profile.conformance ${PROFILE.CONFORMANCE} \
  --stringparam  profile.lang ${PROFILE.LANG} \
  --stringparam  profile.os ${PROFILE.OS} \
  --stringparam  profile.revision ${PROFILE.REVISION} \
  --stringparam  profile.revisionflag ${PROFILE.REVISIONFLAG} \
  --stringparam  profile.role ${PROFILE.ROLE} \
  --stringparam  profile.security ${PROFILE.SECURITY} \
  --stringparam  profile.status ${PROFILE.STATUS} \
  --stringparam  profile.userlevel ${PROFILE.USERLEVEL} \
  --stringparam  profile.vendor ${PROFILE.VENDOR} \
  --stringparam  profile.wordsize ${PROFILE.WORDSIZE} \
  --stringparam  profile.attribute ${PROFILE.ATTRIBUTE} \
  --stringparam  profile.value ${PROFILE.VALUE} \
  ../profiling/profile.xsl  \
  ${INPUT_XML}

Sample build.xml:

xslt
  in=${input-xml}
out=${xincluded-profiled.xml}
style=${ant.file.dir}/../profiling/profile.xsl
classpath=${xercesImpl.jar}
  sysproperty key=org.apache.xerces.xni.parser.XMLParserConfiguration
   
value=org.apache.xerces.parsers.XIncludeParserConfiguration/
  param name=profile.arch expression=${profile.arch} 
if=profile.arch/
  param name=profile.audience expression=${profile.audience} 
if=profile.audience/
  param name=profile.condition expression=${profile.condition} 
if=profile.condition/
  param name=profile.conformance expression=${profile.conformance} 
if=profile.conformance/
  param name=profile.lang expression=${profile.lang} 
if=profile.lang/
  param name=profile.os expression=${profile.os} if=profile.os/
  param name=profile.revision expression=${profile.revision} 
if=profile.revision/
  param name=profile.revisionflag 
expression=${profile.revisionflag} if=profile.revisionflag/
  param name=profile.role expression=${profile.role} 
if=profile.role/
  param name=profile.security expression=${profile.security} 
if=profile.security/
  param name=profile.status expression=${profile.status} 
if=profile.status/
  param name=profile.userlevel expression=${profile.userlevel} 
if=profile.userlevel/
  param name=profile.vendor expression=${profile.vendor} 
if=profile.vendor/
  param name=profile.wordsize expression=${profile.wordsize} 
if=profile.wordsize/
  param name=profile.attribute expression=${profile.attribute} 
if=profile.attribute/
  param name=profile.value expression=${profile.value} 
if=profile.value/
/xslt

On 04/16/2013 08: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 link 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

Re: [docbook-apps] participating GSOC 2013

[David Cramer]

On 04/05/2013 11:29 PM, Kelum Deshapriya wrote:
 I'm Kelum Deshapriya.i'm new to gsoc. I'm willing to participate gsoc
 2013 and work with Docbook XSLT 2.0 stylesheets project. I haven't
 previous experience about project. so i did some searching to learn Docbook.
 http://en.wikipedia.org/wiki/DocBook
 http://www.sagehill.net/docbookxsl/index.html
 https://help.ubuntu.com/community/DocBook
 i'm interesting working with Docbook XSLT 2.0 Stylesheets project. but i
 don't know how to start working this project. so can anyone give me some
 help to start working with this project? thanks.

Hi Kelum,
To work on the xslt 2.0 stylesheets, you'll need decent xslt 2.0 skills.
I'd check out the resources for learning xslt at:

http://wiki.docbook.org/LearningDocBook

The code for the xslt 2.0 stylesheets is here:

https://github.com/docbook/xslt20-stylesheets

Bob Stayton's book, http://www.sagehill.net/docbookxsl/index.html, is
about the xslt 1.0 stylesheets, much remains the same in terms of the
parameters and how they work, but the implementation of those features
may differ substantially in the 2.0 xslts.

I think Jirka or Norm would have to chime in on what features are
to-be-implemented. Another option would be to find a customization of
the 1.0 xslts that hasn't been ported to xslt 2.0 yet and handle that.
For example, webhelp. In that case, you'd depend on the xslt 2.0
stylesheets and build on them.

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] [HELP] How can I get rid of the output of the revhistory / tag in the EPUB output

[David Cramer]

As I mentioned on irc, put the template xsl:template match=revhistory
mode=titlepage.mode/ in your actual customization layer. Bob's book
is for creating customization layers and his information doesn't apply
to stand-alone preprocessing xslts you write. Alternatively, remove
mode=titlepage.mode from the template that matches revhistory in
https://github.com/shlomif/Human-Hacking-Field-Guide/blob/master/HHFG/text/docbook-epub-preproc.xslt
I'd also suggest that you read one of the many fine introductions to xslt.

David

On 03/25/2013 12:15 PM, Shlomi Fish wrote:
 Hi all,
 
 I am trying to get rid of the revhistory / tag in the EPUB output here:
 
 https://github.com/shlomif/Human-Hacking-Field-Guide/tree/master/HHFG/text
 
 see below for more information - any help will be appreciated.
 
 This seems to be misleading:
 http://www.sagehill.net/docbookxsl/FormatRevhistory.html :
 
 
 Tip
 
 A quick way to turn off revhistory from output is to define an empty template
 for it in a customization layer. The following example will turn it off for 
 all
 elements that contain a revhistory:
 
 xsl:template match=revhistory mode=titlepage.mode/

 
 Please see below for the conversation log. Any help will be appreciated.
 
 Regards,
 
   Shlomi Fish
 
 
 rindolf Hi all.
 rindolf I cannot seem to know how to get rid of revhistory.../revhistory
 on my page. rindolf
 https://github.com/shlomif/Human-Hacking-Field-Guide/tree/master/HHFG/text -
 it's here. rindolf LotR: here? rindolf Vampire0: here?
 rindolf Anyone?
 * dcramer_ has quit (Ping timeout: 245 seconds)
 * scotm (~sc...@c-67-189-56-13.hsd1.or.comcast.net) has joined
 * pere (~p...@cm-84.215.38.245.getinternet.no) has joined
 * dcramer_ (~dcra...@of1-nat2.aus1.rackspace.com) has joined
 rindolf couture, dcramer_ , dtardon , joat , LotR , mhnoyes , pbor , pere ,
 scotm , shaunm , stefan2 , sunny256 , ThomasWaldmann , Vampire0 , verm__ : any
 idea?
 * pere did not notice the question.
 dcramer_ rindolf, That would be via the titlepage stuff...
 dcramer_ http://www.sagehill.net/docbookxsl/HTMLTitlePage.html
 rindolf dcramer_: did you look at
 https://github.com/shlomif/Human-Hacking-Field-Guide/blob/master/HHFG/text/docbook-epub-preproc.xslt
  ?
 dcramer_
 https://github.com/rackerlabs/clouddocs-maven-plugin/blob/master/src/main/resources/cloud/webhelp/titlepage/titlepage.templates.xml
 dcramer_ See how revhistory is commented out in the titlepage spec?
 dcramer_ What you do is edit the titlepagespec, then generate a new
 titlepage.xsl from it:
 http://www.sagehill.net/docbookxsl/TitlePageNewElems.html dcramer_ Which you
 then import into your customization layer. dcramer_ rindolf: Give that a
 shot. If you're still having trouble, try the docbook-apps mailing list.
 rindolf dcramer_: OK. rindolf dcramer_: isn't there an easier way?
 dcramer_ Well, that's the right way :-) rindolf dcramer_: why doesn't
 xsl:template match=revhistory mode=titlepage.mode/ rindolf  work?
 dcramer_ I'd have to dig in to see what template is generated by the
 titlepage mechanism. But on the list Bob could answer that off the top of his
 head I bet. dcramer_ The template spec stuff isn't really that hard.
 dcramer_ 1. Edit the titlepage.xml provided with the dist to remove
 revhistory dcramer_ 2. Generate titlepage.xsl by just running a provided
 xslt over the edited spec. dcramer_ 3. Import result into your customization
 layer. dcramer_ Easier in a way.
 


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

Re: [docbook-apps] [HELP] How can I get rid of the output of the revhistory / tag in the EPUB output

[David Cramer]

I'm not sure what this does:

ruby
-s
/home/shlomif/Download/unpack/file/docbook/docbook-xsl-ns-snapshot/epub/bin/dbtoepub
-s docbook-epub-preproc.xslt -o human-hacking-field-guide--english.epub
human-hacking-field-guide--english.db5.xml

But I'm assming that your docbook-epub-preproc.xslt preprocesses your
source before passing it to the DocBook xslts. In that case try the
following. We're matching db:revhistory (where db is bound to
http://docbook.org/ns/docbook) and also we've removed the mode. I also
changed indent=yes to no because that can cause unwanted whitespace:

xsl:stylesheet version = '1.0'
xmlns=http://docbook.org/ns/docbook;
xmlns:db=http://docbook.org/ns/docbook;
xmlns:xsl='http://www.w3.org/1999/XSL/Transform'
xmlns:xlink=http://www.w3.org/1999/xlink;


  xsl:output method=xml version=1.0 encoding=UTF-8 indent=no/

  !-- Get rid of the revhistory element --
  xsl:template match=db:revhistory/

/xsl:stylesheet

David

On 03/26/2013 12:30 PM, Shlomi Fish wrote:
 Hi Bob,
 
 thanks for returning to me. See below for my responses.
 
 On Tue, 26 Mar 2013 08:59:00 -0700
 Bob Stayton b...@sagehill.net wrote:
 
 Hi,
 More details are needed to determine the problem.

 
 let me answer them one by one.
 
 What numbered version of DocBook XSL are you using?
 
 Close to latest docbook-xsl-ns-snapshot from
 http://docbook.sourceforge.net/snapshot/ .
 

 Are you using DocBook 5 and the the docbook-ns stylesheets, or DocBook4 and 
 the non-namespaced stylesheets?
 
 I'm using DocBook 5 and docbook-ns.
 

 Are you processing a book or article?

 
 Technically, the story is an article. You can find it at:
 
 https://github.com/shlomif/Human-Hacking-Field-Guide/blob/master/HHFG/text/human-hacking-field-guide--english.db5.xml
 
 Is the revhistory element located in an info element or in the body of the 
 document? (revhistory can appear in a para, for example)

 
 Inside an info/info
 
 Are you using the epub or epub3 stylesheet?
 
 The EPUB ones I think. I can try using the EPUB 3 too. 
 

 How are you importing it and customizing it

 
 I use this:
 
 ruby
 -s 
 /home/shlomif/Download/unpack/file/docbook/docbook-xsl-ns-snapshot/epub/bin/dbtoepub
 -s docbook-epub-preproc.xslt -o human-hacking-field-guide--english.epub
 human-hacking-field-guide--english.db5.xml
 
 Where docbook-epub-preproc.xslt is:
 
 https://github.com/shlomif/Human-Hacking-Field-Guide/blob/master/HHFG/text/docbook-epub-preproc.xslt
 
 (sorry, I don't have time to reverse engineer your whole build setup).
 
 Sure, I'm happy to provide assistance.
 
 Sorry for losing patience several times before - I think I figured out what 
 the
 problem is, and I was doing something wrong, but it's too bad the toolchains
 did not crash and burn and eat my dog when I did it.
 
 Regards,
 
   Shlomi Fish
 

 Bob Stayton
 Sagehill Enterprises
 b...@sagehill.net
 
 [SNIPPED]
 
 


-
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 bug?

[David Cramer]

On 02/25/2013 05:14 AM, Stefan Hinz wrote:
 Note that the construct that makes WebHelp fail is perfectly legal
 according to the DocBook DTD. We don't get any errors when building
 other formats (XHTML, FO, etc.). Since this is specific to WebHelp, I
 wonder if we've simply hit a bug.
 
 Let me know, and I'll file a bug report on SF.net.

It's very odd that this would affect only webhelp and not other outputs.
Have you tried with just chunked html and htmlhelp? There's nothing in
the webhelp directly related to those constructs.

Could you post a small test case that causes the problem? I just added
that construct to a test document and couldn't get it to fail (using
xsltproc or saxon).

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] WebHelp Search

[David Cramer]

Hi Eric,
There were some changes in this release related to removing the content
directory that might have affected you. Could you provide some more
information about your environment or the output of a build? Are you
using a customized version of the build.xml for example?

Thanks,
David

On 01/14/2013 03:33 PM, Eric Johnson wrote:
 I updated to the most recent version of the XSLT stylesheets and the
 search panel for the WebHelp is broken. I made the suggested changes to
 my tool chain, but I am not getting the htmlFileList.js file generated.
 
 Any ideas on what I goofed up?
 
 TIA
 Eric
 
 -
 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] Profiling on table columns

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/13/2012 10:26 AM, Jirka Kosek wrote:
 So in some cases it can be quite straightforward, in some cases it
 would be very difficult.

Another difficulty is that you might also need/want to adjust column
widths.

Another approach would be to store the content in a custom semantic
format suited to the data and transform it into a CALS or HTML table
as a preprocessing step as part of the build, then xinclude the table
into your doc. The preprocessing step could include/exclude data based
on profiling inputs. The custom format might be easier to understand
and edit than a CALS or HTML table as well.

David

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQyhEyAAoJEMHeSXG7afUhBKQH/3M9RvNb0+LtkYFKOgBgYNtY
fwXak0AeBe19krl/90EQny8LPzCOQ4m+lkf2NaP/kEO/YQQD4j8/8gtVyb3dlfQ4
h0FqgOLuBNiK6MBZgX76jJmJv/ZR2xnkpJMF8Sq2BYnMXIihCkxdMJlflsO+2xF5
f4/aTeZzg7dIlo7hDZCVLYXGO+SogjwhXFYkwaEoTk7qwgPklND5cSsnglPTKW7b
Lnh03l+waGCWwcGtWkXsObrKENCwiL7ZfeTg1CXj7qTbTFzAqxO0SuQa06maydNA
mw0+qm04wvSkrToIGbuRp7UUIt2cBIQLbX/OT+p3vlsc4uvT3YGMh74JjN9SpMo=
=D/39
-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

[docbook-apps] Re: [docbook-dev] new stylesheet release coming

[David Cramer]

On 12/10/2012 04:35 PM, Bob Stayton wrote:
 We will soon be releasing a new version of the DocBook XSL stylesheets.  If 
 you have any bug fixes still pending that need to be checked in, please do 
 so by the end of this week.  Thanks.

Where end of this week = Friday?

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] Creating a separate section/component for Revision History

[David Cramer]

We do something like what you're contemplating, but add the revhistory
via a preprocessing step. The writer puts ?rax revhistory? somewhere
in the doc, then we have some templates like these to add a DocBook
table at that point:

https://gist.github.com/4199240

Note that elsewhere we have a shortDate named template that formats
dates to our liking.

The result is passed on to the normal DocBook xslts.

David


On 12/03/2012 10:42 AM, Kerry, Richard wrote:
  
 
 Team,
 
  
 
 I've successfully removed the Revision History from the title-page of my
 document (ie from the title-page of the FO transform) - that was
 straightforward.
 
 I'd like to add it back as a separate section (*) later in the file -
 probably between the appendix (which is rarely present) and the index
 (which is never present).
 
  
 
 Can anyone advise me where in the stylesheets I need to add my new section ?
 
 I'm expecting to see somewhere the current main structure - ie
 title-page, ToC, section 1 ... section n, Appendices, Index.  I'd expect
 to be adding something in there.
 
 There will probably be a pile of other stuff needed to make this work. 
 
 It may be that I just need to write a 'section' and mark it for special
 handling, then customize a version of the section template to be called
 between the appendix and the index.  This may be simpler.  But I still
 need to find out where to get it called.
 
 Actually, since I'll generally need two revision histories, writing it
 into a separate Section page may also make it easier
 
  
 
 Appreciatively,
 
 Richard.
 
  
 
  
 
 (*) I've said 'section' here but that has a specific meaning.  I think
 what I mean here is what is sometimes referred to as a 'component'.
 
  
 
  
 
  
 
  
 
  
 
 Blue line
 
 *Richard Kerry*
 
 BNCS Engineer
 
 T: +44 (0)20 82259063
 
 M: +44 (0)7812 325518
 
 Room EBX 301, BBC Television Centre, Wood Lane, London, W12 7RJ
 
 richard.ke...@atos.net mailto:richard.ke...@atos.net
 
 uk.atos.net http://uk.atos.net/en-uk/
 
 Atos logo
 
 This e-mail and the documents attached are confidential and intended
 solely for the addressee; it may also be privileged. If you receive this
 e-mail in error, please notify the sender immediately and destroy it. As
 its integrity cannot be secured on the Internet, the Atos group
 liability cannot be triggered for the message content. Although the
 sender endeavours to maintain a computer virus-free network, the sender
 does not warrant that this transmission is virus-free and will not be
 liable for any damages resulting from any virus transmitted.
 


-
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] snapshots unavailable? 11 11 12

[David Cramer]

Seems to be working fine now.

David

On 11/11/2012 02:49 AM, DaveP wrote:
 http://docbook.sourceforge.net/snapshots/
 
 Error 503 Service Unavailable
 
 Service Unavailable
 
 Guru Meditation:
 
 XID: 1275547498
 
 Varnish cache server
 
 
 
 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] olinking in webhelp

[David Cramer]

On 10/24/2012 01:47 PM, Bob Stayton wrote:

Ah, the dreaded Saxon 6.5 DOCTYPE bug. When I set up a system to use
olink previously I recall I hacked around it by having Ant remove the
DOCTYPE as part of the build process (or maybe I used xinclude, I can't
recall, I've used both tricks in different situations).

Webhelp is based on the xhtml xsls because originally the indexer could
only parse xml files. Quite some time ago however, Kasun added tagsoup
into the mix so that it could accept html as well.

 Now I'm not sure how to proceed.  It appears that the xhtml5 output
 works in the two browsers I tested, but I have not done extensive
 testing.  The xhtml5 stylesheet provides support for videoobject and
 audioobject, which could be nice for help systems.

Testing would be the only reason to hesitate. One reason I've liked
xhtml with the doctype in the past is that it kept browsers out of
quirks mode, but I don't keep up with the latest trends in browser
behavior.

 An alternative to switching over to xhtml5 would be to modify webhelp's
 base stylesheet to work like the xhtml5 base stylesheet. That stylesheet
 sets up a replacement for xhtml/docbook.xsl that imports all the other
 xhtml modules but does *not* have the problematic xsl:output element. 
 You can look at xhtml5/xhtml-docbook.xsl to see what I mean.  That means
 webhelp would stick with xhtml instead of xhtml5.
 
 I would suggest that if we don't switch webhelp to xhtml5, that we add a
 webhelp5.xsl anyway, for those who want to generate webhelp based on
 HTML5 so they can get video and audio working.

I don't have strong preferences. Switching base xsls could affect
customization layers, but progress is good too.

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] WebHelp link to index of manuals

[David Cramer]

On 10/22/2012 04:23 PM, Tim wrote:
 Thanks David.

Sure thing. I'll try to get around to adding that area for the links and
stuff back in with a parameter to switch it on and off...no telling when
I'll get to that though. If you need it soon, you'll need to create a
customization layer and pull things from the Rackspace stuff.

Note that the Rackspace xslts are a bit behind the DocBook ones since
we're downstream.

Good luck,
David

 On 21/10/2012 23:17, David Cramer wrote:
 On 10/21/2012 04:31 PM, Tim wrote:
 Hi David,

 I couldn't see the references that you said to look for.  You couldn't
 point me right to them, could you?
 Oops, I thought I'd linked to the file but that link was only to the
 dir. Those lines are in this file

 https://github.com/rackspace/clouddocs-maven-plugin/blob/master/src/main/resources/cloud/webhelp/docbook.xsl


 at lines 401 and 232.

 Sorry about that.

 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] WebHelp link to index of manuals

[David Cramer]

On 10/21/2012 04:31 PM, Tim wrote:
 Hi David,
 
 I couldn't see the references that you said to look for.  You couldn't
 point me right to them, could you?

Oops, I thought I'd linked to the file but that link was only to the
dir. Those lines are in this file

https://github.com/rackspace/clouddocs-maven-plugin/blob/master/src/main/resources/cloud/webhelp/docbook.xsl

at lines 401 and 232.

Sorry about that.

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] WebHelp link to index of manuals

[David Cramer]

On 10/19/2012 11:40 AM, Tim Casling wrote:
 I'm using the WebHelp stylesheets and would like to have a link back to
 a html page that has a list of manuals. In the Rackspace docs that are
 used as an example, I'm referring to the Rackspace Manuals link in the
 area at the top of the contents pane.

Hi Tim,
When Kasun merged the UI improvements from OpenStack/Rackspace, we
decided to omit that bar below the header because there wouldn't
normally be something to put there. I suppose we should parameterize it
so it appears if you want it and have stuff to put there.

The xslts that produce Rackspace's webhelp are available here:

https://github.com/rackspace/clouddocs-maven-plugin

Specifically here:

https://github.com/rackspace/clouddocs-maven-plugin/tree/master/src/main/resources/cloud/webhelp

Look for div id=toolbar... and xsl:template name=breadcrumbs.

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] Spell and grammar checking DocBook/ XML documents

[David Cramer]

On 10/18/2012 09:33 AM, daniel.ke...@finaris.de wrote:
 is annoying since every second word is a technical term and therefore
 highlighted as a mistake. ).

You can can configure Oxygen to skip checking in certain elements (e.g.
programlisting, code, whatever) to reduce the amount of noise.

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] Customized DocBook schema

[David Cramer]

On 09/26/2012 08:57 AM, رضا سالارمهر wrote:
 In
 http://stackoverflow.com/q/55622/752603http://stackoverflow.com/q/55622/752603
 question some DocBook editors are listed, I extended the DocBook schema
 and now I want use it to author book. Which of that editors can be
 modified to use my customized schema and still provide DocBook WYSIWYG
 editors?

All of them.

 If there is one how can I config it?

You'll have to check the docs for each editor. Typically there's a
directory full of DocBook config stuff (css, schema, editor-specific
config, etc; in Oxygen it's in the frameworks dir). You could make a
copy of that and modify it to be your own custom framework,
SalarmehrBook or whatever. Some editors also have an update mechanism
so you can distribute your new config.

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] Images not getting output in all formats using Oxygen 14.0

[David Cramer]

On 09/26/2012 10:56 AM, Paul Taylor wrote:
 Hi, using Oxygen 14.0
 
 I have a docbook file help.xml, and in the same folder a subfolder
 called images with some images in it. I apply the Pdf, Html,
 Xhtml-Chunks and WebHelp transormations, what Ive found is:
 
 Html and Xhtml do not copy the images folder, so the image link is broken
 Pdf outputs the image far too large so it cannot fit on the page (the
 image is 800 pixels wide.
 WebHelp outputs the image just right.
 
 I then added width=300 to the imagedata element and reran the
 transformations, now Pdf looks fine, but WebHelp is far too small.

I generally turn off image scaling for html and set contentwidth for
html (or use scale-down-to-fit for contentwidth and contentheight if
your fo renderer supports it).

http://docbook.sourceforge.net/release/xsl/current/doc/html/ignore.image.scaling.html

 1 So how do I get image sizes to look sensible in all formats ?
 2 How do I get images copied over for html and xhtml formats ?

That's a bug in the oxygen transformation scenario I guess. Image
handling can be quite tricky, especially if you plan to take xincludes
into account. I have a project here that illustrates the problem:

https://github.com/dwcramer/xinclude-example

One of our GSoC students has implemented a solution to copy images,
being careful not to overwrite images that have the same relative path
and file name but are xincluded from different files, but we haven't
merged that stuff into the trunk yet.

David

 
 Paul
 
 -
 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] Images not getting output in all formats using Oxygen 14.0

[David Cramer]

On 09/26/2012 02:33 PM, David Cramer wrote:
 I generally turn off image scaling for html and set contentwidth for
 html (or use scale-down-to-fit for contentwidth and contentheight if
 your fo renderer supports it).

Btw., there's lots of detail about image scaling here:

http://www.sagehill.net/docbookxsl/ImageSizing.html

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] Can docbook me used to create OSX Help books

[David Cramer]

 FYI in case it helps anybody, this is the best I can come up with so far
 
 http://stackoverflow.com/questions/11930989/can-docbook-generate-output-in-apples-help-book-format

Looks like it would be a fairly easy customization layer + build script
that would automate all that. My guess is that people who've done it
haven't bothered to contribute it back (it does take a certain amount of
extra work to make something you've done for your purposes general
enough for others to use).

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] WYSIWYG Editor for docbook

[David Cramer]

On 08/15/2012 02:20 AM, Radu Coravu wrote:
 Bu the way, good new, in Oxygen 14.1 the actions for inserting xrefs and
 links in the Author page will be more evolved, they will show a dialog
 which will allow you to quick find a reference ID. Please see the
 attached image.
 And yes, if you choose to insert from the master file, all IDs from all
 xi:includes will be collected and presented for intertion.

This looks very cool. So if you pick a section from the list I'm
guessing you'll see the title in the window the right? Could it be
configured to show in the left pane:

elementname - title or info/title (if available) - [id value]

Really what people want is the same functionality of the current olink
dialog (where you pick from a list of titles) but without the effort of
setting up olink support.

Of course you're trying to implement this generically so it's useful for
arbitrary schemas where the olink dialog can rely on elements used in
DocBook.

Anyway, I'm looking forward to seeing it.

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] Can docbook me used to create OSX Help books

[David Cramer]

On 08/12/2012 05:01 PM, Paul Taylor wrote:
 Can docbook me used to create OSX Help books ?

Hi Paul,
The DocBook xsls can create HTML out of the box. I haven't looked at OS
X Help in years, but IIRC, it's just html with some metadata added to
the head to cause the topic to appear in the right place in the nav
structures and search results. You may have to do some customization to
cause that metadata to appear in the right place. Bob's book is a great
place to learn about doing these customizations:

http://www.sagehill.net/docbookxsl/index.html

Alternatively, you could hire Bob or another consultant to prepare the
customization layer for you.

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] Can docbook me used to create OSX Help books

[David Cramer]

On 08/13/2012 11:13 AM, David Cramer wrote:
 On 08/12/2012 05:01 PM, Paul Taylor wrote:
 Alternatively, you could hire Bob or another consultant to prepare the
 customization layer for you.

Should have included this link as well:
http://wiki.docbook.org/DocBookConsultancy

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] WYSIWYG Editor for docbook

[David Cramer]

On 08/13/2012 12:07 PM, Mathieu Malaterre wrote:
 I have been using the free version of Serna. It is the only app which
 support XInclude AFAIK.
 
 I used then the docboox 4.x - docbook 5 converter since serna only
 support docbook 4.x
 
 http://www.syntext.com/products/serna-free/

There's a DocBook 5 xsd now, so it should be possible to make Serna
support DocBook 5.x if someone had the inclination and time:

http://www.docbook.org/xml/5.0/xsd/

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] Using offline and online content in Webhelp

[David Cramer]

On 08/10/2012 03:05 PM, Jeff Powanda wrote:
 Using the current DocBook Webhelp stylesheet, is there any way that you
 can generate a help system that uses both offline (local) and online
 (web hosted) content?

Hi Jeff,
The short answer is maybe. You could easily customize a template and add
nodes to the toc that point to remote content, but even if you had the
same toc tree in the remote content, the nodes in the remote content
couldn't take you back to the local content. Similarly, the next and
previous buttons would be a problem. If you had this in the toc:

local chapter 1
 local section 1
 remote section 2
 local section 3

Would the next button in section 1 take you to remote section 2? But
the next and prev buttons on remote section 2 aren't going to be able
to take you back to the local content. You could just suppress the
next/prev buttons and rely only on the toc.

If you simply want to add some nodes to the toc tree that take you to
remote pages such that the links leave the helpset, then that's easy. If
you wanted to have something that keeps the helpset feel, combining
remote and local content, then that won't work with webhelp as
implemented. You could do a bit more if you reimplement it with an old
fashioned frameset or an iframe.

If you do want to customize the left pane toc, the template to look in
is xsl:template name=webhelptoc in webhelp-common.xsl. I imagine
you'd customize it to look for some markup in your book and add nodes to
the toc accordingly. E.g. you might allow the content author to add some
processing instructions like so:

?vocera label=Cool Remote Content
href=http://vocera.com/remote/content/ipsum.html;?

Then have the template add a node to the toc tree.

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] Multilanguage DocBook documents - best practices needed

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/23/2012 01:58 AM, Jirka Kosek wrote:

+1 with a few addenda below:

 In my experience the following works pretty well:
 
 1. Store your source language (usually English) as modular DocBook 
 documents.
 
 2. Prior sending document for translation assemble it into one
 large file.

As part of the preprocessing also:

* Profile to remove any internal content, remarks, and comments that
won't be in the output and might confuse the issue.
* Normalize the line breaks so you have one line for each block
element (e.g. para, title, etc). That way the translation memory tools
won't be confused if the line wrapping changes between releases.
* If processing it into a single file results in a very large file,
consider chunking back into one file per chapter.

 3. Use agency which has very good translation software with
 translation memory

Require that they provide the TM as a deliverable so that you can use
it next time even if you select a different vendor.

Get bids from more than one vendor and compare them carefully. There
are many aspects which can affect the price.

 4. If source document is updated, make one large assembled file
 again -- with translation memory only changed part of documents has
 to be translated again.

In the past, I've had our build produce as an additional artifact an
l10n kit that contained all the preprocessed files and instructions
for the l10n vendor. This process also provided us with a word count
per file which we used to check the vendor's count.

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

iQEcBAEBAgAGBQJQDVe8AAoJEMHeSXG7afUhHbAH/i7n9d8MfNgSNDvSaq08e+uH
nw/UwbFELgWF4/O7/An7DrLFcVuHNqCpu8fGxL4o1QPh6NjNAF4gINLmMi5H39Mw
ViWPHfrKvrIqsEpPfDHjdxIEItM6k14Uu8I6zPJb4kG7SM5d+rY/FE//g7X9Y8B2
lrbGT8Dgg5UBTWD2p/QYgXllTsrAV1Pm7sOCRDGIIrW0+mb7vMWVR+3dMhJk0CIj
ADMD1I5vRMqpN/3CAJqK6UCp38kuMLsj06VnUKcSq6Qsu5RdK/VchH3TcaIgcyp1
LM2g1CikULBNbp9A4T0bU2XVXsGh/V92Bq9DgAtOTCMLNAtLbZ81EfBK2kXpPeU=
=1iXX
-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

Re: [docbook-apps] local.l10n.xml working in the xslt 2.0 stylesheets?

[David Cramer]

On 07/19/2012 10:04 PM, David Cramer wrote:
 Hi there,
 Using the latest xslt 2.0 stylesheets, I've added the following to my
 customization layer for html output:
 
   xsl:param name=local.l10n.xml select=document('')/
   i18n xmlns=http://docbook.sourceforge.net/xmlns/l10n/1.0;
 l:l10n
   xmlns:l=http://docbook.sourceforge.net/xmlns/l10n/1.0;
   language=en
   english-language-name=English
   l:context name=xref
 l:template name=section text=%t/
   /l:context
 /l:l10n
   /i18n
 
 Surprisingly, it doesn't seem to have any effect. Is this feature
 working for anyone else?

Btw., the entire customization layer is here:

https://github.com/rackspace/clouddocs-maven-plugin/blob/webhelpwar/src/main/resources/cloud/war/docbook.xsl

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] RE: Apache resolver library not found

[David Cramer]

On 07/19/2012 07:59 PM, Jeff Powanda wrote:
 Figured it out. It was a classpath problem. I updated the classpath to
 this and it worked:

Interesting and good to know. I tried that once and couldn't get it to
work. I must have given up too soon.

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] Using DiffMk with Docbook

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/11/2012 11:18 AM, David Goss wrote:
 offer some advice, or know of an alternative that might work
 better? Being able to generate revisionflags between versions would
 be more useful than sliced bread is for sandwich making.

There's a commercial product from DeltaXML available as an Oxygen
plugin. I've found it does an excellent job and is easy to use:

http://www.deltaxml.com/products/oxygen-plugin/features.html

You can use it to add revisionflag markup for DocBook or add in the
Oxygen change tracking markup.

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

iQEcBAEBAgAGBQJP/a0IAAoJEMHeSXG7afUhlUMH/2FvsoS4DZMzLsF8ibB4FW+D
9Q0mE7PoJhOCv+fEbdDsfZg4JDhxkwZCaGOV+TPas2gQwZFmXSyxAzQGgppGozsQ
dvbPzjDLGAmjlNn3x6XRI4SMFUg+MruXIGEk147PDio+yArtivN0BeIgk2chxdc1
OhhUk+tRRr3EsoYp/qs8bYcvt9Bb2nCTywrqteIyp3K/Q40h91GjDERPT+fy9Dav
GZeISHEpjwQdmTmrhZazyUEjgAbqxYLBWEbx8bgRl0COBhKU/CcYXr1CoZkeBqBy
/P3yZXAj3LmdbVrXFuWx6rnlv8OH+ncFvaKfvpj60hqarOD1+8rLkXR7TFWanVo=
=Qg20
-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

Re: [docbook-apps] How do I remove the border around Webhelp graphics?

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/10/2012 04:50 PM, Jeff Powanda wrote:
 I?m happy with the output generated by the default Webhelp
 stylesheet except for one problem:  graphics have a visible border
 around them that I?d like to remove. Not sure what I need to
 change. Do I need to update the positioning.css file?

I'm sure it's a css thing, but I don't see any border around the image
on this page:

http://snapshots.docbook.org/xsl/webhelp/docs/content/ch02s05.html

Can you provide or point to an example that shows the problem? (output
and markup would be great)

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

iQEcBAEBAgAGBQJP/OsbAAoJEMHeSXG7afUhz2gH+QEHkIlyfi76wMvG+OIwufeA
0GDgRxqUR0ymluV/5lnqRLb1mtkOcnh7yJb2pkLx00aaVDXw2EzQAb+oSDMBmDt6
h5YLsnOqwqdV6t+rDobzCokXv/DhFfgImENrk+ilkvtzxGG0dxcVieWLxCMo5k9c
aGieiwl3Ttxw9FkM2ir3Et/er8aI3Q3R4SB4PWk+CarBnuWP1d9jxP6D/2vonr/u
hDH2ULT6OENXwcA0OoAKlWEW/jOFT4C8TPAp5oMjR7kPEbDlKupJiQ0cOACUQf8o
7eiEawNILGdo9xVnPkE9Zs7zRGvoxYphqhzRnPlcXdnVqf1ugBUvRO0CxOv8jM0=
=Bl8W
-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

Re: [docbook-apps] Programlistingco issue

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/21/2012 04:53 PM, Carlos Araya wrote:
 We had an earlier conversation about using area spec with 
 programlistingco and how it would not work giving coordinates, and 
 arrived to examples like the one below:
...
 When switching to Jing as my validator I get the following error
 for all the programco examples.
 
 /Users/carlos/experiment/docbook-epub/docbook-howto.xml:76:17:
 error: element programlisting not allowed yet; missing required
 element areaspec
 
 I've worked around this by inserting a dummy areaspec tag and its 
 children. Is there a way for me to eliminate the need to have
 areaspec as part of programlistinco? Is there a reason why I need
 to have the areaspec in an example that doesn't use them? Am I
 missing anything?

Hi Carlos,
I don't know the details of the previous discussion, but we only use
programlistingco when we're also xincluding the code sample in (with
parse=text). That way we can define the line and column number at
which the callout should appear in the code listing.

If we've got a code listing directly in the DocBook file, we instead
add co elements like you do in the example above. In that case, the
programlistingco element is not needed.

I believe you have to have the callout extensions set up for the
areaspec method to work.

As usual, Bob's book [1] has lots of valuable information.

David

[1] http://www.sagehill.net/docbookxsl/AnnotateListing.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP45zTAAoJEMHeSXG7afUhh+cIAIA7Gzpbfjld0tmtLhmQOzlA
+8fzPKHw6R48YGMl/6s202kojRo6RAb2cKI19T3zinVDQBTuDGDsDZwPB0y/D25R
YUvNGwca2mLC/8SxeZwXTDWWOSKRjRt2KKnr4dNok/D+fB/O9Tr8+xqaBhmDB7sw
kQLUacNqkFYV05mdSMddmPbgVqHmm6CNHsJGTCkjstVSk5RDvcGqkhcDkAIOreGz
ZFbna/bbCvexZcfb6dvxfyKMRrgfz0C3OjtjxaWwQ4hU6Mm3ckQe4mpDHX2RKpXA
hhBaoDHVoA2LFFLjhMO8EiJaeZVENVZSJELLts9x4DxnMJez1EQ6rYJNShaJSXA=
=u+qo
-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

Re: [docbook-apps] Customizing html/head/title in chunked output

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Btw., I created a template named user.head.title for this:

http://docbook.svn.sourceforge.net/viewvc/docbook/trunk/xsl/html/docbook.xsl?r1=9396r2=9432

David

On 06/19/2012 12:38 PM, Bob Stayton wrote:
 Hi David, I think that is a good idea.  Go for it.
 
 Bob Stayton Sagehill Enterprises b...@sagehill.net
 
 
 - Original Message - From: David Cramer
 da...@thingbag.net To: DocBook Apps
 docbook-apps@lists.oasis-open.org Sent: Tuesday, June 19, 2012
 7:37 AM Subject: [docbook-apps] Customizing html/head/title in
 chunked output
 
 
 Hi there, I needed to modify the content of html/head/title in
 chunked output and ended up overriding the named template
 head.content. It would be nice not to have to override such a big
 template to modify the content of the title of each html page.
 Should we instead do a call-template and provide a named template
 so the user can more easily customize this?
 
 I notice that the content of the title ultimately comes from 
 xsl:apply-templates select=$node 
 mode=object.title.markup.textonly/, so I could also override a 
 template matching * in the mode object.title.markup.textonly, but
 I suspect that would have undesired side effects beyond the content
 of html/head/title.
 
 Btw., my modification is to add the book title to the
 html/head/title. When you host several chunked books on a single
 domain, some of which contain sections with the same title, then
 the Google search results end up showing several hits in that
 domain with the same title. Adding the book/document title to each
 chunk's html/head/title provides more context in the Google
 results.
 
 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
 

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

iQEcBAEBAgAGBQJP46ATAAoJEMHeSXG7afUh4d4H/jeksSZFFZC1mrtN8eMyh1k1
V/Z+eGiINIrWzbqAFMNhGWU7BacM1gGGT6Qf3UaO3BYhQPauCt6lBQppZLFgerLW
/2tU5+4L+REyyK7vwLHpaHaowtrRtpCkYGgjWomAIEA6jXVujEolt43X8NJ4e4Vz
KP7/iPL9AmgIR4UBrXpkbrc8893Wtki2z4m3u2sLEeR6TaPqlVy9Fs3oeBsh6IAp
Ix1wYrYRuh0ihQV5gtgKbCDgdHje8vhwY1gtniu63nRFBQ/TvGdfXoHiOnM6dCCa
XpSA1RSeJum1IB8e1sZYkZKgpqAY3xLW5r8GZuOVam64C5D2QAKYTCX/XrAqA3s=
=hn00
-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

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

[David Cramer]

-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
 
 
 
 
 
 !-- 
 
 --
 
 !-- ==
 == --
 
 !-- == Saxon Converter macro that uses commons-resolver
 == --
 
 !-- ==
 == --
 
 !-- == input: The file to transform
 == --
 
 !-- == output: The transformation result
 == --
 
 !-- == style: The Style Sheet used for the transformation
 == --
 
 !-- ==
 == --
 
 !-- 
 
 --
 
 macrodef name=saxon
 
 attribute name=input/
 
 attribute name=output/
 
 attribute name=style/
 
 sequential
 
 java classname=com.icl.saxon.StyleSheet fork=true
 
 dir=${basedir} classpathref=dbf.classpath
 
 arg line=-x org.apache.xml.resolver.tools.ResolvingXMLReader/
 
 arg line=-y org.apache.xml.resolver.tools.ResolvingXMLReader/
 
 arg line=-r org.apache.xml.resolver.tools.CatalogResolver/
 
 arg value=-o/
 
 arg value=@{output}/
 
 arg value=@{input}/
 
 arg value=@{style}/
 
 /java
 
 /sequential
 
 /macrodef
 

-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

[docbook-apps] Customizing html/head/title in chunked output

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi there,
I needed to modify the content of html/head/title in chunked output
and ended up overriding the named template head.content. It would be
nice not to have to override such a big template to modify the content
of the title of each html page. Should we instead do a call-template
and provide a named template so the user can more easily customize this?

I notice that the content of the title ultimately comes from
xsl:apply-templates select=$node
mode=object.title.markup.textonly/, so I could also override a
template matching * in the mode object.title.markup.textonly, but I
suspect that would have undesired side effects beyond the content of
html/head/title.

Btw., my modification is to add the book title to the html/head/title.
When you host several chunked books on a single domain, some of which
contain sections with the same title, then the Google search results
end up showing several hits in that domain with the same title. Adding
the book/document title to each chunk's html/head/title provides more
context in the Google results.

David

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

iQEcBAEBAgAGBQJP4I6+AAoJEMHeSXG7afUhkMkIAIFSH8RFvrOP72h91IiHLgRT
HPhVawSmyWzPEHgb7tnPhPpMj3VPcqijox1gZrTPjQLWo9LZ+OB7WQ1D+gS6P51z
1ca0FFT1vJaHMuKDrTpRtg+mRfv56DdJl/KyyuCap1QBbKArK4OAiHd+ZQa0xm4t
hqBI9Zz+6Mwm3zemTUTHrJhu6ZLrrjVUYmodVkN2oW84nQLuXwMuMSkK1F7QDjYf
0eO2jporlsoiya56aDvGU4SUPAUyemK4n0kUxNEFS575YlrsBJtrcv7ngEq5Bsiq
TdPY9CcJ8iuuDGwd+vuJ1aslv+20RzIT23c8kBpPLd8DUzVzUP3aovBxEuCgETQ=
=q/ni
-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

[docbook-apps] Error from DocBook xsls: XTTE0780: Required item type of result of function f:normalize() is document-node();

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi there,
I'm using the xsl 2.0 stylesheets. When I set the preprocess param to
normalize:

  xsl:param name=preprocess select='normalize'/

I get the following error:

Error on line 31 of 4-normalize.xsl:
  XTTE0780: Required item type of result of function f:normalize() is
document-node();
  supplied value has item type
element({http://docbook.org/ns/docbook}book, xs:anyType)
  at f:normalize()
(file:/home/dcramer/Downloads/docbook-xslt2-2.0.3/xslt/base/common/preprocess.xsl#106)
  at f:preprocess()
(file:/home/dcramer/Downloads/docbook-xslt2-2.0.3/xslt/base/html/docbook.xsl#73)
Transformation failed: Run-time errors were reported

I'm still trying to get my head around the way the xsls do
preprocessing, but I thought I'd see if anybody has seen this error.

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

iQEcBAEBAgAGBQJP4N2rAAoJEMHeSXG7afUhH/MIAJGyOmYtcd0ddCS0d47VEY0V
lfluxpkvQJ+loO41reE1BWHmugk1tXhLbVTyLHmk0ne7PYtnSDfZHi/r9srHMRSi
v6xXYAbr3PZNuh+me+KJd67vhZKqrw/Cw3uS6YnBtW2f2dWxKL5oUDLlklh5Tkc8
oRxbMMsmaD/4fsYqkWDVEcEybb6eO0uSngFdxUJx5F2Rez8agZ7Uz7zS4KUXl/Eu
3tB/EP/H19ASWq+Gi14DdoXeCYsmNpzvmPQ8WR6En06g4hTlA5OndUaT8cUJ1veI
Hy4+i+/Xnw7RNprIlESDgA6+N0aoDr/YEKvoUfH7OQ4tHiWqBOOuFCT3LmORnZ8=
=A02+
-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

Re: [docbook-apps] Error from DocBook xsls: XTTE0780: Required item type of result of function f:normalize() is document-node();

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/19/2012 04:30 PM, Jirka Kosek wrote:
 On 19.6.2012 22:14, David Cramer wrote:
 
 I get the following error:
 
 Error on line 31 of 4-normalize.xsl: XTTE0780: Required item type
 of result of function f:normalize() is document-node();
 
 Hi David,
 
 I have fixed this in
 
 https://github.com/docbook/xslt20-stylesheets/commit/929bf17e5017a9c71b9adec947424cc0949d9522

  but I still don't understand why error is raised in the first
 place.

Thanks, that does the trick. Yes, it's puzzling that the other
preprocessing functions work fine without this.

 I'm still trying to get my head around the way the xsls do 
 preprocessing, but I thought I'd see if anybody has seen this
 error.
 
 Look at xslt/base/common/preprocess.xsl. There is function
 f:preprocess which applies pipeline of preprocessing steps. In
 order to improve performance only steps enabled by preprocess
 parameter are applied. Preprocessing steps are done in a fixed
 order, and there are two steps for doing user-defined document
 massage -- preprofile and postprofile. By default those are just
 identities.

Ok, thanks. I want to use normalize to have the autoglossary code
invoked.

 Let me know if you hit any problems. I wrote this code 2 years ago
 and not used it since then.

I notice that the preprocessing steps are only used by the monolithic
html xsls and not by chunk.xsl. I'll take a stab at moving it over to
chunk.xsl as well.

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

iQEcBAEBAgAGBQJP4PVRAAoJEMHeSXG7afUhu7QH/1b6PDtfnVNgEeRKXhEpvGcz
+ZceXMtstWid1Fwx1iyznvTlQ7OECJAdLMBJkfiu4oulnIFfB8nGLn59DH+QoMGv
Hwxx0ejQUtLhXnEqxKUq6RJ3x9lWIfhKV+Yqf4S/7rmAekVo388Tog9LOtHvnLjn
hc36g5s3A8sGwwHG0XsPFqi/I3CNeoLUhnfi2hALZNXaO+exzZRU++jQnJ8Xj9M1
PmLZXGDx4d1ymsEtIVAGzXcRor9jRCV6fbuqOWv+bHxKDWGyc8VbZGFgUGB5tMQO
sV5zJ5FSC50tww4Gtg/OPj+8sM7rPjYzbR1DLQnfy2w5lTL0YkstYULIQiKThZA=
=AL48
-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

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

[David Cramer]

-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:
 
 !DOCTYPE div PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN 
 http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; div
 element=set ...
 
 My workaround for now:
 
 1. Build using collect.xref.targets=only.
 
 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
 

-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

[docbook-apps] DocBook xsl 2.0 stylesheets giving FORG0002:Base URI {} is not an absolute URI

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm getting the following error using the DocBook 2.0 xsls as part of
a Calabash pipeline:

Message: Entering xproc pipeline: war
Message: Validating post-xinclude
Jun 13, 2012 2:38:16 PM
com.xmlcalabash.util.DefaultXProcMessageListener error
SEVERE: 872:err:FORG0002:Base URI {} is not an absolute URI
Jun 13, 2012 2:38:16 PM
com.xmlcalabash.util.DefaultXProcMessageListener error
SEVERE: Base URI {} is not an absolute URI
Jun 13, 2012 2:38:16 PM
com.xmlcalabash.util.DefaultXProcMessageListener error
SEVERE: Base URI {} is not an absolute URI

Early in the pipeline, I do:

  p:add-xml-base/
  p:xinclude fixup-xml-base=true/

Tests prove that that by the time the DocBook xsls see it, the DocBook
looks like this:

book xmlns=http://docbook.org/ns/docbook;
xmlns:xlink=http://www.w3.org/1999/xlink; status=DRAFT
version=5.0
xml:base=file:///home/dcramer/Documents/rax/git-demo/src/docbkx/example.xml
xml:id=example-foo xml:lang=zh
...

At this point, I'm not sure what to try next.

I'm running Calabash 0.9.38 (from within Maven) and the latest version
of the DocBook 2.0 xslts.

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

iQEcBAEBAgAGBQJP2PHYAAoJEMHeSXG7afUh5oIH/RVHrUw8JvBADPMsmWsy1LVG
vT1VyftFhiQ6g/yM55jPHl1DuB16uCUK+gQRlp0pPbr7OaH1wqnybzDW0nhCEhH0
X4qRmBvlEhch12YzXVt8YZoEylKbU4xjIB3Mu/bgHsabe2TYPizro/AXv9oTH3oM
qjW94BCW5MK3lsStLKmxBcwOvhnHTPBiqT3vJWUkYzzjP0kNbdftgCabyeuiqusl
RzeTybSGR3/rzu4/iGNR40bd/v02sJEMZnJGdQnFPjb40dN7k4o8Ix/1Ey5QVIOj
mw2wQRZytEFK8GVVn+tle7KDdIelidsFF1ZMOGucFur9jKE9c+ru9sLmWxPq74k=
=A7yy
-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

[docbook-apps] DynaTree Plugin issues

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Arun,
Replying from my thingbag address (I don't check the gmail addr that
often).

Of the two features, persistence is a must-have. I'm hoping that
having the toc stored in a cached .js file will improve performance
for large docs since it will prevent bloating the size of even small
chunks with the whole toc. I don't think we can know for sure without
some experiments though.

David

- ---

Hi David,

I could write about the issue in this e-mail but i would prefer to
chat with you.

The issue is about getting the persistent feature with lazy loading.

Will talk to you tomorrow about this.


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

iQEcBAEBAgAGBQJP0fHzAAoJEMHeSXG7afUhZ5kH/2TRpAaVy/lslX6Dc5ry8eO5
viCbojM5vqF7Rz3ymv33V4Usk+LIniEum28R4KfahkZpjrIWm4UuyNxigyLaCkXX
MNcz1NE8scjbDLVD0X7paxRbVUcFSmFNtYeSvGeyX82CS2RqdYCMtlz5JxgDpWn+
+QWWWkcNQ15Fa0AuL4FGB+2+xFkAYK+FWLSbQht4CxkO1Wuc3M7XdQTYMPEdxrrG
nBlE63K3/XJBZsC1tX3hjPAhamCEDUOjYqeCm/bKPlQvByXDLutLGUR9CV9g9bMm
Clano+jFwv8FqTNZZ8eucDfgS5sL0t/cveDvvqt64zE01BEOanVuKUK174N9/+s=
=0mf1
-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

Re: [docbook-apps] Should ie.css be included by default in the generated webhelp files?

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Derek,
Btw., I've committed a fix here:

http://docbook.svn.sourceforge.net/viewvc/docbook/trunk/xsl/webhelp/xsl/webhelp-common.xsl?r1=9400r2=9402

It's available in the snapshot:

http://snapshots.docbook.org/

Or you could implement it in a customization layer.

Let me know if there are any further quirks related to this. I don't
spend much time in IE, so often miss bugs that affect only IE.

Thanks,
David

On 06/05/2012 12:09 PM, Derek Van Kooten wrote:
 Wow, yeah, there is no way I would have figured that out. I just
 went ahead and changed some of the css files so that the margin-top
 attribute is set to 0, and the padding-top is set to 120. I tested
 that in both IE and chrome. Both seemed to work fine with those
 settings. Now I dont know if that will break other browsers since
 that was all I had to test with. But, if the conditional css is the
 better way to go then i'll switch it back and try to use what you
 have here. Or, if this is a bug, should I just wait till the next
 release and it is fixed? Suggestions?
 
 On Tue, Jun 5, 2012 at 1:04 PM, Carlos Araya
 carlos.ar...@gmail.com mailto:carlos.ar...@gmail.com wrote:
 
 David:
 
 I think you need to close the xsl:text element on the first line
 of your comment.  I think it should be
 
 xsl:commentxsl:text[if IE]/xsl:text
 
 Carlos On Jun 5, 2012, at 9:57 AM, David Cramer wrote:
 
 Ok, guess that's a bug in webhelp. This is how I have that in my 
 customization layer:
 
 xsl:commentxsl:text[if IE] lt;link rel=stylesheet
 type=text/css
 href=../common/css/ie.css/
 lt;![endif]/xsl:text/xsl:comment
 
 David
 
 On 06/05/2012 11:55 AM, Peter Desjardins wrote:
 Have you tried the xsl:comment element?
 
 http://zvon.org/comp/r/ref-XSLT_1.html#Elements~comment
 
 Peter
 
 On Tue, Jun 5, 2012 at 12:34 PM, Derek Van Kooten 
 derek...@gmail.com mailto:derek...@gmail.com wrote:
 I am using version 1.77.0
 
 I noticed that the generated webhelp files do not look
 correct in Microsoft Internet Explorer. I dug into it a
 little to see what was going on. The div named content doesnt
 have padding-top css attribute being set. The include for
 ie.css is missing in the generated files. So, the content div
 is aligned to the top of the browser in my generated content
 instead of being below the header div like it should be.
 
 I see in some of the example sites that they have this 
 conditional css line
 
 !--[if IE] link rel=stylesheet type=text/css 
 href=../common/css/ie.css/ ![endif]--
 
 In my generated webhelp none of the generated html files
 have this line. I tried to add this into webhelp-common.xsl
 but I cant figure out how to get those html comments into it.
 It wants to treat them like comments to the xsl file and
 ignore them.
 
 
 -

 
 
 
 To unsubscribe, e-mail:
 docbook-apps-unsubscr...@lists.oasis-open.org 
 mailto:docbook-apps-unsubscr...@lists.oasis-open.org
 For additional commands, e-mail: 
 docbook-apps-h...@lists.oasis-open.org
 mailto: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/

iQEcBAEBAgAGBQJPz4RwAAoJEMHeSXG7afUhGDkH/iatA/3Ak+pFR/3GNgxse7Vm
hx9K6dWufWIJI6H5/5sBVESHPUkeb+aQfTk8jszYjOySJ+WOPxl/w/k6t3pxod1o
J4xrX9Y0Y7L+zMwly0yB77pjoTtFPVNfESkKYfhR0jqthoHClUVS+NlpGyci7G/y
7bfa4IyQ4GGNSe3G0m583eMbmjHotm1KpWUrzWEruW6OXTCqLn0BBSL/07ebsnNM
0aEqg96UHjd3SA146cL0amsNjNUMliLNPPEsz1AcvgQHJSpHO+SS9qLA45+Sv5+N
98yhKr+0uXkVaA/Kgs/Dixo0zTfLNfzh1DDh4m5aVNnlDP9SUAqH8TWqcX2WqE8=
=+wHW
-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

Re: [docbook-apps] Should ie.css be included by default in the generated webhelp files?

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ok, guess that's a bug in webhelp. This is how I have that in my
customization layer:

xsl:commentxsl:text[if IE]
lt;link rel=stylesheet type=text/css href=../common/css/ie.css/
lt;![endif]/xsl:text/xsl:comment

David

On 06/05/2012 11:55 AM, Peter Desjardins wrote:
 Have you tried the xsl:comment element?
 
 http://zvon.org/comp/r/ref-XSLT_1.html#Elements~comment
 
 Peter
 
 On Tue, Jun 5, 2012 at 12:34 PM, Derek Van Kooten
 derek...@gmail.com wrote:
 I am using version 1.77.0
 
 I noticed that the generated webhelp files do not look correct in
 Microsoft Internet Explorer. I dug into it a little to see what
 was going on. The div named content doesnt have padding-top css
 attribute being set. The include for ie.css is missing in the
 generated files. So, the content div is aligned to the top of the
 browser in my generated content instead of being below the header
 div like it should be.
 
 I see in some of the example sites that they have this
 conditional css line
 
 !--[if IE] link rel=stylesheet type=text/css
 href=../common/css/ie.css/ ![endif]--
 
 In my generated webhelp none of the generated html files have
 this line. I tried to add this into webhelp-common.xsl but I cant
 figure out how to get those html comments into it. It wants to
 treat them like comments to the xsl file and ignore them.
 
 -

 
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/

iQEcBAEBAgAGBQJPzjqRAAoJEMHeSXG7afUhX3sH/jBYtwLUzMIT7gZJbMRokPvS
mBPJ5b1CsUPexzCsvuWPE5N3yWHhddNe91s5XpHdi5NoTpsibQte7ObD0EPO3SR5
Su2FADQ5qQNoYPlFO9/E/AvTVPVMigoQ801NzcVvZfV41+vKg9zC0dysap4F6QxH
KpulDsu4Fa7fX++JuDP06kvJ20k07usqTt+0FLLw5XE3TfDjUXE6FevG17+/goEH
QEsbK8ejVPLg3iDENpIWOxZwzcymB6vbHDlYKBmJSkMxOTMO8B4eia/gGwoRXNgF
4zxAagqD8evJQkAH+0LAJTM3ndZ2iOmR0aEjX9MGeni68npi4d5f/UqaUzJIFFE=
=Kh9l
-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

Re: [docbook-apps] Should ie.css be included by default in the generated webhelp files?

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Carlos,
Actually, it ends up working out ok since I've escaped the  signs as
lt; inside the xsl:text. Those come out as  in the generated html.
This is in the customization layer that produces the books posted
here, so I know it works :-)

http://docs.rackspace.com/api/

I'm adding this to webhelp-common.xsl (~ line 220) and will commit
once I've tested it.

David

On 06/05/2012 12:04 PM, Carlos Araya wrote:
 David:
 
 I think you need to close the xsl:text element on the first line of
 your comment.  I think it should be
 
 xsl:commentxsl:text[if IE]/xsl:text
 
 Carlos On Jun 5, 2012, at 9:57 AM, David Cramer wrote:
 
 Ok, guess that's a bug in webhelp. This is how I have that in my 
 customization layer:
 
 xsl:commentxsl:text[if IE] lt;link rel=stylesheet
 type=text/css href=../common/css/ie.css/ 
 lt;![endif]/xsl:text/xsl:comment
 
 David
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPzln3AAoJEMHeSXG7afUhrfQH/RjUhOC16z/S9aPadDZ1KDrg
U0nKWfPCsknXRQNS8nLJRc3WgilFB9UgRx0b2mENccLUgiCcra80dsCmytXRS4fp
5yE9O48Q2eqMuQ965NwyizOiqXE8j3KwfcxqYigZ4QzL4k2o6jSiMTOX99uF//gN
xKNsmjww0NA8UyIpnt7lPWZeQF8KFLs7qvuFw9DajeK1HE2iAXZam2eBP0Qu86r/
15Mhj17af8pmAEO/cENCqo20SeFsKt97nzszUvOARYLc1e6LDAKRDXTNw4lVoHck
tKL55jtWM0pzP9ojIG1yk/RW8LIUDCk8Y5TZziunQH0eCSiTDg66goYHjBJeBnI=
=BSbB
-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

Re: [docbook-apps] Is there any way to control what level a page break occurs at for webhelp?

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Peter and Derek,
This thread made me notice that chunk.section.depth is set to 1 by
default in webhelp. I've just changed that to 3 since that makes more
sense as a default value for webhelp (or maybe even a higher value
would makes sense). This change should be in 1.77.1 if it hasn't been
cut yet.

One thing I'll also mention in this context. If you decide to set
chunk.section.depth to a high value (something I do), there's a PI,
?dbhtml stop-chunking?, that lets you stop chunking at arbitrary
places in your tree so that a section with many subsections, now
becomes a single long page. This is useful if the subsections of a
particular section happen to be short:

http://docbook.sourceforge.net/release/xsl/current/doc/pi/dbhtml_stop-chunking.html

David

On 06/04/2012 09:45 AM, Peter Desjardins wrote:
 Try adjusting the chunk.section.depth parameter. I set mine to
 two.
 
 xsl:param name=chunk.section.depth select=2/xsl:param
 
 Other chunking parameters:
 
 http://docbook.sourceforge.net/release/xsl/current/doc/html/chunking.html

  Peter
 
 On Mon, Jun 4, 2012 at 9:19 AM, Derek Van Kooten
 derek...@gmail.com wrote:
 Ok, so I have the following structure to my document:
 
 
 ?xml version='1.0' encoding='UTF-8'? !-- This document was
 created with Syntext Serna Free. --!DOCTYPE book PUBLIC
 -//OASIS//DTD DocBook XML V4.5//EN docbookV4.5/docbookx.dtd
 [] book titleHelp Guid/title chapter titleWhats
 New/title paraDescribe here what is new in this release.
 Include links to sections that reference the fnctionality and
 some how tos./para /chapter chapter id=Installation 
 titleInstallation/title section id=Download 
 titleDownload/title paraThis section will be used to show
 how to download the link 
 linkend=Installationapplication/link./para /section 
 /chapter chapter titleReference Guide/title section
 id=AP_Vendor_Maintenance titleA/P Vendor
 Maintenance/title graphic
 fileref=images/ap_vendor_maintenance.png/ /section section
 id=AP_Not_Posted titleA/P Not Posted/title graphic
 fileref=images/ap_not_posted.png/ /section section
 id=AP_Checks titleA/P Checks/title graphic
 fileref=images/ap_checks.png/ /section /chapter chapter 
 titleHow Toapos;s/title section titleHow To Close a
 Month/title paraDescribe here how to close a month. Include
 pictures, links, etc/para /section /chapter /book
 
 
 So what I have here is a tree that only has two levels of nodes.
 The second level of nodes becomes pages when I convert it to
 webhelp. I would like to have three levels though. So for
 example, all of our Accounts Payable documents would be under a
 node called Accounts Payable. But, when I do that it creates a
 page for Accounts Payable, then each section under Accounts 
 Payable becomes just a section of that page. Now, I dont want
 that because each of those sections under Accounts Payable are
 going to be really long, and I dont want a web page that long. I
 want a page for each section under Accounts Payable.  Maybe a
 different way of asking is, when I have a tree of nodes two
 levels deep I get a page for each top level node, and a page for 
 each second level node. The top level node also shows a Table Of
 Contents for each child node it has. The second level nodes each
 get a page. But, when I go to 3 levels of nodes in a tree, it
 does not create a page for each 3rd level node. Is there way to
 make it do that
 
 This example above only has a few nodes just to show the example,
 but in our actual document we have about 60+ nodes at this level,
 this is why it would make more sense to break them up by group.
 
 Thanks.
 
 
 -

 
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/

iQEcBAEBAgAGBQJPzOZHAAoJEMHeSXG7afUhC8gH/1HFbqdxD7OTOUl9VC6aSYaT
HYyfhoZj/R6ssMkjnYCB925z4OhoDN4YD5I545aNC0mSTuCZ7nbSwcJbZEMZNYPh
mN2BCOVTPqcxX5myzjvv4yOGvJAQAsA4HcCq2WKu6/hZnG88Z2EJ2QyYTul95AyT
b5Rgm+tq3lS1d4ZdeNWGljwo0X0jdbHYql9AFquGPlclBjeZfMozRj9Qec2AZl3N
yTyIGwyoWdjlJNAvmeD1W7/MHZpiPW/ie8Vv/ndgoC/GKtjWSH8prQqpGcRq59Ja
ZMwsdHE9GAOY0HrMi7wlP8X8YZijsXLrnP+hX4cJGMeoN79LKqvTMCjor00VnAA=
=S2EH
-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

Re: [docbook-apps] Passing parameters to my XLS customizing sheet with Apache Ant

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi  Lars,
Have you put in your customization layer (perhaps at the top) a
declaration for the param you're passing in with a default value?

xsl:param name=footnotetext0/xsl:param

David

On 06/02/2012 02:26 PM, Lars Vogel wrote:
 Hello,
 
 I has customizing layer which adds a footnote to my pdf output. In
 this layer I have to define values for the different places
 frequently.
 
 -- xsl:when test=$double.sided != 0 and $sequence = 'even' 
 and $position='right' Example Example, Review version 
 /xsl:when
 
 xsl:when test=$double.sided != 0 and $sequence = 'odd' and
 $position='left' Example Example, Review version /xsl:when
 
 Is there an way to pass parameters to my customizing layer via the 
 Apache Ant build file similar to the parameters I pass to the
 standard XSL sheets? In standard I use for example the following:
 
 param name=chapter.autolabel expression=1 /
 
 I tried to use a similar approach:
 
 I pass the value via the following:
 
 param name=footnotetext expression=Example Example, Review
 version /
 
 I try to evaluate it via the following:
 
 xsl:choose xsl:when test=string($footnotetext) != 0 
 xsl:value-of select=$footnotetext / /xsl:when /xsl:choose
 
 I get the error message:  [xslt] 
 /home/vogella/workspace/docu/de.vogella.publishing/mystylesheets/mypdfdocbook.xsl:147:

 
Error! Variable footnotetext has not been declared
 
 What did I do wrong?
 
 Best regards, Lars
 
 -- Lars http://www.vogella.com - Eclipse, Android and Java
 Tutorials http://www.twitter.com/vogella - Lars on Twitter

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

iQEcBAEBAgAGBQJPynBrAAoJEMHeSXG7afUhhy4H/2o6Do+9+9/A0hDZ9DUYBuZE
XEjujJtpsGdFBeU+tC7JYQADTDvgFS4fKNx5UlS0x85l67loslG6mOBZw6n6qFPK
6iBwQ8hLogRTvguMDYT+wF1jEfQa5Zxgm1Cp3uqRjm0dqrzdtHGQUc18ZoeyQ2kx
076rEMNH+HG+f1RoPKgf7YU/zamVCQjAmyWLNQ18BsUGpCWyDxi2jJ0lmLZxRGfL
6x7HhaRIQ/wge3oY6/obxsWA74X9s5eGmeL7oU+zwUjzjQLhPayIMdMKNYHxX7w4
kKQW9hg1RlfvHxIRb2dLf9TimR6N5mZGcWnQCz74UuFBwmgwrLYn54VbdCV44/Q=
=F7+M
-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

Re: [docbook-apps] Missing Xerces Classpath definition in DocBook XSL 1.77.0 Webhelp Sample

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Dermot,
You do need to point to xercesImpl but you need to do that in the
build.properties file:

# Modify the follosing so that they point to your local
# copy of the jars indicated:
# * Saxon 6.5 jar
# * Xerces 2: xercesImpl.jar
# * xml-commons: xml-apis.jar
xslt-processor-classpath=/usr/share/java/saxon-6.5.5.jar
xercesImpl.jar=/usr/share/java/xercesImpl.jar
xml-apis.jar=/usr/share/java/xml-apis.jar

The xincludes are then resolved at the profiling stage:

...
xslt
 in=${input-xml}
 out=${xincluded-profiled.xml}
 style=../profiling/profile.xsl
 sysproperty
key=org.apache.xerces.xni.parser.XMLParserConfiguratio 
value=org.apache.xerces.parsers.XIncludeParserConfiguration/
...

Note that sysproperty is an ant 1.8.x feature, so be sure you're
using the correct version of ant.

It's important that the xincludes be resolved during the profiling
pass since you want the xincluded content to be profiled (not just the
content in the root file).

Hope that helps.
David

On 05/30/2012 11:22 AM, Dermot O'Halloran wrote:
 
 Hi,
 
 The xinclude contained in the Webhelp sample does not work unless
 you include Xerces in the Ant xslt task. The xinlcude is ignored
 with a Element include in namespace
 'http://www.w3.org/2001/XInclude' encountered in book, but no
 template matches. message:
 
 chunk: [mkdir] Created dir: C:\Program Files 
 (x86)\docbook-xsl-1.77.0\webhelp\docs [xslt] Processing C:\Program
 Files (x86)\docbook-xsl-1.77.0\webhelp\docsrc\readme.xml to
 C:\Program Files 
 (x86)\docbook-xsl-1.77.0\webhelp\docs\null172184698 [xslt] Loading
 stylesheet C:\Program Files 
 (x86)\docbook-xsl-1.77.0\profiling\profile.xsl [xslt] Processing
 C:\Program Files 
 (x86)\docbook-xsl-1.77.0\webhelp\docs\null172184698 to C:\Program
 Files (x86)\docbook-xsl-1.77.0\webhelp\docs\null734982840 [xslt]
 Loading stylesheet C:\Program Files 
 (x86)\docbook-xsl-1.77.0\webhelp\xsl\webhelp.xsl [xslt] language:
 en [xslt] Writing docs/content/ch01.html for chapter [xslt] Writing
 docs/content/ch02s01.html for section [xslt] Writing
 docs/content/ch02s02.html for section [xslt] Writing
 docs/content/ch02s03.html for section [xslt] Writing
 docs/content/ch02s04.html for section [xslt] Writing
 docs/content/ch02s05.html for section [xslt] Writing
 docs/content/ch02.html for chapter [xslt] Writing
 docs/content/ch03s01.html for section [xslt] Writing
 docs/content/ch03s02.html for section [xslt] Writing
 docs/content/ch03.html for chapter [xslt] Writing
 docs/content/ch04.html for chapter [xslt] Element include in
 namespace 'http://www.w3.org/2001/XInclude' encountered in book,
 but no template matches. [xslt] Writing docs/content/index.html for
 book [xslt] Writing docs/index.html [xslt] Writing
 docs/content/search/l10n.js [copy] Copying 92 files to C:\Program
 Files (x86)\docbook-xsl-1.77.0\webhelp\docs [copy] Copying 1 file
 to C:\Program Files (x86)\docbook-xsl-1.77.0\webhelp\docs\content
 
 Including the Xerces JAR in the xslt call as follows gets it
 working:
 
 xslt in=${input-xml} out=${xincluded-profiled.xml} 
 style=../profiling/profile.xsl classpath=${xercesImpl.jar}
 
 I'm not sure why the Xerces JAR needs to be declared explicitly in
 this case as the xinclude works if the sample is built using
 xsltproc from the command line (in Ubuntu). I'm using Java
 1.6.0_31.
 
 Rgds, Dermot

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

iQEcBAEBAgAGBQJPyEinAAoJEMHeSXG7afUhlwgH/0UxKSABDydIw+Bz3s9uTCyW
61sSkzdg+kAx34Kh6/6An49Orc3tPCfwmOxSZvsWRF1fWUlaiHTPKd1Vpo7O38q+
6vyVPpK1atYJCBVOZA6d7gdZ02lV8l1uTsOiceh0akytgSBmVG8gSGekqNbLles9
/MhC4qCp2jS4Su9eg3+xBcLqpFph/VVcRJI3jl9IYDo8UWDDx4YDnfPFJ+Uz4yLH
iy/q/yWU0DXEKqbnZ9m7vR0TBfxuEXOBtHfHisymsLXBZ59f845u8SD3VkY3xpCl
affChtku8v99HwlGkosgsCKlg+eywo3v6s8X6a3dUfCNB2+qCcbJZ/QqIGuIs00=
=EPyg
-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

Re: [docbook-apps] How to put a link at top of generated web help page

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/25/2012 10:12 AM, Derek Van Kooten wrote:
 So, I got my build process to generate a webhelp site and a pdf document
 from my docbook document. All is looking great. I figured out how to
 change the logo  and some of the colors on the generated site. Now, last
 thing I have not figured out yet. How can I put a link on the top of all
 those generated webhelp pages to point to some location, for example, my
 pdf file. I see that this has been done already on some example sites.  
 http://wiki.docbook.org/WebHelp  
 
 I like this
 one http://fusesource.com/docs/ide/2.0/user_guide/RiderGSEclipseRun.html# it
 has print and email buttons. Very nice!
 I would like to do the same and also a link to my generated pdf document.

So that's not currently an out-of-the-box feature, though someday it
should be. You'll have to do two things:

1. Figure out what you want the output to look like. I.e. do the webdev
work on the generated html till you're happy with the result.

2. Customize the xslts so that they produce that. You'll probably want
to add a parameter like pdf.url so you can pass in the name of the pdf
file name.

For #2, Bob's book is handy. It doesn't yet have information about
webhelp, but the general information about creating a customization
layer [1] applies. In fact, webhelp is a customization layer on top of
the xhtml xslts.

In your customization layer you can add the various extra things you
want: the pdf icon, calls to google analytics, some third-party
commenting system, etc. The cost is a little merge pain the next time
you upgrade the base xslts.

If #2 isn't something you're up to, you can pay someone to do it for you
[2].

David

[1] http://www.sagehill.net/docbookxsl/CustomMethods.html
[2] http://wiki.docbook.org/DocBookConsultancy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPv6cTAAoJEMHeSXG7afUhQFoH/1qCdqG1GBfSJ+MmeWfhRbDX
ms2l7hsb2CftzKajQzuSbDoecRb/JjIEmYCu5SZhQb+ZQO1+RihB3xOdiT9oC6pA
sbBhn9vqc0D7lDIIDLxMsvH+SsbX5vZ3yWX7Wq/TljL9PJcfpoTkE1GyGy2E9Idn
QMMhUozKTpSmaYpaQ66UlRRGKmihFKHnA4OJAxA0UgVk/cttqIX+f892emscm0jJ
chwN8aRK0+n2CB9P5ThJ+HoQGuWFMqPlMFLYdYngzNPCjFmEoAXB/rNdSOeJcMka
F3/t+q7nNh46vnM0rolLT4rEhQieteu1vO0WlMtxUqVkznEegMndmPBa5pgYHyg=
=gq5X
-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

Re: [docbook-apps] Getting errors trying to convert docbook to webhelp

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Derek,
Could you confirm that you've set the following properties in the
build.properties file?

xslt-processor-classpath=/usr/share/java/saxon-6.5.5.jar
xercesImpl.jar=/usr/share/java/xercesImpl.jar
xml-apis.jar=/usr/share/java/xml-apis.jar

In particular, xslt-processor-classpath must point to the Saxon 6.5 jar.

Thanks,
David

On 05/24/2012 12:16 PM, Derek Van Kooten wrote:
 Hello,
 
 I am trying to convert a docbook xml file to webhelp. I downloaded
 ant 1.8.4. I created another build.xml file that referenced the
 original build.xml file as outlined in the instructions. I then
 tried to run it and I got the following output.
 
 Buildfile: 
 C:\Users\dvankooten\workspace\SmartWerksServerLibraries\docbook-xsl-1.77.0\webhelp\build2.xml

  validate:
 
 clean: [delete] Deleting directory 
 C:\Users\dvankooten\workspace\SmartWerksServerLibraries\docbook-xsl-1.77.0\webhelp\docs

  chunk: [mkdir] Created dir: 
 C:\Users\dvankooten\workspace\SmartWerksServerLibraries\docbook-xsl-1.77.0\webhelp\docs

 
[xslt] Processing
 C:\Users\dvankooten\workspace\SmartWerksDocumentation\help2.xml to 
 C:\Users\dvankooten\workspace\SmartWerksServerLibraries\docbook-xsl-1.77.0\webhelp\docs\null49735160

 
[xslt] Loading stylesheet
 C:\Users\dvankooten\workspace\SmartWerksServerLibraries\docbook-xsl-1.77.0\profiling\profile.xsl

 
[xslt] Processing
 C:\Users\dvankooten\workspace\SmartWerksServerLibraries\docbook-xsl-1.77.0\webhelp\docs\null49735160

 
to
 C:\Users\dvankooten\workspace\SmartWerksServerLibraries\docbook-xsl-1.77.0\webhelp\docs\null579551438

 
[xslt] Loading stylesheet
 C:\Users\dvankooten\workspace\SmartWerksServerLibraries\docbook-xsl-1.77.0\webhelp\xsl\webhelp.xsl

 
[xslt] : Warning!
 file:/C:/Users/dvankooten/workspace/SmartWerksServerLibraries/docbook-xsl-1.77.0/xhtml/autoidx.xsl:

 
line 547: Attribute 'href' outside of element.
 [xslt] : Warning! 
 file:/C:/Users/dvankooten/workspace/SmartWerksServerLibraries/docbook-xsl-1.77.0/xhtml/autoidx.xsl:

 
line 596: Attribute 'href' outside of element.
 [xslt] : Warning! 
 file:/C:/Users/dvankooten/workspace/SmartWerksServerLibraries/docbook-xsl-1.77.0/xhtml/autoidx.xsl:

 
line 596: Attribute 'href' outside of element.
 [xslt] : Warning! 
 file:/C:/Users/dvankooten/workspace/SmartWerksServerLibraries/docbook-xsl-1.77.0/xhtml/autoidx.xsl:

 
line 620: Attribute 'href' outside of element.
 [xslt] : Warning! 
 file:/C:/Users/dvankooten/workspace/SmartWerksServerLibraries/docbook-xsl-1.77.0/xhtml/autoidx.xsl:

 
line 620: Attribute 'href' outside of element.
 [xslt] : Warning! 
 file:/C:/Users/dvankooten/workspace/SmartWerksServerLibraries/docbook-xsl-1.77.0/xhtml/lists.xsl:

 
line 815: Attribute 'type' outside of element.
 [xslt] : Warning! 
 file:/C:/Users/dvankooten/workspace/SmartWerksServerLibraries/docbook-xsl-1.77.0/xhtml/callout.xsl:

 
line 109: Attribute 'href' outside of element.
 [xslt] : Warning! 
 file:/C:/Users/dvankooten/workspace/SmartWerksServerLibraries/docbook-xsl-1.77.0/xhtml/xref.xsl:

 
line 181: Attribute 'href' outside of element.
 [xslt] : Warning! 
 file:/C:/Users/dvankooten/workspace/SmartWerksServerLibraries/docbook-xsl-1.77.0/xhtml/xref.xsl:

 
line 966: Attribute 'href' outside of element.
 [xslt] : Warning! 
 file:/C:/Users/dvankooten/workspace/SmartWerksServerLibraries/docbook-xsl-1.77.0/xhtml/formal.xsl:

 
line 208: Attribute 'id' outside of element.
 [xslt] : Warning! 
 file:/C:/Users/dvankooten/workspace/SmartWerksServerLibraries/docbook-xsl-1.77.0/xhtml/formal.xsl:

 
line 419: Attribute 'id' outside of element.
 [xslt] : Warning! 
 file:/C:/Users/dvankooten/workspace/SmartWerksServerLibraries/docbook-xsl-1.77.0/xhtml/htmltbl.xsl:

 
line 21: Attribute 'id' outside of element.
 [xslt] : Warning! 
 file:/C:/Users/dvankooten/workspace/SmartWerksServerLibraries/docbook-xsl-1.77.0/xhtml/inline.xsl:

 
line 96: Attribute 'href' outside of element.
 [xslt] : Warning! 
 file:/C:/Users/dvankooten/workspace/SmartWerksServerLibraries/docbook-xsl-1.77.0/xhtml/inline.xsl:

 
line 96: Attribute 'href' outside of element.
 [xslt] : Warning! 
 file:/C:/Users/dvankooten/workspace/SmartWerksServerLibraries/docbook-xsl-1.77.0/xhtml/inline.xsl:

 
line 131: Attribute 'href' outside of element.
 [xslt] : Warning! 
 file:/C:/Users/dvankooten/workspace/SmartWerksServerLibraries/docbook-xsl-1.77.0/xhtml/inline.xsl:

 
line 131: Attribute 'href' outside of element.
 [xslt] : Warning! 
 file:/C:/Users/dvankooten/workspace/SmartWerksServerLibraries/docbook-xsl-1.77.0/xhtml/inline.xsl:

 
line 171: Attribute 'href' outside of element.
 [xslt] : Warning! 
 file:/C:/Users/dvankooten/workspace/SmartWerksServerLibraries/docbook-xsl-1.77.0/xhtml/inline.xsl:

 
line 171: Attribute 'href' outside of element.
 [xslt] : Warning! 
 file:/C:/Users/dvankooten/workspace/SmartWerksServerLibraries/docbook-xsl-1.77.0/xhtml/inline.xsl:

 
line 693: Attribute 'href' outside of element.
 [xslt] : Warning! 
 

Re: [docbook-apps] How do I get the generated content to use a specific name

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Derek,
You'll find some good information about this in Bob Stayton's book.
Regarding how to control the names of chunked files, see:

http://www.sagehill.net/docbookxsl/Chunking.html

When you cross reference to a page using xref with a linkend
attribute, then the link text and target file name are computed
automatically. If you use link and linkend, then just the file name is
computed automatically and you can supply your own link text:

http://www.sagehill.net/docbookxsl/CrossRefs.html

If you want to link between files, you can use olink, but that
requires that you set up an olink database.

David

On 05/24/2012 02:59 PM, Derek Van Kooten wrote:
 I see some of the samples listed use very specific names for their 
 content. For example
 
 http://docs.rackspace.com/files/api/v1/cf-devguide/content/Additional_Resources-d1e388.html

 
 
 Notice how the name of the page is Additional_Resources and the
 content is about Additional Resources.
 
 When I run the program I get generated names like /ch01s02.html
 
 Thats all fine and good. But if I have a specific page of content I
 want to link to, I need it to have a name that doesnt change. For
 example, lets say I have a chapter that documents how are invoice
 system works. Well, I would like the name of that generated page to
 be /invoice.html or something like that, so I could then link to it
 from our application.
 
 Is there some tag or something I can put on that chapter to get the
 name of the page that is generated to be something specific?

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

iQEcBAEBAgAGBQJPvpt9AAoJEMHeSXG7afUhbt0H/RxT5KRdy+NTLPVBUXxDI30v
c2oFzUMUwO1VmLJmYaFEyRdsYWCt/eQR5qI7VEDAAH4pDzZO/G/l9rpFMjtM721E
sxN4SPTJ0QnrpNWA7/VC2ALfIPDRWSLln5BeAnqTI+qbkkgSXkF5LFaMzI3kJdYt
g7me2vp1eREJ/vGv0a5RWpWDZT18UmI9rQ3ZQj4A7SjGychZE/e+8KeMYwhUy7pN
lkyQUNrqqV5qPCyvZ5EHL3vuzxJA+mwuqR2C+2/L4ElZHYCb33Sd8pE01R1NoLub
nlJqPnFyYdAhphDt4pNanc4w3s4rYSYDzgyXbZIKvREJq8AAy1PdrQ+TQ1Gu9I4=
=btwR
-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

Re: [docbook-apps] webhelp with custom build.xml

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/24/2012 03:31 PM, Bob Stayton wrote:
 Hi, I'm trying to get the webhelp in 1.77.0 working.  I don't want
 to change the distribution files, so as recommended I've created my
 own build.xml in the directory with my doc files, and it imports
 the webhelp/build.xml file.  I can set properties and such before
 the import and that works.
 
 But the webhelp target  fails at the profiling step because the
 path to the profiling stylesheet is
 style=../profiling/profile.xsl in webhelp/build.xml, and that
 path is taken as relative to my custom build.xml file, not
 webhelp/build.xml, so the path fails.  Is there a way to have that
 path read as relative to webhelp/build.xml rather than my custom
 build.xml?

Hi Bob,
I'm having trouble reproducing this, though someone else reported the
same thing. Could you zip up a small test project and send it to me
offlist so I can have a look?

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

iQEcBAEBAgAGBQJPvqBeAAoJEMHeSXG7afUhNiAH/1UpMZhvUDeWpOP0/zxSrBTd
dEfjcaNPSmwH5RGRyBPUiPehbA4K3uZXykkpWO5eS5lhrdN3Eq0i6VZPOV2lgaBv
hl0WWCLr3Y88Ey1a9fSXdRaMdDHLEiLwxCbrYmxhmkWfJJQMyOT97zxOWFS576ez
id/e4lp3jljG1pUVRKWoP2NP+PBp3IJ3PnXbQVsPGN1CQYdsB8fEDYmm3ntQPj+l
eF7/F/WGqoDTDd6XTW16uWtUoLb3LaJETosvE5BINs12hiMKC0SOS6sCA+CpDrUM
Cn6ZXNnSz4xlIPT01scd65BHf2wDKNiSp1z3sYjYAdh9Z642grCg0nf9lisKnxo=
=ah+2
-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

Re: [docbook-apps] webhelp with custom build.xml

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/24/2012 04:28 PM, Jirka Kosek wrote:
...
 I think that this is a bug in webhelp/build.xml. Path should use 
 property which is set to location of master build file, e.g.:
 
 style=${ant.file.dir}/../profiling/profile.xsl
 
 I can't test this now, so I'm not commiting this change into
 repository.

Thanks Jirka. I've committed that change.

David

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

iQEcBAEBAgAGBQJPvvuYAAoJEMHeSXG7afUh8igH/2smTLNxTOGvQDU4DSuSb5Nh
Eu9VB9UgOGiAQ+ryut5H/j0Wcrm+pf8KnE9OtP4JtO3xhxkTilgcVJZv04k7J+bT
W0qb0GqMNOuvFT5I+VXxHLBKTM5sCj3Emc75s34IYxi7x3EUSkbmG11f/utzSuSt
LNfmpp8KzwG9W8zSmoYvZhyCFDWVMuubo5O+7U8kbB51MzmfowkfRhaNRqk/v0i5
imgU8O3QxU/wcN3QgHLCc9IlWBvkjKsd2B7HVcEpwr80sJmBGv/+F4jP4kzjpOlJ
CRnL69zCTBknoeV1Uun8r/QzfeN2JMf7VbePT4GNvDMpoxuxIqg0Lu/gtWqNB8Q=
=JO27
-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

[docbook-apps] What does title mean in generate.toc entries

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've long wondered about this. In the param generate.toc, what does
title do in an entry like the following:

article toc,title

See:
http://docbook.sourceforge.net/release/xsl/1.76.1/doc/html/generate.toc.html

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

iQEcBAEBAgAGBQJPu6MnAAoJEMHeSXG7afUhENcH/RENNOGUKCzDa6lKSGtKiaIe
PVwSlbr/LvBTIaPlnI/3sTcHzQUgtQAFblEdcqI/boKRaPkE18SU1FmYB/Iv2Ogl
9OkTguDbc4ntjxpkkiyPcmYxBLHD2u8nFE3T3WGhLw93mJ3bHfsNAxE4+wVdDzya
o2WG5rLLjyn75/ZTjol+nDuQtzkb4HecEqLwKq0VQ6eeZZVpYwEO5lgwtkBruLnO
RILpamL+woQrCVptuc1rL9efv5dl8OjWVxyOtNr8xM3ucJSdkgYVEXo0glIncFsc
CXG7laX9E3K7yE+QYmVMVIHQRdZ157BbuBrW9XLEEA50Uh4ipmxwWHyFTSjk848=
=zai2
-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

Re: [docbook-apps] What does title mean in generate.toc entries

[David Cramer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/22/2012 09:47 AM, Thomas Schraitle wrote:
 
 According to Bob's book, chapter 10. General customizations[1]:
...
 [1] http://sagehill.net/docbookxsl/TOCcontrol.html#TOCcomponents

Ok, makes sense now. I should have thought to check Bob's book.

Thanks,
David

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

iQEcBAEBAgAGBQJPu7MHAAoJEMHeSXG7afUh+cUIAJqJoY1s/Zi+qx44YAciLZH9
61+92Fuc+fmsRQCIpjcqMl9FVciytGL5DJFJWvKCY4n4R6f6JU0i0TCe95TZ+yW+
LQMP/MJiVSUZfLUxL9yK3CX0pdxzq1hLTG8v92aKY46jikSQEK9phqHo3odz6g0I
HT96gD9Mg7e6NAi1uJ8wp0Xq0IvccT+tm2ezQ85msTvd6FqAwZI93gJEqNWbhU/O
8BlGrEFMfxOHwXqppd6nLdfuCMqEg3daA9ywi66vdebQFA769JQ2qeZNOvmJhs1C
aSbQXPP262JgXnMhOyMognfla/aRdKtOvL/qWbAgfD/TosmPU4uzOaLcipWkQWo=
=fv9J
-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