<br><font size=2 face="sans-serif">Ken,</font>
<br>
<br><font size=2 face="sans-serif">Thanks very much for that reply - it
has helped to clarify the issues involved.</font>
<br>
<br><font size=2 face="sans-serif">I agree that there is a problem knowing
what to do with various attributes on the blocks. In the case of Docbook
xsl (from Norman Walsh) the only attribute on the block element is the
id attribute. I am not quite sure what use is made of it, but for my application
I don't think it would matter of the block was removed. In the xsl exported
by Arbortext Styler I am not sure what the full range of attributes could
be, but none that I have seen are essential for my purposes (as far as
I know).</font>
<br>
<br><font size=2 face="sans-serif">If I remove the blocks, the output form
the xslt will be something like:</font>
<br>
<br><font size=2 face="sans-serif"><fo:page-sequence</font>
<br><font size=2 face="sans-serif"> <fo:flow</font>
<br><font size=2 face="sans-serif"> A</font>
<br><font size=2 face="sans-serif"> <fo:page-sequence</font>
<br><font size=2 face="sans-serif">
<fo:flow</font>
<br><font size=2 face="sans-serif">
B</font>
<br><font size=2 face="sans-serif">
</fo:flow</font>
<br><font size=2 face="sans-serif"> </fo:page-sequence</font>
<br><font size=2 face="sans-serif"> C</font>
<br><font size=2 face="sans-serif"> </fo:flow</font>
<br><font size=2 face="sans-serif"></fo:page-sequence</font>
<br>
<br><font size=2 face="sans-serif">What I was suggesting was that the W3
standard ought to allow such nesting. It would then be up to XEP to extract
three parts to make three sibling page concepts. So it would then not be
an xslt problem, but the far preferable "someone else's problem"!</font>
<br>
<br><font size=2 face="sans-serif">However there would still be issues
with some page-sequence attributes (eg force-page-count) that would need
to be addressed. XEP could also handle nesting within fo:blocks provided
the interpretation of attributes were consistent with user requirements
- which may or may not be a problem.</font>
<br>
<br><font size=2 face="sans-serif">To be really general, the transitions
to different page geometries should not have to be symmetrically placed
in the source xml. Modifying your example, the source could be</font>
<br>
<br><font size=2><tt> <block<br>
A<br>
<block<br>
B<br>
<block<br>
C<br>
<?switchpage master-reference="A3Landscape"/><br>
<block<br>
X<br>
</block<br>
<block<br>
Y<br>
</block<br>
<block<br>
Z<br>
</block<br>
D<br>
</block<br>
E<br>
</block<br>
<?switchpage master-reference="A4Portrait"/><br>
F<br>
</block<br>
</tt></font>
<br><font size=2 face="sans-serif">Furthermore, the actual transition could
even be mid-block. An attribute of the switchpage pi could say "carry
on writing to the current page, but when that is full, change to the new
pageset and continue writing into that". I anticipate that there could
be implementation problems, and there may be other strong objections.</font>
<br>
<br><font size=2 face="sans-serif">As it may be some time before W3 and
XEP allow such nesting, I think my best way forward may well be to remove
the unecessary blocks and emit a psmi:page-sequence and use your ingenious
solution. The output from the first xslt pass would then be something
like:</font>
<br>
<br><font size=2 face="sans-serif"><fo:page-sequence</font>
<br><font size=2 face="sans-serif"> <fo:flow</font>
<br><font size=2 face="sans-serif"> A</font>
<br><font size=2 face="sans-serif"> <psmi:page-sequence
master-reference="A3Landscape"/></font>
<br><font size=2 face="sans-serif"> B</font>
<br><font size=2 face="sans-serif"> <psmi:page-sequence
master-reference="A4Portrait"/></font>
<br><font size=2 face="sans-serif"> C</font>
<br><font size=2 face="sans-serif"> </fo:flow</font>
<br><font size=2 face="sans-serif"></fo:page-sequence</font>
<br>
<br><font size=2 face="sans-serif">And then the above would be transformed
using your wonderful psmi.xsl.</font>
<br>
<br><font size=2 face="sans-serif">Regards, Doug x2571</font>
<br>
<br><font size=2 face="sans-serif">The content of this message is Applied
Materials Confidential. If you are not the intended recipient and
have received this message in error, any use or distribution is prohibited.
Please notify me immediately by reply e-mail and delete this message
from your computer system. Thank you.</font>
<br>
<br>
<br>
<br>
<table border width=100%>
<tr valign=top>
<td>
<br>
<br>
<br><font size=1 face="sans-serif"><b>"G. Ken Holman" <gkholman@CraneSoftwrights.com></b></font>
<br><font size=1 face="sans-serif">Sent by: owner-xep-support@renderx.com</font>
<br><font size=1 face="sans-serif">11/06/2004 17:11</font>
<br><font size=1 face="sans-serif">Please respond to xep-support</font>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To:
xep-support@renderx.com</font>
<br><font size=1 face="sans-serif"> cc:
</font>
<br><font size=1 face="sans-serif"> Subject:
Re: [xep-support] A3 pages and Landscape
Pages</font>
<br><font size=2 face="sans-serif">
</font></table>
<br>
<br>
<br><font size=2><tt>At 2004-06-11 15:15 +0100, Douglas_Morrison@contractor.amat.com
wrote:<br>
>Thanks very much for that suggestion. One problem for me is the <br>
>requirement to insert the psmi marker as a direct child of fo:flow.
The <br>
>xsl I am using could put in several nested fo:blocks before reaching
the <br>
>element that requires the change in page geometry. I'm not sure how
to get <br>
>round that.<br>
><br>
>It seems to me the best solution would be to allow nested pagesets
and <br>
>process them accordingly. Why not?<br>
<br>
Consider the situation where one has nested blocks and the need for a page:<br>
<br>
<block<br>
A<br>
<block<br>
B<br>
<block<br>
C<br>
<page<br>
<block<br>
X<br>
</block<br>
<block<br>
Y<br>
</block<br>
<block<br>
Z<br>
</block<br>
</page<br>
D<br>
</block<br>
E<br>
</block<br>
F<br>
</block<br>
<br>
In the object hierarchy, "D", "E" and "F"
have the same properties as "A", <br>
"B", and "C". Would that imply the same kinds
of blocks in the <br>
newly-created page sequence? If so, what happens to those properties
of <br>
the blocks that apply at the start of the block (initial property set,
<br>
space-before, etc.)? Padding? backgrounds?<br>
<br>
And if that were all determined, what would the XSLT be to extract the
<br>
three parts above into three sibling page concepts ... the recursive-call
<br>
requirements are, I believe, doable but very awkward and not easily <br>
generalizable.<br>
<br>
I've assessed that "process them accordingly" is untenable and
messy in the <br>
general case .... I'd be interested to hear proposals for general solutions
<br>
to such situations.<br>
<br>
..................... Ken<br>
<br>
--<br>
Public training 3 days XSLT & 2 days XSL-FO: Phoenix,AZ 2004-08-23<br>
World-wide on-site corporate, govt. & user group XML/XSL training.<br>
G. Ken Holman mailto:gkholman@CraneSoftwrights.com<br>
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/f/<br>
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995)<br>
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/f/bc<br>
Legal business disclaimers: http://www.CraneSoftwrights.com/legal<br>
<br>
-------------------<br>
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'<br>
in the body of the message to majordomo@renderx.com from the address<br>
you are subscribed from.<br>
(*) By using the Service, you expressly agree to these Terms of Service
http://www.renderx.com/tos.html<br>
</tt></font>
<br>