docbook-apps

  • 1.  Re: [docbook-apps] long text includes generating wasted page breaks

    Posted 10-19-2006 16:52
    Chris,
    The FO processor bumps the start of the long example to the next page
    because of the keep-together.within-column="always" property on the block
    containing the example. That's from the 'formal.object.properties'
    attribute-set.

    You're wondering why, since it won't fit on the next page either, the FO
    processor doesn't just start it on page 1. The way FO processors work with
    keeps is that the property adds a "keep condition" to the block, which is
    tested on the first page. It fails to fit there, so it bumps it to the
    next page and consumes the keep condition. On the second page there is no
    keep condition, so it just starts there. The FO processor doesn't look
    ahead to see if it fits on the second page, and then backtrack to the first
    page. It just processes the content for the current page. For all it
    knows, the second page could be a bigger page-master that would fit the
    example, if it were to test it. But it doesn't test it on the second page.

    The solution is to add a processing instruction to this example:

    <example>

    ...

    Now it should start on the first page.

    Bob Stayton
    Sagehill Enterprises
    DocBook Consulting
    bobs@sagehill.net





  • 2.  Re: [docbook-apps] long text includes generating wasted page breaks

    Posted 10-19-2006 17:23
    You sunk all the balls on the pool table with one shot, hit the nail
    directly on the head, etc...

    Thank you!

    On 10/19/06, Bob Stayton <bobs@sagehill.net> wrote:
    > Chris,
    > The FO processor bumps the start of the long example to the next page
    > because of the keep-together.within-column="always" property on the block
    > containing the example. That's from the 'formal.object.properties'
    > attribute-set.
    >
    > You're wondering why, since it won't fit on the next page either, the FO
    > processor doesn't just start it on page 1. The way FO processors work with
    > keeps is that the property adds a "keep condition" to the block, which is
    > tested on the first page. It fails to fit there, so it bumps it to the
    > next page and consumes the keep condition. On the second page there is no
    > keep condition, so it just starts there. The FO processor doesn't look
    > ahead to see if it fits on the second page, and then backtrack to the first
    > page. It just processes the content for the current page. For all it
    > knows, the second page could be a bigger page-master that would fit the
    > example, if it were to test it. But it doesn't test it on the second page.
    >
    > The solution is to add a processing instruction to this example:
    >
    > <example>
    >
    > ...
    >
    > Now it should start on the first page.
    >
    > Bob Stayton
    > Sagehill Enterprises
    > DocBook Consulting
    > bobs@sagehill.net
    >
    >
    >
    Original Message


  • 3.  Using a MedaObject to get a PDF to scale to the page body size

    Posted 10-23-2006 23:16

    I am attempting to use a "mediaobject" to insert a PDF into the body of my
    docbook page. I want the pdf to maintain aspect ratio without extending over
    the border of the body. However, even when I use scalefit="1 width="100%"
    contentheight="100%", I can end up with the internal pdf taller then the
    page body. It will often run over the region-after extent.

    I have tried many combinations, however, none seem to work. Is there a way
    to do this?

    Below is a chapter section of my docbook. I am using XEP.

    <chapter>
    <chapterinfo>
    <author></author>
    </chapterinfo>

    <mediaobject>
    <imageobject>
    <imagedata fileref="http://webserver/my.pdf format="PDF" scalefit="1
    width="100%" contentheight="100%" >
    </imagedata>
    </imageobject>
    </mediaobject>

    </chapter>




Related Content