Comments inline...actually, no, they're not, they are really block-stacking, but you get the drift. :-)
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Karen Lease > Sent: May 2, 2002 7:21 PM > To: [EMAIL PROTECTED] > Subject: Re: [REDESIGN] Line layout manager discussion > > Arved, Keiron et. al. > > I guess logically it's true that the blocks nested in inlines should be > wrapped in inline areas, but it makes me nervous :-) > At least they cause line breaks, that much seems sure. Good...if we all agree with that then I think it is the main point gotten out of the way, because every other situation has to do with child FOs all being inline or block-level, for which the results are less dubious. > I still think > that we should put pressure on the spec editors to either get rid of > structure or clarify it in the next version (ha, ha). If people need > blocks in inlines, they have inline-container. > > In fact, I'd like to think that the possibility of including block-level > FOs in inline-level FOs is purely for convenience or "semantic nesting" > and should not really affect the area tree, except to cause line breaks > before and after the block areas. > > The most legitimate use I can see for this kind of semantic nesting is > basic-link, because it could spread the link semantics over several > areas; kind of a link-wrapper. The main thing is, let's make sure that we have agreement (codified through use of these diagrammed examples) on all matters that affect placement. I understand that we want to have a warm fuzzy about our understanding of the spec, but that's not going to happen with everything. To be precise, if I can get a number of these examples created, what we can do is identify situations where we can say, this one is 100% solid (we know this is right, there is no uncertainty in the spec), this one is iffy (there may be small inconsistencies between our placement and what the spec authors intended), or this one is problematic (contradictions, for example). Once we have classified the examples, we can do damage control on the uncertain ones. Namely, let's do it this way, but let's be aware that things could be interpreted another way, and if so, how heavily committed are we in our code? On a related matter when it comes right down to brass tacks I am really only concerned about placement (accuracy of rendering). Both with Fop and with my other project I find it easier to use the conceptual areas, and I get the sense that others also feel this way, but let's face it, as long as our final result is consistent it doesn't really matter if our internal structures deviate. > ------------- > > For the record, I disagree with Arved's reading of Line-Building. I read > 4.7.2, point 5 as saying that a block area generated by an fo:block can > contain a mixture of block areas and line areas. On this particular point I think we are fortunate insofar as it is not going to affect placement. > Also, if we look at 4.7.3 (inline-building), I find it curious that it > starts by saying TWICE that an inline FO places inline areas and anchor > inline areas returned by its child FOs in inline areas which it > generates, and then suddenly throws a block-area into the condition > described in point 1. Looks more like a hasty copy/paste from the list > for Line-building! > > As Keiron says, if the spec writers had been clearer, we wouldn't have > to spend hours chasing our tails like this! I find the transitions from relatively formal set-oriented treatments to casual prose disconcerting. As soon as I see formal then my Pedant-O-Meter cranks way up, and I find it hard to switch off. :-) > Regards, > Karen > > Arved Sandstrom wrote: > > > [SNIP] > > > > _If_ there were blocks nested inside the top-level block these > would produce > > normal block areas that are single children of normal block > areas produced > > by the top-level block. My reading of Line-Building is that normal block > > areas generated by a fo:block have either _single_ block areas > _or_ one or > > more line areas as children, not a mixture. > > > > Final comment: it is the close intermingling of inlines and > blocks in this > > example that causes so much line breaking. Clearly each of the 2 nested > > blocks could be wrapped in inlines (fo:inline or whatever), and > as a result > > everything in the example, in theory, could be in _one_ line area. > > > > Anyhow, please critique away. :-) > > > > Regards, > > Arved --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
