[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Re: foo ... bar Re: Q: XML+XSL transforms to a print-ready format
Subject: Re: foo ... bar Re: Q: XML+XSL transforms to a print-ready format From: "James Tauber" <jtauber@xxxxxxxxxxx> Date: Sun, 10 Oct 1999 03:25:28 -0400 |
> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: foo ... bar Re: Q: XML+XSL tran, Paul Tchistopolskii | Thread | Re: foo ... bar Re: Q: XML+XSL tran, Paul Tchistopolskii |
Re: foo ... bar Re: Q: XML+XSL tran, Paul Tchistopolskii | Date | Re: Practical Suggestion for XSLT P, Oren Ben-Kiki |
Month |