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] CALSpair format alternatives

On Mon, 17 Oct 2005 00:09:48 +0900, Michael Smith <smith@xml-doc.org>  

> nico <nicolas.marsgui@libertysurf.fr> writes:
>> But in the TDG example (2.0.12) the "units" attribute is set for  
>> areaspec.
>> And I guess that the units are inherited. Right?
>> <areaspec units="calspair">
>>   <areaset id="oneway" coords="">
>>     <area id="oneway1" coords="300 400"/>
> I don't know. :(
> TDG does not say anything about the units being inherited, but
> that example certainly seems to imply that they can be inherited.
> And the logic used in the DocBook HTML and FO stylesheets is that
> they are inherited.

Yes, and it is consistent with other attribute inheritences that exist in  
DocBook, like for tables (colsep, etc.)

> But still, that example does not make sense, because CALSPair
> needs four coordinates, as far as I can tell.


> Anyway, it seems the TDG is in need of some revising and
> clarification in that example and in the specification for
> handling of the Coords attributes.

I've filled a TDG tracker item for this.

>> >>- "x y"
>> >
>> >That is valid but could be either LineColumn or LineRange
>> Ok. Does it make sense if for graphic elements these units are  
>> interpreted
>> as the following calspair: "x,y x,y"?
> I do not know, and TDG does not make it clear.

IMHO, I find handy to have "x y" meaning a point coordinate.

> I suppose that the DocBook Project stylesheets are the "de facto"
> reference implementation of DocBook processing, so that if you
> find things not clearly specified in TDG, looking at the logic in
> the FO and HTML stylesheets is probably the way to go.

Yes, but it is better to have such aspects clearly defined in the  
documentation, at least to avoid some misconceptions or several  
implementations that behave differently.


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