On Tue, 2002-05-28 at 01:20, Peter B. West wrote: > < > I started writing this before the flurry of messages in the last day or > two, so it may now be redundant. If so, however, I have missed part of > the conversation. My recollection of consensus of opinion some months > ago was as I state just below. > > > > I think you will still have attribute resolution problems. Remember > that some attributes are only going to be resolved during the layout.
The layout is handled by the viewer of the document. All we can do is transfer across the flow and other information. For properties that depend on the layout then they either need to be transferred to the output document in a meaningful way, translated or ignored (default value). I would like to have a look at how the MIF handler would work with this but I don't have a viewer so it is a bit difficult (does anyone have access to a viewer?). > It seems to me that the general solution would involve the definition of > a structure api, taking account of the layout dependencies. to get > there, you need to define an XML equivalent of the structure that is > presented to the RTF renderer. Define all of the data types that are > being passed into RTF, and isolate the circumstances in which > information cannot be passed across prior to layout. Out of that you > might get three interface definitions: ideal RTF, layout RTF and FOTree > RTF. With any luck, ideal RTF would co-incide completely with layout > RTF, and differ only in a few minor details from FOTree RTF. If we do a parallel layout and resolve the properties that cannot be transferred at the same time then it may give a better result. I guess it would depend on circumstances and if it is really worth it. I don't know the 'use cases' so it would only be a guess. > Then have the same thing done for, say, MIF. From a comparison of the > layout MIF and FOTree MIF, try to develop a general FOStructure API > which will hopefully be flexible enough to accommodate any other > structure renderers which come along. The danger in not doing that is > that you end up with an FOStructure API that is only an RTFStructure API. > > It may be necessary to build in a fundamental option to choose, e.g., > layout RTF or FOTree RTF. In the latter case, the User Agent would > arbitrate unresolved arrtibutes; in the former, the layout engine would > have to proceed far enough to resolve all of the attributes. One > possibility in the former case is that you _may_ find it is possible to > do the transformation to FOTree RTF in XSLT. Just a flight of fancy > perhaps. > > You may already have documented the structure transformations needed for > FO->RTF. If so, it would be a very good idea to include them in the NEW > DESIGN documentation. > > Peter --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
