Bug 752851
| Summary: | <screen> with <computeroutput>/<userinput> do not work as expected | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Community] Publican | Reporter: | Raphaël Hertzog <raphael> | ||||
| Component: | publican | Assignee: | Jeff Fearn 🐞 <jfearn> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Ruediger Landmann <rlandman+disabled> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 2.8 | CC: | fbolton, rlandman+disabled | ||||
| Target Milestone: | --- | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-11-14 21:11:56 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
(In reply to comment #0) > The output will be scrambled because publican will clean the newlines within > <computeroutput>. The code only considers that <computeroutput> is not verbatim > instead of looking up further in the ancestry to discover if a verbatim > environment is in place. computeroutput is not a verbatim tag, and is never treated like a verbatim tag, regardless of it's locating within an XML node tree. That seems a weird behaviour if it's really the expected one. Anyway can you at least include the small XSL change? <computeroutput> is still allowed in <screen> and should not be rendered in bold there. Your answer led me dubious so I asked on the upstream mailing list and I got this answer: ----- The specification says that "Line-specific environments," which include the verbatim elements, preserve whitespace and line breaks in the source text. The general description of inline elements says that inlines "do not cause line or paragraph breaks." I take that to mean that unlike a block element, the processor should not insert a line break before or after an inline element. I don't take it to mean that inlines change the mode of operation inherited from the enclosing block. I suppose the specification could explicitly say that white space and line breaks inside an inline are to be treated in accordance with the style of the enclosing block. However, I think it's pretty clear, esp. since any other interpretation would force you to do some pretty gruesome things (like closing an inline at the end of a line, then reopening it at the beginning of the next), just to preserve the verbatim environment. ----- So I'm reopening the bug in particular since the patch is ready and I don't really see any harm in applying it. I honestly don't see who would benefit from the current Publican behavior. Nobody needs to lose spaces and newlines in a inline tag within a verbatim environment. Refs: http://lists.oasis-open.org/archives/docbook-apps/201111/msg00050.html Inline tags are white space insensitive, verbatim tags are white space sensitive. This doesn't change just because you put a white space insensitive element inside a white space sensitive one. There are hundreds, if not thousands, of existing examples of verbatim tags with nested inline tags, changing the current behaviour would have an enormous effect for no real gain. *** Bug 915674 has been marked as a duplicate of this bug. *** |
Created attachment 532865 [details] Suggested patch If you have docbook like this: <screen><computeroutput>$ </computeroutput><userinput>date; sleep 1; date</userinput> <computeroutput>jeudi 10 novembre 2011, 16:31:36 (UTC+0100) jeudi 10 novembre 2011, 16:31:37 (UTC+0100)</computeroutput> </screen> The output will be scrambled because publican will clean the newlines within <computeroutput>. The code only considers that <computeroutput> is not verbatim instead of looking up further in the ancestry to discover if a verbatim environment is in place. I noticed the problem in a translation, I'm not sure if it also happens for the original language but I guess so. Another problem is that in the output we expect <userinput> to use a bold font (and this works) but <computeroutput> should not be bold so that it's easy to differentiate what the user must type (and this is not the case currently). This default formatting of docbook-xsl is overridden by some changes in xsl/pdf.xsl. I have a patch for both issues. For the second issue, my patch adds a supplementary override that restores the original behaviour in the specific case of <computeroutput> as a children of <screen>. I did this because I don't know the rational for the original change, but maybe you can simply drop the override for <computeroutput>, i.e. remove computeroutput in that block: <xsl:template match="command|filename|keycap|classname|literal|computeroutput|option|code"> <xsl:call-template name="inline.boldmonoseq"/> </xsl:template> Thank you for considering my patch.