Subject: Re: foo ... bar Re: Q: XML+XSL transforms to a print-ready format From: "Paul Tchistopolskii" <paul@xxxxxxx> Date: Sat, 9 Oct 1999 16:38:02 -0700 |
> > > 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
trouble getting XT to run on BSDi, Pete Beazley | Thread | Re: foo ... bar Re: Q: XML+XSL tran, James Tauber |
trouble getting XT to run on BSDi, Pete Beazley | Date | Re: foo ... bar Re: Q: XML+XSL tran, James Tauber |
Month |