[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

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

---

---

> 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.

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.

> 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'.

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

This simple kind of running header is not just hard, it is impossible in the
current draft.

This has absolutely nothing to do with RenderX. It is a problem with XSL
FOs!

[...]
> 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.

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.

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.

> 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.

> 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?

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!

<aside>I can't believe I'm arguing the virtues of Word!</aside>

>  > 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'.

No. They are exactly the same kind. The only difference is the frequency
with which they change.

> 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)'".

I think the biggest misunderstanding on the thread is a confusion between
what the XSL spec supports and what your product supports. The situation you
describe above doesn't make sense. If you are claiming to have an XSL FO
renderer, then it is only incomplete if it does not do things required of
the spec. But Sebastian is not arguing that at all. He is talking about the
incompleteness of the *spec*, not any particular product.

> 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.

But that is a matter for the XSL WG, not XSL implementers. It is up to the
XSL WG to ensure that the needs of users are met. It is up to the developer
to conform to the spec. If a developer has a user that requires more than
the spec gives, they have to make a decision whether to offer a proprietary
solution.

> 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 disagree. People expect to be able to find a renderer that will achieve
that output they desire. Especially if that output would have been possible
in Microsoft Word! If it turns out the renderer doesn't do what is desired
because the spec doesn't allow it, it is a problem with the spec, not the
renderer.

> > 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.

> > 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.

> > 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?

> 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.

How many times do I have to say this: NO ONE IS BLAMING RENDERX. Sebastian
is expressing a requirement that cannot be met by XSL FO renderers because
it can't be done with XSL FOs. This is not a criticism of anything that
RenderX is doing *unless* you claim that RenderX can do everything that is
required in a typical production environment.

> 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.

Of course. This is what XSLT was designed for! No one is arguing against
that. In a lot of cases, most of the work is done by XSLT. But XSLT isn't
aware of page breaks. So things like running headers cannot be done at the
XSLT level.

> 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.

I don't know who you are arguing against here. XSLT has always been a part
of XSL. I don't know anyone who is claiming that XSL FOs should be used
without XSLT.

James


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

---