This is probably a bit of a silly question, but I can't figure out how to enable the admonition icons.
I've seen that with other parsers there's an options for this: with xsltproc, I've heard that you can do:
But I haven't had any success doing similar things with DAPS. I'm very new, so if there's some resource that tells you how to do things like this I would be very grateful if someone could point me at it :)
Hamish
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
However, with callouts, admonitions, and navigation graphics you also need to consider the path to the images. The respective parameters are named:
admon.graphics.path
callout.graphics.path
navig.graphics.path
In the upstream DocBook stylesheets--/usr/sharexml/docbook/stylesheets/(nwalsh|nwalsh5)/current on SUSE-- they are set to "mages/ and images/callouts/.
For HTML and ePUB builds, the upstream DocBook stylesheets generate e.g.
<img src="images/note.png"/>
For PDF the respective code in the fo file looks like the following:
<fo:external-graphic src="url(images/note.png)"/>
Since the DocBook stylesheets cannot copy images, this is something the XML processing chain needs to take care of - if you use xsltproc you either need to copy the image files or set a valid path. For HTML and ePUB this is something DAPS takes care of. The images are copied from <STYLEROOT>/images to
<HTMLOUTPUT>/static/images
(If you want to know why it's static/, see below). Therefore the paths need to be set as follows:
As I discovered while reseraching for this post, I did not implement such an automatic processing for PDF builds (because we use inline SVGs for PDF builds with the SUSE stylesheets and therefore do not need it). I opened an issue for it ( https://github.com/openSUSE/daps/issues/419 ) and will try to fix it ASAP.
Until this is fixed, use the following values for the callout and admonition graphics paths for PDFs (navigation images are HTML only):
(if you are not using SUSE, you may need to adjust the paths)
Some additional remarks:
The --force parameter
To ensure a better performance, DAPS only rebuilds files if the source files (XML, DC-files or images) have changed. the downside of this is that parameter changes on the command-line will have no effect. Therefore, if you specify --param or --stringparam on the command line, make sure to also specify "--force"; this ensures all files will be rebuilt. Note that --force is a general parameter that must be specified before the subcommand (e.g. html or pdf), while the --param and --stringparam parameters need to be specified after the subcommand.
Permanantly adding parameters to the DC-file
Once you have found a set of parameters that are working for you, you can add them to the DC-file. Thus you do not have to specify them on the command line every time. This is achieved by setting XSLTPARAM:
XSLTPARAM="--param="admon.graphics=1"
If you want to specify more than one parameter, you need to specify them space-seperated on a single line. This easily makes the DC-file unreadable, therefore you can divide it to several lines by using "XSLTPARAM+=". Note that the first entry requires "=":
As long as you need different parameters for HTML/ePUB and PDF builds, you can create a second DC-file for PDF builds only.
The static/ directory
As said before, handling of admonitions, callout and navigation graphics needs to be done by the processing chain. The upstream DocBook stylesheets provide these images in <STYLEROOT>/images/ from where you can copy or link them.
However, when writing custom stylesheets you very likely want to add CSS and Javascript. Whatsmore, both CSS and JavaScript will very likely contain relative links to images. If you want to have a portable HTML output (that can, for example be copied onto a webserver,, you need to make sure a fixed directory structure for images, css and Javascript. Therefore DAPS also supports <STYLEROOT>/static/ (see https://github.com/openSUSE/suse-xsl/tree/develop/suse2013/static for an example).
DAPS searches for <STYLEROOT>/static/ and, if that cannot be found, for <STYLEROOT>/images/. While a static directory is copied as-is, the image directory gets copied to <HTMLOUTPUT>/static. This ensures that the same parameter for admonitions, callouts and navigation images can be used, regardless of the source of the images.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
https://github.com/openSUSE/daps/commit/5c09e57 fixes the issue that requires to use different paths for admonition and callout graphics in PDF and HTML builds. It will be integrated into the next release.
In case you ant to use it with DAPS 2.4.0, you have the following options:
if you are directly using a git checkout,, switch to the develop branch and pull. If you prefer to stay on the stable master branch, create a branch from master and cherry-pick commit 5c09e57. It will update make/pdf.mk. Once the next DAPS version is released, switch back to master, pull and delete your branch
View and moderate all "DAPS General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion, old (read-only)"
Hi there,
This is probably a bit of a silly question, but I can't figure out how to enable the admonition icons.
I've seen that with other parsers there's an options for this: with xsltproc, I've heard that you can do:
But I haven't had any success doing similar things with DAPS. I'm very new, so if there's some resource that tells you how to do things like this I would be very grateful if someone could point me at it :)
Hamish
Hi,
in general, you can pass any XSLT parameters or string parameters to DAPS similar to xsltproc:
daps --stringparam="KEY=VALUE" --param="KEY=VALUE"
However, with callouts, admonitions, and navigation graphics you also need to consider the path to the images. The respective parameters are named:
admon.graphics.pathcallout.graphics.pathnavig.graphics.pathIn the upstream DocBook stylesheets--
/usr/sharexml/docbook/stylesheets/(nwalsh|nwalsh5)/currenton SUSE-- they are set to "mages/andimages/callouts/.For HTML and ePUB builds, the upstream DocBook stylesheets generate e.g.
For PDF the respective code in the fo file looks like the following:
Since the DocBook stylesheets cannot copy images, this is something the XML processing chain needs to take care of - if you use xsltproc you either need to copy the image files or set a valid path. For HTML and ePUB this is something DAPS takes care of. The images are copied from
<STYLEROOT>/imagesto(If you want to know why it's
static/, see below). Therefore the paths need to be set as follows:The trailing
/is required. Example:As I discovered while reseraching for this post, I did not implement such an automatic processing for PDF builds (because we use inline SVGs for PDF builds with the SUSE stylesheets and therefore do not need it). I opened an issue for it ( https://github.com/openSUSE/daps/issues/419 ) and will try to fix it ASAP.
Until this is fixed, use the following values for the callout and admonition graphics paths for PDFs (navigation images are HTML only):
(if you are not using SUSE, you may need to adjust the paths)
Some additional remarks:
The
--forceparameterTo ensure a better performance, DAPS only rebuilds files if the source files (XML, DC-files or images) have changed. the downside of this is that parameter changes on the command-line will have no effect. Therefore, if you specify
--paramor--stringparamon the command line, make sure to also specify "--force"; this ensures all files will be rebuilt. Note that --force is a general parameter that must be specified before the subcommand (e.g. html or pdf), while the --param and --stringparam parameters need to be specified after the subcommand.Permanantly adding parameters to the DC-file
Once you have found a set of parameters that are working for you, you can add them to the DC-file. Thus you do not have to specify them on the command line every time. This is achieved by setting XSLTPARAM:
If you want to specify more than one parameter, you need to specify them space-seperated on a single line. This easily makes the DC-file unreadable, therefore you can divide it to several lines by using "XSLTPARAM+=". Note that the first entry requires "=":
See https://github.com/openSUSE/daps/blob/develop/doc/DC-daps-user for sn example and https://github.com/openSUSE/daps/blob/develop/etc/config.in for more information.
As long as you need different parameters for HTML/ePUB and PDF builds, you can create a second DC-file for PDF builds only.
The static/ directory
As said before, handling of admonitions, callout and navigation graphics needs to be done by the processing chain. The upstream DocBook stylesheets provide these images in
<STYLEROOT>/images/from where you can copy or link them.However, when writing custom stylesheets you very likely want to add CSS and Javascript. Whatsmore, both CSS and JavaScript will very likely contain relative links to images. If you want to have a portable HTML output (that can, for example be copied onto a webserver,, you need to make sure a fixed directory structure for images, css and Javascript. Therefore DAPS also supports
<STYLEROOT>/static/(see https://github.com/openSUSE/suse-xsl/tree/develop/suse2013/static for an example).DAPS searches for
<STYLEROOT>/static/and, if that cannot be found, for<STYLEROOT>/images/. While a static directory is copied as-is, the image directory gets copied to<HTMLOUTPUT>/static. This ensures that the same parameter for admonitions, callouts and navigation images can be used, regardless of the source of the images.Hi,
https://github.com/openSUSE/daps/commit/5c09e57 fixes the issue that requires to use different paths for admonition and callout graphics in PDF and HTML builds. It will be integrated into the next release.
In case you ant to use it with DAPS 2.4.0, you have the following options:
if you are directly using a git checkout,, switch to the develop branch and pull. If you prefer to stay on the stable master branch, create a branch from master and cherry-pick commit
5c09e57. It will updatemake/pdf.mk. Once the next DAPS version is released, switch back to master, pull and delete your branchif you have installed DAPS via an RPM package or via make/make install, replace
/usr/share/daps/make/pdf.mkwith this version: https://raw.githubusercontent.com/openSUSE/daps/5c09e572fd1372ea3274beb8a19ca9675bbcf70a/make/pdf.mkHave fun, Frank.
Hi,
Same person - I've just created an account now.
Thank you, that's really helpful :)
I'm actually running DAPS 2.2.0 that I compiled on Linux Mint, so I'd better recompile!
Thanks again,
Hamish