[xep-support] Clarrification Needed: Implications of writing mode on region-body

From: W. Eliot Kimber (eliot@isogen.com)
Date: Wed Mar 12 2003 - 06:48:00 PST

  • Next message: Wick Swain: "[xep-support] A couple of newbie questions"


    There is disagreement between XSL Formatter and XEP over the implication
    of setting writing-mode on region-body and my reading of the spec cannot
    find a clear justification for either interpretation.

    In section 7.27.7, the definition of the writing-mode property, the spec

    o When "writing-mode" is applied to the fo:region-*, it defines the
    column-progression within each region. The inline-progression-direction
    is used to determine the stacking direction for columns (and the default
    flow order of text from column-to-column).

    o To change the "writing-mode" within an fo:flow or fo:static-content,
    either the fo:block-container or the fo:inline-container, as
    appropriate, should be used.

    With XEP, setting writing-mode on region-body only changes the positions
    of the columns on the page--it does not affect the writing mode of the
    areas within the flow contained within the region body.

    With XSL Formatter, the writing mode is propogated to the areas within
    the region body.

    XEP's approach is supported by two pieces of evidence I can find:

    - The fact that different page masters can have different writing modes
    for region-body, which would only make sense if the intent is to only
    affect the position of columns (enabling inside/outside column position
    layouts, which are otherwise impossible to achieve with XSL-FO 1.0).

    - The two bullets above, which can be read as limiting the affect of
    writing mode on simple-page-master and region-body, effectively creating
    a special case that overides the normal propogation rules for the
    writing-mode property (that is, that the writing mode of a containing
    reference area (region-body) determines the writing mode of normal areas
    within that reference area (areas within the flow)).

    XSL Formatter's approach is supported by the fact that writing-mode is
    set on reference areas and that there is no other direct way to set the
    writing mode on a page sequence or flow except to set it on the
    body-region (which is the nearest ancestor reference area for the flow
    areas). The only other way to do it would be to put the entire flow into
    a block-container that sets the writing mode [see note below]. Also, the
    two bullets above do not explicitly say that they are defining the
    *only* effects of writing-mode when specified on simple-page-master or
    region-body, so they can be read as defining *additional* implications
    in addition to the normal implication of writing-mode on reference areas.

    Thus, my question is this:

    Does setting writing-mode on simple-page-master or region-* affect
    *only* the placement of page regions or columns or does it also
    determine the default writing mode of any contained areas?

    If I hadn't thought about the implications of writing mode being
    different for different page masters or body regions within a page
    sequence, I would have assumed that writing mode on page masters or page
    regions sets the writing mode for their contained areas (XSL Formatter's
    interpretation), but the fact that one could have different writing
    modes on different page masters calls this into question, since the only
    reason for having different writing modes on different pages would be to
    control area and column position but not text writing mode (since one
    would not normally want writing mode to change based on the chance break
    of a page and if you really needed to control writing mode that closely
    you could use block containers within the flow).

    Note that requiring a root-level block-container to set writing mode
    would seriously complicate the markup for multi-column layouts that
    require column spanning (which is all of them in my experience), as you
    would have to intersperse flow-child block containers with flow-child
    blocks with span="all". This would make generation of flow content quite
    difficult at best.

    This analysis suggests either that XSL Formatter's interpretation is
    correct (root-level block-container not required to set flow-level
    writing mode) or that the spec is underspecified and should provide a
    way to set writing mode for the flow's normal areas at the flow or page
    sequence level in a way that does not interfere with writing-mode set on
    page-sequence-master or region-body or that having different writing
    modes on different region-bodies within the same page sequence should be
    a reportable error (and thereby avoiding the problem altogether).

    This issue was raised by an XEP user's attempt to get an inside/outside
    page layout that puts headers and marginalia in the outside column and
    content in the inside column. This could be done *if* XEP's
    interpretation is correct, otherwise it cannot be achieved in XSL 1.0.
    However, because columns must be of equal width, this solution would be
    unsatisfactory for most use cases (where the content column would
    normally be wider than the header/marginalia column). Therefore, I do
    not find this use case to be a compelling argument for XEP's
    interpretation. I also note that XEP provides extensions to fo:float
    that allow inside/outside float positions, which does enable a
    satisfactory solution to this particular layout requirement (it could
    also be satisfied by providing inside/outside positioning of list item
    label and body).



    W. Eliot Kimber, eliot@isogen.com
    Consultant, ISOGEN International
    1016 La Posada Dr., Suite 240
    Austin, TX  78752 Phone: 512.656.4139
    (*) 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 : Wed Mar 12 2003 - 06:42:18 PST