Stefan Knorr

Hello, Frank, Thomas, and I who are maintaining DAPS have decided that we should try to unify the web presence of DAPS as much as possible. This forum was the last part of DAPS still hosted on Sourceforge instead of GitHub. It too shall now go and be replaced by GitHub. Unfortunately, GitHub does not have forum functionality, but given the volume of this forum, it should be just fine to replace it with the GitHub issue tracker. There is now a new "forum" label on GitHub, please use it for discussion...

Hello, Frank, Thomas, and I who are maintaining DAPS have decided that we should try to unify the web presence of DAPS as much as possible. This forum was the last part of DAPS still hosted on Sourceforge instead of GitHub. It too shall now go and be replaced by GitHub. Unfortunately, GitHub does not have forum functionality, but given the volume of this forum, it should be just fine to replace it with the GitHub issue tracker. There is now a new "forum" label on GitHub, please use it for discussion...

Uh, that is a good question. I think you are using a modified version of our SUSE stylesheets. I must admit, I think we (that is, mostly I) broke some parts of autotoc a bit. In particular, there is a ToC depth parameter, something akin to $toc.max.depth that might be helpful but is probably a bit broken in the HTML version (I don't think we ever changed much about the set ToC in the PDF version -- that use case was never quite as important to us). Nevertheless, I guess it is a good idea to at least...

Uh, that is a good question. I think you are using a modified version of our SUSE stylesheets. I must admit, I think we (that is, mostly I) broke some parts of autotoc a bit. In particular, there is a ToC depth parameter, something akin to $toc.max.depth that might be helpful but is probably a bit broken in the HTML version (I don't think we ever changed much about the set ToC in the PDF version -- that use case was never quite as important to us). Nevertheless, I guess it is a good idea to at least...

I don't think so... There is daps -m MAIN.myblub.xml ... which can be used instead of daps -d DC-myblub .... Conceptually, the MAIN parameter and ROOTID are the centerpieces of a DC file -- the reason to introduce DC files was originally mostly to cache those two values [1]. However, I guess nothing stops you from using e.g. the daps -m ... syntax in a Makefile or so..? Not sure what your exact use case is here, though. hth Stefan [1] This is history told by someone who was not there at the inception...

I don't think so... There is -m MAIN.myblub.xml which can be used instead of -d DC-myblub. Conceptually, the MAIN parameter and ROOTID are the centerpieces of a DC file -- the reason to introduce DC files was originally mostly to cache those two values [1]. However, I guess nothing stops you from using e.g. the daps -m ... syntax in a Makefile or so..? Not sure what your exact use case is here, though. hth Stefan [1] This is history told by someone who was not there at the inception of DAPS, of ...

Install the package xml-commons-resolver12 to get rid of the Java/resolver issues. However, I am not sure about why you see the "can't determine DocBook version" error: If this is DocBook 5, make sure the namespace xmlns:d="http://docbook.org/ns/docbook". Replace :d with something appropriate, which can also be nothing depending on how your normal tags look -- i.e. whether they are explicitly namespaced (like <d:book/>) or whether they are implicitly namespaced (like <book/>). If this is DocBook...

I can't promise that we will get to implementing every feature request on GitHub. But, I can pretty much promise that if there is no one who opens an issue for it, it will be forgotten at some point. :)