Arved, This is a good idea. I half-heartedly suggested as much to Matthew Huggett when he asked what a non-programming technical writer might contribute. It requires too deep an insight into the spec, but he (or Cyril) may of some assistance to you.
What would be even more generally useful would be to get the spec editors to put up a site, possibly with disclaimers plastered all over it, to which they post FAQs on the spec. They must get a lot of repeating questions from the various parties who are trying to implement. I'm not subscribed to the xsl-editors mailing list (which I suppose I should be.) Is anyone else subscribed? If so, have requests like this been made before? Peter Arved Sandstrom wrote: >Hi, Keiron > >I think what I should do is establish a section on the website with all the >other design notes that is a central location for these kinds of studies. >This could be the first one. I can undertake to start churning these out on >a fairly regular basis - I think we need them. > >Once they are in CVS then it would be easier for others to annotate them, >modify them, and what have you. We'll have to settle on a mutually agreeable >figure format so as not to unduly restrict access. > >As far as the spec goes, absolutely, I agree. That's why I think that these >diagrams help so much - in order to draw them you must work your way through >the spec in detail. The process also exposes any gotchas before too much >code has been written based on different assumptions. > >I'll proceed on the above basis and set up a place for these >diagrams/studies, and crank out some more. I am somewhat reluctant to do any >coding at the moment until such a time (hopefully not far away) where I am >satisfied that I understand the new design well. > >Arved > > > >>-----Original Message----- >>From: Keiron Liddle [mailto:[EMAIL PROTECTED]] >>Sent: May 2, 2002 6:18 AM >>To: [EMAIL PROTECTED] >>Subject: Re: [REDESIGN] Line layout manager discussion >> >>I agree with you (except for the last statment about one line). >> >>I found this statement interesting: >>6.6.7. fo:inline >> >>"An fo:inline that is a child of an fo:footnote may not have block-level >>children. An fo:inline that is a >>descendant of an fo:leader or of the fo:inline child of an >>fo:footnote may >>not have block-level children, >>unless it has a nearer ancestor that is an fo:inline-container." >> >>It suggests that what you are saying is correct and that block-level >>elements create a block area outside the immediate line area. So >>to have a >>block area inside a line area you must use the inline-container, a block >>is never automatically embedded. >> >> >>Also in this section, reading between the lines (it's amazing how they >>manage to contradict themselves in such a short section) >> >>4.7.3. Inline-building >> >>An inline fo element with a block element as a child will create inline >>areas and return the block area. >>It will create a single inline area that can fit consecutive child inline >>areas on a single line. So the child inline areas are put into parent >>inline areas that are separated by line breaks and block areas. >> >>So Karen's approach is looking better. >> >>I really wish this spec would say relevant things in the right places and >>mention how everything is handled rather than being so vague. >> >> > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
