Frank Sundermeyer

DAPS supports all profiling variables that upstream DocBook supports. These are XML: arch, DC-file: PROFARCH XML: audience, DC-file: PROFAUDIENCE XML: condition, DC-file: PROFCONDITION XML: conformance, DC-file: PROFCONFORMANCE XML: lang, DC-file: PROFLANG XML: os, DC-file: PROFOS XML: outputformat, DC-file: PROFOUTPUTFORMAT XML: revision, DC-file: PROFREVISION XML: revisionflag="added|changed|deleted|off, DC-file: PROFREVISIONFLAG XML: role, DC-file: PROFROLE XML: security, DC-file: PROFSECURITY...

The lack of DocBook 5(.1) is most likely also the reason why building the AsciiDoc manual fails during compilation. AsciiDoctor produces a DB 5 XML file from the AsciiDoc sources that gets validated afterwards. And that validation step fails in the example you posted above. I have created an issue for this: https://github.com/openSUSE/daps/issues/488

Do you have asciidoctor or asciidoc as a build requirement? Looks like it builds the asciidoc documentation and fails to generate valid XML. I assume that this is caused by asciidoc. Can you try asciidoctor instead and see if it works? If not, try to remove asciidoc/asciidoctor from the build dependencies. In that case the asciidoc document will not be built and the error should go away (the resulting DAPS will, nevertheless support ASCIIDoc). Looks like I should work on https://github.com/openSUSE/daps/issues/486...

Hi, almost 1 ½ years after DAPS 2.4 it is time for a new major release: DAPS 3.0. With this release we are proud to announce a significant addition to the DAPS feature set: AsciiDoc support. In addition to creating your documens from DocBook, you can now also create them from AsciiDoc sources. And it does not stop here: you will be able to use your existing DocBook stylesheets with your AsciiDoc sources! Want to know more details? See the AsciiDoc Quickstart (which, of course, was generated from...

Hi, just some additional information: The absolute minimum on input DAPS needs is a MAIN file. Therefore it is sufficient to rum daps -m <MAIN>. In case you need to specify additional parameters such as a rootid or a stylesheet directory, you can use the respective command line parameters to set them. These additional parameters are usually the same for every build. That's why you can specify a DC-file that defines these parameters, so you do not have to specify them on every run of DAPS. A DC-file...

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 update make/pdf.mk....

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.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/....

Hi, it has been a long time since we released a new DAPS version, but we were pretty pleased with 2.3.0 and therefore reduced the pace a little bit. DAPS 2.4.0 is mainly a bugfix release and additionally comes with significant improvements on documentation. Download DAPS 2.4.0 For download alternatives and installation instructions refer to the installation instructions. Here is the complete list of changes: New Features added a dependency checker for DAPS (/usr/bin/daps-check-deps) that makes it...