Re: [docbook-apps] Re: Including a variable in an xlink:href value

[Mark Craig]

Hello Janice,

Since you're using Maven, as a workaround you could use bare Maven
expressions and perform Maven filtering on the source before using the
docbkx plugin.

Maven filtering replaces expressions like ${project.version} with the
values of their Maven properties. For example, in a 1.0.0-SNAPSHOT project,
${project.version} would be replaced with 1.0.0-SNAPSHOT. Unlike docbkx,
which works on the XML, Maven filtering works with the files as if they
were plain text.

In the source, no need to figure out how to embed a processing instruction
inside an attribute value. Just use the Maven expression. In your example:
xlink:href="
https://mycompany.com/directory/file-name-${project.version}.tar.gz;

In the  of your Maven pom.xml:

   - Use the Maven resources plugin before docbkx-tools to make a filtered
   copy of your DocBook sources. You can use the
   
https://maven.apache.org/plugins/maven-resources-plugin/copy-resources-mojo.html
   goal to be able to set the output directory, ignore image files, escape
   literal ${...}s in your docs, etc.
   - Configure docbkx-tools to use the filtered sources in the output
   directory of the Maven resources plugin, rather than the original
   (unfiltered) sources.

Hope it helps. Regards,

Mark

On Wed, Jan 10, 2018 at 2:10 PM, Janice Manwiller  wrote:

> I probably should clarify that the  notation
> is specific to the Maven docbkx plugin, which we use to generate the output.
>
> I also tried to create an entity file containing a version entity using
> the info from http://www.sagehill.net/docbookxsl/Db5Entities.html. When I
> tried to add the DOCTYPE element to refer back to the entity file, Oxygen
> rejected it as not being well-formed. So I couldn't test whether I could
> use an entity reference to incorporate the version number in the link
> target.
>
>
>
> On Thu, Jan 4, 2018 at 11:14 AM, Janice Manwiller 
> wrote:
>
>> In my docs, I currently use  to indicate to
>> insert the current product version number into the text.
>>
>> I'm adding a link to a URL that includes the version number in the file
>> name, but if I try to include the version number variable in the link, like:
>>
>> xlink:href="https://mycompany.com/directory/file-name-> ${project.version}?>.tar.gz"
>>
>> I get an error that the link cannot include the < character.
>>
>> Is there any way to include the variable in the link, so that the version
>> number portion of the URL is populated automatically? Right now I'm stuck
>> having the link be to the enclosing directory, with the file name referred
>> to separately:
>>
>> file-name-.tar.gz in
>> https://mycompany.com/directory/;>https://mycomp
>> any.com/directory/
>>
>> Thanks,
>>
>> Janice
>>
>
>
>
> --
> Janice Manwiller
> Principal Technical Writer
> Sqrrl Data, Inc.
> www.sqrrl.com | @SqrrlData
>

Re: [docbook-apps] Switching manpage generation from docbook-SGML to docbook-xml

[Mark Craig]

Hello,

If you get the DocBook XSL stylesheets, you can probably do the conversion
with the xsltproc tool as shown in
http://www.sagehill.net/docbookxsl/RefentryToMan.html

Hope it helps,
Mark

PS The XSL conversion works fine in the toolchain I'm using (in a Maven
project, so with a plugin based on https://github.com/mimil/docbkx-tools ),
and we do almost nothing to change the default configuration for man page
conversion. Just this:

 
 



On Fri, Oct 6, 2017 at 10:52 AM, Guido Günther  wrote:

> Hi,
>
> I'm currently trying to switch git-buildpackage's documentationน from
> SGML to XML. That worked out nicely for the HTML docs but there's one
> problem with the manpages I'm stuck with. I used the build manpages.refs
> from docbook2man to get the cross references in the manpages right:
>
> https://github.com/agx/git-buildpackage/blob/master/docs/Makefile#L64
>
> Now I can't seem to figure out how this works with docbook2x-man. Is
> this at all possible? If not are there other tools that can handle this?
> Any hint would be greatly appreciated!
> Cheers,
>  -- Guido
>
> น) https://github.com/agx/git-buildpackage/blob/master/docs/
>
> -
> 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] future of DocBook XML Schema (XSD)?

[Mark Craig]

Hi,

At present we are using declarations that reference the XSD, such as:

http://docbook.org/ns/docbook; version="5.0" xml:lang="en"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation="http://docbook.org/ns/docbook
  http://docbook.org/xml/5.0/xsd/docbook.xsd;
  xmlns:xinclude="http://www.w3.org/2001/XInclude;>
...


It looks like the XMLSchema-related attributes are unnecessary. In other
words, if I remove cached schemas from my editor (using IntelliJ IDEA),
edit the book and open it again, this appears to work fine as well for
validation and tag completion and so forth:

http://docbook.org/ns/docbook; version="5.0" xml:lang="en"
  xmlns:xinclude="http://www.w3.org/2001/XInclude;>
...


How does an editor know how to resolve that to
http://docbook.org/xml/5.0/rng/docbook.rng?

We also use a tool for validation and link checking that currently uses the
XSD, though it can no doubt be changed to use the RNG.

Regards,
Mark

On Tue, Oct 18, 2016 at 11:04 PM, Steve Ball 
wrote:

> Hi Bob,
>
> I manage a large schema that uses DocBook 5. The normative schema is
> RelaxNG. This schema is automatically translated to XSD using Trang, but
> the resulting XSD files have to be post-processed in order to fix them
> before they are useable by consumers.
>
> DocBook 6 in pure RelaxNG+Schematron would be fine with me.
>
> Cheers,
> Steve Ball
>
> > On 19 Oct 2016, at 5:51 AM, Bob Stayton  wrote:
> >
> > The DocBook Technical Committee is considering dropping the XML Schema
> version of DocBook in a future version 6.  We would like to hear from any
> members of the DocBook community who would be affected by this change.
> >
> > Let me be clear that this change is not on the horizon, but part of our
> long term planning.  The DocBook TC takes great care in maintaining
> backwards compatibility on point releases because we know how much the
> DocBook community relies on stable sources.  When DocBook rolls to a new
> major version number, we treat that as an opportunity to introduce changes
> that are not backwards compatible.  The change from 4 to 5 was such.  If we
> foresee such changes coming, we give the DocBook community very advanced
> notice to prepare for them.
> >
> > We will continue to maintain the DocBook standard in RelaxNG with
> Schematron rules, and will continue to generate a compatible DTD.
> >
> > However, the process of maintaining the XSD version of DocBook is
> proving burdensome because it cannot be completely generated by a
> conversion program, and requires manual tweaking.  Because we are not sure
> if anyone is actually using the XSD version, we are wondering if this is
> worth the effort.  If you are using it, or have tools that depend on XSD,
> please let us know.
> >
> > You can reply directly to me if you don't want to discuss it on the
> mailing list.
> >
> > --
> > Bob Stayton
> > Sagehill Enterprises
> > b...@sagehill.net
> >
> > -
> > To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org
> > For additional commands, e-mail: docbook-h...@lists.oasis-open.org
> >
>
>
> -
> To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
>
>

[docbook-apps] Re: Profiling/conditional text based on document context?

[Mark Craig]

Thanks, Simon. I'll look how we could integrate use of PACBook into the
build.

Regards,
Mark

[docbook-apps] mark.optional.procedure.steps for HTML in 1.79.0?

[Mark Craig]

Hello,

In testing 1.79.0, I was pleased to find this turned on by default:
http://snapshots.docbook.org/xsl/doc/fo/mark.optional.procedure.steps.html

What is the equivalent parameter for HTML output?

Regards,
Mark

Re: [docbook-apps] Restrictive Docbook XML editor which enforces Docbook schema?

[Mark Craig]

Hello,

IDEs like Eclipse and IntelliJ IDEA don’t quite prevent you from inserting the 
wrong element or attribute, but once you’ve fetched the XSD they help with tag 
completion and also immediately flag invalid markup (in red text for example). 
Both those IDEs let you run validation, making it straightforward to find 
markup errors.

Of course both IDEs have you edit text. Neither have WYSIWYG capabilities as 
far as I know.

Regards,
Mark

 On 15 Jan 2015, at 16:01, Dan Shelton dan.f.shel...@gmail.com wrote:
 
 Is there a Docbook XML editor which enforces the Docbook schema during 
 editing?
 
 I am looking for an editor which loads the Docbook XML schema and then
 only allows the creation of tags which are allowed at the current
 position in the XML document.
 
 Dan
 
 -
 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] Coloring only internal links in FO?

[Mark Craig]

Thanks Nick!

olink vs. link xlink:role=http://docbook.org/xlink/role/olink; is
indeed what makes the difference.
I was I guess mistakenly expecting them to work in the same way.

In my example, your solution works fine both using xsltproc, fop, and the
stylesheets directly and also using docbkx-tools with olink
targetdoc=book targetptr=chapterlink to book's chapter/olink, but
not with link having xlink:role=http://docbook.org/xlink/role/olink;.

I guess the workaround is then to transform all the links with olink roles
into olink before processing the output.

Regards,
Mark


On Wed, Jun 4, 2014 at 11:20 AM, Wood Nick nick.w...@ncia.nato.int wrote:

  Mark,



 Then I doubt the xsl:param name=activate.external.olinks select=0 /
 will work.  Have you tried linking using olink targetdoc=”foodoc”
 targetptr=”foochap /, if you haven’t there are some additional actions
 required such as generating the target data files.



 I have a sample (on an internal network) if you need it.



 Regards



 Nick



 *From:* Mark Craig [mailto:mark.cr...@gmail.com]
 *Sent:* Wednesday, June 04, 2014 10:16 AM
 *To:* Wood Nick
 *Cc:* Bob Stayton; DocBook Apps

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



 Hi Nick,



 The sample uses link with xlink:role set:





  link xlink:href=book#chapter



xlink:show=new



xlink:role=http://docbook.org/xlink/role/olink;chapter/link





 Regards,

 Mark



 On Wed, Jun 4, 2014 at 9:12 AM, Wood Nick nick.w...@ncia.nato.int wrote:

 Mark,



 Are you using the olink element in your source document, as I seem to
 recall in a post on the docbkx user forum that you was using link instead?



 Regards



 Nick





 *From:* Mark Craig [mailto:mark.cr...@gmail.com]
 *Sent:* Tuesday, June 03, 2014 9:41 PM
 *To:* Bob Stayton
 *Cc:* DocBook Apps
 *Subject:* Re: [docbook-apps] Coloring only internal links in FO?



 Hello again,



 On the docbkx-tools list, Cedric suggested I try to reproduce the symptom
 of color showing up when xsl:param name=activate.external.olinks
 select=0 / without using docbkx-tools, but instead using the 1.78.1
 stylesheets directly.



 That's actually easier said than done.



 With
 https://github.com/markcraig/DOCS-47/commit/6b5ca793474887655dcfe95d585a8e0cbf5af9e5
 I can generate PDFs that do include olinks, and the inter-book olink does
 turn out blue. But I'm not sure the olinks are getting resolved correctly.



 Where could I find a simpler example to read so I can see how turning off
 activate.external.olinks does deactivate the coloring?



 Regards,

 Mark



 On Fri, May 2, 2014 at 11:34 PM, Mark Craig mark.cr...@gmail.com wrote:

 Thanks Bob, Chris,



 At least I see what the expected behavior is.



 No doubt a problem somewhere in my own code.



 Mark





 On Fri, May 2, 2014 at 7:53 PM, Bob Stayton b...@sagehill.net wrote:

 Hi Mark,
 Unless I'm misunderstanding what you are trying to do,
 it should already work that way.  That is, if you are setting
 activate.external.olinks to zero, then the external olinks should render as
 plain text and not be formatted with the xref.properties attribute-set.
  The xref.properties attribute-set is only applied when fo:basic-link is
 being output with @internal-destination, or if the element is an actual
 xref which also generates that output.

 I just tried it with 1.78.1 and setting:

 xsl:param name=activate.external.olinks select=0/
 xsl:param name=current.docidshortbook/xsl:param



 xsl:attribute-set name=xref.properties
   xsl:attribute name=color#47a/xsl:attribute
 /xsl:attribute-set

 In my PDF, the internal olinks are colored, but my external olinks are not
 (and are not active).

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



 On 5/2/2014 12: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:

xsl:attribute-set name=xref.properties
  xsl:attribute name=color#47a/xsl:attribute
/xsl:attribute-set

 This makes all the links blue... unfortunately including deactivated
 external olinks.

 I have tried setting olink.properties, too, with #000 as the color, but I
 still see blue text in the PDF output for all links, including deactivated
 external links.

 Asking authors to add more attributes to external links is something I'd
 like to avoid.

 Thanks in advance for your time and your help.

 Regards,
 Mark

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

[Mark Craig]

Just a quick follow up question...

Is this the intended (permanent) behavior of
http://docbook.sourceforge.net/release/xsl/current/doc/fo/activate.external.olinks.html
in that it work only for olink elements and not also with elements having
the xlink:role=http://docbook.org/xlink/role/olink; attribute?

(I was thinking of elements having the xlink:role=
http://docbook.org/xlink/role/olink; attribute as being olinks, too.)

Regards,
Mark


On Wed, Jun 4, 2014 at 11:36 AM, Mark Craig mark.cr...@gmail.com wrote:

 Thanks Nick!

 olink vs. link xlink:role=http://docbook.org/xlink/role/olink; is
 indeed what makes the difference.
 I was I guess mistakenly expecting them to work in the same way.

 In my example, your solution works fine both using xsltproc, fop, and the
 stylesheets directly and also using docbkx-tools with olink
 targetdoc=book targetptr=chapterlink to book's chapter/olink, but
 not with link having xlink:role=http://docbook.org/xlink/role/olink;.

 I guess the workaround is then to transform all the links with olink roles
 into olink before processing the output.

 Regards,
 Mark


 On Wed, Jun 4, 2014 at 11:20 AM, Wood Nick nick.w...@ncia.nato.int
 wrote:

  Mark,



 Then I doubt the xsl:param name=activate.external.olinks select=0 /
 will work.  Have you tried linking using olink targetdoc=”foodoc”
 targetptr=”foochap /, if you haven’t there are some additional actions
 required such as generating the target data files.



 I have a sample (on an internal network) if you need it.



 Regards



 Nick



 *From:* Mark Craig [mailto:mark.cr...@gmail.com]
 *Sent:* Wednesday, June 04, 2014 10:16 AM
 *To:* Wood Nick
 *Cc:* Bob Stayton; DocBook Apps

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



 Hi Nick,



 The sample uses link with xlink:role set:





  link xlink:href=book#chapter



xlink:show=new



xlink:role=http://docbook.org/xlink/role/olink;chapter/link





 Regards,

 Mark



 On Wed, Jun 4, 2014 at 9:12 AM, Wood Nick nick.w...@ncia.nato.int
 wrote:

 Mark,



 Are you using the olink element in your source document, as I seem to
 recall in a post on the docbkx user forum that you was using link instead?



 Regards



 Nick





 *From:* Mark Craig [mailto:mark.cr...@gmail.com]
 *Sent:* Tuesday, June 03, 2014 9:41 PM
 *To:* Bob Stayton
 *Cc:* DocBook Apps
 *Subject:* Re: [docbook-apps] Coloring only internal links in FO?



 Hello again,



 On the docbkx-tools list, Cedric suggested I try to reproduce the symptom
 of color showing up when xsl:param name=activate.external.olinks
 select=0 / without using docbkx-tools, but instead using the 1.78.1
 stylesheets directly.



 That's actually easier said than done.



 With
 https://github.com/markcraig/DOCS-47/commit/6b5ca793474887655dcfe95d585a8e0cbf5af9e5
 I can generate PDFs that do include olinks, and the inter-book olink does
 turn out blue. But I'm not sure the olinks are getting resolved correctly.



 Where could I find a simpler example to read so I can see how turning off
 activate.external.olinks does deactivate the coloring?



 Regards,

 Mark



 On Fri, May 2, 2014 at 11:34 PM, Mark Craig mark.cr...@gmail.com wrote:

 Thanks Bob, Chris,



 At least I see what the expected behavior is.



 No doubt a problem somewhere in my own code.



 Mark





 On Fri, May 2, 2014 at 7:53 PM, Bob Stayton b...@sagehill.net wrote:

 Hi Mark,
 Unless I'm misunderstanding what you are trying to do,
 it should already work that way.  That is, if you are setting
 activate.external.olinks to zero, then the external olinks should render as
 plain text and not be formatted with the xref.properties attribute-set.
  The xref.properties attribute-set is only applied when fo:basic-link is
 being output with @internal-destination, or if the element is an actual
 xref which also generates that output.

 I just tried it with 1.78.1 and setting:

 xsl:param name=activate.external.olinks select=0/
 xsl:param name=current.docidshortbook/xsl:param



 xsl:attribute-set name=xref.properties
   xsl:attribute name=color#47a/xsl:attribute
 /xsl:attribute-set

 In my PDF, the internal olinks are colored, but my external olinks are
 not (and are not active).

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



 On 5/2/2014 12: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:

xsl:attribute-set name=xref.properties
  xsl:attribute name=color#47a/xsl:attribute
/xsl:attribute-set

 This makes all the links blue... unfortunately

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

[Mark Craig]

Thanks Bob,

I have submitted https://sourceforge.net/p/docbook/bugs/1337/

Regards,
Mark


On Wed, Jun 4, 2014 at 4:33 PM, Bob Stayton b...@sagehill.net wrote:

 No, I don't think this is the intended behavior.  The link elements with
 the olink role should behave the same as olink elements.
 Can someone please file a bug report on the DocBook SourceForge site to
 capture this problem so it can be fixed?


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

 On 6/4/2014 2:52 AM, Mark Craig wrote:

 Just a quick follow up question...

 Is this the intended (permanent) behavior of
 http://docbook.sourceforge.net/release/xsl/current/doc/
 fo/activate.external.olinks.html
 in that it work only for olink elements and not also with elements
 having
 the xlink:role=http://docbook.org/xlink/role/olink; attribute?

 (I was thinking of elements having the xlink:role=
 http://docbook.org/xlink/role/olink; attribute as being olinks, too.)

 Regards,
 Mark


 On Wed, Jun 4, 2014 at 11:36 AM, Mark Craig mark.cr...@gmail.com wrote:

  Thanks Nick!

 olink vs. link xlink:role=http://docbook.org/xlink/role/olink; is
 indeed what makes the difference.
 I was I guess mistakenly expecting them to work in the same way.

 In my example, your solution works fine both using xsltproc, fop, and the
 stylesheets directly and also using docbkx-tools with olink
 targetdoc=book targetptr=chapterlink to book's chapter/olink, but
 not with link having xlink:role=http://docbook.org/xlink/role/olink;.

 I guess the workaround is then to transform all the links with olink
 roles
 into olink before processing the output.

 Regards,
 Mark


 On Wed, Jun 4, 2014 at 11:20 AM, Wood Nick nick.w...@ncia.nato.int
 wrote:

Mark,



 Then I doubt the xsl:param name=activate.external.olinks select=0
 /
 will work.  Have you tried linking using olink targetdoc=”foodoc”
 targetptr=”foochap /, if you haven’t there are some additional actions
 required such as generating the target data files.



 I have a sample (on an internal network) if you need it.



 Regards



 Nick



 *From:* Mark Craig [mailto:mark.cr...@gmail.com]
 *Sent:* Wednesday, June 04, 2014 10:16 AM
 *To:* Wood Nick
 *Cc:* Bob Stayton; DocBook Apps

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




 Hi Nick,



 The sample uses link with xlink:role set:





   link xlink:href=book#chapter



 xlink:show=new



 xlink:role=http://docbook.org/xlink/role/olink;chapter/link





 Regards,

 Mark



 On Wed, Jun 4, 2014 at 9:12 AM, Wood Nick nick.w...@ncia.nato.int
 wrote:

 Mark,



 Are you using the olink element in your source document, as I seem to
 recall in a post on the docbkx user forum that you was using link
 instead?



 Regards



 Nick





 *From:* Mark Craig [mailto:mark.cr...@gmail.com]
 *Sent:* Tuesday, June 03, 2014 9:41 PM
 *To:* Bob Stayton
 *Cc:* DocBook Apps
 *Subject:* Re: [docbook-apps] Coloring only internal links in FO?




 Hello again,



 On the docbkx-tools list, Cedric suggested I try to reproduce the
 symptom
 of color showing up when xsl:param name=activate.external.olinks
 select=0 / without using docbkx-tools, but instead using the 1.78.1
 stylesheets directly.



 That's actually easier said than done.



 With
 https://github.com/markcraig/DOCS-47/commit/
 6b5ca793474887655dcfe95d585a8e0cbf5af9e5
 I can generate PDFs that do include olinks, and the inter-book olink
 does
 turn out blue. But I'm not sure the olinks are getting resolved
 correctly.



 Where could I find a simpler example to read so I can see how turning
 off
 activate.external.olinks does deactivate the coloring?



 Regards,

 Mark



 On Fri, May 2, 2014 at 11:34 PM, Mark Craig mark.cr...@gmail.com
 wrote:

 Thanks Bob, Chris,



 At least I see what the expected behavior is.



 No doubt a problem somewhere in my own code.



 Mark





 On Fri, May 2, 2014 at 7:53 PM, Bob Stayton b...@sagehill.net wrote:

 Hi Mark,
 Unless I'm misunderstanding what you are trying to do,
 it should already work that way.  That is, if you are setting
 activate.external.olinks to zero, then the external olinks should
 render as
 plain text and not be formatted with the xref.properties attribute-set.
   The xref.properties attribute-set is only applied when fo:basic-link
 is
 being output with @internal-destination, or if the element is an actual
 xref which also generates that output.

 I just tried it with 1.78.1 and setting:

 xsl:param name=activate.external.olinks select=0/
 xsl:param name=current.docidshortbook/xsl:param



 xsl:attribute-set name=xref.properties
xsl:attribute name=color#47a/xsl:attribute
 /xsl:attribute-set

 In my PDF, the internal olinks are colored, but my external olinks are
 not (and are not active).

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



 On 5/2/2014 12: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

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

[Mark Craig]

Hello again,

On the docbkx-tools list, Cedric suggested I try to reproduce the symptom
of color showing up when xsl:param name=activate.external.olinks
select=0 / without using docbkx-tools, but instead using the 1.78.1
stylesheets directly.

That's actually easier said than done.

With
https://github.com/markcraig/DOCS-47/commit/6b5ca793474887655dcfe95d585a8e0cbf5af9e5
I can generate PDFs that do include olinks, and the inter-book olink does
turn out blue. But I'm not sure the olinks are getting resolved correctly.

Where could I find a simpler example to read so I can see how turning off
activate.external.olinks does deactivate the coloring?

Regards,
Mark


On Fri, May 2, 2014 at 11:34 PM, Mark Craig mark.cr...@gmail.com wrote:

 Thanks Bob, Chris,

 At least I see what the expected behavior is.

 No doubt a problem somewhere in my own code.

 Mark



 On Fri, May 2, 2014 at 7:53 PM, Bob Stayton b...@sagehill.net wrote:

 Hi Mark,
 Unless I'm misunderstanding what you are trying to do,
 it should already work that way.  That is, if you are setting
 activate.external.olinks to zero, then the external olinks should render as
 plain text and not be formatted with the xref.properties attribute-set.
  The xref.properties attribute-set is only applied when fo:basic-link is
 being output with @internal-destination, or if the element is an actual
 xref which also generates that output.

 I just tried it with 1.78.1 and setting:

 xsl:param name=activate.external.olinks select=0/
 xsl:param name=current.docidshortbook/xsl:param


 xsl:attribute-set name=xref.properties
   xsl:attribute name=color#47a/xsl:attribute
 /xsl:attribute-set

 In my PDF, the internal olinks are colored, but my external olinks are
 not (and are not active).

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


 On 5/2/2014 12: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:

xsl:attribute-set name=xref.properties
  xsl:attribute name=color#47a/xsl:attribute
/xsl:attribute-set

 This makes all the links blue... unfortunately including deactivated
 external olinks.

 I have tried setting olink.properties, too, with #000 as the color, but I
 still see blue text in the PDF output for all links, including
 deactivated
 external links.

 Asking authors to add more attributes to external links is something I'd
 like to avoid.

 Thanks in advance for your time and your help.

 Regards,
 Mark

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

[Mark Craig]

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:

  xsl:attribute-set name=xref.properties
xsl:attribute name=color#47a/xsl:attribute
  /xsl:attribute-set

This makes all the links blue... unfortunately including deactivated
external olinks.

I have tried setting olink.properties, too, with #000 as the color, but I
still see blue text in the PDF output for all links, including deactivated
external links.

Asking authors to add more attributes to external links is something I'd
like to avoid.

Thanks in advance for your time and your help.

Regards,
Mark

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

[Mark Craig]

Thanks Bob, Chris,

At least I see what the expected behavior is.

No doubt a problem somewhere in my own code.

Mark



On Fri, May 2, 2014 at 7:53 PM, Bob Stayton b...@sagehill.net wrote:

 Hi Mark,
 Unless I'm misunderstanding what you are trying to do,
 it should already work that way.  That is, if you are setting
 activate.external.olinks to zero, then the external olinks should render as
 plain text and not be formatted with the xref.properties attribute-set.
  The xref.properties attribute-set is only applied when fo:basic-link is
 being output with @internal-destination, or if the element is an actual
 xref which also generates that output.

 I just tried it with 1.78.1 and setting:

 xsl:param name=activate.external.olinks select=0/
 xsl:param name=current.docidshortbook/xsl:param


 xsl:attribute-set name=xref.properties
   xsl:attribute name=color#47a/xsl:attribute
 /xsl:attribute-set

 In my PDF, the internal olinks are colored, but my external olinks are not
 (and are not active).

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


 On 5/2/2014 12: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:

xsl:attribute-set name=xref.properties
  xsl:attribute name=color#47a/xsl:attribute
/xsl:attribute-set

 This makes all the links blue... unfortunately including deactivated
 external olinks.

 I have tried setting olink.properties, too, with #000 as the color, but I
 still see blue text in the PDF output for all links, including deactivated
 external links.

 Asking authors to add more attributes to external links is something I'd
 like to avoid.

 Thanks in advance for your time and your help.

 Regards,
 Mark

[docbook-apps] NPE when building RTF from .fo

[Mark Craig]

Hello,

With DocBook XSL 1.78.1 and Apache FOP 1.1, I'm running into an NPE when
building RTF. Has anyone else run into this?

I first encountered this issue with docbkx-tools,
https://code.google.com/p/docbkx-tools/issues/detail?id=112

Here's how I reproduce it driving the stylesheets with xsltproc instead of
docbkx-tools. (This requires Apache Maven to generate the DocBook example.)

$ mvn \
archetype:generate \
-DgroupId=org.mcraig.test \
-DartifactId=docbkx-rtf-build \
-Dversion=1.0-SNAPSHOT \
-DarchetypeGroupId=com.agilejava.docbkx \
-DarchetypeArtifactId=docbkx-quickstart-archetype \
-DarchetypeVersion=2.0.15

$ xsltproc \
--output book.fo \
--xinclude \
--stringparam fop1.extensions 1 \
docbook/fo/docbook.xsl \
docbkx-rtf-build/src/docbkx/book.xml

PDF generates fine...

$ ./fop-1.1/fop book.fo book.pdf
Feb 25, 2014 10:15:23 PM org.apache.fop.events.LoggingEventListener
processEvent
WARNING: Font Symbol,normal,700 not found. Substituting with
Symbol,normal,400.
Feb 25, 2014 10:15:23 PM org.apache.fop.events.LoggingEventListener
processEvent
WARNING: Font ZapfDingbats,normal,700 not found. Substituting with
ZapfDingbats,normal,400.
Feb 25, 2014 10:15:23 PM org.apache.fop.events.LoggingEventListener
processEvent
INFO: Rendered page #1.
Feb 25, 2014 10:15:23 PM org.apache.fop.hyphenation.Hyphenator
getHyphenationTree
SEVERE: Couldn't find hyphenation pattern for lang=en.
Feb 25, 2014 10:15:23 PM org.apache.fop.events.LoggingEventListener
processEvent
INFO: Rendered page #2.
Feb 25, 2014 10:15:23 PM org.apache.fop.events.LoggingEventListener
processEvent
SEVERE: Image not found. URI: media/martin-luther-king.jpg. (See position
2:52635)
Feb 25, 2014 10:15:23 PM org.apache.fop.events.LoggingEventListener
processEvent
INFO: Rendered page #3.
Feb 25, 2014 10:15:23 PM org.apache.fop.events.LoggingEventListener
processEvent
INFO: Rendered page #4.

RTF results in an NPE...

$ ./fop-1.1/fop book.fo -rtf book.rtf
Feb 25, 2014 10:14:50 PM org.apache.fop.events.LoggingEventListener
processEvent
WARNING: Only simple-page-masters are supported on page-sequences. Using
default simple-page-master from page-sequence-master titlepage. (See
position 2:21064)
Feb 25, 2014 10:14:50 PM org.apache.fop.cli.Main startFOP
SEVERE: Exception
org.apache.fop.apps.FOPException
java.lang.NullPointerException
at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:303)
at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:130)
at org.apache.fop.cli.Main.startFOP(Main.java:177)
at org.apache.fop.cli.Main.main(Main.java:208)
Caused by: java.lang.NullPointerException
at
org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221)
at
org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:119)
at
org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:325)
at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:175)
at
org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484)
at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:300)
... 3 more

-

java.lang.NullPointerException
at
org.apache.fop.render.rtf.RTFHandler.startPageSequence(RTFHandler.java:221)
at
org.apache.fop.fo.pagination.PageSequence.startOfNode(PageSequence.java:119)
at
org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:325)
at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:175)
at
org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at 

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

[Mark Craig]

Thanks David,

Hmm, it does seem to work… but, as Bob suggested, only if I set the height 
attribute to something specific.

In other words, height=100% leaves the image spilling into the bottom margin.
height=7in seems to work for my page size as long as the image is alone with 
no text.

Mark

On 06 Jan 2014, at 16:09, David Cramer da...@thingbag.net wrote:

 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

[docbook-apps] Fitting tall images in PDF

[Mark Craig]

Hello,

As suggested in http://www.sagehill.net/docbookxsl/ImageSizing.html, I have
been using imagedata  ... scalefit=1 width=100% contentdepth=100%/
to keep images at their natural size unless too wide to fit.

What are the settings to do the same with regard to image depth (i.e.
height)?
In other words, keep images at their natural size unless too tall to fit.

Adding depth=100% and contentwidth=100% does not seem to fit overly
tall images. Perhaps this is because, The following attributes are
mutually exclusive: contentwidth, scale, and scalefit. If more than one of
these attributes is used on an image, then the earliest one in this list
takes precedence.

At present I'm still using 1.76.1 stylesheets.

Thanks for suggestions.

Regards,
Mark

Re: [docbook-apps] Olinks in PDF missing valid destination?

[Mark Craig]

Hi Bob,

What I observed with insertOlinkPdfFrag left undefined -- I'm assuming
that means insert.olink.pdf.frag is 0 -- I was getting
external-destination=url(#dest=) in the .fo. No file name, no fragment.

I think docbkx-tools 2.0.14 is picking up version 1.76.1 stylesheets. What
I didn't do is get the stylesheets and try without docbkx-tools.

Regards,
Mark


On Thu, Oct 24, 2013 at 7:46 PM, Bob Stayton b...@sagehill.net wrote:

 **
 Hi Mark,
 Can you clarify one point for me?   When insertOlinkPdfFrag is not set
 to 1, does not properly resolved mean the link can open the other PDF
 document but not scroll to the proper location, or does it not open the
 other PDF at all?  I would expect the former.

 I'm not a user of docbkx-tools, but I presume setting
 insertOlinkPdfFrag is the same as setting the DocBook XSL stylesheet
 parameter named 'insert.olink.pdf.frag', right?  That parameter's default
 value should probably be 1, now that all XSL-FO processors support the
 fragment identifiers.

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

  *From:* Mark Craig mark.cr...@gmail.com
 *Sent:* Thursday, October 24, 2013 6:00 AM
 *To:* Wood Nick nick.w...@ncia.nato.int ; DocBook 
 Appsdocbook-apps@lists.oasis-open.org
 *Subject:* Re: [docbook-apps] Olinks in PDF missing valid destination?

 By the way,

 When I want to resolve olinks between PDF documents, it looks like I also
 need insertOlinkPdfFrag1/insertOlinkPdfFrag.

 Otherwise external-destinations are not properly resolved (though
 according to Olink debug messages they are resolved).

 Again, I'm seeing this behavior with 1.76.1.

 Regards,
 Mark

  On Oct 23, 2013, at 3:38 PM, Mark Craig wrote:

  Hi Nick,

 Thanks very much for your help.

 Following your suggestion does the trick:

 currentDocidbook/currentDocid

 As a result, the link gets resolved as an internal-destination in the .fo,
 and this works fine in the PDF.

 fo:basic-link internal-destination=chapterfo:inlinelink to the next
 chapter/fo:inline/fo:basic-link.

 Regards,
 Mark

  On Oct 23, 2013, at 2:35 PM, Wood Nick wrote:

   Mark,
 ** **
 I do not pretend to be an expert on this – I setup my pdf olinks using
 Bob’s excellent book plus some guidance you have posted in the past.
 However, have you tried adding currentDocid/ in the configuration/ of
 your POM and then using the sitemap in your olinkdb.xml (as I believe this
 provide the location of the documents).
 ** **
 Regards
 ** **
 Nick
 ** **
 ** **
  *From:* Mark Craig [mailto:mark.cr...@gmail.com]
 *Sent:* Wednesday, October 23, 2013 10:11 AM
 *To:* DocBook Apps
 *Subject:* [docbook-apps] Olinks in PDF missing valid destination?
 ** **
 Hello,
  ** **
  In the past I have successfully set up Olink resolution for HTML.
  ** **
  I have read and tried to implement
  http://www.sagehill.net/docbookxsl/OlinkPrintOutput.html#PdfLinkingSetup*
 ***
  But I'm not managing to do the same for PDF.
  ** **
  A clickable link of the Olink is there in the PDF, but with no valid
 destination.
  ** **
  This is with docbkx-tools 2.0.14, so DocBook XSL 1.76.1 and FOP 1 (I
 think 1.1).
  ** **
  My little test is at https://github.com/markcraig/DOCS-47.
  (There's only one Olink, in the para at line 20 of 
 book.xmlhttps://github.com/markcraig/DOCS-47/blob/master/src/docbkx/book.xml#L20
 .)
  ** **
  The main part of the target database 
 documenthttps://github.com/markcraig/DOCS-47/blob/master/src/docbkx/olinkdb.xml
  for
 the test is minimal:
  ** **
  ?xml version='1.0' encoding='utf-8'?
  !DOCTYPE targetset[
  …
  !ENTITY book SYSTEM '../../target/target.db'
  ]
  targetset
   document targetdoc=book baseuri=book.pdfbook;/document
  /targetset
  ** **
  Although Olink debug messages make it look like the stylesheets are
 finding a match for the link, the .fo is missing information.
  ** **
  In the build output, I see:
  ** **
  Olink debug: cases for targetdoc='book' and targetptr='chapter' in
 language ''.
  Olink debug: CaseA matched.
  Olink debug: CaseA key is the final selection: book/chapter/
  ** **
  But the .fo has an external-destination with no actual destination:
  ** **
  fo:basic-link show-destination=replace
 external-destination=url(#dest=)
  fo:inlinelink to the next chapter/fo:inline/fo:basic-link
  ** **
  If I remove the baseuri value from the document element in the target
 database document, then the external-destination attribute changes a little:
 
  ** **
   fo:basic-link show-destination=replace
 external-destination=url(#dest=chapter)
  fo:inlinelink to the next chapter/fo:inline/fo:basic-link
  ** **
  What should I do differently for a valid destination to be generated?
  ** **
  Thanks for your advice.
  Regards,
  Mark

[docbook-apps] Olinks in PDF missing valid destination?

[Mark Craig]

Hello,

In the past I have successfully set up Olink resolution for HTML.

I have read and tried to implement
http://www.sagehill.net/docbookxsl/OlinkPrintOutput.html#PdfLinkingSetup
But I'm not managing to do the same for PDF.

A clickable link of the Olink is there in the PDF, but with no valid 
destination.

This is with docbkx-tools 2.0.14, so DocBook XSL 1.76.1 and FOP 1 (I think 1.1).

My little test is at https://github.com/markcraig/DOCS-47.
(There's only one Olink, in the para at line 20 of book.xml.)

The main part of the target database document for the test is minimal:

?xml version='1.0' encoding='utf-8'?
!DOCTYPE targetset[
…
!ENTITY book SYSTEM '../../target/target.db'
]
targetset
 document targetdoc=book baseuri=book.pdfbook;/document
/targetset

Although Olink debug messages make it look like the stylesheets are finding a 
match for the link, the .fo is missing information.

In the build output, I see:

Olink debug: cases for targetdoc='book' and targetptr='chapter' in language ''.
Olink debug: CaseA matched.
Olink debug: CaseA key is the final selection: book/chapter/

But the .fo has an external-destination with no actual destination:

fo:basic-link show-destination=replace external-destination=url(#dest=)
fo:inlinelink to the next chapter/fo:inline/fo:basic-link

If I remove the baseuri value from the document element in the target 
database document, then the external-destination attribute changes a little:

fo:basic-link show-destination=replace 
external-destination=url(#dest=chapter)
fo:inlinelink to the next chapter/fo:inline/fo:basic-link

What should I do differently for a valid destination to be generated?

Thanks for your advice.
Regards,
Mark

Re: [docbook-apps] Listitem overwrites text in orderedlist

[Mark Craig]

Hi Matteo,

Setting orderedlist.label.width, 
http://docbook.sourceforge.net/release/xsl/current/doc/fo/orderedlist.label.width.html,
 seemed to help.

Setting that to 1.8em instead of the default 1.2em seemed to fix the problem 
for lists having a double-digit number of items, 
http://sources.forgerock.org/changelog/commons?cs=433, at least in my case.
Perhaps the exact setting will be different for you.

Hope it helps.

Regards,
Mark

On Oct 1, 2013, at 8:29 AM, Matteo Regazzo wrote:

 Hi everybody,
 
 I'm just learning, since 3 months, to use docbook and to write the 
 stylesheets.
 Now I have this problem: in the orderedlist of the FO the distance from the 
 listitem to the text is not dynamic and if the listitem number (dot included) 
 takes more space because it's made by 2 or more numbers (eg. 16. instead of 
 1.) it enters in the text space and mixes with it, in other words 
 overwrites the text. I'm not able to find a property of the list block to 
 arrange this problem, or (more probably) I'm using it in a wrong way.
 
 I tried in these ways, but without success:
 
 1)
 xsl:attribute-set name=list.block.spacing
 xsl:attribute name=space-after20px/xsl:attribute
 /xsl:attribute-set
 
 2)
 !--xsl:attribute-set name=list.item.label
 xsl:attribute name=margin-right20/xsl:attribute
 /xsl:attribute-set--
 
 3)(I've found this one in a website)
 xsl:attribute-set name=list.label.spacing
 xsl:attribute name=right
 xsl:choose
 xsl:when test=self::orderedlist2em/xsl:when
 xsl:otherwise0pt/xsl:otherwise
 /xsl:choose
 /xsl:attribute
 /xsl:attribute-set--
 
 I even tried with different properties of each attribute-set...
 Have you ever had this problem? Do you have any suggestion?
 
 Matteo

Re: [docbook-apps] Wide verbatim shading overflowing into right margin in PDF

[Mark Craig]

Thanks Bob,

I see now that it's documented, 
http://docbook.sourceforge.net/release/xsl/1.76.1/doc/fo/monospace.verbatim.font.width.html,
 and also that I can reach a sort of compromise with this. Maybe forcing width, 
if specified, to some known value that will force alignment with the right 
margin.

If writers want the stylesheets to treat wide programlisting elements like wide 
tables, in the style of pgwide=1, how should they go about it?

There doesn't seem to be a pgwide attribute on programlisting. Even in the 
current docs ?dbfo pgwide? looks like it applies only to equation and example.

Regards,
Mark

On Jul 11, 2013, at 7:09 PM, Bob Stayton wrote:

 Hi Mark,
 That shading is the background color of the fo:block-container that contains 
 a programlisting with width.  The width of the block-container is computed as 
 follows:
  
 @width * $monospace.verbatim.font.width
  
 where $monospace.verbatim.font.width is one of the DocBook parameters, whose 
 default value is 0.60em. You can adjust either the width or the param to get 
 a narrower box.
  
 Bob Stayton
 Sagehill Enterprises
 b...@sagehill.net
 
 From: Mark Craig
 Sent: Thursday, July 11, 2013 8:59 AM
 To: DocBook Apps
 Subject: [docbook-apps] Wide verbatim shading overflowing into right margin 
 in PDF
 
 Hello,
 
 What is the correct way to avoid wide verbatim shading from overflowing into 
 the right margin in PDF?
 
 In the attached .png, the CVS program listing example has width=92. I'd 
 like to stop the shading at the right margin, just as it starts at the left. 
 Instead the shading runs to the right edge of the page.
 
 missing-right-margin.png
 
 The build uses the v1.76.1 stylesheets with the following customization:
 
   xsl:param name=shade.verbatim select=1/
   xsl:attribute-set name=shade.verbatim.style
xsl:attribute name=background-color#d4d4d4/xsl:attribute
xsl:attribute name=border0.5pt dashed #626d75/xsl:attribute
xsl:attribute name=padding3pt/xsl:attribute
xsl:attribute name=wrap-optionno-wrap/xsl:attribute
xsl:attribute name=font-size0.75em/xsl:attribute
   /xsl:attribute-set
 
 Thanks for your advice. Regards,
 Mark

Re: [docbook-apps] Re: Eliminating soft hyphens shown in mid line?

[Mark Craig]

With docbkx-tools if I set the FO processor extensions correctly and
comment out the custom fonts, I can process the FO separately (at least it
worked for this test).

   - FOP 1.1 output is broken in the same fashion as FOP 1.0 output.
   - Antenna House's AHFormatterV6 trial version output looks good.
   - XEP trial version output looks good.

I haven't tried any other formatters besides Antenna House's and XEP, but
suspect this is a FOP issue.

Mark


On Thu, Apr 18, 2013 at 6:34 PM, Bob Stayton b...@sagehill.net wrote:

 **
 Sometimes that works.  8^)
 The FO extensions generated for each processor may trip up the process.
 I've found that FOP is the most picky about failing on unrecognized code,
 so going from FOP to something else usually works.

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

  *From:* Mark Craig mark.cr...@gmail.com
 *Sent:* Thursday, April 18, 2013 9:25 AM
 *To:* Bob Stayton b...@sagehill.net
 *Cc:* docbook-apps@lists.oasis-open.org
 *Subject:* Re: [docbook-apps] Re: Eliminating soft hyphens shown in mid
 line?

 Thanks. Can I do that by just taking the .fo generated during the build
 and processing it with another FO processor?

 (Not sure how to swap out the FO processor in docbkx-tools.)

 Mark

  On Apr 18, 2013, at 6:20 PM, Bob Stayton wrote:

  Was this example tested with another FO processor besides FOP?  That
 would settle whether it is a FOP problem.

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

  *From:* Mark Craig mark.cr...@gmail.com
 *Sent:* Thursday, April 18, 2013 6:48 AM
 *To:* docbook-apps@lists.oasis-open.org
 *Subject:* [docbook-apps] Re: Eliminating soft hyphens shown in mid line?

 In fact it looks like whether the soft hyphen shows up in mid line depends
 on the following character.

 itemizedlist
 listitemparaliteral../literal/para/listitem
 listitemparaliteral. ./literal/para/listitem
 listitemparaliteral./literal/para/listitem
 listitemparaliteral.]/literal/para/listitem
 listitemparaliteral.\/literal/para/listitem
 listitemparaliteral./literal/para/listitem
 listitemparaliteral.a/literal/para/listitem
 listitemparaliteral.Z/literal/para/listitem
/itemizedlist


 produces the following in the PDF:

  • .-­.
 • . .
 • .
 • .­-]
 • .\
 • .-­
 • .a
 • .Z


 Mark


 On Thu, Apr 18, 2013 at 3:23 PM, Mark Craig mark.cr...@gmail.com wrote:

 Hello,

 Apologies if this is really a FOP question. I'm a bit out of my depth.

 I've added some FO customization based on Bob Stayton's helpful
 suggestion on putting hyphenation within table 
 cellshttp://www.mail-archive.com/docbook@lists.oasis-open.org/msg05030.html,
 adding soft hyphens after . in literal.

 For most of the text the customization works exactly as desired in PDF.
 For example, inside of a para,
 literalcom.iplanet.am.sdk.caching.enabled/literal shows up split where
 necessary.

  You must explicitly set this property to true, because setting com.-
 iplanet.am.sdk.caching.enabled to false in the previous step disables
 both user and configuration data caching.


 I have many examples of this working throughout the documentation I'm
 working on, and it is particularly helpful in table cells.

 Unfortunately, in some cases, such as termliteraluserattr =
 [parent[child-level].]attr#GROUPDN|USERDN/literal/term, the soft
 hyphen shows up after the . even though the line does not break. (I've
 replaced the soft hyphen in the following with a hyphen so you can see what
 I mean.)

 userattr = [parent[child-level].­-]attr#GROUPDN|USERDN


 What should I do to avoid the soft hyphen appearing in the PDF in such
 cases?

 Thanks for your time and your help,
 Mark

Re: [docbook-apps] Re: Eliminating soft hyphens shown in mid line?

[Mark Craig]

I have put together a small .fo and seen the issue with the FOP nightly
build, so have mailed their user list.

Thanks again.
Mark


On Fri, Apr 19, 2013 at 9:56 AM, Mark Craig mark.cr...@gmail.com wrote:

 With docbkx-tools if I set the FO processor extensions correctly and
 comment out the custom fonts, I can process the FO separately (at least it
 worked for this test).

- FOP 1.1 output is broken in the same fashion as FOP 1.0 output.
- Antenna House's AHFormatterV6 trial version output looks good.
- XEP trial version output looks good.

 I haven't tried any other formatters besides Antenna House's and XEP, but
 suspect this is a FOP issue.

 Mark


 On Thu, Apr 18, 2013 at 6:34 PM, Bob Stayton b...@sagehill.net wrote:

 **
 Sometimes that works.  8^)
 The FO extensions generated for each processor may trip up the process.
 I've found that FOP is the most picky about failing on unrecognized code,
 so going from FOP to something else usually works.

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

  *From:* Mark Craig mark.cr...@gmail.com
 *Sent:* Thursday, April 18, 2013 9:25 AM
 *To:* Bob Stayton b...@sagehill.net
 *Cc:* docbook-apps@lists.oasis-open.org
 *Subject:* Re: [docbook-apps] Re: Eliminating soft hyphens shown in mid
 line?

 Thanks. Can I do that by just taking the .fo generated during the build
 and processing it with another FO processor?

 (Not sure how to swap out the FO processor in docbkx-tools.)

 Mark

  On Apr 18, 2013, at 6:20 PM, Bob Stayton wrote:

  Was this example tested with another FO processor besides FOP?  That
 would settle whether it is a FOP problem.

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

  *From:* Mark Craig mark.cr...@gmail.com
 *Sent:* Thursday, April 18, 2013 6:48 AM
 *To:* docbook-apps@lists.oasis-open.org
 *Subject:* [docbook-apps] Re: Eliminating soft hyphens shown in mid line?

 In fact it looks like whether the soft hyphen shows up in mid line
 depends on the following character.

 itemizedlist
 listitemparaliteral../literal/para/listitem
 listitemparaliteral. ./literal/para/listitem
 listitemparaliteral./literal/para/listitem
 listitemparaliteral.]/literal/para/listitem
 listitemparaliteral.\/literal/para/listitem
 listitemparaliteral./literal/para/listitem
 listitemparaliteral.a/literal/para/listitem
 listitemparaliteral.Z/literal/para/listitem
/itemizedlist


 produces the following in the PDF:

  • .-­.
 • . .
 • .
 • .­-]
 • .\
 • .-­
 • .a
 • .Z


 Mark


 On Thu, Apr 18, 2013 at 3:23 PM, Mark Craig mark.cr...@gmail.com wrote:

 Hello,

 Apologies if this is really a FOP question. I'm a bit out of my depth.

 I've added some FO customization based on Bob Stayton's helpful
 suggestion on putting hyphenation within table 
 cellshttp://www.mail-archive.com/docbook@lists.oasis-open.org/msg05030.html,
 adding soft hyphens after . in literal.

 For most of the text the customization works exactly as desired in PDF.
 For example, inside of a para,
 literalcom.iplanet.am.sdk.caching.enabled/literal shows up split where
 necessary.

  You must explicitly set this property to true, because setting com.-
 iplanet.am.sdk.caching.enabled to false in the previous step disables
 both user and configuration data caching.


 I have many examples of this working throughout the documentation I'm
 working on, and it is particularly helpful in table cells.

 Unfortunately, in some cases, such as termliteraluserattr =
 [parent[child-level].]attr#GROUPDN|USERDN/literal/term, the soft
 hyphen shows up after the . even though the line does not break. (I've
 replaced the soft hyphen in the following with a hyphen so you can see what
 I mean.)

 userattr = [parent[child-level].­-]attr#GROUPDN|USERDN


 What should I do to avoid the soft hyphen appearing in the PDF in such
 cases?

 Thanks for your time and your help,
 Mark

[docbook-apps] Eliminating soft hyphens shown in mid line?

[Mark Craig]

Hello,

Apologies if this is really a FOP question. I'm a bit out of my depth.

I've added some FO customization based on Bob Stayton's helpful suggestion
on putting hyphenation within table
cellshttp://www.mail-archive.com/docbook@lists.oasis-open.org/msg05030.html,
adding soft hyphens after . in literal.

For most of the text the customization works exactly as desired in PDF. For
example, inside of a para,
literalcom.iplanet.am.sdk.caching.enabled/literal shows up split where
necessary.

You must explicitly set this property to true, because setting com.-
 iplanet.am.sdk.caching.enabled to false in the previous step disables
 both user and configuration data caching.


I have many examples of this working throughout the documentation I'm
working on, and it is particularly helpful in table cells.

Unfortunately, in some cases, such as termliteraluserattr =
[parent[child-level].]attr#GROUPDN|USERDN/literal/term, the soft
hyphen shows up after the . even though the line does not break. (I've
replaced the soft hyphen in the following with a hyphen so you can see what
I mean.)

userattr = [parent[child-level].­-]attr#GROUPDN|USERDN


What should I do to avoid the soft hyphen appearing in the PDF in such
cases?

Thanks for your time and your help,
Mark

[docbook-apps] Re: Eliminating soft hyphens shown in mid line?

[Mark Craig]

In fact it looks like whether the soft hyphen shows up in mid line depends
on the following character.

   itemizedlist
 listitemparaliteral../literal/para/listitem
 listitemparaliteral. ./literal/para/listitem
 listitemparaliteral./literal/para/listitem
 listitemparaliteral.]/literal/para/listitem
 listitemparaliteral.\/literal/para/listitem
 listitemparaliteral./literal/para/listitem
 listitemparaliteral.a/literal/para/listitem
 listitemparaliteral.Z/literal/para/listitem
/itemizedlist


produces the following in the PDF:

• .-­.
 • . .
 • .
 • .­-]
 • .\
 • .-­
 • .a
 • .Z


Mark


On Thu, Apr 18, 2013 at 3:23 PM, Mark Craig mark.cr...@gmail.com wrote:

 Hello,

 Apologies if this is really a FOP question. I'm a bit out of my depth.

 I've added some FO customization based on Bob Stayton's helpful suggestion
 on putting hyphenation within table 
 cellshttp://www.mail-archive.com/docbook@lists.oasis-open.org/msg05030.html,
 adding soft hyphens after . in literal.

 For most of the text the customization works exactly as desired in PDF.
 For example, inside of a para,
 literalcom.iplanet.am.sdk.caching.enabled/literal shows up split where
 necessary.

 You must explicitly set this property to true, because setting com.-
 iplanet.am.sdk.caching.enabled to false in the previous step disables
 both user and configuration data caching.


 I have many examples of this working throughout the documentation I'm
 working on, and it is particularly helpful in table cells.

 Unfortunately, in some cases, such as termliteraluserattr =
 [parent[child-level].]attr#GROUPDN|USERDN/literal/term, the soft
 hyphen shows up after the . even though the line does not break. (I've
 replaced the soft hyphen in the following with a hyphen so you can see what
 I mean.)

 userattr = [parent[child-level].­-]attr#GROUPDN|USERDN


 What should I do to avoid the soft hyphen appearing in the PDF in such
 cases?

 Thanks for your time and your help,
 Mark

Re: [docbook-apps] Re: Eliminating soft hyphens shown in mid line?

[Mark Craig]

Thanks. Can I do that by just taking the .fo generated during the build and 
processing it with another FO processor?

(Not sure how to swap out the FO processor in docbkx-tools.)

Mark

On Apr 18, 2013, at 6:20 PM, Bob Stayton wrote:

 Was this example tested with another FO processor besides FOP?  That would 
 settle whether it is a FOP problem.
  
 Bob Stayton
 Sagehill Enterprises
 b...@sagehill.net
 
 From: Mark Craig
 Sent: Thursday, April 18, 2013 6:48 AM
 To: docbook-apps@lists.oasis-open.org
 Subject: [docbook-apps] Re: Eliminating soft hyphens shown in mid line?
 
 In fact it looks like whether the soft hyphen shows up in mid line depends on 
 the following character.
 
itemizedlist
 listitemparaliteral../literal/para/listitem
 listitemparaliteral. ./literal/para/listitem
 listitemparaliteral./literal/para/listitem
 listitemparaliteral.]/literal/para/listitem
 listitemparaliteral.\/literal/para/listitem
 listitemparaliteral./literal/para/listitem
 listitemparaliteral.a/literal/para/listitem
 listitemparaliteral.Z/literal/para/listitem
/itemizedlist
 
 produces the following in the PDF:
 
 • .-­.
 • . .
 • .
 • .­-]
 • .\
 • .-­
 • .a
 • .Z
 
 Mark
 
 
 On Thu, Apr 18, 2013 at 3:23 PM, Mark Craig mark.cr...@gmail.com wrote:
 Hello,
 
 Apologies if this is really a FOP question. I'm a bit out of my depth.
 
 I've added some FO customization based on Bob Stayton's helpful suggestion on 
 putting hyphenation within table cells, adding soft hyphens after . in 
 literal.
 
 For most of the text the customization works exactly as desired in PDF. For 
 example, inside of a para, 
 literalcom.iplanet.am.sdk.caching.enabled/literal shows up split where 
 necessary.
 
 You must explicitly set this property to true, because setting com.-
 iplanet.am.sdk.caching.enabled to false in the previous step disables
 both user and configuration data caching.
 
 I have many examples of this working throughout the documentation I'm working 
 on, and it is particularly helpful in table cells.
 
 Unfortunately, in some cases, such as termliteraluserattr = 
 [parent[child-level].]attr#GROUPDN|USERDN/literal/term, the soft hyphen 
 shows up after the . even though the line does not break. (I've replaced the 
 soft hyphen in the following with a hyphen so you can see what I mean.)
 
 userattr = [parent[child-level].­-]attr#GROUPDN|USERDN
 
 What should I do to avoid the soft hyphen appearing in the PDF in such cases?
 
 Thanks for your time and your help,
 Mark
 

Re: [docbook-apps] how email works

[Mark Craig]

Hello,

The documentation at http://www.docbook.org/tdg51/en/html/email.html doesn't 
seem to give a definitive answer, In some processing environments,  email may 
automatically generate a hypertext link (a mailto: URL).

The 1.76.1 stylesheets definitely generate an active mailto:usern...@domain.com 
link from
link xlink:href=mailto:usern...@domain.com;usern...@domain.com/link
for example. Works for me even in PDF output.

Regards,
Mark

On Apr 18, 2012, at 3:02 PM, Abhishek Singh wrote:

 Hi,
 
 I am new to docbook and I want to write test for checking email for 
 docbook.can anyone tell me the behavior of emailusern...@domain.com/
 email.what it will show as output is it simply usern...@domain.com or it is 
 linked(usern...@domain.com)?
 
 Abhishek Singh
 

Re: [docbook-apps] make.clean.html pre

[Mark Craig]

Not a solution, but a workaround for Apache servers with mod_pagespeed:

$ cat .htaccess
...
ModPagespeed off

Regards,
Mark

PS For those of us posting HTML output on Apache servers: YMMV, but there 
appears to be some benefit in having Apache deflate HTML, CSS, JavaScript. 
(http://betterexplained.com/articles/how-to-optimize-your-site-with-gzip-compression/)
 It seems mod_pagespeed does this, as well as a few other things.
If you leave make.clean.html as per default, then perhaps you don't need to 
care.

On Mar 29, 2012, at 2:20 AM, Bob Stayton wrote:

 Hi all,
 That change from pre to div was made while trying to fix a different bug:
 
 http://sourceforge.net/tracker/?func=detailaid=2844927group_id=21935atid=373747
 
 The problem was that images for callout bugs are not valid inside a pre.  
 Other solutions?
 
 Bob Stayton
 Sagehill Enterprises
 b...@sagehill.net
 
 
 - Original Message - From: Mark Craig mark.cr...@gmail.com
 To: Jirka Kosek ji...@kosek.cz
 Cc: docbook-apps@lists.oasis-open.org
 Sent: Wednesday, March 28, 2012 6:49 AM
 Subject: Re: [docbook-apps] make.clean.html  pre
 
 
 Thank you, Jirka, for your reply.
 
 I have filed 3512384: Wrap verbatim w/ pre when make.clean.html=1 to 
 track this.
 
 Regards,
 Mark
 
 On Mar 28, 2012, at 3:02 PM, Jirka Kosek wrote:
 
 On 28.3.2012 14:30, Mark Craig wrote:
 
 Is there already an RFE for wrapping pre-formatted content with pre?
 Perhaps a quick workaround for the customization layer?
 
 Hmm, definitively pre should be output always for verbatim elements,
 styled div is clearly markup abuse.
 
 I don't see this tracked, so please fill bug report if you can. Thanks.
 
 Jirka
 
 -- 
 --
 Jirka Kosek  e-mail: ji...@kosek.cz  http://xmlguru.cz
 --
  Professional XML consulting and training services
 DocBook customization, custom XSLT/XSL-FO document processing
 --
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
 --
 
 
 
 -
 To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
 For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
 
 
 


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

[docbook-apps] make.clean.html pre

[Mark Craig]

Hello,

Since switching to make.clean.html=1 (with 1.76.1), I've been happy feeling 
like I can just change the CSS if need at some point to restyle HTML output in 
place.

But I'm starting to think the XSL ought to wrap a pre element around 
pre-formatted content, not just because of 
https://bugzilla.mozilla.org/show_bug.cgi?id=116083 but also because of 
http://www.w3.org/TR/html401/struct/text.html#h-9.1 and what I observed on an 
Apache server with mod_pagespeed.

div class=programlisting style=white-space: pre;class Test
{
public static void main(String [] args)
{
System.out.println(This is a program listing.);
}
}/div

Gets turned into this:

div class=programlisting style=white-space: pre;class Test
{
public static void main(String [] args)
{
System.out.println( This is a program listing. );
}
}/div

Is there already an RFE for wrapping pre-formatted content with pre?
Perhaps a quick workaround for the customization layer?

Thanks for your help.
Regards,
Mark

Re: [docbook-apps] inlinemedia figure

[Mark Craig]

Hello Jeff,

You might try normalizing the DPI settings in the .png files, as
described in 
http://stackoverflow.com/questions/4261838/xsl-fo-image-size-issue-with-pdfs

Most of the .png files seem to start out at 72 or 96 DPI, whereas they
may need to be 160 DPI or more to look right in the PDF.

Regards,
Mark

On Tue, Mar 27, 2012 at 5:47 AM, Jeff Storey
jeff.sto...@nextcentury.com wrote:
 I have a few inlinemediaobjects in my document. They are used to display
 icons that are typically used in the toolbar in the application. The images
 themselves are 22x22, but when I generate the pdf file, the images are much
 larger than 22x22 (almost 2x as large). Is there a way to ensure they stay
 at their natural size?

 This is how I include the icon:

 inlinemediaobject
     imageobject
     imagedata fileref=myicon.png/
     /imageobject
 /inlinemediaobject

 Thanks,
 Jeff

-
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 title page for PDF

[Mark Craig]

Yes, I see the same result when using fo/titlepage.xsl from the
stylesheet distribution for example.

However, if I use template/titlepage.xsl as described in
http://www.sagehill.net/docbookxsl/TitlePageNewElems.html then I get
an XSL stylesheet full of content.

Hope it helps,
Mark

On Sun, Mar 25, 2012 at 9:05 PM, Jeff Storey
jeff.sto...@nextcentury.com wrote:
 I'm trying to create a custom title page for my docbook when converting it
 to PDF.

 When trying to generate an xsl template from a title page, I run the command
 (this just uses the default titlepage spec):

 xsltproc  --output mytitlepage.xsl titlepage.xsl titlepage.templates.xml

 I got the titlepage.xsl and titlepage.templates.xml file from here
 http://docbook.sourceforge.net/release/xsl/current/fo/

 When I run this, mytitlepage.xsl is several hundred lines, but it is all
 empty lines. Can someone help with what I'm doing wrong?

-
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] Generate relative longdesc on img?

[Mark Craig]

Just checking… no objections apparently since last week.

Should I have opened an issue somewhere to track removal of longdesc on img in 
generated HTML?

Regards,
Mark

On Mar 19, 2012, at 6:25 PM, Bob Stayton wrote:

 Hi Mark,
 I believe the original intent was for screen readers.
 
 Bob Stayton
 Sagehill Enterprises
 b...@sagehill.net
 
 
 - Original Message - From: Mark Craig mark.cr...@gmail.com
 To: docbook-apps@lists.oasis-open.org
 Sent: Sunday, March 18, 2012 1:04 AM
 Subject: Re: [docbook-apps] Generate relative longdesc on img?
 
 
 Thanks, Bob, for the explanation. Seems like dropping the longdesc
 attr on image would be fine.
 
 Is the attribute there originally for screen readers, for users are
 not going to read a visual representation of the page?
 
 Regards,
 Mark
 
 On Sat, Mar 17, 2012 at 9:08 PM, Bob Stayton b...@sagehill.net wrote:
 Hi,
 The directory in the longdesc attribute of the an img element comes from
 either a dbhtml dir processing instruction if the mediaobject has one, or
 the base.dir param.
 
 The W3C designates the longdesc attribute as a URL, which means it should be
 relative to the HTML file that contains it. Using either the dbhtml dir or
 the base.dir in that attribute is not correct, because then the link path
 from the HTML file (which is in base.dir) would be wrong. So I consider
 this a bug in the stylesheet.
 
 Like you said, it doesn't seem to matter much, because the a href link to
 the actual long description file is correctly constructed relative the the
 HTML file. And this W3C page:
 
 http://www.w3schools.com/tags/att_img_longdesc.asp
 
 says Tip: The longdesc attribute is so poorly supported that it should not
 be used. To offer a long description of an image, simply create a link (that
 is visible to anyone) to a page with the description.
 
 The HTML5 spec appears to have dropped the longdesc attribute entirely.
 Since DocBook XSL generates a visible link, I'm tempted to drop support for
 this attribute in the stylesheets rather than fix it since it appears to be
 useless. Any objections?
 
 Bob Stayton
 Sagehill Enterprises
 b...@sagehill.net
 
 
 
 - Original Message -
 From: Mark Craig
 To: docbook-apps@lists.oasis-open.org
 Sent: Friday, March 16, 2012 2:59 AM
 Subject: [docbook-apps] Generate relative longdesc on img?
 
 Hello,
 
 What HTML customization serves to get relative paths in the longdesc
 attribute on img elements?
 
 The longdesc links and pages are fine, so it's not something noticeable when
 browsing. But img elements in HTML are coming out with absolute paths in
 longdesc attributes.
 
 For example:
 
 img src=images/standalone-repl.png
 longdesc=/opt/jenkins/.jenkins/jobs/OpenDJ Community Site (core
 docs)/workspace/target/docbkx/html/admin-guide/figure-standalone-repl.html
 
 The corresponding source for the whole media object is:
 
 mediaobject xml:id=figure-standalone-repl
 altDedicated servers versus consolidated instances/alt
 imageobject
 imagedata fileref=images/standalone-repl.png format=PNG/
 /imageobject
 textobject
 paraDedicated servers are suited to environments with large numbers
 of replicas./para
 /textobject
 /mediaobject
 
 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
 
 
 


-
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] Generate relative longdesc on img?

[Mark Craig]

Nevermind, thanks, Bob, 
http://docbook.svn.sourceforge.net/viewvc/docbook?view=revisionrevision=9246

Regards,
Mark

On Mar 23, 2012, at 1:55 PM, Mark Craig wrote:

 Just checking… no objections apparently since last week.
 
 Should I have opened an issue somewhere to track removal of longdesc on img 
 in generated HTML?
 
 Regards,
 Mark
 
 On Mar 19, 2012, at 6:25 PM, Bob Stayton wrote:
 
 Hi Mark,
 I believe the original intent was for screen readers.
 
 Bob Stayton
 Sagehill Enterprises
 b...@sagehill.net
 
 
 - Original Message - From: Mark Craig mark.cr...@gmail.com
 To: docbook-apps@lists.oasis-open.org
 Sent: Sunday, March 18, 2012 1:04 AM
 Subject: Re: [docbook-apps] Generate relative longdesc on img?
 
 
 Thanks, Bob, for the explanation. Seems like dropping the longdesc
 attr on image would be fine.
 
 Is the attribute there originally for screen readers, for users are
 not going to read a visual representation of the page?
 
 Regards,
 Mark
 
 On Sat, Mar 17, 2012 at 9:08 PM, Bob Stayton b...@sagehill.net wrote:
 Hi,
 The directory in the longdesc attribute of the an img element comes from
 either a dbhtml dir processing instruction if the mediaobject has one, or
 the base.dir param.
 
 The W3C designates the longdesc attribute as a URL, which means it should be
 relative to the HTML file that contains it. Using either the dbhtml dir or
 the base.dir in that attribute is not correct, because then the link path
 from the HTML file (which is in base.dir) would be wrong. So I consider
 this a bug in the stylesheet.
 
 Like you said, it doesn't seem to matter much, because the a href link to
 the actual long description file is correctly constructed relative the the
 HTML file. And this W3C page:
 
 http://www.w3schools.com/tags/att_img_longdesc.asp
 
 says Tip: The longdesc attribute is so poorly supported that it should not
 be used. To offer a long description of an image, simply create a link (that
 is visible to anyone) to a page with the description.
 
 The HTML5 spec appears to have dropped the longdesc attribute entirely.
 Since DocBook XSL generates a visible link, I'm tempted to drop support for
 this attribute in the stylesheets rather than fix it since it appears to be
 useless. Any objections?
 
 Bob Stayton
 Sagehill Enterprises
 b...@sagehill.net
 
 
 
 - Original Message -
 From: Mark Craig
 To: docbook-apps@lists.oasis-open.org
 Sent: Friday, March 16, 2012 2:59 AM
 Subject: [docbook-apps] Generate relative longdesc on img?
 
 Hello,
 
 What HTML customization serves to get relative paths in the longdesc
 attribute on img elements?
 
 The longdesc links and pages are fine, so it's not something noticeable when
 browsing. But img elements in HTML are coming out with absolute paths in
 longdesc attributes.
 
 For example:
 
 img src=images/standalone-repl.png
 longdesc=/opt/jenkins/.jenkins/jobs/OpenDJ Community Site (core
 docs)/workspace/target/docbkx/html/admin-guide/figure-standalone-repl.html
 
 The corresponding source for the whole media object is:
 
 mediaobject xml:id=figure-standalone-repl
 altDedicated servers versus consolidated instances/alt
 imageobject
 imagedata fileref=images/standalone-repl.png format=PNG/
 /imageobject
 textobject
 paraDedicated servers are suited to environments with large numbers
 of replicas./para
 /textobject
 /mediaobject
 
 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
 
 
 
 

[docbook-apps] Olink sitemap for chunked HTML?

[Mark Craig]

Hello,

I'm stumped getting the sitemap right to resolve Olinks in chunked HTML. The 
Olinks between different files of the same document seem to come out fine. But 
Olinks between documents are broken.

Bob Stayton's book, DocBook XSL: The Complete Guide, has solved lots of the 
DocBook XSL problems between my keyboard and chair. So I'm probably misreading 
the chapter on Olinks or missing something in the section about sitemaps, 
http://www.sagehill.net/docbookxsl/OlinkDetails.html#UsingSitemap

Would one of you have a working, open source example of Olinks between docs in 
chunked HTML that I could read through to perhaps understand?

If not, an example that demonstrates the problem is at 
https://github.com/markcraig/olink-test (with the problem showing up for 
example in target/docbkx/html/bogus-guide/index/ch01.html#olink-checks after 
you `mvn pre-site`; first link in the section works and it's inside the 
document; second link in the section fails to make it to the other document).

Thanks for your time and your advice.

Regards,
Mark

Re: [docbook-apps] Olink sitemap for chunked HTML?

[Mark Craig]

Aha! Thanks very much, Peter.

I got confused, thinking I only needed the baseuri attribute for
single-page HTML output.

That fixes it the problem completely.

Before (and broken):

 sitemap
  dir name='html'
   dir name='another-doc'
dir name='index'
 document targetdoc='another-doc'
  another-doc;
 /document
/dir
   /dir
   dir name='bogus-guide'
dir name='index'
 document targetdoc='bogus-guide'
  bogus-guide;
 /document
/dir
   /dir
  /dir
 /sitemap

After (and fixed):

 sitemap
  dir name='html'
   dir name='another-doc'
dir name='index'
 document targetdoc='another-doc'
   baseuri='../../another-doc/index/'
  another-doc;
 /document
/dir
   /dir
   dir name='bogus-guide'
dir name='index'
 document targetdoc='bogus-guide'
   baseuri='../../bogus-guide/index/'
  bogus-guide;
 /document
/dir
   /dir
  /dir
 /sitemap

Thanks again.

Regards,
Mark

On Thu, Mar 22, 2012 at 7:35 PM, Peter Desjardins
peter.desjardins...@gmail.com wrote:
 Here's an example of a map that I am using for chunked HTML.

 It can be a little tricky to figure out what the relative path to
 other documents is. It all depends on how you are packaging the HTML
 files. Mine are grouped in directories for the product, then the
 document, and then a directory named html. So my links from one
 document to another have to go up three directories in the hierarchy
 and then back down the path to the directory that holds the chunked
 files for each specific document.

 targetset
   sitemap
      dir name=documentation
         document targetdoc=ERDSupportingInfo

 baseuri=../../../platform/documentfoo/html/documentfooTargetswebhelp;/document
         document targetdoc=ERDSupportingInfo

 baseuri=../../../otherproduct/bardocument/html/bardocumentTargetswebhelp;/document
      /dir
   /sitemap
 /targetset

 Peter

 On Thu, Mar 22, 2012 at 2:07 PM, Mark Craig mark.cr...@gmail.com wrote:
 Hello,

 I'm stumped getting the sitemap right to resolve Olinks in chunked HTML. The
 Olinks between different files of the same document seem to come out fine.
 But Olinks between documents are broken.

 Bob Stayton's book, DocBook XSL: The Complete Guide, has solved lots of the
 DocBook XSL problems between my keyboard and chair. So I'm probably
 misreading the chapter on Olinks or missing something in the section about
 sitemaps, http://www.sagehill.net/docbookxsl/OlinkDetails.html#UsingSitemap

 Would one of you have a working, open source example of Olinks between docs
 in chunked HTML that I could read through to perhaps understand?

 If not, an example that demonstrates the problem is
 at https://github.com/markcraig/olink-test (with the problem showing up for
 example in target/docbkx/html/bogus-guide/index/ch01.html#olink-checks after
 you `mvn pre-site`; first link in the section works and it's inside the
 document; second link in the section fails to make it to the other
 document).

 Thanks for your time and your advice.

 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] Generate relative longdesc on img?

[Mark Craig]

Thanks, Bob, for the explanation. Seems like dropping the longdesc
attr on image would be fine.

Is the attribute there originally for screen readers, for users are
not going to read a visual representation of the page?

Regards,
Mark

On Sat, Mar 17, 2012 at 9:08 PM, Bob Stayton b...@sagehill.net wrote:
 Hi,
 The directory in the longdesc attribute of the an img element comes from
 either a dbhtml dir processing instruction if the mediaobject has one, or
 the base.dir param.

 The W3C designates the longdesc attribute as a URL, which means it should be
 relative to the HTML file that contains it.  Using either the dbhtml dir or
 the base.dir in that attribute is not correct, because then the link path
 from the HTML file (which is in base.dir) would be wrong.  So I consider
 this a bug in the stylesheet.

 Like you said, it doesn't seem to matter much, because the a href link to
 the actual long description file is correctly constructed relative the the
 HTML file.  And this W3C page:

 http://www.w3schools.com/tags/att_img_longdesc.asp

 says Tip: The longdesc attribute is so poorly supported that it should not
 be used. To offer a long description of an image, simply create a link (that
 is visible to anyone) to a page with the description.

 The HTML5 spec appears to have dropped the longdesc attribute entirely.
 Since DocBook XSL generates a visible link, I'm tempted to drop support for
 this attribute in the stylesheets rather than fix it since it appears to be
 useless.  Any objections?

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



 - Original Message -
 From: Mark Craig
 To: docbook-apps@lists.oasis-open.org
 Sent: Friday, March 16, 2012 2:59 AM
 Subject: [docbook-apps] Generate relative longdesc on img?

 Hello,

 What HTML customization serves to get relative paths in the longdesc
 attribute on img elements?

 The longdesc links and pages are fine, so it's not something noticeable when
 browsing. But img elements in HTML are coming out with absolute paths in
 longdesc attributes.

 For example:

 img src=images/standalone-repl.png
 longdesc=/opt/jenkins/.jenkins/jobs/OpenDJ Community Site (core
 docs)/workspace/target/docbkx/html/admin-guide/figure-standalone-repl.html

 The corresponding source for the whole media object is:

    mediaobject xml:id=figure-standalone-repl
     altDedicated servers versus consolidated instances/alt
     imageobject
      imagedata fileref=images/standalone-repl.png format=PNG/
     /imageobject
     textobject
      paraDedicated servers are suited to environments with large numbers
      of replicas./para
     /textobject
    /mediaobject

 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

[docbook-apps] Generate relative longdesc on img?

[Mark Craig]

Hello,

What HTML customization serves to get relative paths in the longdesc attribute 
on img elements?

The longdesc links and pages are fine, so it's not something noticeable when 
browsing. But img elements in HTML are coming out with absolute paths in 
longdesc attributes.

For example:

img src=images/standalone-repl.png 
longdesc=/opt/jenkins/.jenkins/jobs/OpenDJ Community Site (core 
docs)/workspace/target/docbkx/html/admin-guide/figure-standalone-repl.html

The corresponding source for the whole media object is:

   mediaobject xml:id=figure-standalone-repl
altDedicated servers versus consolidated instances/alt
imageobject
 imagedata fileref=images/standalone-repl.png format=PNG/
/imageobject
textobject
 paraDedicated servers are suited to environments with large numbers
 of replicas./para
/textobject
   /mediaobject

Regards,
Mark

[docbook-apps] make.clean.html and Firefox handling of white-space: pre ?

[Mark Craig]

Hello,

I liked setting xsl:param name=make.clean.html select=1 / and using 
white-space: pre; in the CSS. Of course, I did this expecting readers to be 
able to copy/paste the pre formatted content in a sort of WYSIWYG way.

But I didn't test in Firefox until a reviewer mentioned that all the newlines 
were gone when he pasted. Then I saw 
https://bugzilla.mozilla.org/show_bug.cgi?id=116083 : copy paste of CSS 
white-space: pre; content does not preserve whitespace.

This Firefox bug has been around for some time. It doesn't seem to be going 
away soon. Are there any plans to work around it in a future version of the 
DocBook XSL stylesheets?

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] make.clean.html and Firefox handling of white-space: pre ?

[Mark Craig]

Hi Bob,

I was thinking of trying 
https://bugzilla.mozilla.org/show_bug.cgi?id=116083#c43 :

 Joseph Lenton 2011-09-28 09:45:06 PDT
 Workaround:
 
 Convert each new line character into a 'br' tag, and each space into 
 'nbsp;'. The browser will convert these back into newlines and spaces when 
 they are copied by the user.
Regards,
Mark

On Feb 10, 2012, at 6:01 PM, Bob Stayton wrote:

 Hi Mark,
 The 'make.clean.html=1' setting replaces pre with div and class attribute 
 in the HTML output.  What sort of workaround did you have in mind?  Adding 
 another param that would keep make.clean.html for other things but override 
 this output to pre?
 
 Bob Stayton
 Sagehill Enterprises
 b...@sagehill.net
 
 
 - Original Message - From: Mark Craig mark.cr...@gmail.com
 To: docbook-apps@lists.oasis-open.org
 Sent: Friday, February 10, 2012 5:17 AM
 Subject: [docbook-apps] make.clean.html and Firefox handling of white-space: 
 pre ?
 
 
 Hello,
 
 I liked setting xsl:param name=make.clean.html select=1 / and using 
 white-space: pre; in the CSS. Of course, I did this expecting readers to be 
 able to copy/paste the pre formatted content in a sort of WYSIWYG way.
 
 But I didn't test in Firefox until a reviewer mentioned that all the newlines 
 were gone when he pasted. Then I saw 
 https://bugzilla.mozilla.org/show_bug.cgi?id=116083 : copy paste of CSS 
 white-space: pre; content does not preserve whitespace.
 
 This Firefox bug has been around for some time. It doesn't seem to be going 
 away soon. Are there any plans to work around it in a future version of the 
 DocBook XSL stylesheets?
 
 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
 
 
 


-
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 and custom.css.source ?

[Mark Craig]

Thanks Bob,

I'm pulling the stylesheets through docbkx-tools without actually specifying 
the version directly in my projects. Perhaps I could overload the templates in 
my customization file for chunked output, but it looks a lot simpler to wait 
and to continue copying the CSS file to the output for now.

Looking forward to the upcoming release when it's ready.

Regards,
Mark

On Feb 8, 2012, at 7:20 PM, Bob Stayton wrote:

 Yes, that bug still exists in 1.76.1  It is fixed in the snapshot builds, 
 though.  Or if you don't want to switch to the snapshot build, you could copy 
 that corrected template from the email to your customization layer, but you 
 must take care to preserve import precedence in a chunking customization. 
 That template affects chunking behavior, so should go into the chunking 
 customization file that imports all the others, and should have a 
 priority=1 added so it takes precedence.
  
 Yet another reason to get the next release out soon.  8^)
  
 Bob Stayton
 Sagehill Enterprises
 b...@sagehill.net
  
  
 - Original Message -
 From: Mark Craig
 To: DocBook Apps
 Sent: Tuesday, February 07, 2012 11:07 PM
 Subject: [docbook-apps] Chunking and custom.css.source ?
 
 Hello,
 
 What should I be doing to get the CSS from a custom.css.source file to be 
 picked up in chunked HTML?
 Works fine for plain (non-chunked) HTML output with 1.76.1.
 
 Mail from last April makes it sound like there might have been a bug, 
 http://lists.oasis-open.org/archives/docbook-apps/201104/msg00012.html
 
 Thanks for your advice.
 
 Regards,
 Mark

[docbook-apps] Chunking and custom.css.source ?

[Mark Craig]

Hello,

What should I be doing to get the CSS from a custom.css.source file to be 
picked up in chunked HTML?
Works fine for plain (non-chunked) HTML output with 1.76.1.

Mail from last April makes it sound like there might have been a bug, 
http://lists.oasis-open.org/archives/docbook-apps/201104/msg00012.html

Thanks for your advice.

Regards,
Mark

Re: [docbook-apps] Setting up a DocBook system

[Mark Craig]

Hello Richard,

David Cramer is write in mentioning user-friendly editors.
Templates/examples for typical documents might help, too.

Few complaints from part-time or novice authors concern the build system.
Instead, they get lost in markup choices or putting a document together
from scratch.

Regards,
Mark

On Sat, Nov 19, 2011 at 3:03 AM, Eric Johnson ericjohn...@apache.orgwrote:

 Richard,
 Check here: http://forgedp.fusesource.org/
 It is an easy to install package that uses ant to drive the build process.
 Cheers,
 Eric

  On Friday, November 18, 2011, Kerry, Richard richard.ke...@atos.net
 wrote:
 
  Team,
 
  I am setting up a Docbook system.
  When I did so for the first time for some tests a couple of years ago I
 didn't worry too much about whether everything was done using the best
 tools, or in the best way.
  This time I want to be a bit more certain I'm doing things the best way
 and not missing anything.  I want to produce a susyem that colleagues can
 use and foresee resistence if it is more difficult than it needs to be.
 
  I've started out by looking at Bob Stayton's book on-line.  But, I
 think it is a bit out of date.
  Can anyone direct me to any more up-to-date Getting Started guides ?
  Or Bob, is there any chance that you might update your on-line book, in
 particular the version numbers referenced for Saxon and Fop ?  And the
 class names to use (The section on Saxon still refers to version 6 and the
 ICL version of the class-name).
 
 
 
 
 
  Appreciatively,
  Richard.
 
 
 
 
 
 
  Richard Kerry
 
  BNCS Engineer
 
 
 
  T: +44 (0)20 82259063
 
  M: +44 (0)7812 325518
 
  Room 457 Drama Building, BBC Television Centre, Wood Lane, London, W12
 7RJ
 
  richard.ke...@atos.net
 
  uk.atos.net
 
 
 
 
 
 
 
  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.
 
 
 
  --
  Principle Technical Writer
  FuseSource
  Phone: (781) 280-4174
  E-Mail: emjohn...@fusesource.com
  Blog: http://documentingit.blogspot.com/
  Twitter: finnmccumial
 

Re: [docbook-apps] cacute missing in PDF only

[Mark Craig]

Thanks again.

From Pascal and Mehdi on the FOP users list, I learned that the font metrics 
files are not necessary with DejaVu fonts used with FOP 1.0. When I process the 
.fo directly without using the font metrics files, pointing only to the DejaVu 
fonts, the ć indeed appears in the output.

Regards,
Mark

On Oct 6, 2011, at 1:04 PM, Bob Stayton wrote:

 Hi Mark,
 FOP's error message says 0x107, which is the correct Unicode value for Latin 
 Small Letter C with acute, which suggests that the FO output is correct.
  
 I think you will need to consult the FOP list  on this one.
  
 Bob Stayton
 Sagehill Enterprises
 b...@sagehill.net
  
  
 - Original Message -
 From: Mark Craig
 To: Bob Stayton
 Cc: docbook-apps@lists.oasis-open.org
 Sent: Thursday, October 06, 2011 2:17 AM
 Subject: Re: [docbook-apps] cacute missing in PDF only
 
 Thanks, Bob, for your help.
 
 I've set my project up to use DejaVu, which as seen in the font viewer does 
 include ć in all the families, styles, and weights available.
 
 Looking at your instructions on missing characters:
 If the entity were entered wrong, I'd expect it to be a problem in all output 
 formats, not just PDF.
 Regarding named character entities, the character is not defined as cacute;, 
 but instead just typed it in as a special character or as #263;. (neither 
 works)
 If it were the output encoding, wouldn't the WARNING not be able to recognize 
 the glyph at all, rather than identify it correctly?
 When I export the RTF to PDF, the ć shows up fine. So I'm guessing it's not 
 the output medium.
 This is the only character not resolving that I've seen -- though almost all 
 content is English for now -- in PDF, yet the entity resolves correctly in 
 other output formats such as HTML and RTF.
 
 Where else should I look?
 
 Regards,
 Mark
 
 On Oct 6, 2011, at 7:58 AM, Bob Stayton wrote:
 
 Hi,
 cacute is in the ISO Latin2 character set, and I suspect the Helvetica-Bold 
 font that FOP is using has glyphs only for ISO Latin1. If you can find out 
 where LibreOffice gets its fonts, you might be able to configure FOP to use 
 those font files.
  
 Or add a more complete Unicode font to the 'symbol.font.family' stylesheet 
 param as a fallback, although that might be satisfactory if the fallback 
 font does not closely resemble the main font. See:
  
 http://www.sagehill.net/docbookxsl/SpecialChars.html#MissingChars
  
 Bob Stayton
 Sagehill Enterprises
 b...@sagehill.net
  
  
 - Original Message -
 From: Mark Craig
 To: docbook-apps@lists.oasis-open.org
 Sent: Wednesday, October 05, 2011 10:30 AM
 Subject: [docbook-apps] cacute missing in PDF only
 
 Hello,
 
 I have a ć (cacute, #263;) missing in PDF (not HTML or RTF).
 
 This seems to be the error:
 
 Oct 5, 2011 7:07:42 PM org.apache.fop.events.LoggingEventListener 
 processEvent
 WARNING: Glyph ? (0x107, cacute) not available in font Helvetica-Bold. 
 
 If I go into LibreOffice, I can enter ć in Helvetica font and make it bold. 
 (Is Helvetica-Bold something else?)
 How should I work around this?
 
 Thanks for your time and your help.
 
 Regards,
 Mark
 
 

[docbook-apps] cacute missing in PDF only

[Mark Craig]

Hello,

I have a ć (cacute, #263;) missing in PDF (not HTML or RTF).

This seems to be the error:

Oct 5, 2011 7:07:42 PM org.apache.fop.events.LoggingEventListener
processEvent
WARNING: Glyph ? (0x107, cacute) not available in font Helvetica-Bold.

If I go into LibreOffice, I can enter *ć* in Helvetica font and make it
bold. (Is Helvetica-Bold something else?)
How should I work around this?

Thanks for your time and your help.

Regards,
Mark

[docbook-apps] XSL-FO size of embedded fonts?

[Mark Craig]

Hello,

I'm weighing the value of embedding a font vs. sticking with the defaults in 
PDF, and am not sure whether to be surprised at how much embedding a font 
increases the size of small files.

The font families are DejaVu TrueType. I am not using 
encoding-mode=single-byte in the font metrics.

 xsl:param name=body.font.familyDejaVuSerif/xsl:param
 xsl:param name=dingbat.font.familyDejaVuSerif/xsl:param
 xsl:param name=monospace.font.familyDejaVuSansMono/xsl:param
 xsl:param name=sans.font.familyDejaVuSans/xsl:param
 xsl:param name=title.font.familyDejaVuSans/xsl:param

True, the entire size of all of DejaVu on disk when unpacked is 9.7 MB, though 
the zipped download is half of that.

With those parameters set, short draft release notes, for example, at 
http://opendj.forgerock.org/doc/OpenDJ-Release-Notes.pdf come out to about 940 
KB on disk. Only English text in there, nothing fancy.

When those parameters are commented out, the same release notes take up 56 KB 
on disk.

Is that size increase to be expected?
Is there some other parameter I should set to reduce the size of the resulting 
PDF?

I'm using docbkx-tools 2.0.13 to process the content. So the underlying XSL is 
version 1.76.1.

Thanks for your time and your advice.

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] Draftmode image location

[Mark Craig]

Hello,

Another alternative that seems to work across versions of the stylesheets as
long as you have web access is to point to
http://docbook.sourceforge.net/release/images/draft.png.

Regards,
Mark

On Wed, May 25, 2011 at 9:40 PM, Barton Wright bwri...@streambase.comwrote:

 You could set up a symbolic link in your ../../doctools/ directory. Name
 the symlink docbook-xsl and have it always point to the latest
 docbook-xsl-version that you’re using.



 Then you:

 -- always select “../../doctools/docbook-xsl/images/draft.png” and never
 have to edit the path

 -- change only the symlink to start using a new XSL version



 This even works nowadays on Windows 7, which has real symbolic links that
 you create with the mklink command.



 *From:* deannel...@aol.com [mailto:deannel...@aol.com]
 *Sent:* Wednesday, May 25, 2011 3:19 PM
 *To:* docbook-apps@lists.oasis-open.org
 *Subject:* [docbook-apps] Draftmode image location



 All



 1. Is there a better way of accessing the draft.png file in stock docbook
 xsl tree from my customization layer so I don't have to change the version
 number every time I update the XSL to a new version?



xsl:param name=draft.watermark.image
 select='../../doctools/docbook-xsl-1.76.1/images/images/draft.png'/



 Could there be a standard docbook-xsl version ENTITY that I can build a
 path from?

 Like this?

xsl:param name=draft.watermark.image
 select='../../doctools/DOCBOOK_XSL_VERSION;/images/images/draft.png'/

 2. Is there are parameter that can be set, similar to base.dir, that points
 to the base location of the stylesheets? Then the callout, draft image, and
 other locations could be relative to that directory.



 How do other folks get around this without hand tuning paths every time a
 version changes?







 Regards,

 Dean Nelson

[docbook-apps] How to insert JavaScript near end of HTML without chunking?

[Mark Craig]

Hello,

How does one insert script content, such as for Google Analytics, near the
end of generated HTML?

Chunking is turned off by popular reader demand. Setting user.footer.content
does not appear to generate anything in the HTML.

HTML generation is managed through docbkx-tools, which encapsulate the
stylesheets, so I do not actually specify the version of the stylesheets
anywhere in my project. Docbkx-tools do let me specify a stylesheet for
customization, currently used for example to set values for parameters
documented at http://docbook.sourceforge.net/release/xsl/current/doc/.

Thanks in advance for your advice.

Regards,
Mark

Re: [docbook-apps] How to insert JavaScript near end of HTML without chunking?

[Mark Craig]

Hello, thanks for your suggestion.

This is what I tried after I found user.footer.content only gets used when
chunking.

Trouble is, I can insert the file in the HTML following the instructions you
cite.

But either I get effectively lt;scriptgt; etc. in the HTML, using
xinclude:include href=ga.txt parse=text /.
Or the HTML is okay but the build breaks generating PDF with xinclude:include
href=ga.txt /, because the FO specification has never heard of script
elements.

Regards,
Mark


On Thu, May 19, 2011 at 3:23 PM, Peter Desjardins peter.desjardins.us@
gmail.com wrote:

 On Thu, May 19, 2011 at 2:28 AM, Mark Craig mark.cr...@gmail.com wrote:

  How does one insert script content, such as for Google Analytics, near
 the
  end of generated HTML?
  Chunking is turned off by popular reader demand.

 Can you use a technique like this one?

 http://www.sagehill.net/docbookxsl/InsertExtHtml.html#CodeInPage

 Since you're not chunking, it might be easy to add a processing
 instruction at the end of your document.

 Peter




-- 
*Mark Craig*
e: mark.cr...@gmail.com
t: +33 7 60 69 95 68
blog: http://mcraig.org/mec

Re: [docbook-apps] How to insert JavaScript near end of HTML without chunking?

[Mark Craig]

Hello again,

Well... this seems to work, though it doesn't feel right. I put this as one
of the tasks for the maven-antrun-plugin of the POM:

   replace dir='${basedir}/target/docbkx/html/' token=
'lt;/bodygt;'

 include name='**/**/*.html' /

 replacevaluelt;script type=text/javascriptgt;


  var _gaq = _gaq || [];

  _gaq.push(['_setAccount', 'UA--*']);

  _gaq.push(['_trackPageview']);


  (function() {

var ga = document.createElement('script'); ga.type = 'text/javascript';
ga.async = true;

ga.src = ('https:' == document.location.protocol ? 'https://ssl' : '
http://www') + '.google-analytics.com/ga.js';

var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(ga, s);

  })();


lt;/scriptgt;lt;/bodygt;/replacevalue

/replace

It would be cool if there were something like user.footer.content that
worked without chunking.

Regards,
Mark

On Thu, May 19, 2011 at 3:45 PM, Mark Craig mark.cr...@gmail.com wrote:

 Hello, thanks for your suggestion.

 This is what I tried after I found user.footer.content only gets used when
 chunking.

 Trouble is, I can insert the file in the HTML following the instructions
 you cite.

 But either I get effectively lt;scriptgt; etc. in the HTML, using
 xinclude:include href=ga.txt parse=text /.
 Or the HTML is okay but the build breaks generating PDF
 with xinclude:include href=ga.txt /, because the FO specification has
 never heard of script elements.

 Regards,
 Mark


 On Thu, May 19, 2011 at 3:23 PM, Peter Desjardins peter.desjardins.us@
 gmail.com wrote:

 On Thu, May 19, 2011 at 2:28 AM, Mark Craig mark.cr...@gmail.com wrote:

  How does one insert script content, such as for Google Analytics, near
 the
  end of generated HTML?
  Chunking is turned off by popular reader demand.

 Can you use a technique like this one?

 http://www.sagehill.net/docbookxsl/InsertExtHtml.html#CodeInPage

 Since you're not chunking, it might be easy to add a processing
 instruction at the end of your document.

 Peter




 --
 *Mark Craig*
 e: mark.cr...@gmail.com
 t: +33 7 60 69 95 68
 blog: http://mcraig.org/mec




-- 
*Mark Craig*
e: mark.cr...@gmail.com
t: +33 7 60 69 95 68
blog: http://mcraig.org/mec

Re: [docbook-apps] How to insert JavaScript near end of HTML without chunking?

[Mark Craig]

Aha, ?db*html*-include href=mycode.html?. I'll try that.

Regards,
Mark

On Thu, May 19, 2011 at 5:20 PM, David Cramer da...@thingbag.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 It appears he was using an xinclude to pull in the script (rather than a
 processing instruction as suggested in Bob's book). The xinclude will be
 resolved for all formats, so would break fo. The PI however would be
 ignored/discarded by the fo xsls.

 David

 On 05/19/2011 10:12 AM, Peter Desjardins wrote:
  I've never used docbkx-tools, maybe I'm misunderstanding your
  publishing process. I'm surprised that a customization for HTML has
  any effect on your FO.
 
  Peter
 
  On Thu, May 19, 2011 at 9:45 AM, Mark Craig mark.cr...@gmail.com
 wrote:
  Hello, thanks for your suggestion.
  This is what I tried after I found user.footer.content only gets used
 when
  chunking.
  Trouble is, I can insert the file in the HTML following the instructions
 you
  cite.
  But either I get effectively lt;scriptgt; etc. in the HTML, using
  xinclude:include href=ga.txt parse=text /.
  Or the HTML is okay but the build breaks generating PDF
  with xinclude:include href=ga.txt /, because the FO specification
 has
  never heard of script elements.
  Regards,
  Mark
 
  On Thu, May 19, 2011 at 3:23 PM, Peter Desjardins
  peter.desjardins...@gmail.com wrote:
 
  On Thu, May 19, 2011 at 2:28 AM, Mark Craig mark.cr...@gmail.com
 wrote:
 
  How does one insert script content, such as for Google Analytics,
 near
  the
  end of generated HTML?
  Chunking is turned off by popular reader demand.
 
  Can you use a technique like this one?
 
  http://www.sagehill.net/docbookxsl/InsertExtHtml.html#CodeInPage
 
  Since you're not chunking, it might be easy to add a processing
  instruction at the end of your document.
 
  Peter
 
 
 
  --
  Mark Craig
  e: mark.cr...@gmail.com
  t: +33 7 60 69 95 68
  blog: http://mcraig.org/mec
 
 
  -
  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/

 iQEcBAEBAgAGBQJN1TU8AAoJEMHeSXG7afUhkOIH/jN1u33VydWIzJI5dX+U23q+
 x3hDpIMm2PDiq56URcDOYrWckYp+wIouNFv0wysfVt5zLBbFoIEcQQJqzDwHOlrr
 cEiVxwgzp2Qf9T2lVmoggrHntd3DPzGJinSz25aA5LA491lLBY6lJKPpvz5Q3FLl
 EMvRWBFP4H9xQSh7m5xnAd3FEn9qmeiXBvx0W8VszZE75O/epQIFAOzTEPzQKOBx
 I4FsJYhicKbZaQzrayqjcOXUrLruO3ki9cKJ7L/JmtNeoCgkD1u72i4E0E6H+/6F
 O+P09PRuytxiymGgG6/LMM13uvYBjLeG14MVYmstWXeWuqymTE4QZvpli9NoIYs=
 =fNUq
 -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




-- 
*Mark Craig*
e: mark.cr...@gmail.com
t: +33 7 60 69 95 68
blog: http://mcraig.org/mec