|Bob Stayton||Jun 29, 2006 2:39 pm|
|Rowland, Larry||Jul 17, 2006 12:54 pm|
|Rowland, Larry||Jul 17, 2006 1:02 pm|
|Jirka Kosek||Jul 19, 2006 2:21 am||.bin|
|Neil Roeth||Jul 19, 2006 4:46 am|
|Jirka Kosek||Jul 19, 2006 8:23 am||.bin|
|Steven Cogorno||Jul 19, 2006 9:22 am|
|Norman Walsh||Jul 19, 2006 9:51 am||.pgp|
|nico||Jul 19, 2006 12:08 pm|
|nico||Jul 19, 2006 12:54 pm|
|Norman Walsh||Jul 19, 2006 1:44 pm||.pgp|
|Jirka Kosek||Jul 19, 2006 1:45 pm||.bin|
|John L. Clark||Jul 19, 2006 2:12 pm||.pgp|
|Dave Pawson||Jul 20, 2006 11:17 am|
|nico||Jul 20, 2006 12:30 pm|
|Subject:||Re: [docbook] Re: [docbook-tc] Followup to Norm's write up on numbering.|
|Date:||Jul 19, 2006 12:08:51 pm|
On Wed, 19 Jul 2006 11:22:06 +0200, Jirka Kosek <jir...@kosek.cz> wrote:
Rowland, Larry wrote:
2) Add an optional @linenumberstep (or something similar) that allows the author to override the global setting for line number increment. This is not to say that the stylesheet should not be as intelligent as possible about when to use the step increments based on the length of the example. This is to accommodate those special cases where the stylesheet rules are producing inappropriate behavior for the specific case being dealt with.
Two programs are being discussed, one a short program that interacts with a longer program. [...]
Let me say that I still think that such attribute is completely presentional and it should not be added to DocBook. Each programlisting has invisible intrinsic line numbers -- you can always start counting line numbers from the start of listing manually. Of course if you reference line numbers it is more then reasonable to display line numbers to make navigation to particular line number easier. But even without such facility, you can find line number in discussion.
I don't see why you are stuck about the presentational aspect. Indeed, when you ask for linenumbering, you ask for "line numbers shown in the rendering output". In a sense, it's also a rendering attribute.
Moreover, there are many other docbook attributes that directly affect the rendering: itemizedlist/@spacing, itemizedlist/@mark, orderedlist/@numeration, all the imagedata @contentwidth, @width, @depth, etc. are interpreted differently depending on the output target, but they give some indications about how to render lists and images. When table HTML tags have been introduced in docbook, the @bgcolor has not been removed, and it's a rendering attribute.
But particular type of numbering (fonts, number of digits, increment) is completely presentional issue which should be handled by processing system (stylesheets, editor, ...). Line numbering step is similar to auto numbering of sections -- there is also no DocBook markup to control depth of auto numbering.
For me line numbering step is not like auto numbering, since I precisely want to set the step. BTW, if the PIs have been introduced to handle such a thing, I guess it's because it's usefull, handy and meaningfull. The example from Larry is a case from real world, where the docbook writer want precisely line numbers like this in this portion of code, and like that in another.
I'm sure that in 99,99 % of cases you can control line numbering step automatically in stylesheets. For this 0,01 % you can always put something like role="densenumbering" to your programlistings.
During last telcon someone was arguing that he/she doesn't like using custom attributes and custom stylesheets for handling such cases. Well, but how do you then control situations in which for example:
- each document has different depth of autolabeling of sections - some book/chapters should/shouldn't contain toc/lot - ...
Ok, it's always impossible to customize every bit of the output with a set of parameters, attributes, or PIs. This said, the parameters, PIs and attributes are here to prevent from everyone to rewriting its own stylesheet and handle the most common configurable aspects. I don't see the linenumbering step as an esoterical thing that needs every user to write something special.
I would really appreciate if DocBook can contain as less presentational markup as possible. DocBook was designed as an interchange format which captures semantics. @linenumberstep attribute doesn't improve semantic, nor possibilities of interchange.
I also appreciate when a document is not polluted with many processing-specific PIs, that another processor cannot handle nor understand. In addition, playing too much with user-made stylesheets is not good for interchange too.