Glen Mazza wrote: > We don't do HTML at all (Xalan's department)-- HTML is > browser dependent. HTML is not an output format.
I know, the purpose was to illustrate my point, since everyone is familiar with HTML, but perhaps not with MIF or RTF. If you think it makes sense for FOP to output RTF, then it also makes sense for FOP to support HTML (at least in combination with CSS2). > w/RTF, "as for reaching even basic conformance"--my > impression on XSL-FO was that we must render up to the > maximum capabilities of the output format. > > So where there is an FO object or property that RTF > simply can't support, this would *not* mean (1) we're > incompliant with the XSL-FO spec w.r.t. the RTF > rendering, or (2) that RTF cannot done via an XSL-FO > input. Well, formatting objects are mandatory for a specific conformance level regardless of the output medium (sometimes different for visual and aural output media of course). As for properties, the specification already defines behaviour if certain rendering properties can not be represented. This is true for color and fonts, for example. The specification, however, seems to always assume that you (the implementation) have precise control over the formatting and pagination process, which you don't have with RTF. Example: expressions including functions seem to be basic conformance level to me. RTF doesn't support expressions. How will you resolve an expression that can only be determined a formatting-time if you can't hand over the expression to RTF? You cannot anticipate the actual formatting an RTF renderer (like Word) will do, if only because a different hyphenation library is used. > I think the "binary" of PDF is also human-readable, > just like RTF is, albeit it's more complex and has > much more functionality. It appears that the main > difference between the two groups is back to some > needing page numbering and others not. With this I don't agree at all. First, PDF is only human-readable in a way that PostScript is, too - and only if you totally leave out encoded objects. You could even say that PDF is something like annotated and restricted PostScript. Nitpicking aside - this is basically true. Second, it's not really about page numbering. The difference is formatting. By formatting I mean deciding were lines and pages are broken and where glyphs and other graphical elements are put exactly. If you don't know where exactly a glyph will end up, it's not formatting. 8-) Extreme example: XSL:FO to formatted ASCII. There are lots of constraints that you now have, but the formatter will still know where each glyph will display. Before we're getting too philosophical, let me say that we're now talking two different issues: 1. Is it possible to develop a conforming XSL:FO implementation that produces RTF or MIF or similar ouput? 2. Are there really two different groups of output formats and does it really make sense to support both in one tool (FOP). My answers: 1. Probably no. Only if all XSL:FO specification constraints are either directly supported by the destination language (RTF, MIF, whatever) or can be transformed into supported destination language elements without anticipating concrete formatting steps (like line-breaking). Anyway, this probably cannot be definitely resolved without contacting the W3C. Also, it's a rather academical (or worse, legal) issue unless/until you want to claim conformance for these output types for FOP. 8-) 2. Yes, there are, and no, it doesn't really. That's a bit like taking a C compiler that produces machine code, and then add the capability to produce Java source code output to that C compiler. Yes, you can do it, but no, it doesn't make too much sense, since the only code you share is the parsing stuff and abstract syntax tree building. Of course, the few parts that *can* be shared *should* be shared. Maybe it's even worth to bundle both things into one "tool" or library - if only for the user's convenience. I just think it's absolutely not worth the bother to clutter major parts of FOP (old or new) with stuff needed by converter-type output renderers, when these don't even profit from these same major parts of FOP. All of the stuff needed for FO->RTF or FO->MIF conversion is pretty straightforward stuff. IMO not at all comparable with the complexities lurking in actually *formatting* according to the XSL:FO specification. Sermon ends. 8-) -- Cappelino Informationstechnologie GmbH Arnd Beißner --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
