[xep-support] A3 pages and Landscape Pages

Tue Jun 15 08:46:08 PDT 2004

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 at CraneSoftwrights.com>
Sent by: owner-xep-support at renderx.com
11/06/2004 17:11
Please respond to xep-support

        To:     xep-support at renderx.com
        cc: 
        Subject:        Re: [xep-support] A3 pages and Landscape Pages

At 2004-06-11 15:15 +0100, Douglas_Morrison at 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 at 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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.renderx.com/pipermail/xep-support/attachments/20040615/899e3b08/attachment.html>