Re: foo ... bar Re: Q: XML+XSL transforms to a print-ready format

["Paul Tchistopolskii" <paul@xxxxxxx>]

> If we agree on what it meant by "running headers" then do you agree that
> they exist in many books? When I said pick up two or three books and look
> for running headers, you said you picked up 10 and couldn't see anything
> non-renderable. I didn't ask if you could see anything non-renderable, I
> asked if you could see running headers.

I agree that 'running headers' exist  in many books.
 
> I will explain again. Imagine that on even pages you want the name of the
> chapter of the book in the header and on the odd pages you want the name of
> the section within that chapter in the header. Now imagine that each chapter
> begins a new page, but each section does not.
> 
> THIS CANNOT BE DONE USING THE CURRENT DRAFT OF XSL

I agree that 'running heardes' as well as many other things 
cannot be done using the current draft of XSL.
 
> This simple kind of running header is not just hard, it is impossible in the
> current draft.

Many simple things are impossible with current draft if using it AS-IS.
I agree.

> [...]
> > 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.
> 
> Let me say again: the simple kind of running headers described above
> (chapter on even, section on odd with no break-before on sections) CANNOT BE
> DONE USING XSL FOs.

I agree. 
 
> However, this simple kind of runing headers CAN BE DONE IN MICROSOFT WORD.
> Not only that but DICTIONARY-STYLE HEADERS, the type that you called
> "exotic", CAN BE DONE IN MICROSOFT WORD.

Yes, I agree. Misrosoft Word is a big program, written by many 
developers for many years. It can do many things.

> I think Microsoft Word is *LESS* powerful than a typical day-to-day
> formatter used by publishing professionals and yet it can do, not only
> simple running headers like my example above but the dictionary-style
> headers that Sebastian wants and that I used in my one and only self-typeset
> book.

I agree. There are many other publishing systems other than 
Microsoft Word and they can do many things. For example, there 
are some packages  which  allow you to create a very beautiful 
layouts. I agree  - MS Word may be less powerful than a 'typical
day-to-day formatter' ( even I still don't  understand  what is 
'typical day-to-day formatter', because nobody was presize enough 
to name it ( for example ... I guess .. TeX ? Oh... sorry... I'm guessing 
again.. ).

> > Without  the xml-input  + PDF-output  the
> > 'running heads'  task is still *not* specified enough.
> 
> I disagree. Sebastian and I have specified the task quite clearly.

I agree. The task was to do a 'running heads' . To change 
the page header depending on some intuitive but obvious rule(s).
 
> Sebastian's is a *real* problem. He is trying to format a *real* document.
> He has come across a *real* problem in the current XSL spec. The XSL WG have
> always know about this, and I'm sure XSL will eventually be able to handle
> it. But at the moment it can't. There is no need for you to defend it. XSL
> just plain can't do what Sebastian (and I) would like it to be able to do.
> And we are suggesting that it is not an unreasonable thing to want to do.
> After all, Microsoft Word lets you do it!

I understand. It is a real problem. XSL does not support 'running heads'.
It supports just a page number.  You even can not assign the different 
page number to each part of the page when you are printing it in a 
landscape orinetation. 'Running heads' is more complex task.
 
> > > 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?
> 
> No, what you need is the ability to set parameters in your flow that are
> used to generate text in your static-content. And you need the ability to
> select the first and last value that a parameter has on a particular page.

Yes, if you are talking about the common soultion,  but not about the 
subset. I agree. 
 
> > > 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.
> 
> That's fine. But understand that what people do with Word is a long long way
> away from what professional typesetters do. People get a desktop publishing
> package and think they know how to typeset. That's like getting your drivers
> licence and thinking you could drive Formula-1.

I agree. I'm sure many complex publishing packages have many 
nice features. 
 
> > > 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.
> 
> Running headers are necessary for a lot of publishing work. If the spec
> doesn't support them, that's a problem. Right?

Yes, there are many nice and complex things which  spec does 
not support.  Maybe there are also many trivial things current 
spec does not support,  or the support is strange.

Do I understand right that XSL FO will become 'OK'  for 
production environment when it'l support  more features that 
MS Word currently provides... ?

Oh... not only MS Word but the 'typical day-to-day formatter'
provides?

Maybe it's better for us to stay away from areas 
already covered by 'typical day-to-day formatters' ....  

Even I don't understand what is that  'typical day-to-day formatter', 
I'm sure they can do smart page numbering and 'running heads' 
in their proprietary nonstandard way. 

The only question for me is now why should not I do it in the 
proprietary way? 

I actualy see no answer to this question except  "because W3C has not 
specified  it in the latest draft and it'l take maybe a  year to get it specified". 
So everything is fine and it appears that  the MS way with XML ( "take a 
basics. Make it work. Use your namespace for the rest" ) is the only 
possible way you have if you want something working today.

Thank you for the explanation, now I now what should I tell to 
the clients about 'running heads'. If I'l get one asking...  
Who knows...

Rgds.Paul.

PS.  

Maybe some day I'l find an xml input with PDF output rendered by 
some 'typical day-to-day formatter',  to play with it, just to show  that it is not 
a big deal to create similiar proprietary solution with  XSL FO based 
renderx engine. As well as I'l be glad to get the xml imput + PDF output from 
any proprietary package with the example of 'realy complex table'.  Maybe it's 
because I  have a strange feeling that I still don't understand what is that 
'typical day-to-day  formatter' and what is that  'realy complex table' ?

( Actualy  I had an experience  rendering some semiconductor-related 
enterprise documents with tables from FrameMaker to HTML ......but 
maybe there is something realy complex I can't imagine ... ) 

Oh... better to forget about it ...

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




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