From: Bob Stayton (bobs@sagehill.net)
Date: Tue Jun 15 2004 - 10:24:35 PDT
Just a note to mention that if you remove the id attribute, then any bookmark or cross reference that points to that element will no longer work in the PDF.
Bob Stayton
Sagehill Enterprises
DocBook Consulting
bobs@sagehill.net
----- Original Message -----
From: Douglas_Morrison@contractor.amat.com
To: xep-support@renderx.com
Sent: Tuesday, June 15, 2004 8:46 AM
Subject: Re: [xep-support] A3 pages and Landscape Pages
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 - 10:37:37 PDT