[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]