Bug#382505: We'd need to update the upstream docs also
If you were to change the Debian docbook-xsl package such that it uses /etc/papersize as a default papersize instead of using letter, as the upstream docs say, then you run the risk of a users discovering that every time they generate FO output, they are getting a different default thatn what the upstream docs say they should be getting, and them perhaps having no idea why that is happening. I suppose that if you implemented this, we could update the upstream docs to say that the default is letter except on Debian, where it's whatever is specified in /etc/papersize. But we've never put anything system-specific into the upstream docs before, and IMHO, this wouldn't really merit a setting a precedent for doing that. smime.p7s Description: S/MIME cryptographic signature
Bug#382505: We'd need to update the upstream docs also
Am Dienstag, den 05.09.2006, 16:30 +0900 schrieb Michael(tm) Smith: If you were to change the Debian docbook-xsl package such that it uses /etc/papersize as a default papersize instead of using letter, as the upstream docs say, then you run the risk of a users discovering that every time they generate FO output, they are getting a different default thatn what the upstream docs say they should be getting, and them perhaps having no idea why that is happening. True. I suppose that if you implemented this, we could update the upstream docs to say that the default is letter except on Debian, where it's whatever is specified in /etc/papersize. I thought about simply patching the docs in the debian package along with the param.xsl adding a notes - that we (Debian) try to read /etc/papersize to get the value and fall back to the described default - that this is limited to only reading /etc/papersize (PAPERSIZE and PAPERCONF cannot be examined) - that more info is in README.Debian (necessary commands) I don't think, that this should be put in upstream docs directly. I would maybe suggest (if you like the idea of reading the libpaper config), that you implement this in the XSL2 stylesheets using unparsed-text() of a file, set to /etc/papersize by default. The implementation for XSL1 is more a (working) workaround. But XSL2 offers the possibilities to do this, so it could be implemented. But we've never put anything system-specific into the upstream docs before, and IMHO, this wouldn't really merit a setting a precedent for doing that. See above. Don't put anything system specific into the docs. It's also possible, that one day this patch will be dropped, because of a better solution or any issues and then upstream docs may be outdated (and wrong) then. So I really don't think it's a good idea to put this into upstream docs. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382505: We'd need to update the upstream docs also
Daniel Leidert [EMAIL PROTECTED], 2006-09-05 15:23 +0200: I thought about simply patching the docs in the debian package along with the param.xsl adding a notes That assumes the users actually have installed docbook-xsl-doc and that they are reading it instead of say, simply reading them over the web at http://docbook.sourceforge.net/release/xsl/current/doc/ That doesn't seem to me to be a very good assumption to make. I don't think, that this should be put in upstream docs directly. I would maybe suggest (if you like the idea of reading the libpaper config), that you implement this in the XSL2 stylesheets using unparsed-text() of a file, set to /etc/papersize by default. The DocBook XSL stylesheets are OS-agnostic, by design. /etc/papersize is not a system-agnostic value to set as a default in a set of stylesheets designed to work across platforms. The implementation for XSL1 is more a (working) workaround. But XSL2 offers the possibilities to do this, so it could be implemented. We are a long, long way away from having a usable set of stylesheets that rely on XSL2 See above. Don't put anything system specific into the docs. It's also possible, that one day this patch will be dropped, because of a better solution or any issues and then upstream docs may be outdated (and wrong) then. So I really don't think it's a good idea to put this into upstream docs. And my point is that if it's not put into the upstream docs (and believe me, I'm not disagreeing that is shouldn't be), then it the patch should be dropped from Debian. You otherwise will have users who have no idea where the default value is coming from. --Mike smime.p7s Description: S/MIME cryptographic signature
Bug#382505: We'd need to update the upstream docs also
Am Mittwoch, den 06.09.2006, 00:59 +0900 schrieb Michael(tm) Smith: Daniel Leidert [EMAIL PROTECTED], 2006-09-05 15:23 +0200: [Should the workaround be mentioned in upstream docs?] See above. Don't put anything system specific into the docs. It's also possible, that one day this patch will be dropped, because of a better solution or any issues and then upstream docs may be outdated (and wrong) then. So I really don't think it's a good idea to put this into upstream docs. And my point is that if it's not put into the upstream docs (and believe me, I'm not disagreeing that is shouldn't be), then it the patch should be dropped from Debian. You otherwise will have users who have no idea where the default value is coming from. I could simply add a note [1] to the xsl:message, where you (upstream) output, which format is used (fo/docbook.xsl - root.messages). IMHO this is enough to make users aware of this little workaround. [1] E.g.: See /usr/share/doc/docbook-xsl/README.Debian for more information. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382505: We'd need to update the upstream docs also
Hi Daniel, I could simply add a note [1] to the xsl:message, where you (upstream) output, which format is used (fo/docbook.xsl - root.messages). IMHO this is enough to make users aware of this little workaround. [1] E.g.: See /usr/share/doc/docbook-xsl/README.Debian for more information. Yep. I hadn't thought of that. Great idea -- and sounds lke a reasonable solution to me. --Mike smime.p7s Description: S/MIME cryptographic signature
