Re: [xep-support] fo:markers/fo:flow

From: Nikolai Grigoriev (
Date: Thu Jan 23 2003 - 11:26:21 PST

  • Next message: Nikolai Grigoriev: "Re: [xep-support] XEP rendering XML to PDF with Thai Fonts"

    Hi Els,

    > For running headers I've been using markers similar to the example below:
    > <xsl:template match="chapter/title">
    > <fo:block xsl:use-attribute-sets="head1"
    > break-before="page">
    > <fo:marker marker-class-name="sect-head" >
    > <fo:block><xsl:value-of select="."/>
    > </fo:block>
    > </fo:marker>
    > <xsl:apply-templates/>
    > </fo:block>
    > </xsl:template>

    This example is quite OK: the marker is the first child of fo:block.
    The validator should con complain on this. We use markers in
    this same way for the XSL FO tutorial, included in each copy of XEP.

    > This worked fine in 2.78 versions of XEP. However, with the newer 3.xx
    > versions, I get errors reporting that the fo:marker has to be an initial
    > child of fo:flow.

    XEP 2.78 used DTD validation. With a DTD, you cannot constrain
    an element to be a first child in a mixed content model. XEP 3.0
    boasts a more powerful XSLT-based validator, capable of capturing
    this mismatch.

    > If this is true, it will be rather cumbersome to revise the applicable
    > stylesheets, so I would like to know why this is implemented
    > this way and if it is correct according to the standard.

    We didn't change the implementation; so if you turn off validation,
    you probably get the same results. But I still believe there might
    actually be fo:marker elements that are not initial children
    of their parents (parent is fo:flow in your case). I'd rather
    not leave them there.

    If you want to disable the error message (or turn it into a warning),
    there is a possibility to customize the validator stylesheet, located
    in lib/xep3<version>_<edition>.jar: com/renderx/xep/folint.xsl.
    But this is an extreme method: it seriously undermines portability,
    and leaves you with invalid XSL FO. I cannot recommend it,
    except as a temporary hack if the situation is absolutely critical.

    > When I look at the Spec, (6.11.3 fo:marker)it says that the "fo:marker has
    > to be an initial child of its parent formatting object." Unfortunately the
    > spec does not include a DTD to see where fo:marker is allowed.
    > RenderX, however, offers a DTD on their website which I looked at
    > (
    > According to this DTD <fo:marker> is included in the entity %wrappers;,
    > which is one of the options within the entity "%blocks;" that come
    > directly within fo:flow.
    > The content of "%blocks;" is repeatable and thus I should be
    > able to use a block first within fo:flow and then an fo:marker
    > element or am I wrong?

    The content of the %blocks; is repeatable because it is a mixed
    content model (i.e. includes #PCDATA). As you probably know,
    you cannot constrain neither the number nor the order of elements
    in a mixed content model - these are XML rules. So, despite
    provisions of chapter 6.11.3, I could not constrain marker
    position in the DTD.

    To summarize a bit: loose marker controls was a problem of 2.78,
    happily overcome in 3.x. We didn't change our mind about
    permissible marker configurations; instead, we learnt to validate
    them better. I believe that fixing your stylesheets is the only
    correct method to handle the problem.

    Best regards,
    Nikolai Grigoriev

    (*) To unsubscribe, send a message with words 'unsubscribe xep-support'
    in the body of the message to from the address
    you are subscribed from.
    (*) By using the Service, you expressly agree to these Terms of Service

    This archive was generated by hypermail 2.1.5 : Thu Jan 23 2003 - 11:27:35 PST