Comments inline. > -----Original Message----- > From: Tony Graham [mailto:[EMAIL PROTECTED] > Sent: February 24, 2003 10:26 AM > To: [EMAIL PROTECTED] > Subject: RE: markers in redesign > > > Arved Sandstrom wrote at 24 Feb 2003 08:01:40 -0400: > > Comments below. > > > > > -----Original Message----- > > > From: Peter B. West [mailto:[EMAIL PROTECTED] > > > Sent: February 24, 2003 6:53 AM > > > To: [EMAIL PROTECTED] > > > Subject: Re: markers in redesign > > > > > [ SNIP ] > > > > > It seems to me that the "hierarchy" is not the same as the > area tree or > > > fo tree hierarchy. It is a unique hierarchy constructed by > applying the > > > constraints on the qualifying areas. The boundary conditions impose > > > absolute constraints - violate one and you are out. But the other > > > conditions are not absolute, and they, along with actual page for > > > multi-page boundaries, are used to construct the hierarchy. > > > > Yes, that's my interpretation. Precisely so. It is tempting to confuse > > "hierarchy" for "tree". But the language of the spec in regard > of markers > > defines a different hierarchy, one which happens to map > closely to the area > > tree, but is highly filtered. > > It's not just areas. fo:wrapper 'does not generate any areas', but > also 'may always have a sequence of zero or more fo:markers as its > initial children.'
No, you're quite right, Tony, fo:wrapper does not generate areas. But it _returns_ areas, assuming that its children do (there are presumably some pathological cases), and those areas are what markers act on. "wrapper" is transparent. I may have missed your point on this. > ... > > The thing that bugs me is, when there is no qualifying area in the > > "containing page" (Note to spec editors: try saying currently-formatted > > page), after filtering, then it becomes anarchy. It seems like user > > I wasn't there when the spec was written, but it seems to me that > 'currently-formatted page' presupposes making pages on the fly and > doesn't quite describe pages that are unbounded in one or both > directions (i.e. where there is only ever one page) and also doesn't > describe the possible processing model of making all the pages from > the fo:flow and then going back and fixing up the static content. OK, you've got me here. :-) I fall into the trap of ignoring "media-usage" too frequently. So the point is well taken. Regarding the second point, that processing model ignores an "error-if-overflow" value for "overflow"; process a thousand pages and then only afterwards find out that you ought to have aborted with a message? Regards, Arved --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
