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