none
How does DOCX pick the page break when everything says no? RRS feed

Answers

  • Hello Dave,

    Yes--sorry for the delay and thank you for your patience.

    I've looked at this in some depth and I haven't found anywhere that the standard prescribes a precedence between the page boundary controls for paragraphs and table rows. The language for two of these settings in the standard seems to leave some room for implementations to be flexible. Both keepLines and keepNext include the phrase "whenever possible" when describing the effect on layout. cantSplit is firmer in its requirement, requiring that a row that would be rendered on two different pages to always start on a new page.

    We do have one relevant implementation note regarding the interaction between paragraphs and tables for keepLines:

    [MS-OI29500] §2.1.45: Word does not keep lines together when rendering paragraphs in a table.

    I think it's safe to say that the interaction between these properties is implementation defined and subject to change, but the current behavior seems logical. I created a small document to demonstrate the effect of these settings. I've shared it at http://1drv.ms/1yQvcq4. You can see that keepNext and cantSplit produce the same results, and keepLines has no effect as expected from the aforementioned implementation note.

    In short, the current behavior for calculating page breaks in content consisting of paragraphs within table rows, both keepNext and cantSplit will influence where breaks are placed, and keepLines will have no effect.

    Please let me know if this helps or if something doesn't seem right to you.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    • Marked as answer by DavidThi808 Wednesday, April 22, 2015 10:24 PM
    Wednesday, April 22, 2015 6:48 PM

All replies

  • Hi Dave:

    I have alerted the open specifications team regarding your inquiry. A member of the team will be in touch soon.


    Regards, Obaid Farooqi

    Tuesday, April 7, 2015 11:36 PM
    Owner
  • Hello Dave,

    I will be working with you on this one. I will follow up here with any questions and/or findings soon.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Wednesday, April 8, 2015 3:14 PM
  • Hello Dave,

    This scenario appears to be defined by ISO/IEC 29500. The paragraphs are contained in rows that are set to be kept together. That is represented in the document with the <cantSplit> element in the <trPr> properties. Looking at §17.4.6, it says in part:

        "If this property is set, then all contents of a table row shall be rendered on the same page by moving the start of the current row to the start of a new page if necessary. If the contents of this table row cannot fit on a single page, then this row shall start on a new page and flow onto multiple pages as necessary."

    There is also an implementation note in [MS-OI29500] §2.1.118 that confirms Word's behavior:

        "a. The standard states that the row shall start on a new page and flow onto multiple pages as necessary when the contents of the table row cannot fit on a single page.
        Word starts the row on a new page and cuts off overflowing contents as necessary under this circumstance."

    Please let me know whether or not you agree that these documents explain how Word is choosing to handle the page breaks for this.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Friday, April 10, 2015 5:23 PM
  • Hi Matt;

    Does this mean the keepWithNext para setting is ignored between rows? If so, then yes, this all makes sense.

    thanks - dave


    What we did for the last 6 months - Made the world's coolest reporting & docgen system even more amazing

    Friday, April 10, 2015 8:28 PM
  • Hello Dave,

    I started to reply that yes, the row property takes precedence and is unaffected by the paragraph properties, but then I did some additional testing and that doesn't always seem to hold true. I will need to do some further research to understand the interaction between these properties.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Monday, April 13, 2015 11:31 PM
  • Hi Matt;

    Any update yet?

    thanks - dave


    What we did for the last 6 months - Made the world's coolest reporting & docgen system even more amazing

    Wednesday, April 22, 2015 2:19 PM
  • Hello Dave,

    Yes--sorry for the delay and thank you for your patience.

    I've looked at this in some depth and I haven't found anywhere that the standard prescribes a precedence between the page boundary controls for paragraphs and table rows. The language for two of these settings in the standard seems to leave some room for implementations to be flexible. Both keepLines and keepNext include the phrase "whenever possible" when describing the effect on layout. cantSplit is firmer in its requirement, requiring that a row that would be rendered on two different pages to always start on a new page.

    We do have one relevant implementation note regarding the interaction between paragraphs and tables for keepLines:

    [MS-OI29500] §2.1.45: Word does not keep lines together when rendering paragraphs in a table.

    I think it's safe to say that the interaction between these properties is implementation defined and subject to change, but the current behavior seems logical. I created a small document to demonstrate the effect of these settings. I've shared it at http://1drv.ms/1yQvcq4. You can see that keepNext and cantSplit produce the same results, and keepLines has no effect as expected from the aforementioned implementation note.

    In short, the current behavior for calculating page breaks in content consisting of paragraphs within table rows, both keepNext and cantSplit will influence where breaks are placed, and keepLines will have no effect.

    Please let me know if this helps or if something doesn't seem right to you.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    • Marked as answer by DavidThi808 Wednesday, April 22, 2015 10:24 PM
    Wednesday, April 22, 2015 6:48 PM
  • Hi;

    Thanks for the work on this. This matches what we've found too, but I feel a lot better having a semi-official Microsoft stamp of approval to what we found.

    thanks - dave


    What we did for the last 6 months - Made the world's coolest reporting & docgen system even more amazing

    Wednesday, April 22, 2015 10:25 PM