xsl-list
[Top] [All Lists]

RE: xsl-fo header problems

2003-04-22 12:54:12
At 2003-04-22 13:03 +0100, David(_dot_)Pawson(_at_)rnib(_dot_)org(_dot_)uk 
wrote:
The request was to get the marker from 'the previous page heading'
(i.e. the static content of the previous page) IIRC?

Yes, I think you recall correctly about the symptom, but one doesn't retrieve markers "from the static content". I'm thinking his problem is a subsequent page's static content is not retrieving a marker from flow flowed on an earlier page.

I intrepreted the requirement to be to maintain the section title
as header until it changed?

As did I.

However, playing with the retrieve-marke options shows up some really
strange values.

Oh?

The rec is about as clear as mud in  this area.

I've not had any issues with this, which isn't to say it isn't clear to all readers, but I'm not sure where you are having concerns.

Within page, picking up first and last (dictionary style)
works. But within page-sequence I simply can't get it.

I read it as merely looking back in the flow towards the beginning of the page sequence until a given marker is found.

See if Mike clarifies just what he wanted.

Yes ... but I have heard from FOP users that FOP does not retrieve anything not on the given page, in contravention of retrieve-boundary="page-sequence" (which happens to be the default).

You also said:

Readers should note, however, that my placing of the marker in only the
first block instead of in a block that wraps the other blocks associates
the marker with *only* the first block ... the combination of
retrieve-boundary="page-sequence" and
retrieve-position="first-starting-within-page" means the above will work
without having to do the wrapping.  When dealing with the last block for a
marker, you must wrap the set of blocks with a block with the marker being
the first child of the wrapper block.

Yes, and I stand by it!  :{)}

Sorry Ken. I don't understand this.

Ouch.  I'm sorry it didn't make sense.

You keep referring to (your book p206/7) parents of markers,
I guess you mean other markers, as in nested markers?

No, not at all. The <block> parent of the <markers>. Looking at the diagram on page 207, see how the "A", "B", and "C" <marker> elements are all the first children of their respective parent blocks?

AFAIK the rec talks about only children of a marker being retrieved?

Correct.

I.e. not content in parents of markers?

Correct. But looking at my quote above you'll see I'm not talking about retrieval ... the markers are *associated* with the contents of the parent of the marker, hence the need for the wrapping block, and as the marker must be the first child, I usually just use a simple block to wrap the bunch.

Note on the bottom of page 205 "the marker's parent's total area is called a "qualifying area", and thus the marker is associated with all of the marker's parent's areas. On page 206 I state "A maker must either be the first child of its parent object, or only have other sibling markers before it", thus following the rule repeated often in the Rec (as in 6.5.2 below the content model syntax in "Contents") and summarized in 6.11.3 as: "The fo:marker has to be an initial child of its parent formatting object."

The diagram on page 207 shows how each marker is the first child element of each block, and looking at the bottom areas in the area tree, how the areas produced by the parent blocks all have their respective markers associated with them. Remember from the drawing on page 55 and the description at the top of page 57 that the children of the root node in the area tree are pages, so on page 207 you can see how the "A" marker is associated with areas on three separate pages, the "B" marker is on one page, and the "C" marker is on two pages.

Having followed the Recommendation to associate a given marker with multiple areas possibly on multiple pages, one can then specify using retrieve-position= which area with a marker to use and with retrieve-boundary= how far back in the pages to look.

Quite a classy design, I thought when I read it. I think James Tauber was behind that one, but I'm not positive.

 Thanks Ken.
regards DaveP

I'm sorry the above detail in the book wasn't readily apparent to you, but it was honed based on questions and comments from my instructor-led deliveries of this chapter and I think it is all there and accessible. Students needed to see the area tree and how the markers were associated and why the marker has to be the first of its parent area in order to be associated with all of its parent's descendants ... the drawing came out of a sketch I made in front of the students that helped the students understand.

Please let me know if you find any other areas of the book need more explaining. Meanwhile, I'll see if anything more can be added to the next release of the electronic edition (BTW, the Fourth Edition of the electronic rendition was released a couple of weeks ago; everyone who bought a copy should have already been informed of their free update).

If you have the time, please let me know what it was in the book that led you astray. And that offer goes to all customers of the books, as changes will be made available to the customers of the electronic edition through the perpetual free updates. If your company has a site-wide or world-wide license for the electronic rendition, and you haven't been given access to the latest April 2003 edition, please contact them ... they should have received their update notices a while ago.

Thanks, Dave, for the feedback!

............................. Ken

--
Upcoming hands-on courses:   Europe (XSLT/XPath):    May  5, 2003
-                            Europe (XSL-FO):        May 16, 2003
- (XSLT/XPath and/or XSL-FO) North America:      June 16-20, 2003

G. Ken Holman                mailto:gkholman(_at_)CraneSoftwrights(_dot_)com
Crane Softwrights Ltd.         http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0   +1(613)489-0999 (F:-0995)
ISBN 0-13-065196-6                      Definitive XSLT and XPath
ISBN 0-13-140374-5                              Definitive XSL-FO
ISBN 1-894049-08-X  Practical Transformation Using XSLT and XPath
ISBN 1-894049-10-1              Practical Formatting Using XSL-FO
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/s/bc


XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list



<Prev in Thread] Current Thread [Next in Thread>