Okay, so the proposals for new ID generation rules are:
1. "similar-to-title" 2. "s.similar.to.title" 3. "sn-similar-to-title"
I vote for
1 (b). s.similar-to-title
as it provides a different separator to distinguish structural info from semantic, content-related info.
I have seen the most problem in the PDF builds, but the HTML builds also seem to do funny stuff with more vertical space if you don't run your first and last text against the opening and closing <screen> tags, respectively. In other words, given these two examples:
<!-- first example --> <screen> <computeroutput> foo bar </computeroutput> </screen>
<!-- second example --> <screen><computeroutput>foo bar</computeroutput></screen>
The second example renders into a more pleasing vertical context, without a lot of wasted space. The PDF, IIRC, was particularly ugly if you didn't use the second form, but I seem to remember the HTML also was noticeably different.
I can't get anything to build PDF right now to test this, but in HTML I see the same thing as output, so am not sure of the advantage of the different way you suggest it.
I do notice that doing sgml-fill-paragraph will make them line up like:
<screen><computeroutput>foo bar</computeroutput></screen>
Then introducing the line break gets the functionality you mention.
Ultimately, I think we will want to drop the redundant <computeroutput> and use a CDATA container instead. In that case, _all_ whitespace will be considered for certain. All content will need to use the left margin of the XML as starting point for indention.
FWIW, I've switched over to <screen><![CDATA[ ...verbatim content... ]]></screen> with no ill effects (yet).
Example:
<screen><![CDATA[<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.1//EN">]]></screen>
There are those times when having the capability of just dumping your content into a CDATA section can really simplify the markup.
OTOH, if the HTML/CSS styling issue Tammy brings up presents problems, then I'd support using <computeroutput>.
FWIW, the <screen><computeroutput> combo doesn't seem to add anymore semantic info due to overlap in meaning between the two elements.
My $0.02, Mark
-- ---------------------------------------------------------- Mark Johnson <mjohnson@xxxxxxxxxx> OS Product Documentation Group Engineering, Red Hat, Inc. <http://www.redhat.com> Tel: 919.754.4151 Fax: 919.754.3708 GPG fp: DBEA FA3C C46A 70B5 F120 568B 89D5 4F61 C07D E242
