Re: Reverting changes in AFP Renderer
Reply below.. Jeremias Maerki wrote: I'm not sure I follow you. Do you mean that you'd always maintain the transformation stack in the renderer? That's certainly something that needs to be done in a uniform way. Yes, a base renderer/painter could maintain both the transformation stack and common palette state features (paint color, brush thickness, font etc) as it traverses the block levels within the area tree. For PDF/PS/Java2D you'd still always apply any transformation to the output formats. For PCL (and probably AFP) you wouldn't do that (because you can't) but instead apply the current transformation to any coordinate that needs to be accessed in a uniform way. Is that it? If yes, you could simply pull up the graphicContext and graphicContextStack fields from PCLRenderer and establish that pattern for all subclasses. Could these coordinate transformations not be done by FOP as it is rendering the output file rather than delegating responsibility of performing these transformations to the PDF/PS interpreter? With this approach, the same rendering mechanism could be shared amongst renderers, just the absolute coordinates would be provided in the output file and not a series of matrices with which to derive the coordinates. This should result in printing/displaying being a little faster as the output format interpreter would be saved from having to do as many matrix calculations at runtime, also the resulting output file would be smaller for each document. Hope you follow my thinking. Adrian.
Re: More ideas for configuration/extension?
On Feb 27, 2008, at 16:21, Adrian Cumiskey wrote: For either my suggestion or Andreas' further proposal we would certainly need to do a little bit of refactoring, abstracting out all those member config variables in FopFactory into a base configuration object. This base configuration object would be a singleton and *unmodifiable* and would only serve the function of providing the default fallback configuration settings Yep, that's what I meant. The configuration of the FopFactory would only be used if there is no override at the level of the UserAgent/ Document (or even elsewhere?). It would indeed be immutable. The intention is not to mess with the settings here, but more to keep those settings, and *if* a user specifies overriding config-settings, to create a temporary config that provides the overrides. A second user agent configuration object would be created per user agent, this configuration would be modifiable. The user agent configuration would derive configuration values from the base configuration when values were not provided programmatically through API on the fly. A third configuration object could represent the document level configuration. This would be created on construction of the FO tree and it would derive its default values from the user agent configuration which in turn would derive its values (in their absence) from the base configuration. Hope I explained how that would work clearly enough, does that make sense? Yes it does, more or less. I hadn't really considered details yet, but I guess I'd see it as a stack of configurations, where the top of the stack is always consulted first. The FopFactory config would be the bottom. This scoping seems a little bit too clever for me ;-). Heh, I get that a lot... :-) I'm not sure how useful this use case would be. I think its useful enough to just have a document level configuration defined within the fo:declarations. Well, it could be handy if the user knows in advance, for example, that there is one block in the entire document where he has a table that does not adhere 100% to the XSL-FO Rec. Of course, we're all inclined to say that the stylesheet should be adapted in that case, but that is not always as easily said as it is done... Being able to override strict-validation for just one block would offer immediate relief, where changing the stylesheet could take multiple days or weeks, depending on who is the owner/maintainer. Being able to override the base-url would probably at most be neat for the page-sequence level. Bummer about the fo:declarations is that it always appears after the fo:layout-master-set, and some settings apply to the latter (page- width or -height fallback). Cheers Andreas
Re: future renderer design (was: Reverting changes in AFP Renderer)
On 27.02.2008 17:09:49 Adrian Cumiskey wrote: Reply below.. Jeremias Maerki wrote: I'm not sure I follow you. Do you mean that you'd always maintain the transformation stack in the renderer? That's certainly something that needs to be done in a uniform way. Yes, a base renderer/painter could maintain both the transformation stack and common palette state features (paint color, brush thickness, font etc) as it traverses the block levels within the area tree. For PDF/PS/Java2D you'd still always apply any transformation to the output formats. For PCL (and probably AFP) you wouldn't do that (because you can't) but instead apply the current transformation to any coordinate that needs to be accessed in a uniform way. Is that it? If yes, you could simply pull up the graphicContext and graphicContextStack fields from PCLRenderer and establish that pattern for all subclasses. Could these coordinate transformations not be done by FOP as it is rendering the output file rather than delegating responsibility of performing these transformations to the PDF/PS interpreter? Only to a certain extent. For painting text, you still have to write a text matrix (Tm) to the output format because otherwise, you'd have to paint the text using shapes which is not what we want. And for painting nested graphics you'd also have no other way than to establish new coordinate systems in the output format because you may not have full control over what plug-ins do in terms of painting code production (EPS, for example). At any rate, I'd find it unfortunate if we didn't make use of some of the basic features of such document formats. With this approach, the same rendering mechanism could be shared amongst renderers, just the absolute coordinates would be provided in the output file and not a series of matrices with which to derive the coordinates. This should result in printing/displaying being a little faster as the output format interpreter would be saved from having to do as many matrix calculations at runtime, also the resulting output file would be smaller for each document. Hope you follow my thinking. I don't buy the faster and smaller argument. The smaller maybe to a very small extent. You'd still have to write many transformation matrices to the output format. And these will be more complex (and more difficult to debug) if they are always combined with all previous transformations. You'd only save a bit if you have many fixed positioned block-containers (break-out restore). Concerning the performance aspect, the critical parts are the parsing of the intermediate format, handling nested graphics and font embedding, not the renderer itself. Whether you do the transformation inside FOP or in the output format I don't expect a significant change in performance. Or did you do some profiling that would lead you in this direction? Jeremias Maerki
