From: Douglas_Morrison@contractor.amat.com
Date: Tue Jun 15 2004 - 08:46:08 PDT
Ken,
Thanks very much for that reply - it has helped to clarify the issues
involved.
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).
If I remove the blocks, the output form the xslt will be something like:
<fo:page-sequence
<fo:flow
A
<fo:page-sequence
<fo:flow
B
</fo:flow
</fo:page-sequence
C
</fo:flow
</fo:page-sequence
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"!
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.
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
<block
A
<block
B
<block
C
<?switchpage master-reference="A3Landscape"/>
<block
X
</block
<block
Y
</block
<block
Z
</block
D
</block
E
</block
<?switchpage master-reference="A4Portrait"/>
F
</block
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.
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:
<fo:page-sequence
<fo:flow
A
<psmi:page-sequence master-reference="A3Landscape"/>
B
<psmi:page-sequence master-reference="A4Portrait"/>
C
</fo:flow
</fo:page-sequence
And then the above would be transformed using your wonderful psmi.xsl.
Regards, Doug x2571
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.
"G. Ken Holman" <gkholman@CraneSoftwrights.com>
Sent by: owner-xep-support@renderx.com
11/06/2004 17:11
Please respond to xep-support
To: xep-support@renderx.com
cc:
Subject: Re: [xep-support] A3 pages and Landscape Pages
At 2004-06-11 15:15 +0100, Douglas_Morrison@contractor.amat.com wrote:
>Thanks very much for that suggestion. One problem for me is the
>requirement to insert the psmi marker as a direct child of fo:flow. The
>xsl I am using could put in several nested fo:blocks before reaching the
>element that requires the change in page geometry. I'm not sure how to
get
>round that.
>
>It seems to me the best solution would be to allow nested pagesets and
>process them accordingly. Why not?
Consider the situation where one has nested blocks and the need for a
page:
<block
A
<block
B
<block
C
<page
<block
X
</block
<block
Y
</block
<block
Z
</block
</page
D
</block
E
</block
F
</block
In the object hierarchy, "D", "E" and "F" have the same properties as "A",
"B", and "C". Would that imply the same kinds of blocks in the
newly-created page sequence? If so, what happens to those properties of
the blocks that apply at the start of the block (initial property set,
space-before, etc.)? Padding? backgrounds?
And if that were all determined, what would the XSLT be to extract the
three parts above into three sibling page concepts ... the recursive-call
requirements are, I believe, doable but very awkward and not easily
generalizable.
I've assessed that "process them accordingly" is untenable and messy in
the
general case .... I'd be interested to hear proposals for general
solutions
to such situations.
..................... Ken
-- Public training 3 days XSLT & 2 days XSL-FO: Phoenix,AZ 2004-08-23 World-wide on-site corporate, govt. & user group XML/XSL training. G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/f/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) Male Breast Cancer Awareness http://www.CraneSoftwrights.com/f/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal ------------------- (*) To unsubscribe, send a message with words 'unsubscribe xep-support' in the body of the message to majordomo@renderx.com from the address you are subscribed from. (*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html ------------------- (*) To unsubscribe, send a message with words 'unsubscribe xep-support' in the body of the message to majordomo@renderx.com from the address you are subscribed from. (*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html
This archive was generated by hypermail 2.1.5 : Tue Jun 15 2004 - 09:06:23 PDT