Re: Problems with examples
W. Eliot Kimber wrote: strictly. But it probably should issue a warning, at least. I'll submit that on the XEP support list. RenderX reports that this change will be in the next maintenance release of XEP. Cheers, E. -- W. Eliot Kimber, [EMAIL PROTECTED] Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Problems with examples
Peter B. West wrote: W. Eliot Kimber wrote: Eliot, I'm not sure how to proceed. The war-cry of workers on the X-web is surely, "Remember HTML!" The argument for a new content model for simple-page-master is cogent, and I'm sure that the editors will listen to it. (How the result will be expressed is a different matter. How *do* you express it?) In the meantime, the spec is plain on this point, so why not follow it? Absolutely, we should follow the spec--that is the safest route. I was really just noting that, given the unique aspect of this one sequence group, XEP's validator was not entirely out of line for not enforcing it strictly. But it probably should issue a warning, at least. I'll submit that on the XEP support list. Any AND content model can be refactored as an OR group of sequence groups: ((region-body, region-before?, region-after?, region-start?, region-end?) | (region-before, region-body, region-after?, region-start?, region-end?) | ... > But as you can imagine, this can get quite long, especially when you have to ensure that the resulting model is not ambiguous. I will submit a request to clarify the true constraints on this content model to the FO editors list. Cheers, Eliot -- W. Eliot Kimber, [EMAIL PROTECTED] Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Problems with examples
Oleg Tkachenko wrote: Peter B. West wrote: I have debugging my FO tree building be running it against various example fo files. Of the three I have used so far, I have found problems with two. ./docs/examples/pagination/allregions.fo has the problem that I mentioned in an earlier past; the simple-page-master does not have region-body as the first region specified. Hmmm, allregions.fo looks okay to me. Probably this stuff is also in tables/background.fo, this one really have btw, neither antenna nor XEP don't complain on it. The FO spec is clear that the content is a sequence group. However, semantically, there's no point in constraining the order of occurrence in this case as there is no interdependenc of the elements. I'm sure that if XML had AND connectors the editors would have used them. Since there can be no practical failure that would result from a different order of region declarations, I think it's appropriate to not enforce the content model. In fact, I did a quick survey of all the formatting objects and this is the only case in which a sequence group is used where the order does not have some obvious purpose (e.g., putting declarations before uses). While any implementation would be free to complain if the order were not followed, I would consider that to be a "Simon Says" behavior--that is, complaining about something that could either be recovered from without risk or that cannot possibly hurt anything in the first place. I'm not sure how culturally distributed the childs' game of Simon Says is, but the basic idea is that one child gives orders and the other performs them IFF the first child says "Simon Says", as in "Simon says touch your nose" or "touch your nose" (if the orderee complies, the first child says iperiously "I didn't say Simon Says") (at least I think that's how it's played--it's been a long time since I played it and I have no children at hand to remind me of the details). In any case, I consider Simon Says behavior to be one of the more heinous sins of software implementation. It's especially prevelant in the implementation of standards, as one might expect. On the other hand, unrestrained recovery and fallback can lead to its own problems, as we learned from HTML. For example, I've found XSL Formatter's almost total lack of validation of FO instances to be counter productive in the long run if one is not checking their FO markup, either with XEP or by inspection against the spec. Fortunately, RenderX provides their validator as service to the community, so there's no excuse for anyone producing FO instances that don't at least conform to the rules XEP validates. Cheers, E. -- W. Eliot Kimber, [EMAIL PROTECTED] Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Fwd: EXSLFO Project]
Oleg Tkachenko wrote: Hello! Looks like Eliot forgot to crosspost it to our list: Ooops--I knew I was forgetting one. Thanks for copying it. Cheers, E. -- W. Eliot Kimber, [EMAIL PROTECTED] Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: default page width
Oleg Tkachenko wrote: Hello! I'm about to fix bug #10158 and I wonder, why in FOP default page width is 8in although spec recommends 8.26in[1]. Well, actually in absence of User Agent page width is implementation-defined, so we can leave 8in happily (actually XEP also uses 8x11in defaults, but Antenna - 8,26x11). Opinions? 8.26--that gives you the A4 width and US length, that is, the universal page size that will give acceptable results on either US or A4 paper. Cheers, E. -- W. Eliot Kimber, [EMAIL PROTECTED] Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XML area tree question
Oleg Tkachenko wrote: Yes, that sounds great. Somebody have to design spec of it :) Apart from this: may be it's time to establish exsl-fo community to define common crossformatter extensions like exslt.org does for xslt? Sounds like it. I hadn't done this yet because I got some conflicting responses and I've been swamped with other work. I'll submit a Sourceforge application for the project as soon as I get a chance. Cheers, E. -- W. Eliot Kimber, [EMAIL PROTECTED] Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XML area tree question
Matthias Brunner wrote: Hello, in this thread (http://marc.theaimsgroup.com/?l=fop-user&m=103227363003594&w=2) I asked whether you could use FOP extensions to get the pagination back into the source XML document. There was some discussion of this requirement on one of the FO lists not too long ago. It's a general requirement of all FO implementations. My suggestion was to enable the arbitrary output of "side files" that contain whatever information the style sheet writer wants to output. XEP already provides a generalized output mechanism that goes some way toward satisfying this requirement, although I would like a more general solution that lets me put essentially arbitrary markup in the output, but with the ability to refer to artifacts of the paginated result document (page numbers, marker values, mappings of input elements to the pages they occurred on, etc.). Cheers, Eliot -- W. Eliot Kimber, [EMAIL PROTECTED] Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Sample FO Documents
As I mentioned in another forum, I have a fairly comprehensive set of samples, both contrived and realistic, that are available to any implemmentors. I'd be happy to provide these to the FOP team--just let me know who to send them to or where to upload them. These have been developed both as demos of using FO to do multi-language composition of technical manuals and as samples in service of a new FO course we're developing. The downside for FOP is that these examples were developed initially using XSL Formatter, which is the most feature complete implementation. That means that the samples and demos have not been tailored to work w/in FOP's current limitations. Cheers, Eliot -- W. Eliot Kimber, [EMAIL PROTECTED] Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Sun xsl formatter being donated to open source
Keiron Liddle wrote: On Tue, 2002-11-19 at 09:18, Oleg Tkachenko wrote: Hello there! Nikolai Grigoriev discovered new xsl formatter becoming open source ;) http://www.xmlconference.org/xmlusa/2002/thursday.asp#vp5 Comments? Does anybody plan to participate xml 2002? Some people even suggest it's Apache where Sun want to donate it to. So why would they do it in that order. Why not donate resources to develop. I haven't heard anything so we'll see what happens. I spoke with Tony Graham of Sun, who will be speaking on this at XML 2002. He said he was not at liberty to discuss it all in advance of the conference--apparently they are working out the final legal details of the release or something to that effect. Cheers, Eliot -- W. Eliot Kimber, [EMAIL PROTECTED] Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Frustration With FOP
I feel a need to say something about my frustration with FOP, because I think it's a potential issue for the XSL FO world in general and it concerns me, especially as a person who's working very hard to try to advance the acceptance and use of FO, both through educating potential users and working with the various implementations to identify flaws and suggest improvements. First, let me be clear that FOP as a project is a very good thing: the world absolutely needs a solid open-source implementation of XSL FO. I know that the FOP volunteers are working very hard and have put in an amazing amount of effort on the development achievements to date. I know how hard it is to implement page composition at all, much less in the context of a highly generalized scheme like XSL FO. My frustration stems from the fact that FOP, as good as it is, is simply not ready for general use--it implements too few features of FO and has too many implementation bugs to be considered a candidate for any sort of production use except in the most constrained use cases. This means, for example, that I cannot report my experience with how FO implements a particular feature for the simple reason that FOP is unable to process most of my samples *at all*. For example, I just downloaded the latest stable release and tried to run it against a sample I have that exercises a wide range of table rendering options. Because FOP doesn't implement support for percentages for lengths on blocks (the message I get indicates that it doesn't know how to deal with "100%" as a value for inline-progression-dimension, which must be coming from "width="100%" on my tables), it can't render these table samples at all. Because my focus as an integrator is on building production systems for my customers, I can't justify building test cases that will work within the severe constraints currently imposed by FOP. This frustrates me. My frustration is not that FOP can't do this stuff--it is still in early development--but that the FOP documentation doesn't make it clear that it can't do this stuff. If one reads the documentation, including the limitations, it would appear that FOP implements almost everything in FO--the list of features listed as explicitly not supported is very short. But my tests, and a look at the FOP to-dos, make it clear that FOP is much more limited. This leads to a serious mismatch between expectations and reality. My fear, already borne out by some personal experience, is that FOP will give people a bad first impression of XSL FO, making them think that FO is much more limited than it is. We've already seen a number of posts to the various FO-related forums where people have confused FOP and XSL-FO, thinking that a limitation in the current version of FOP is a limitation in XSL-FO generally. I really don't like having to say "I haven't tried X with FOP" because it makes it sound like I have something against FOP, which I don't. It's simply a fact that it's still at an early point in its development. Thus, I would like to urge the FOP team to be more clear about the current limitations in FOP--list every property value and required behavior that isn't yet implemented. Also, be clear that, at its current level of development, FOP is not suited for production use. It's fine for experimentation and it's fine if you can live within the constraints it imposes, but it is not yet a general-use FO implementation (that is, an implementation that is all or mostly plug compatible with the other available implementations). I think this would go a long way toward avoiding the mismatch between expectation and experience that can cause people to get a bad first impression of XSL FO. Or said another way: I should not have to explain to any of my customers why FOP is not yet a candidate FO implementation for them--that should be clear from the FOP site. When that status changes, I will be the first to let my customers and prospects know, because I know they would all like to have one more option, one that has no up-front license cost [which is not the same as saying that FOP is free--there are no free production solutions, only solutions with upfront licenses costs and solutions without; but there is always a cost to implementing any tool set for production use and usually the license cost is the least part of it.] For example, we have integrated the Apache Lucene full-text engine in several projects now. I would love to be able to do the same with FOP. Cheers, Eliot -- W. Eliot Kimber, [EMAIL PROTECTED] Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
