Re: [docbook-apps] Coloring only internal links in FO?

[Chris Ridd]

On 02 May, 2014,at 08:07 AM, Mark Craig  wrote:

Hello,

What is the right way with the 1.78.1 stylesheets to color only internal links 
in FO?

I'd like to deactivate external olinks in PDF output with 
activate.external.olinks, and then leave external links the same color as 
surrounding text, but keep color on internal links (and URLs) because without 
visual cues it can be difficult to notice that they're active.

At present I'm using the following customization, loosely based on 
http://www.sagehill.net/docbookxsl/OlinkFormatting.html:

  
    #47a
  

This makes all the links blue... unfortunately including deactivated external 
olinks.
 
There is an example of this kind of styling in the XSL-FO spec, which you'll 
probably want to mimic: http://www.w3.org/TR/xsl/#d0e12911

I'm not sure how you'd set this up in the docbook stylesheets. A quick grep of the 1.78.1 
stylesheets doesn't reveal any "active-state" strings so there may be some work 
to do...

Chris

Re: [docbook-apps] EPUB3: how to use base.dir ?

[Chris Ridd]

On 24 Apr 2013, at 05:17, Carlos Araya  wrote:

> Bob,
> 
> The latest snapshot, downloaded tonight I get the same validation error. 
> 
> epub-check:
>  [java] ERROR: docbook-howto.epub: Length of the first filename in 
> archive must be 8, but was 13


It sounds like something has gone wrong with the zip file creation.

The first filename in the zip file is required to be called "mimetype" and it 
must contain the characters "application/epub+zip". I don't think that's 
changed between epub 2 to epub 3.

Chris
-
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] All callouts being added to package.opf/content.opf (epub)

[Chris Ridd]

On 30 Apr 2012, at 18:01, Carlos Araya wrote:

> I have the following elements on my customization layer
> 
> 
> .png
> images/callouts/
> 
> 
> It works for epub3 but not for the epub version of the stylesheets. I'll dive 
> into the epub files and see if I can figure out where the issue is

Does changing callout.graphics.number.limit help?

Chris

-
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] All callouts being added to package.opf/content.opf (epub)

[Chris Ridd]

On 28 Apr 2012, at 20:56, Carlos Araya wrote:

> I think I know the answer but this is driving me crazy... 
> 
> I am using callouts in my document and when transforming it to epub (either 
> version) with the latest snapshot (snapshot_9307) and have the following 
> problem.
> 
> * I am only using 9 callouts in the example I'm using them in but the 
> package/content files lists all 15 callouts. 
> * I've made sure that I'm only copying 9 images into the epub directory. 
> * I've verified that my Ant build script is only copying the content from my 
> source image directory that has the 9 callouts I am using. 
> 
> Is there a way to restrict the number of callout images that get added to the 
> package/content file? 

Are you setting any of the callout.graphics.* parameters? Bob describes them at 
the bottom of this page:



Chris

-
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] Suppressing "title" attributes in HTML

[Chris Ridd]

On 9 Jan 2012, at 00:28, David Cramer wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 01/08/2012 06:13 AM, Chris Ridd wrote:
>> Getting all these changes out in a new formal release of the
>> stylesheets would be nice...
>> 
>> Cheers,
>> 
>> Chris
> 
> I agree. We're past due for a release.

Is there anything practical we can do to assist in a new release?

Chris

-
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] Suppressing "title" attributes in HTML

[Chris Ridd]

On 7 Jan 2012, at 12:12, David Cramer wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Btw., Bob fixed this in svn a while ago.
> 
> David
> 

Getting all these changes out in a new formal release of the stylesheets would 
be nice...

Cheers,

Chris

-
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 include [long] dashes...

[Chris Ridd]

On 1 Jan 2012, at 00:01, Giuseppe Greco wrote:

> Hi all,
> 
> Does anybody know how to include [long] dashes to separate sentences (DocBook 
> 5 NG)?
> 
> Any help would be really appreciated.

Do you mean an em dash, or something else?

If you do mean an em dash, just use the numeric entity. Something like this:

First part — second part.

Reading  there seems to be a range of views 
over the spaces either side of the dash.

Chris

-
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 compact itemizedlist formatting in html output possible?

[Chris Ridd]

On 5 Nov 2011, at 16:33, Bob Stayton wrote:

> Indeed this problem has been noted before, and it has been fixed in SVN.  The 
> 1.76.1 stylesheets emitted , and the next 
> release will emit , since all browsers 
> support multiple-valued class attributes.  In the interim, you could create a 
> custom template in mode="class.value" to do that:
> 
> 
> itemizedlist compact
> 
> 
> and then use CSS to style it.
> 
> Bob Stayton
> Sagehill Enterprises
> b...@sagehill.net

Is it worth releasing 1.76.2 at some point?

Chris

-
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] Rendering of imageobjectco

[Chris Ridd]

We're using 'imageobjectco's in our manuals (we must have sinned greatly in our previous lives), and I'm wondering if there is a better way to render them.Currently they're a bit of a no-op - the default rendering in FO is identical to an imageobject. For HTML the default rendering is also of an image but it also sets up an HTML imagemap.Neither of these actually draw the callout bugs, which bothers me :-)I think I have a solution though that will work for HTML and FO. I have a rough and a bit broken prototype for HTML conversion that essentially converts to this:      1    2    (etc)  where the outer 'div' has this CSS style:  background: url(path/to/image) no-repeat;  position: relative;  width: (width of the image)px;  height: (height of the image)px;so the image gets drawn in the background, unfortunately only at full 1:1 resolution. (There may be some CSS extensions to do the scaling.) There's a 'span' for each bug, and they each have this CSS style:  display: inline;  position: absolute;  top: (pixel offset from top of image via area coords)px;  left: (pixel offset from left of image via area coords)px;The content of the span elements would be the appropriate Unicode character for the bug, or an image, both as at present. I'm not sure if they have hyperlink semantics - should they jump to the calloutlist? That's probably doable.I *think* the same sort of structure will work for FO, as FO seems to support the same sort of CSS styling that I'm proposing to use for the HTML.I haven't got an FO prototype yet. My HTML prototype is still just an ugly hack to the rather long process.image template.The disadvantage of this scheme is that the image might not get printed as it is "background", and semantically it feels a bit weird.But on the upside this feels like a semi-sane way to do callouts. You don't need to pre-render the callouts into the images at all (we do that for FO, and I'd need to do that for HTML too) and you get nice pretty bugs (if you use the Unicode bug style).Does anyone have any thoughts? Is this a bad idea?Chris

Re: [docbook-apps] Image callouts and roles

[Chris Ridd]

On 03 Oct, 2011,at 02:21 PM, Bob Stayton  wrote:




Indeed.  Here is the update to the template 
for the imageobjectco element I was going to check in.  It should work 
equally well in an html or fo customization layer. It uses the same 
mechanism to select a role attribute.  The difference from mediaobject 
is that it only does the selection if the right conditions are met, on the 
assumption that you may intend to have multiple imageobjects in your 
output.   Let me know if it works for you.
 Awesome, thanks Bob!It seems to do the right thing viz display a single imageobject depending on the role.The HTML imagemap produced seems to be broken, which I can reproduce with the stock stylesheets and a single imageobject.          The source document had  I also tried forcing units="calspair", but still got NaNs. I'll investigate more; this is rather likely to be my fault :-)Cheers,Chris

Re: [docbook-apps] Image callouts and roles

[Chris Ridd]

On 03 Oct, 2011,at 11:37 AM, Bob Stayton  wrote:






Hi  Chris,
OK.  Prior to Docbook 5, imageobjectco only 
allowed one imageobject, so that is the case that the stylesheet currently 
handles.  I did not realize that more  than one was allowed in DocBook 
5, so that will need  to get fixed in the stylesheets. I filed a bug 
report.
Thanks; sorry for messing up the original test case. 
For now, the selection process applies only to the 
direct children of mediaobject.  That's why you are getting both images in 
your output.  You'll need to create two children of mediaobject for the 
selection to work.Indeed that works (rendering one image) but I think it leaves me with a different problem :-)The reason I'm using an imageobjectco is because after the (in this case) 'screenshot' element I've got a calloutlist which has callout elements referencing various areas on the imageobjectco.Now if I'm using multiple 'imageobjectco' elements, each would have a separate 'areaspec', and each 'areaspec' would have a separate list of 'area's. Because the 'callout' has to reference the area by its xml:id, this looks to me like I'd need to create two 'area' elements with the same xml:id. Not good!If I create areas with different xml:ids, I can use text in my calloutlist, however that gets rendered as "(1)(1) text". eg                                                                      text      (Both variants there are using PNGs, just for simplicity. In reality one would be an SVG and the other would be PNG.)Cheers,Chris

Re: [docbook-apps] Image callouts and roles

[Chris Ridd]

On 29 Sep, 2011,at 12:27 PM, Bob Stayton  wrote:






Hi Chris,
Rendering two images side-by-side in FO output is 
not expected behavior.  The selection process takes into account all the 
allowed objects:
 
   
select="imageobject|imageobjectco 
|videoobject|audioobject|textobject"/>
   ...
 
You say you got both the .svg and the .png image in 
your FO output?  I copied and pasted your example into a test file and 
processed it with the stock 1.76.1 stylesheet and I got just the .svg 
image. 
 Sorry, I was trying several different things and screwed up my test case. The following includes both images when transformed to FO with the stock 1.76.1 fo/docbook.xsl stylesheet:                                                                                That is, one imageobjectco containing two imageobjects that differ by role. My transformation is done using:$ xsltproc --nonet --xinclude --stringparam xep.extensions 1 --output article.fo /path/to/docbook-xsl-1.76.1/fo/docbook.xsl article.xmlCheers,Chris

Re: [docbook-apps] Image location

[Chris Ridd]

On 30 Sep, 2011,at 02:07 PM, Chris Ridd  wrote:If you can (given the other fun you seem to be having with FOP) I might be confusing your problems with Tom's - sorry!Chris

Re: [docbook-apps] Image location

[Chris Ridd]

On 30 Sep, 2011,at 11:29 AM, Lars Vogel  wrote:Hello,I'm trying to create PDF from my Docbook output via the corresponding stylesheets but FOP cannot find the image. I read Bobs description and I believe the path of the image is correctly setup.
http://www.sagehill.net/docbookxsl/GraphicsLocations.htmlhttp://www.sagehill.net/docbookxsl/ModularDoc.html#XIncludeGraphics
The generated FO source look like the following:
and files are in the following structure:article.fo/content/images/DojoFolder10.gifI also tried:
article.fo/images/DojoFolder10.gifIf I run the FOP transformation I receive: [fop] Image not found. URI: content/images/DojoFolder10.gif. (See position 60:101)
Any advice would I'm doing wrong?Although we switched to XEP a while back, I did start off using FOP. I can't remember exactly why my old FOP Makefiles did this, but it *looks* like they were trying hard to get working references to images. So what I used to do in my old Makefiles was to change to the directory containing my book.xml, and then run the xsltproc and fop from there. I also set img.src.path to `pwd`, which may have been overly paranoid...If you can (given the other fun you seem to be having with FOP), I would recommend getting the free personal edition of XEP and see how that works. We felt that XEP was a much better processor than FOP, and it was worth our while spending the relatively small amount getting the non-free version.Chris

[docbook-apps] Image callouts and roles

[Chris Ridd]

I'm using role attributes and the docbook stylesheets (successfully) to use one image format when rendering to FO, and other when rendering to HTML (i.e. epub).  Foo                        However I have a couple of images using callouts, and using roles like that doesn't seem to work:                                                           The SVG is just a wrapper that references the similarly named PNG and then adds some callout bugs.Rendering that to FO results in two images side-by-side. Not sure if that's a bug, or expected behaviour. It isn't what I want though.However if I change the second imageobject to an imageobjectco, which seems the logical structure, the  is problematic - I have a single calloutlist that needs to refer to the "same" callout in either image. And I can't have two s with have the same xml:id :-(I hate image callouts! :-)Is there a more correct way to organize my two alternate images?Cheers,Chris

Re: [docbook-apps] Removing HTML TOC from epub

[Chris Ridd]

On 22 Sep, 2011,at 08:49 PM, Bob Stayton  wrote:






Hi Chris,
Regarrding your first question, you can set the 
stylesheet param named 'generate.toc' to empty to turn off the TOC chunk.  
You will still get the NCX toc.
 I just had a chance to do that, and it worked! Thanks :-)
I noticed the same issue with customizing the epub 
2 stylesheet  If your customization consists only of parameter 
settings, then importing it should work.  However, it is a chunking 
stylesheet, so any template changes require paying careful attention to import 
precedence for them to work.  Generally that requires two separate 
customization files, but the epub/docbook.xsl needs to be rearranged for that to 
work.  Based on the experience I gained from creating the epub 3 
stylesheet, I plan to rearrange the files in the  epub directory for EPUB 2 
output to make it easier to customize. Are the epub3 stylesheets checked in anywhere, and should we be using them instead of the epub2 ones?Chris

Re: [docbook-apps] Removing HTML TOC from epub

[Chris Ridd]

On 23 Sep 2011, at 17:47, Keith Fahlgren wrote:

> Hi,
> 
> On Thu, Sep 22, 2011 at 11:30 PM, davep  wrote:
>> Since the toc is never needed (the ncx supplants a toc), would it make sense
>> to delete the call to generate it such that annoyance is removed?
> 
> 
> Many publishers deliberately include an HTML TOC in their EPUB
> documents. An HTML TOC can offer more nuanced layout and text than an
> NCX TOC and is appropriate for some titles.

It sounds like it *can* be useful in some cases, but maybe shouldn't be the 
default.

Chris

-
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] Removing HTML TOC from epub

[Chris Ridd]

Epubs have a table of contents used by readers (toc.ncx?) which makes the generated HTML table of contents rather superfluous. How does one prevent its generation in 1.76.1?Actually a rather more general question is how (or what's best practice) to customize the epub stylesheets. The shipped epub/docbook.xsl doesn't really seem amenable to being customized by an importing stylesheet. The FO stylesheets are significantly more flexible in this regard.Or should I be editing a copy of epub/docbook.xsl and customizing it that way? There's a lot of logic in that stylesheet that I really don't want to copy and try and keep in sync with the shipping file.Cheers,Chris

Re: [docbook-apps] re:New docbook-xsl-ns snapshots

[Chris Ridd]

On 22 Apr 2011, at 05:52, Kasun Gajasinghe wrote:

> At a previous discussion it was suggested that following causes the
> error. This *might* be the case.
> 
> tar: ../testdocs/i18n: Cannot utime: Operation not permitted
> tar: ../testdocs/graphics: Cannot utime: Operation not permitted
> tar: ../testdocs/tests/mathml: Cannot utime: Operation not permitted
> tar: ../testdocs/tests/ebnf: Cannot utime: Operation not permitted
> tar: ../testdocs/tests/svg: Cannot utime: Operation not permitted
> tar: ../testdocs/tests: Cannot utime: Operation not permitted
> tar: ../testdocs/imagelib: Cannot utime: Operation not permitted
> tar: ../testdocs: Cannot utime: Operation not permitted
> tar: ..: Cannot utime: Operation not permitted
> tar: Exiting with failure status due to previous errors
> make: [zip] Error 2 (ignored)
> 
> [1] 
> http://sourceforge.net/mailarchive/forum.php?thread_name=E1PD0em-0004BI-D8%40sideshowbarker.net&forum_name=docbook-snapshots

The line causing these errors is:

tar cfP - -X /scratch/tar.exclude * .[^.]* | (cd /scratch/docbook-xsl-snapshot; 
tar xfP -)

Googling for the error brought up 
 which 
suggests it is a problem during the untarring, and adding m to the options (ie 
tar xfPm -) would help.

Tar's P option tries to preserve all the permissions and timestamps; Pm will do 
that *except* for the timestamps.

But why is tar trying to call utime in the first place? I see a number of lines 
much earlier on using touch like this:

touch -t 19700101 `basename $f`

I'd *guess* that's the root cause. Why is the Makefile trying to set the 
modification times back to (time_t)0?

Chris

-
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] Do callouts on images work?

[Chris Ridd]

On 12 Apr 2011, at 16:51, Dave Pawson wrote:

> On Tue, 12 Apr 2011 16:28:07 +0100
> Chris Ridd  wrote:
> 
>> I've got a bunch of screenshots containing hand-drawn arrows and
>> annotations that I think would be better done as callouts, but I
>> don't seem to be able to get callouts rendering properly to PDF.
>> 
>> Do they actually work?
>> 
>> If they do, does anyone have a working example they could share?
>> Here's my non-working XML:
>> 
>>
>>  
>>
>>  
>>
>> 
>>
>>  
>>
>> 
>>
>>  
>>Here I am in the middle.
>>  
>>
>>  
>>
>> 
>> [I'm not sure what purpose the linkends="c1" serves, if any.]
> 
> 
>  
>   e
> 
>   
>  

So they work in programlistings but not mediaobjects?

Chris

-
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] Do callouts on images work?

[Chris Ridd]

On 12 Apr 2011, at 17:01, Jacques Foucry wrote:

> Le 12.04.2011 17:28, Chris Ridd a écrit :
>> Do they actually work?
> 
> I fact, as Bob said, It doesn't work.

Thanks both of you - you've saved my wall getting another set of head-shaped 
dents :-)

> I use a lot of callout bugs on my figure for my book. My solution (which is 
> not very elegent) is to put manually the callout on a picture as background 
> of a svg image. My callout bug are in svg so the result image is not to big.

It may not be elegant, but that's pretty clever! Are your bugs just drawn 
objects, or are they marked up as  elements?

Chris



-
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] Do callouts on images work?

[Chris Ridd]

I've got a bunch of screenshots containing hand-drawn arrows and annotations 
that I think would be better done as callouts, but I don't seem to be able to 
get callouts rendering properly to PDF.

Do they actually work?

If they do, does anyone have a working example they could share? Here's my 
non-working XML:


  

  



  



  
Here I am in the middle.
  

  


[I'm not sure what purpose the linkends="c1" serves, if any.]

With the default docbook.xsl stylesheet and XEP this renders as a completely 
plain screenshot without any overlaid numbers. The callout underneath is 
rendered OK as a white 1 in a black circle.

Chris

-
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] glossary template buglet?

[Chris Ridd]

On 19 Mar 2011, at 21:20, Chris Ridd wrote:

> I am using a customization layer. I could very well have messed something up 
> there, as I do have customized chapter/appendix titling and possibly took a 
> shortcut there which missed glossary. I shall look at that template closely 
> (I should have thought of that first - apologies), but trying with the stock 
> stylesheets is another good idea.

And using the stock fo/docbook.xsl stylesheet I get the expected "Glossary" 
title, not the book title. So a bug in my customization layer!

My component.title template tries to lay things out side by side:

  Chapter 7Exciting Stuff

  Appendix H   Reference Stuff

   Glossary

So I followed the example at 
<http://www.sagehill.net/docbookxsl/SideBySide.html> which uses  to generate the RHS, and that seems to 
be the cause.

Chris



-
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] glossary template buglet?

[Chris Ridd]

On 19 Mar 2011, at 01:44, Bob Stayton wrote:

> Hi Chris,
> I'm not able to duplicate this problem.  In general, the DocBook stylesheets 
> use the term "component" to refer to a child of book, and "division" for set, 
> book or part. So if your glossary element is a child of book, then 
> "component.title" would be correct.  I'm surprised that "component.title" 
> caused the book title to display, because the call to it selects the glossary 
> element.

Thanks for taking a look at this, Bob.

> Perhaps you could describe the structure of your book and the location of the 
> glossary?

Sure. We're using XXE and Docbook 5.0, and the resulting document looks like:

  

  Book Title
  ...
  ...
  ... (logo for cover)

...
... (10 chapters)
... (8 appendixes)

  Glossary
   (lots of glossdivs)
A
... (lots of glossentrys)
  

   

> And excuse me if you have already tried this, but does the book validate?  
> And do you get this result with the stock DocBook XSL stylesheets or a 
> customization layer?  If a customization, have you tried the stock 
> stylesheets?

Yes, the book validates.

I am using a customization layer. I could very well have messed something up 
there, as I do have customized chapter/appendix titling and possibly took a 
shortcut there which missed glossary. I shall look at that template closely (I 
should have thought of that first - apologies), but trying with the stock 
stylesheets is another good idea.

Chris

-
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] pgwide support with Docbook 5

[Chris Ridd]

On 19 Mar 2011, at 01:31, Bob Stayton wrote:

> Hi Chris,
> pgwide is permitted on table, both CALS and HTML tables. Here is the 
> definitive guide:
> 
> http://www.docbook.org/tdg5/en/html/cals.table.html
> 
> I looked in the DTD and the RelaxNG schema, and see pgwide available on 
> table.  How did you conclude that it was not permitted?

XXE reported it as invalid.

I think we are using HTML tables, not CALS tables. 
 has no pgwide.

Maybe HTML tables were a tactical mistake on our part!

Chris

-
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] pgwide support with Docbook 5

[Chris Ridd]

I've successfully used pgwide="1" on some wide tables with FOP.

However that was on a book using Docbook 4.x. I see with some dismay that 
Docbook 5 doesn't permit pgwide on tables... What replaced it?

Chris

-
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] glossary template buglet?

[Chris Ridd]

In the default titlepage template for glossary, the title is formed from:

Re: [docbook-apps] Document properties in FOP are out of date

[Chris Ridd]

On 10 Dec 2010, at 18:16, Bob Stayton wrote:

> Hi Chris,
> Yes, that template is out of date since it does not support author/orgname 
> from DB5. Could you please file a bug report on the DocBook SourceForge site 
> about it?

I'm ahead of you already: Bug 3132862. It sounds like author/orgname is the 
markup I should be sticking with.

> Including corpauthor from DB4 in the DB5 namespaced stylesheets is not a 
> concern. Currently the stylesheets are written to support both DocBook 4 and 
> 5.  The namespaced version of the stylesheets for DocBook 5 are generated 
> from the non-namespaced version by a script, so they are nearly identical 
> except for the use of the namespace prefix on element matches.

Yes, the only problem it caused me was that I searched the templates to see 
what markup it might look for, and then added the element(s) in my doc to fit. 
A slight case of the tail wagging the dog, but sometimes it is hard finding the 
"right" element to use in DB :-)

Obviously that's a slightly risky strategy given the stylesheets cater for 
multiple DB versions.

> Supporting both DB4 and DB5 with the same stylesheets is possible for two 
> reasons:
> 
> 1.  Elements in both versions have the same meaning in DB5 as they do in DB4, 
> in general.
> 
> 2.  In a pattern-matching language like XSLT, a stylesheet can contain 
> patterns that never match, but don't create problems.  Since corpauthor would 
> not be seen in a DB5 document, that pattern would never match there.  
> Likewise, adding support for author/orgname will not harm the processing of a 
> DB4 document, as that pattern would not be seen there.
> 
> So far we have been able to maintain one set of stylesheets for both 
> versions.  This is highly desirable so they don't get out of synch.

I totally agree.

Cheers,

Chris

-
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] Document properties in FOP are out of date

[Chris Ridd]

Hi,

In the current version of fo/fop1.xsl the PDF "Document Properties" seem to be 
set from something called "corpauthor":



  

(Verified in trunk: 
)

That element doesn't seem to exist in DB 5, but was in 4.4. The replacement for 
 seems to be something like: 
..., but that doesn't seem to match up with 
the templates.

Are the templates wrong (out of date) or should I use different markup to get a 
"corporate" author into my manuals?

Cheers,

Chris



-
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] Conceptual problem formatting material

[Chris Ridd]

On 1 Nov 2010, at 19:21, Bob Stayton wrote:

> Oops, hit Send by accident on the previous mail.
> 
> I did omit a crucial piece of information.  In the first template I meant to 
> process it in a mode other than normal mode:
> 
>  mode="frontmatter"/>
> 
> and that uses the template with:
> 
> 
>  actually processing goes here
> 
> 
> and the empty template is for normal mode (without a mode attribute).  Hope 
> that makes more sense.

It does make much more sense :-)

Thanks Bob and Guiseppe! I may have more questions as I get further up the 
creek without a paddle...

Cheers,

Chris

-
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] Conceptual problem formatting material

[Chris Ridd]

On 1 Nov 2010, at 16:49, Bob Stayton wrote:

> Hi Chris,
> I've done similar books like this using preface elements with role 
> attributes, and then customizing the book template to output them in the 
> order you want.  The titlepage template system is not really appropriate for 
> that kind of extended information.

Right, thanks for helping me avoid that particular blind alley :-)

> For each special preface, I add a template with match="prefa...@role = 
> 'something']" to handle its formatting, and then add the following to the 
> book template to apply it:
> 
> 
> 
> That way if a book instance does not have such a preface, this step is just 
> skipped.
> 
> You'll also want to add an empty template in normal mode to prevent the 
> preface element from being processed again in book order:
> 
> 

I'm confused now. Firstly I've got one  with several sections, not 
multiple s. (Though we're amenable to creating multiple s if 
it makes things easier. It isn't /quite/ separating content from presentation 
though :-)

But I'm mostly confused about your contradictory suggestions in the 1st and 
last lines! ie

add a template with match="prefa...@role='something']" to format it
add an empty template with match="prefa...@role='something']"

Ah - there's a mode parameter?

> You'll need to decide which of these have their own fo:page-sequence, and 
> call the template name 'page.sequence' with that as content.
> 
> And you'll need to customize the templates named 'page.number.format' and 
> 'initial.page.number' to get the right page numbering scheme.
> 
> The trickiest part in this design is getting the copyright and "Contacting" 
> information on the same page.  The copyright info is normally processed in 
> the titlepage page-sequence.  For that case, I would customize the template 
> named 'book.titlepage.verso' to apply templates to that preface element, and 
> leave that one out of the book template.

I'm away from my stylesheets ATM, but will look at that tomorrow. I've already 
managed to remove the copyright stuff from my titlepage, and I *think* I've 
removed the preface from my book template, so I'm part the way there. The 
dratted preface still appears in my TOC, so some butchery is still needed...

Cheers,

Chris

-
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] Conceptual problem formatting material

[Chris Ridd]

Hi,

I am trying to reproduce the structure of existing manuals written in 
Framemaker, in 2 new manuals written using Docbook and I'm having a little 
trouble working out how one is supposed to do radical formatting of front 
matter.

Our manuals are s.

I have a custom title page constructed via a titlepage template, which just has 
the front cover. So far so (relatively) easy...

But then I have some pages with different page numbering (eg i .. vi) that 
include a slightly custom formatted TOC, an untitled copyright section, and 
then some titled (but un-numbered) sections describing Typographical 
Conventions etc. (One of the existing Frame manuals is accessible at 
 in case I'm not explaining 
this well.)

The copyright section feels like it should come from the book info, but the 
remaining stuff feels like preface material.

What's the best approach for arranging these things? I'm starting to look at 
overriding the "book" template from fo/division.xsl, but have a sneaking 
suspicion that I really should be doing this all in the titlepage template.

Or is there another way?

I did look at Bob's otherwise excellent book, but didn't really get a good 
feeling for the best approach here.

Cheers,

Chris 

-
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] PNGs not appearing in PDF (appearing fine in HTML)

[Chris Ridd]

On 27 Oct 2010, at 19:54, Mauritz Jeanson wrote:

> |  BTW, the links on this page:
> | http://wiki.docbook.org/topic/MacOsx
> |  result in 404 errors. Is there a better place to go to find 
> |  out how to install the latest and greatest docbook on Mac OS X?
> 
> 
> I hope there is... But I know very little about Mac OS X, sorry. 

You can install the docbook schemas and stylesheets using the normal Unix 
tarballs of course. However what I usually do is to use MacPorts, as that won't 
modify any Apple-supplied stuff, it patches things (if necessary) to make them 
build and work on OS X, and is a convenient way of installing packages like 
this.

Go to  and then when it is installed & 
set up, run:

sudo port install docbook-xsl

Cheers,

Chris

-
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] Inserting Acrobat PDF "comments" into a Docbook PDF

[Chris Ridd]

Jeff Hooker wrote:

Hi all,

Google and the Adobe PDF specification have let me down; let's see if
anyone here has the answer.

I'd like to be able to insert Acobat "comment" markers into the PDFs
that I generate using the DocbookXSL stylesheets so that reviewers can
simply use the "view next comment" feature in Acrobat rather than
scrolling through long documents looking for visual change markers (we
use DeltaXML to generate and style change markers). I can't find any
information on how to form the markers, etc. Has anyone else ever done
this? Got any ideas?


That's a neat idea.

These are done by inserting pdfmarks into the stream - googling for 
"pdfmark reference manual" should turn up the details. I don't know how 
you'd make a stylesheet emit a custom pdfmark however, doubtless it is 
processor-specific.


Cheers,

Chris

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

Re: [docbook-apps] Metadata in FO?

[Chris Ridd]

On 5 Feb 2008, at 18:01, W. Martin Borgert wrote:


On Tue, Feb 05, 2008 at 03:40:33PM +, Chris Ridd wrote:

On 5 Feb 2008, at 13:33, W. Martin Borgert wrote:

is there a way to get DocBook XML metadata into the PDF
metadata? Information such as Title, Author, Keywords? Or is it
all lost in the FO stage? TIA!


It depends on the FO processor - they usually support PIs that let  
you
include PDF metadata; the docbook xsl stylesheets already know to  
write
the correct PIs for FOP and XEP. (Maybe other processors, but I've  
tried

those two.)


How would I activate those PIs for use with FOP? I tried
fop.extensions and fop1.extensions w/o success. TIA!


Looking again at one of the docs we generate with fop, and while it  
has the PDF outline it doesn't have the title/author stuff set after  
all. Sorry to mislead you.


Apparently fop doesn't support doing that directly, according to <http://xmlgraphics.apache.org/fop/faq.html#pdf-doc-properties 
>.


You either have to post-process your PDF file, or use a different  
processor. XEP has worked very well for me in the past, though  
produces larger files than fop.


Cheers,

Chris

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

Re: [docbook-apps] Metadata in FO?

[Chris Ridd]

On 5 Feb 2008, at 13:33, W. Martin Borgert wrote:


Hi,

is there a way to get DocBook XML metadata into the PDF
metadata? Information such as Title, Author, Keywords? Or is it
all lost in the FO stage? TIA!

Btw. I'm using docbook-xsl 1.73.2, fop 0.94/xmlroff 0.5.3, and
xsltproc 1.1.22, if it matters.


It depends on the FO processor - they usually support PIs that let you  
include PDF metadata; the docbook xsl stylesheets already know to  
write the correct PIs for FOP and XEP. (Maybe other processors, but  
I've tried those two.)


Cheers,

Chris

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

Re: [docbook-apps] Docbookk/FOP Exceptions on Fedora Core 7

[Chris Ridd]

On 23 Dec 2007, at 11:44, Daniel Leidert wrote:


Am Sonntag, den 23.12.2007, 06:45 + schrieb Chris Ridd:

On 23 Dec 2007, at 01:20, Daniel Leidert wrote:

Am Samstag, den 22.12.2007, 11:50 -0800 schrieb Harry Goldschmitt:


[fop and a java.lang.OutOfMemory exception]

The Java -Xms and -Xmx options do not help?


Fedora boxes only come with "GCJ", which fails on things that work in
Sun's JVM for Linux.


This is not true. GIJ accepts these options too. It further accepts
their equivalent options -ms and -mx.


I didn't know it took those command-line arguments, but my point was  
that the gcj VM doesn't run some Java code correctly and maybe that's  
the problem here. See if another JVM solves things.


Cheers,

Chris

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

Re: [docbook-apps] Docbookk/FOP Exceptions on Fedora Core 7

[Chris Ridd]

On 23 Dec 2007, at 01:20, Daniel Leidert wrote:


Am Samstag, den 22.12.2007, 11:50 -0800 schrieb Harry Goldschmitt:


I've just upgraded one of my Linux machines to Fedora Core 7 and have
begun seeing out of memory exceptions using admon.graphics when
generating a PDF file.  My Fedora Core 6 machine still works fine.
I've tried using both FOP 0.93 and FOP 0.94 on FC7 as well as both
Jimi and JAI to handle the graphics.  The out of memory exception is
a known FOP problem with no reported fix.


The Java -Xms and -Xmx options do not help?


Fedora boxes only come with "GCJ", which fails on things that work in  
Sun's JVM for Linux. I'd double-check that I wasn't using gcj and was  
using Sun's JVM.


Cheers,

Chris

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

Re: [docbook-apps] Menuchoices in lists, using FOP

[Chris Ridd]

On 24 Oct 2007, at 11:18, Vincent Hennebert wrote:

There is probably an FO setting to change the way lines are  
stacked, but

the easiest is probably to use a font that has glyphs for both the
normal characters and the arrow you want to use as a menu separator.
There are plenty of them, both commercial and free. The FreeSerif  
[1] is

one of them and looks like Times.


That's certainly a possibility, but I think I'd prefer just to  
downgrade to something like a ">" instead of embedding a font.


Yuck :-(

Cheers,

Chris

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

[docbook-apps] Menuchoices in lists, using FOP

[Chris Ridd]

Hi,

I'm using Docbook and the related XSL stylesheets pretty successfully  
except for one odd problem.


I have a number of procedures containing steps, and if a para inside  
a step contains a menuchoice, and my stylesheet sets:



   → 


then the step's sequence number is drawn vertically offset from the  
first line of the text. I uploaded a screenshot of this to a bug report:





This occurs if I use either xep 4 or fop 0.94. I'm running on Solaris.

The reason I'm explicitly setting the Symbol font is to workaround a  
known problem in fop. That workaround's also done in fo/inline.xsl in  
docbook-xsl 1.73.2, but only if fop1.extensions is non-zero.


Why is the line height getting mangled?

Is there a better way of getting an arrow character as a separator  
here, if I'm using fop?


Cheers,

Chris

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