gmane.text.docbook.apps

HtmlHelp/CHM - Revision History+generate.revhistory.link - not visible in output

Kerry, Richard — 2013-05-20T13:22:06


I'm looking at the CHM/HtmlHelp output from my project.  (Using Saxon-6, Microsoft Html Help Compiler, and Ant to call them both)

I want to customize how the Revision History is displayed.  I would like to be able to show it linked from the title-page, using generate.revhistory.link.



If I copy the d:revhistory and d:revhistory/d:revision templates from html/block.xsl I can customize them with no problem.  However, that is relevant to "in-line" revision histories, ie within a <section>.  I would like to have the Revision History available linked from the title page, but in another page, which should be achievable using generate.revhistory.link.



However, if I copy the d:revhistory and d:revhistory/d:revision templates for mode="titlepage.mode" from html/titlepage.xsl I start getting problems.  (Note that at this stage I've made no changes to those templates so that can't be what's causing the problem)



The first problem I noticed was that merely copying the relevant templates out of the default styl

Re: Page numbers in body.margin.outer

Bob Stayton — 2013-05-15T21:55:11

Hi Claudio,
This should get you started, with some comments:

<!-- Shift some of the page side margin to the body side margin to make room -->
<xsl:param name="page.margin.outer">.5in</xsl:param>
<xsl:param name="body.margin.outer">.25in</xsl:param>
<xsl:param name="region.outer.extent">12pt</xsl:param>
<!-- extend the side region over the header/footer regions -->
<xsl:param name="side.region.precedence">true</xsl:param>

<xsl:attribute-set name="region.outer.properties">
  <!-- By default, the side region reference-orientation is 90 so text is rotated to fit,
     so this sets it back to zero for upright numbers -->
  <xsl:attribute name="reference-orientation">0</xsl:attribute>
 <!-- But I don't think FOP supports "outside" yet -->
  <xsl:attribute name="text-align">outside</xsl:attribute>
  <xsl:attribute name="width">0.25in</xsl:attribute>
</xsl:attribute-set>

<xsl:attribute-set name="outer.region.content.properties">
  <!-- Put any text formatting attributes here --></xsl:attribute-set>

<xsl:template

Re: Box around the footer (re-post with images attached)

Bob Stayton — 2013-05-15T18:19:01

Hi Richard,
The 'foot.sep.rule' template can apply attributes to the fo:table that displays the footer content.  You probably used that to add the border around the whole footer.

To get the spacing you want, I recommend using margin properties in the fo:block element in the footer.content template.  That fo:block is used in each of the three table cells in the footer.   Something like:

<fo:template name="footer.content">
  ...
  <fo:block>
      <xsl:attribute name="border">0.1pt solid red</xsl:attribute>
      <xsl:attribute name="margin-left">6pt</xsl:attribute>
      <xsl:attribute name="margin-right">6pt</xsl:attribute>
      <xsl:attribute name="margin-top">3pt</xsl:attribute>
      <xsl:attribute name="margin-bottom">12pt</xsl:attribute>

      <xsl:choose>
          ...

You might define and use an attribute-set instead.  I added a border attribute just so you can see where the boundaries are, so you will want to remove that after testing.  

With the border turned on, you can experiment with paddin

Box around the footer (re-post with images attached)

Kerry, Richard — 2013-05-15T12:41:12


Ok - retrying this.  The images may appear in-line but I've attached the files in case they don't.

And I've added descriptions in case they still don't appear.



I've managed to get a border around my document's footer, using foot.sep.rule.

However, it isn't spaced how I want it and I can't get it to change in the way I want.



I'm trying to get (word footer.png):



[X]


The image shows a number of text items in the footer.  There is a box around all of them.
There is a space of a few millimetres/pixels (Looks like about 1mm) between the top of the text and the top line.
There is a slightly wider space between the right and left edges of the text and their respective border lines.
There is a gap between the bottom of the text and the bottom border line of roughly the height of one line of text.


but I'm getting (pdf footer.png):


[X]


There is a space of a few millimetres/pixels (Looks like about 2mm this time) between the top of the text and the top border line.
There is no significant space betw

Re: WARNING: cannot add < at >xml:base to node set root element. Relative paths may not work.

Lars Vogel — 2013-05-15T09:47:23

Thanks everyone for the reply. I'm not using Docbook 5 nor do I use
profile-docbook.xsl.
I'm also using saxon6.5.5 and the Docbook I'm processing is one big file
which I preprocessed with an XInclude Ant tasks.

I will try to investigate further and if I find out more, I post this to
the this group.

Thanks again everyone, Lars




2013/5/14 Alexey Neyman <stilor< at >att.net>

Re: WARNING: cannot add < at >xml:base to node set root element. Relative paths may not work.

Alexey Neyman — 2013-05-14T19:55:05

Indeed, I've just checked and Xerxes seems to have the same issue.

So, this is one caveat to keep in mind when processing modular DocBook 
documents with Saxon/Xerxes.

Regards,
Alexey.

On Tuesday, May 14, 2013 12:00:50 pm Bob Stayton wrote:

Re: WARNING: cannot add < at >xml:base to node set root element. Relative paths may not work.

Bob Stayton — 2013-05-14T19:00:50

I don't think Saxon itself supports XIncludes.  Saxon uses the Xerces parser 
with the XInclude function turned on:

http://www.saxonica.com/documentation/sourcedocs/controlling-parsing.html

The XInclude spec says that xml:base attributes must be relative to the 
closest ancestor xml:base. I'm pretty sure that is how Saxon 6 behaves.  If 
Saxon9 is generating xml:base attributes always relative to the top level, 
then that is not what the XInclude spec says, nor what the DocBook 
stylesheet expects.

Bob Stayton
Sagehill Enterprises
bobs< at >sagehill.net

--------------------------------------------------
From: "Alexey Neyman" <stilor< at >att.net>
Sent: Tuesday, May 14, 2013 10:25 AM
To: <docbook-apps< at >lists.oasis-open.org>
Cc: "Bob Stayton" <bobs< at >sagehill.net>; "Lars Vogel" <lars.vogel< at >gmail.com>
Subject: Re: [docbook-apps] WARNING: cannot add < at >xml:base to node set root 
element. Relative paths may not work.

Re: RE: Box around the footer

Stefan Knorr — 2013-05-14T17:28:14

Hi Richard,

On Di, 2013-05-14 at 16:46 +0000, Kerry, Richard wrote:

I see an Outlook Web Access login screen. So, no they don't seem to have
come through.

Hth, Stefan.

Re: WARNING: cannot add < at >xml:base to node set root element. Relative paths may not work.

Alexey Neyman — 2013-05-14T17:25:47

Hi Lars, Bob,

Just one point: xsltproc does xml:base fixup on nodesets included through 
XInclude, so inside the document there are xml:base elements added properly. 
However, Bob's point still stands: if the top-level document is in non-current 
directory, it will break the external references.

Speaking of Saxon, I am not sure if it does xml:base fixup properly on 
XIncluded modular documents from different directories. Originally, I was 
investigating a bug in libxml2 regarding xml:base fixup (pushed to master, 
will be in the next release), but I also tried Saxon. Here is a link to the 
thread on libxml2 mailing list (which has a small test case attached):

  https://mail.gnome.org/archives/xml/2013-April/msg00024.html

In brief, Saxon seems to emit xml:base relative to top-level document rather 
than to the most recent point of inclusion. DocBook stylesheets (at least, 
1.78.0 that I used) assume the location relative to the base of the including 
nodeset. xsltproc conforms to the expectations of DocBo

RE: Box around the footer

Kerry, Richard — 2013-05-14T16:46:17


I don't know what everyone else is seeing in this message ....

One one client (Outlook) I'm getting little red Xs telling me the image is not available.

On the other (webmail, using IE 9) I can see the images as I thought I was sending them.



If they haven't come through please let me know and I'll find some other way of sending them.





Uncertainly,

Richard.





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.kerry< at >atos.net<mailto:richard.kerry< at >atos.net>
uk.atos.net<http://uk.atos.net/en-uk/>
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

Box around the footer

Kerry, Richard — 2013-05-14T16:12:44


I've managed to get a border around my document's footer, using foot.sep.rule.

However, it isn't spaced how I want it and I can't get it to change in the way I want.



I'm trying to get :



[https://webmail.siemens-it-solutions.com/OWA/attachment.ashx?id=RgAAAADuafvq2wn5ToY5TFygcdi1BwAxjteD9W0ARqkWij6loXgaAAAAAQlZAABhxn3HMwi9SbLUtlBySA26AAAVOvmVAAAJ&attcnt=1&attid0=EACLf%2bZZePPtSaIp6eKC8ubY&attcid0=7716d0a4-6acd-4cd0-af75-6cdb428b6975]


but I'm getting :


[https://webmail.siemens-it-solutions.com/OWA/attachment.ashx?id=RgAAAADuafvq2wn5ToY5TFygcdi1BwAxjteD9W0ARqkWij6loXgaAAAAAQlZAABhxn3HMwi9SbLUtlBySA26AAAVOvmVAAAJ&attcnt=1&attid0=EAAuTDbeBlA9QYoLDLUMY1bp&attcid0=a154a93e-4a37-4e49-b724-a60be5177ece]

Note the lack of spacing at both left and right edges. Also the requirement for roughly one text line below the text showing here (some documents will have some text there).

I seem to get some effect by customizing footer.content.properties - that's how I've got the text to be grey.
However I don't seem

Re: WARNING: cannot add < at >xml:base to node set root element. Relative paths may not work.

Bob Stayton — 2013-05-14T16:01:37

Hi Lars,
You should get that message only when two conditions are met:

1.  You are processing a DocBook 5 document with the non-namespaced stylesheets.
         or
    You are single-step profiling by using profile-docbook.xsl (probably your case).

and

2.  You are using xsltproc (which lacks an extension function to get the name of the current directory).

With either condition in (1), the document is preprocessed into an internal nodeset (a nodeset held in memory) before being processed by the stylesheets.  The internal nodeset loses all contact with the filesystem where the files originated, so the preprocessing template tries to add relative directory references into the internal nodeset by adding xml:base attributes to preserve the relative locations.  It uses an extension function to get the original base directory of the document, but xsltproc does not have a function to fetch that information, while Saxon and Xalan do.

So if you use modular doc and the modules are in various directories, that dire

WARNING: cannot add < at >xml:base to node set root element. Relative paths may not work.

Lars Vogel — 2013-05-14T14:13:29

Hello,

since a while I get the following warning during the transformation with
the docbook distribution:

WARNING: cannot add < at >xml:base to node set root element.  Relative paths may
not work.

I'm not sure what triggers this warning, a Google search resulted in hints
about Docbook V5.0 but I'm still using Docbook 4.5.

I'm currently using the docbook-xsl-1.77.1 distribution and I think (but
I'm not sure) that I have this warning since I upgraded from 1.76. The
output looks ok to me, but this warning does not create a warm fussy
feeling. ;-)

Any hint how to get rid of this warning?

Best regards, Lars

Re: Fw: Namespace issues with titlepage templates in slides

Jirka Kosek — 2013-05-14T11:36:08


Indeed


But might be your code might be extended to handle this case as well and
emit warning message?


No, they are generated from the single source which currently is
docbook-xsl. During the build process correct namespace declarations and
d: prefixes are added into all XPath expressions and docbook-xsl-ns is
created.


Currently master one is non-ns version, but there is plan to reverse the
process in a due future.

Conversion is done by xslns-build Perl script in releasetools directory.

Jirka

Re: dbtoepub is broken on latest docbook-xsl-ns-snapshot

Shlomi Fish — 2013-05-12T11:09:16

Hi Bob and all,

On Sun, 12 May 2013 00:06:57 +0300
Shlomi Fish <shlomif< at >shlomifish.org> wrote:


Thanks! Using the 1.78.1 distribution appears to have made it work again.

Regards,

Shlomi Fish

Page numbers in body.margin.outer

Claudio Tubertini — 2013-05-12T10:52:32

I would like to put the page number (in chapters or articles) in the
body.margin.outer (I believe this is the correct parameter, but I'm not
sure), in the middle of the page, instead of usual place in footer or
header. Can someone suggest me where to look for? I'm using FOP processor
with Oxygen.
Regards
Claudio Tubertini

Re: dbtoepub is broken on latest docbook-xsl-ns-snapshot

Shlomi Fish — 2013-05-11T21:06:57

Hi Bob,

On Sat, 11 May 2013 13:02:29 -0700
"Bob Stayton" <bobs< at >sagehill.net> wrote:


Thanks for letting me know and for the advice about the workaround. I'm going
to try it.

Regards,

Shlomi Fish

Re: Re: FOP quirk

Bob Stayton — 2013-05-11T20:03:10

Thanks for confirming it.

Bob Stayton
Sagehill Enterprises
bobs< at >sagehill.net


From: Alexey Neyman 
Sent: Saturday, May 11, 2013 10:03 AM
To: docbook-apps< at >lists.oasis-open.org 
Cc: Bob Stayton 
Subject: Re: [docbook-apps] Re: <menuchoice> FOP quirk


Hi Bob,



The proposed workaround works for me:



< at >< at > -1114,8 +1114,9 < at >< at >

<xsl:variable name="mm.separator">

<xsl:choose>

<xsl:when test="($fop.extensions != 0 or $fop1.extensions != 0 ) and

- contains($menuchoice.menu.separator, '&#x2192;')">

- <fo:inline font-family="Symbol">

+ contains($menuchoice.menu.separator, '&#x2192;') and

+ $symbol.font.family != ''">

+ <fo:inline font-family="{$symbol.font.family}">

<xsl:copy-of select="$menuchoice.menu.separator"/>

</fo:inline>

</xsl:when>



Regards,

Alexey.



On Friday, May 10, 2013 11:53:24 PM Bob Stayton wrote:


Hi Alexey,

When I use the default fonts in FOP and remove the special code and allow FOP 1.1 to fall back through the font list to Symbol, then the arrow character is positioned slightly *

Re: dbtoepub is broken on latest docbook-xsl-ns-snapshot

Bob Stayton — 2013-05-11T20:02:29

The snapshot build machine is still having problems, and they seem to be at 
the filesystem level rather than the DocBook tools level. We are working to 
get it fixed.  In the meantime, use the 1.78.1 distribution instead of the 
snapshot build.  Sorry.

Bob Stayton
Sagehill Enterprises
bobs< at >sagehill.net

--------------------------------------------------
From: "Shlomi Fish" <shlomif< at >shlomifish.org>
Sent: Saturday, May 11, 2013 9:42 AM
To: "Shlomi Fish" <shlomif< at >shlomifish.org>
Cc: <docbook-apps< at >lists.oasis-open.org>
Subject: Re: [docbook-apps] dbtoepub is broken on latest 
docbook-xsl-ns-snapshot

Re: Re: FOP quirk

Alexey Neyman — 2013-05-11T17:03:36

Hi Bob,

The proposed workaround works for me:

< at >< at > -1114,8 +1114,9 < at >< at >
   <xsl:variable name="mm.separator">
     <xsl:choose>
       <xsl:when test="($fop.extensions != 0 or $fop1.extensions != 0 ) and
-                contains($menuchoice.menu.separator, '&#x2192;')">
-        <fo:inline font-family="Symbol">
+        contains($menuchoice.menu.separator, '&#x2192;') and
+        $symbol.font.family != ''">
+        <fo:inline font-family="{$symbol.font.family}">
           <xsl:copy-of select="$menuchoice.menu.separator"/>
         </fo:inline>
       </xsl:when>

Regards,
Alexey.

On Friday, May 10, 2013 11:53:24 PM Bob Stayton wrote:


Hi Alexey,
When I use the default fonts in FOP and remove the special code and allow FOP 1.1 to 
fall back through the font list to Symbol, then the arrow character is positioned 
slightly *below* the baseline, which looks awful.  If I retain the fo:inline font-
family="Symbol", then it positions correctly.  So I will retain the fo:inline exception 
and set it to the $symbo

Re: dbtoepub is broken on latest docbook-xsl-ns-snapshot

Shlomi Fish — 2013-05-11T16:42:21

Hi all,

does anyone have any idea about it?

Regards,

Shlomi Fish

On Wed, 8 May 2013 14:08:59 +0300
Shlomi Fish <shlomif< at >shlomifish.org> wrote: