OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [docbook] Re: [docbook-tc] Followup to Norm's write up on numbering.


On Wed, 19 Jul 2006 11:22:06 +0200, Jirka Kosek <jirka@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.
>>
>>     Example:
>>
>>     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.

Regards,
BG


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]