Activity for Stefan Knorr
-
Stefan Knorr modified a comment on discussion DAPS General 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...
-
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. :)
-
Iirc, profiling is broken with saxon6 ... what you could try maybe is this: Profile with xsltproc: daps -d ... profile Build with saxon: daps -d ... pdf --xsltproc=saxon There is no way to use saxon just for one of the steps otherwise, I think. Sorry.
-
iirc, profiling is broken with saxon6 ... what you could try maybe is this: Profile with xsltproc: daps -d ... profile Build with saxon: daps -d ... pdf --xsltproc=saxon
-
Did you open an issue for this at https://github.com/openSUSE/suse-xsl ? I think this could reasonably be done without support from the formatter at least for HTML.
-
Did you open an issue for this at? https://github.com/openSUSE/suse-xsl I think this could reasonably be done without support from the formatter at least for HTML.
-
This makes me wonder about the scope of the daps project and not for the first time. Hm, so first: please differentiate between DAPS and the SUSE stylesheets. Those are separate projects, if somewhat interwoven. Most of the issues you name here seem to squarely fall into stylesheet territory. Anyway, both DAPS and stylesheet development is currently very much driven by internal needs. I realize that this does make it harder for you to work with them. On the other hand, it is all open-source and open...
-
This makes me wonder about the scope of the daps project and not for the first time. Hm, so first: please differentiate between DAPS and the SUSE stylesheets. Those are separate projects, if somewhat interwoven. Most of the issues you name here seem to squarely fall into stylesheet territory. Anyway, both DAPS and stylesheet development is currently very much driven by internal needs. I realize that this does make it harder for you to work with them. On the other hand, it is all open-source and open...
-
On the other hand, when generating HTML everything is fine with the footnote. Yeah, HTML is totally different code than FO/PDF. Interestingly, upgrading to suse-xsl-2.7.0.2 requires upgrading of package liberation-fonts to liberation2-fonts. Could this cause some font selection incompability? It should not. We mostly did this because the old liberation-fonts package was being dropped and we were one of the last packages still depending on it. I think on older (supported SLE/openSUSE) distributions...
-
Hi Stefan, I can tell you that DAPS does not do any external validation of generated...
-
Hi Martin, from DAPS, you should get a parameter called img.src.path. So you should...
-
Hi Martin, from DAPS, you should get a parameter called img.src.path. So you should...
-
Hi Stefan, yes, I tend to agree that this is a bug in our stylesheets -- can you...
-
Done that now -- if you are using the stylesheets from the repo, there is now a parameter...
-
Hello Martin, making the Geeko tail on the cover interchangeable has been an idea...
-
Pardon for spamming with duplicated posts, the sourceforge site did not show them...
-
Pardon for spamming with duplicated posts, the sourceforge site did not show them...
-
Re: Webhelp DAPS error above: The error may be a bit misleading. If you take a look...
-
Re: Webhelp DAPS error above: The error may be a bit misleading. If you take a look...
-
Re: Webhelp stylesheet error: The error may be a bit misleading. If you take a look...
-
Re: Webhelp stylesheet error: The error may be a bit misleading. If you take a look...
-
DAPS currently does not support SVG images for HTML output, only for FO (PDF). The...
-
Actually, the quick fix seems like a good idea to me: that way, you can easily drop...
-
A short while ago, SVGs on the web didn't work well. (I. e. IE did not have SVG support....
-
A short while ago, SVGs on the web didn't work well. (I. e. IE did not have SVG support....
-
Hm, I think DAPS was created in an era when SVG on the web didn't work well. (I....
-
Hm, I think DAPS was created in an era when SVG on the web didn't work well. (I....
-
This might (might!) be an xmlcatalog issue... We recently had some Debian fixes in...
-
Thanks for the tips. Parameters are nice but there is an even easier solution! In...
-
Hm, not sure if that actually causes your issue (it should not), but WARNING: toc...
-
Hm, not sure if that actually causes your issue (it should not), but WARNING: toc...
-
Hm, not sure if that actually causes your issue (it should not), but WARNING: toc...
-
Anonymous, all the fixes should be packaged up now. For the moment, DAPS 2.1.5 is...
-
Hm... maybe that is a bug in the suse-xsl build process..? A misfiring regex or so......
-
Hm... maybe that is a bug in the suse-xsl build process..? A misfiring regex or so......
-
In the repo, the place for the Hungarian l10n would be gentext/locale/hu.xml
-
Hungarian localization for Publication Date (PubDate and pubdate) is MIA
-
XSLT1.0, DB5 Compatibility: XSL Namespace Insertion Is Buggy
1 >
