Paul Tchistopolskii writes:
 > The previous claim was : "XSL FO implementation 
 > is weak because it can not render the "complex tables"
 > 
 > So far the only presize example of 'what is complex tables?'
 > we got was a reference to http://www.nwalsh.com

hang on, I never said Norm's tables were complex. I gave them  as examples 
of tables to start off with. I cannot render them properly in
PassiveTeX yet, so was curious to see RenderX do them. 

I don't have any complex tables marked up in XSL FO at present, but we 
could start with the famous "AT&T Common Stock" table, if you
like. I'll try and put that in XML and make a stylesheet.

 > It all comes to the real situation with XML.
 > 
 > Those who already have XML in place and who want their 
 > XML-based framework to work - are more forgiving 
 > to the XML renderer than those who have XML as a buzzword
 > on their web-site. 

I really do not know from where you derive this claim. *My* take on
the situation is that we see the difference between people `trading
down' from book typesetting systems (eg Arbortext, Framemaker, 3B2,
LaTeX), and people `trading up' from Netscape. I badly want a standard 
formatting language to typeset my XML documents, but compromising on
page formatting features is simply not an option. If I was currently
using HTML + Netscape, and was offered something that does better, I'd no
doubt accept it gladly. But I am not in that situation; to me, in my
book-typesetting persona (I have others), XSL FO as it is proposed is
interesting, but not a real option.

 > 
 > Of course we'l take into account that there are also w > 'running
 > heads' of another class(es).  At least now we
 > understand that the dictionary-specific stuff  *could* be 
 > left in a dictionary-specific namespace.  Right ?

to reinforce the point, NO. there is nothing special about
dictionaries. they are just an extreme case of the daily routine of
`section title in running head'

 > Generaly speaking -  I don't think  everything should be solved 
 > on the level of  XSL FOs.  Maybe some stuff should be solved 
 > at the 'level up' ? For us - the 'level-up' is XSLT. I should mention 
 > that at the first  versions of our engine we were considering to 
 > write a significant  part of  FO renderer in XSLT.
I'd go along with that. I am considering the same myself, for some
things (basically, to give me more clues about tables)

 > 'spacer'  tags right now. For the sake of poor users I think 
 > it may be not that bad idea if all of  XSL FO developers 
 > will start sharing their 'spacer' tags so that it'l save 
 > poor users. However, I may be asking too much in the 

James did make a specification for the running heads, but I will
leave it to him whether or not he wants to propose it, so that XSL FO
implementors can implement the same thing

Sebastian


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list