> > > Running headings are not exotic. They are very common in books. I would
> > > guess that if you picked up two or three books right now, one of them at
> > > least would have running headings.
> >
> > I picked up 10 books, trying to find something that look
> > 'not renderable'. There are just different page headers there.
> > Each of our 40 testcases at   www.renderx.com  has a
> > page header.
> 
> Did any of the books have a header that changed with each section? That is
> what I mean by running headings/headers. Currently, XSL only lets you vary
> headers for each page sequence. That means you can't have a header that
> indicates the section where a section doesn't necessarily start on a new
> page.

I understand the thing you are talking about.  I did understand 
it the first time Sebastian wrote it.  I also have not ignored 
your words about the page-sequences.

When I'm saying that  I see 'nothing not-renderable - 
there are just a page headers' it does not mean that I don't 
understand  the *possible* complications. I do. I'm just 
waiting for something  more presize about those *possible*
complications than 'runnig heads are easy for 
typical day-to-day formatter but are hard for XSL FO'. 

*Both*  parts of this claim should be backed by something
more than words. I can not consider the references to 
the professional experience to be something more than 
words. Of course, I *greatly* respect people who have spend 
more time than I did with professional typography e t.c.
Unfortunately, it has nothing common with particular 
claim  I'm working with. 

The claim was : "XSL FO is weak  because 'typical day-to-day
formatters' can do running headers' and XSL FO based - can not" 
I'm trying to get the  real-life example that will show that this 
claim is correct in both parts.

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

So far the tables there are just a *subset* of our internal 
testcases ( not yet published ).

Without  the xml-input  + PDF-output  the 
'running heads'  task is still *not* specified enough.

( As well as 'complex tables' claim.)

If one will re-read the thread from the beginning 
it will be obvious that I've been  placed in the 
situation when I should guess *what* is 
considered to be a *real* problem. Is it 
dots in the head ?  Is it dictionary specific stuff?
What else?

So far all my attempts to place this thread into 
something constructive are vain and as a result 
I'm considered to be a moron who just can't 
understand  the trivial things. That's boring.

 > The closest book to me right now (Java in a Nutshell) has running headers
> not only indicating sections, but in the case of the API reference at the
> back, indicating the class being talked about.

So from your letter  we see that we have 'runnig headers' of 
at least  2 kinds. 'Indicating sections' and 'indicating the class'.

It would be great to get the presize usecase for the functionality 
we are discussing. Just imagine the situation when we'l render 
the 'runnig headers' of class (1). Next day we do it,  somebody 
again says that "XSL FO renderer is incomplete, because 
I realy need a 'runnig headers of class (2)'". 

It appears that this 'running headers' stuff  is similiar to tables.
People want it. They want it to bee good. When being asked
about : "what  in particular is good enough?"  - the situation 
becomes not that clear as it was before. 

<BTW>

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. 

Please do not take my  words personaly. Obviosly 
I don't think you are "just thinking" about the XML, 
or you are using it as a buzzword  ;-)  Of course I don't think 
Sebastian does ;-)

</BTW>
 
> I agree that XML + desired PDF is a good way to specify a requirement.

I see it to be the only possible way to understand what could 
be the real workaround in FOs to solve the puzzle. 

For example, maybe it'l be just enough to provide a one 
extra attribute to page-sequence? 

Of course we'l take into account that there are also 
'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 ?

> What I disagree with is that a "typical day-to-day formatter" shouldn't be
> able to do running headers. Perhaps we differ on what a "typical day-to-day
> formatter" is. I *don't* mean a web browser and I *don't* mean Microsoft
> Word (although Word might very well be able to do running headers). I mean
> tools that professional publishers use in producing professional
> publications.

We differ on many things here. 
 
> Running headers should be supported by a typical formatter. XSL doesn't
> support them. This is not a criticism of RenderX. It is something missing in
> XSL that if not included in 1.0 will have to be added very soon afterwards
> if XSL is going to be used in the kinds of production environments that
> Sebastian is talking about.

I still don't understand  what particular  problems do you see 
there. Unfortunately I can not start explaining the most elegant 
solution before I'l get a presize task specification, becuse it 
appears  now  that  ( for some reason) renderx is  blamed for 
such a subtile things - I could never imagine it before.

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.

To me - XSLT is *still* the part of XSL and considering  XSL FO 
to be the *olny* APL to rendering is just a mistake. We don't need 
yet another monster. We do need a set of components. 

It appears that this discussion is not helping us to 
make a situation with XSL FO better than it is now, but 
results in some strange assumptions those are made 
because of my poor English, I think. 

I think that it's now better for me to ignore the rest 
of this thread because  is not bringing us closer  to the 
working XSL FO renderer and unfortunately I have no 
other goals yet.  I should make it work  even the 
XSL WG will silently postpone the standard  for next 
year, because it is the missing link.

I still think that  the real showstopper with XSL FO 
is *not* the tables,  'running heads'  or any other 
small technical issue.

My original idea when I saw the 'problem' was that instead 
of just intorducing  our own 'spacer'  tag for 'runnig heads'  
( like you are doing in FOP) we'l firstly  try to provide some 
practical  improvements  to the  XSL FO standard, implementing 
the 'experimental' version  of the XSL FO standard so that it'l  
be easier to explain  why we are suggesting some change.

Maybe it'l be better for us to take your way and to start with 
'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 
world where technical issues are nothing if comparing them 
with some other issues. If my suggestion clearly shows 
my lack of political experience, I apologize and please 
ignore it.

Anyway.

I should say "thank you" to all of  XSL FO implementators 
who are writing to this list. We did learn many things from you 
( mostly non-tehcnical ;-)

Rgds.Paul.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 paul@xxxxxxxxx   www.renderx.com   www.pault.com
 XMLTube * Perl/JavaConnector * PerlApplicationServer
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



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