Hi Ken.
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?
Guessing that the circles are blocks? Then yes. I'm OK with that.
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,
which never made sense, since an empty marker isn't much use.
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.
Yep. Up to either page or page-sequence or document.
No problem there.
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.
Mmm. No you lost me there. There's no statement of the qualifying
area for the diagram, and the 3 pages?? to the left (text says 4 btw)
dont' seem to align with the tree diagram?
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.
Sorry Ken no. Selecting content (children of markers),
I've always associated with the transform stage, hence I've never
had hundreds of markers to choose from (or even 3 :-)
I had a real job making an example that picked an overflow area
from the previous page, but finally managed it (what a daft name,
first-including-carryover :-) Picking content from the current
page-sequence,
I really can't see any use for it.
I've chosen content from the source document (section/chap titles etc),
but from the current page-sequence? Why might that be necessary.
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.
Having created some false examples, I'm clearer, but still
prefer to select from source document content, letting the formatter
pick the appropriate one relative to the current page.
Quite a classy design, I thought when I read it. I think
James Tauber was
behind that one, but I'm not positive.
I like the idea of running headers,
though the syntax (and description?) could do with improvement IMO.
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.
Then I guess I'm missing the lecture that went behind those notes :-)
regards DaveP.
-
NOTICE: The information contained in this email and any attachments is
confidential and may be legally privileged. If you are not the
intended recipient you are hereby notified that you must not use,
disclose, distribute, copy, print or rely on this email's content. If
you are not the intended recipient, please notify the sender
immediately and then delete the email and any attachments from your
system.
RNIB has made strenuous efforts to ensure that emails and any
attachments generated by its staff are free from viruses. However, it
cannot accept any responsibility for any viruses which are
transmitted. We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent those of RNIB.
RNIB Registered Charity Number: 226227
Website: http://www.rnib.org.uk
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list