Nested Master Pages

Fragments and Master Pages

If you are designing your forms using fragments, you will likely have done some work to get consistent master page definitions in your final document. The strategy most form authors follow is to define a set of re-usable master pages and include them in their host template.  All included fragment subfoms will then make use of the master page definitions found in the host template.

But what many form authors do not realize is that it is possible for the fragment to bring its own set of master pages into the host document.  The strategy is to define the collection of master pages as a child of the fragment being included.  I have created a sample XDP to illustrate this.  Note in the hierarchy that there are three sets of master pages: one for the root subform, and one each for the group1 and group2 subforms:

In this example, the group1 subform will look up its master page definitions in its nested master page collection. Same for group2.  And if group1 or group2 were to be included as a fragment, their master page definitions would be automatically included, since they’re part of the subform.  If group1 and group2 used the master page definitions defined under form1 and were included as a fragment, they would then use the master page definitions found in their host document.

Referencing Master Pages

Assume we have a master page that is defined with this syntax:

<pageArea name=”Page1″ id=”Page1_ID”>

In Designer, when the pagination option is: ‘ Place: On Page: “Page1” ‘, the syntax generated by Designer will reference this page by name:

<subform name=”usePage1″>
    <breakBefore target=”Page1″ targetType=”pageArea”/>   

However, we can also reference by id:

<subform name=”usePage1″>
    <breakBefore target=”#Page1_ID” targetType=”pageArea”/>   

Referencing pages by name is the best strategy when you are sharing a global set of master pages. As long as you are consistent in your naming scheme, the “Page1” referenced by your fragment will be replaced by “Page1” found in the host template.

However, if your master pages are embedded in your fragments, then you don’t want to share page definitions. In this case there is less ambiguity if we use ID references instead of name references.

In fact, there is a bug in the current shipping products where if the top-level “Page1” is in use when group1 is added to the layout, then “Page1” will continue to be used for “group1” — but it is the wrong “Page1”.  Here is a sample XDP to illustrate the bug.  The workaround is to either use unique names for your nested master pages, or switch to use id references.

Using unique names is easier. Using id references means either hand-editing the XML source or writing a designer macro to change the syntax.

5 Responses to Nested Master Pages

  1. Keith Gross says:

    The links to your two sample XDPs are broken.

  2. Thanks Keith. Now fixed.

  3. rohit kumar behera says:

    Hi John,

    I don’t know if this is the right place my question – I have posted the same problem in Adobe Forum. Niall Donovan came up with an idea which I implemented but didn’t work.

    The requirement is I want two tables – Table A & Table B which should be placed side by side. When there is a data overflow for any or all of the 2 tables it should come properly in the next page with page breaks. I have used two tables (repeatable subforms) and placed them in flowed (Western Text) subform – when Table A overflows then the Table B is pushed to the next page even if there is ample space on the right.
    I realized that this behavior is due to Western text flow direction of the outer flowed subform. You can find the sample in the following link –

    The above sample form will make things clearer.

    Please let me know if there is any way to override this default behavior

    • John Brinkman says:

      This is not an easy problem to get right. But the general principle you need to follow is the same as when displaying parallel columns of text. See:
      In this case you want to place both tables side-by-side in a positioned subform.
      However the next problem is to make sure that you can find a common split point between the tables. In your case, this was complicated by using object heights with a very fine precision — 3 digits after the decimal. Increases the likelihood of rounding errors. As well, if the structure of the layout doesn’t require tables, it’s probably just as well to use regular flowed subforms. (although in theory, tables should work. They’re just more complicated.)
      I modifed your sample to get the result you were looking for. I’ll send it offline.

  4. Pingback: Form Stitching Design Pattern « FormFeed