Re: Structure renderers area trees (Re: startup refactoring)
Peter B. West wrote: Bertrand is probably in the best position to comment wrt RTF. Is anyone familiar with MIF. Does it simply define page structures and flows? I'm roughly familiar with MIF - did some rough HTML to MIF conversion years ago. Basically MIF is structured text that is annotated with stylenames, which needn't even by defined in the MIF (but can, if I remember correctly). As for the general discussion on renderer types: IMO, it's a mistake to mangle renderers that produce formatted page-level output like PDF or PostScript with renderers that produce flow output in other formatting languages, like HTML, RTF or MIF. The latter is rather a conversion step, and you would need not the area tree but rather the FO element tree to do a good conversion. Fundamentally, I think these two different kinds of renderer tasks just have two things in common: a parser and an FO element tree, and that's it. So my suggestion would be to implement only formatted output in FOP and refactor the other outputs into a separate tool. If you need a clear differentiation between the renderer types, you might take this one: do I need to know the size of a glyph in a certain font/size to produce the output? If yes, the appropriate renderer goes into FOP, if not, it goes into a separate tool. Just my 2 cents, of course. -- Cappelino Informationstechnologie GmbH Arnd Beißner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
Victor Mote wrote: If you can convince me that it is not possible for layout and rendering to be refactored into distinct tasks or services, then my interest in FOP diminishes to zero, and I'll stop making so much noise. I don't see why that should be true. Layout and rendering can be factored into different packages of services, actually this is already done to a large extent. However, the interface is quite complex, and I don't think you can plug in the old layout engine without rewriting significant parts of it into the framework provided by HEAD. I don't follow your point about SVG. From a big-picture, abstract standpoint, why do we need to think of SVG any differently than any other graphic type? Inlined SVG code is parsed by the FOTreeBuilder. In any case, the FOTreeBuilder must have at least some knowledge about anything wich can appear in instream-foreign-object. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Bug report for Fop [2003/06/22]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 635|Opn|Nor|2001-02-18|Doesn't support id= attribute in fo:page-sequence | | 953|Opn|Nor|2001-03-12|Incorrect hyperlinks area rendering in justified t| | 1063|New|Nor|2001-03-21|fop does not handle large fo files| | 1180|New|Maj|2001-04-02|Problem with monospaced font | | 1859|Opn|Min|2001-05-22|org.apache.fop.apps.Driver.reset() doesn't fully r| | 1998|New|Nor|2001-06-05|linefeed-treatment not understood | | 2150|Ass|Maj|2001-06-13|New page with a table-header but without any tabl| | 2475|Ass|Nor|2001-07-06|Borders don't appear to work in fo:table-row| | 2740|New|Maj|2001-07-23|multi-page tables sometimes render badly | | 2909|New|Maj|2001-07-30|Gradient render error | | 2964|Ass|Nor|2001-08-02|problems with height of cells in tables | | 2988|New|Maj|2001-08-03|0.19: list-item-label does not stick to list-item-| | 3044|Ass|Maj|2001-08-08|keep-together not functioning | | 3280|New|Nor|2001-08-27|PCL Renderer doesn't work | | 3305|Opn|Nor|2001-08-28|list-block overlapping footnote body | | 3497|New|Maj|2001-09-07|id already exists error when using span=all attr| | 3824|New|Blk|2001-09-25|MIF option with tables| | 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S| | 4126|New|Nor|2001-10-12|FontState.width() returns pts instead of millipts | | 4226|New|Nor|2001-10-17|The orphans property doesn't seem to work | | 4388|New|Nor|2001-10-24|Nullpointer exception in the construction of new D| | 4415|New|Nor|2001-10-25|scaling=uniform does not work on images... | | 4510|New|Nor|2001-10-30|fo:inline common properties ignored? | | 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG | | 4614|New|Maj|2001-11-03|wrap property combined with Chinese | | 4767|New|Nor|2001-11-09|SVG text is distored in PDF output| | 5001|New|Nor|2001-11-21|content-width and content-height ignored? | | 5010|New|Enh|2001-11-21|Better error reporting needed | | 5047|Ass|Nor|2001-11-23|Dotted border style is not supported | | 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using | | 5335|Opn|Min|2001-12-10|Text with embedded CID fonts not retrievable from | | 5655|Ass|Nor|2002-01-02|text-decoration cannot take multiple values | | 6094|Opn|Maj|2002-01-29|0.20.3rc hangs in endless loop| | 6237|Opn|Nor|2002-02-05|#xFB01 (fi ligature) produces a sharp? | | 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output| | 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem| | 6437|New|Maj|2002-02-13|Tables without fo:table-column don't render | | 6483|New|Nor|2002-02-15|Table, Loop, footer could not fit on page, moving| | 6844|New|Nor|2002-03-04|No line breaks inserted in list-item-label| | 6918|New|Enh|2002-03-06|reference-orientation has no effect | | 6929|New|Nor|2002-03-06|Cells border hidden by cells background | | 6997|New|Nor|2002-03-09|Row-spanned row data breaks over a page within a c| | 7140|New|Enh|2002-03-15|page-position attribute set to last on condition| | 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on| | 7283|New|Nor|2002-03-20|Table border misaligned when using margin-left in | | 7337|New|Nor|2002-03-21|border around external image leaves empty space | | 7487|New|Nor|2002-03-26|break-before=page for table inserts empty page | | 7496|New|Nor|2002-03-26|The table header borders are not adjusted to the b| | 7525|New|Cri|2002-03-27|table with spans inside a list-block | | 7919|New|Cri|2002-04-10|problem to use attribute linefeed-treatment and li| | 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images | |
RE: startup refactoring
J.Pietschmann wrote: Victor Mote wrote: If you can convince me that it is not possible for layout and rendering to be refactored into distinct tasks or services, then my interest in FOP diminishes to zero, and I'll stop making so much noise. I don't see why that should be true. Layout and rendering can be factored into different packages of services, actually this is already done to a large extent. However, the interface is quite complex, and I don't think you can plug in the old layout engine without rewriting significant parts of it into the framework provided by HEAD. Agreed. I don't follow your point about SVG. From a big-picture, abstract standpoint, why do we need to think of SVG any differently than any other graphic type? Inlined SVG code is parsed by the FOTreeBuilder. In any case, the FOTreeBuilder must have at least some knowledge about anything wich can appear in instream-foreign-object. OK, now I follow. Yes, the difference between SVG other graphics packages would be the namespace issue. The FOTree builder needs to know what to do with the namespace. So, for a renderer-agnostic FOTree builder to work properly, it should parse the SVG create the necessary objects in the FOTree. The Renderer (this would be the workhorse object that actually renders, not the somewhat-related RenderType control object that controls) then should be responsible to either ignore it or place it into the output, depending on its capabilities. But the FOTree builder doesn't need to know or care. (At the risk of getting esoteric, if the Document object knows that none of the output options requested support SVG, it could tell the FOTree builder to ignore that namespace and save the memory. FOTree builder still doesn't need to know or care about why, it simply serves Document). Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure renderers area trees (Re: startup refactoring)
--- Arnd Beißner [EMAIL PROTECTED] wrote: Q If you need a clear differentiation between the renderer types, you might take this one: do I need to know the size of a glyph in a certain font/size to produce the output? If yes, the appropriate renderer goes into FOP, if not, it goes into a separate tool. /Q So the XSL-FO spec--which FOP is trying to implement for as many output types as possible--is not relevant for those output types which don't need to know glyph size? By putting it into a separate tool, that is what you may be implying. Glen __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
--- Victor Mote [EMAIL PROTECTED] wrote: (At the risk of getting esoteric, if the Document object knows that none of the output options requested support SVG, it could tell the FOTree builder to ignore that namespace and save the memory. That's one helluva smart document you're planning there... ;) Glen __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure renderers area trees (Re: startup refactoring)
Glen Mazza wrote: So the XSL-FO spec--which FOP is trying to implement for as many output types as possible--is not relevant for those output types which don't need to know glyph size? By putting it into a separate tool, that is what you may be implying. In a way, that's true. You need control over glyph placement (and, of course, lines, area, etc.) if you want to do a conforming implementation. I don't think you will be able to reach even basic conformance with output types HTML, RTF and MIF - expect perhaps in a very degenerate way (like creating an image for each page). With RTF (but only with a very recent version of it), you might stand a chance to reach at least roughly basic conformance. Conceptually, XSL:FO, RTF, MIF and HTML are the same thing (no nitpicking please 8-)). A renderer implementation of each of these standards produces glyphs, lines, and other low-level graphical objects that have definitive place on a medium. This is structurally some very different from converting between these language conversion. To summarize my view on this: FO-RTF, FO-MIF, FO-HTML is a conversion between similar high-level-languages where each language element has a similar corresponding language element in the destination language. FO-PDF, FO-PostScript, FO-PCL, FO-AWT are formatting processes. The formatting part is what makes up the primary goal and especially most of the complexity of FOP. How about seeing things from this perspective: transformation of XSL:FO to RTF, MIF and HTML could be done using an XSLT stylesheet (provided that you create a trivial XML representation of RTF and MIF first, of course). That stylesheet would be complex, of course, but on the 'possible side', because these transformations fundamentally are tree transformations of the same kinds of things. What can be shared between conversion and formatting beside the things I already mentioned? I think you can forget almost everything about fonts, the layouters, the area tree. How does this sound to you? -- Cappelino Informationstechnologie GmbH Arnd Beißner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure renderers area trees (Re: startup refactoring)
--- Arnd Beißner [EMAIL PROTECTED] wrote: Glen Mazza wrote: So the XSL-FO spec--which FOP is trying to implement for as many output types as possible--is not relevant for those output types which don't need to know glyph size? By putting it into a separate tool, that is what you may be implying. In a way, that's true. You need control over glyph placement (and, of course, lines, area, etc.) if you want to do a conforming implementation. I don't think you will be able to reach even basic conformance with output types HTML, RTF and MIF - We don't do HTML at all (Xalan's department)-- HTML is browser dependent. HTML is not an output format. I don't know MIF, so can't comment on it. 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. To summarize my view on this: FO-RTF, FO-MIF, FO-HTML is a conversion between similar high-level-languages where each language element has a similar corresponding language element in the destination language. FO-PDF, FO-PostScript, FO-PCL, FO-AWT are formatting processes. 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. How about seeing things from this perspective: transformation of XSL:FO to RTF, MIF and HTML could be done using an XSLT stylesheet (provided that you create a trivial XML representation of RTF and MIF first, of course). Certainly with HTML, it's done all the time; I suspect you're also correct with RTF. __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure renderers area trees (Re: startup refactoring)
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]
Re: Structure renderers area trees (Re: startup refactoring)
Arnd Beissner wrote: determined a formatting-time if you can't hand over the Correction, this typo can be misleading: determined at formatting-time if you can't hand over the -- Cappelino Informationstechnologie GmbH Arnd Beißner Bahnhofstr. 3, 71063 Sindelfingen, Germany Email: [EMAIL PROTECTED] Phone: +49-7031-463458 Fax: +49-7031-463460 Mobile: +49-173-3016917 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: startup refactoring
Glen Mazza wrote: --- Victor Mote [EMAIL PROTECTED] wrote: (At the risk of getting esoteric, if the Document object knows that none of the output options requested support SVG, it could tell the FOTree builder to ignore that namespace and save the memory. That's one helluva smart document you're planning there... ;) Just to clarify -- I don't intend to write such logic, or even suggest that it would be a good thing. The only point that I am trying to make is that if you get the control objects lined up right you can make the whole thing pretty sophisticated flexible, and still maintain Separation of Concerns. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Structure renderers area trees (Re: startup refactoring)
Le Dimanche, 22 juin 2003, à 21:15 Europe/Zurich, Arnd Beißner a écrit : ...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? Probably not, XSL-FO is clearly meant for page output and RTF and MIF (unless abused in strange ways) are document formats, not page formats. 2. Are there really two different groups of output formats and does it really make sense to support both in one tool (FOP) There are definitely two groups, and I agree with you that All of the stuff needed for FO-RTF or FO-MIF conversion is pretty straightforward stuff The whole point of the StructureHandler interface is to be able to reuse FOP's frontend for structure-based renderers. The impact of StructureHandler on the standard FOP output formats (PDF mostly) is minor, but it allows the FOP pipeline to branch cleanly, after the parsing and attributes resolution, to generate either structure-based or page-based formats. Besides sharing code, the advantage in RTF and similar output formats being developed as part of FOP is the community: one project with more audience instead of several, each with a smaller audience. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
