Bug 752851

Summary: <screen> with <computeroutput>/<userinput> do not work as expected
Product: [Community] Publican Reporter: Raphaël Hertzog <raphael>
Component: publicanAssignee: Jeff Fearn <jfearn>
Status: CLOSED NOTABUG QA Contact: Ruediger Landmann <rlandman+disabled>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 2.8CC: fbolton, rlandman+disabled
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-14 16:11:56 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
Suggested patch none

Description Raphaël Hertzog 2011-11-10 10:46:23 EST
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>

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

Thank you for considering my patch.
Comment 1 Jeff Fearn 2011-11-10 22:26:41 EST
(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.
Comment 2 Raphaël Hertzog 2011-11-11 03:24:43 EST
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.
Comment 3 Raphaël Hertzog 2011-11-14 02:10:26 EST
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
Comment 4 Jeff Fearn 2011-11-14 16:11:56 EST
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.
Comment 5 Fintan Bolton 2013-02-26 05:28:02 EST
*** Bug 915674 has been marked as a duplicate of this bug. ***