The guidelines of GridTemplate design , below, will help you ensure that the information obtained during the scanning your template, is the information you think, and that diary generation proceeds uneventfully (many of the guidelines below should also be followed for plain Quark files and InDesign files).

1. Use a consistent scheme to define the height and width of GridTemplates

Make sure that you are consistent on the definition that you use to determine what the size of a GridTemplate refers to. Is it the image size ? The untrimmed page size, or the final trimmed page size ? Each of the above is a valid choice, but you must always be consistent, mostly if you will be importing non-dated QuarkXPress or InDesign pages as info pages.

2. Do not use facing pages in GridTemplates

When creating a new QuarkXPress or InDesign document to be used as a GridTemplate, always make sure that the options shown on the right are unchecked.

➢When using QuarkXPress, if the Allow Odd Pages on Left box is grayed-out, then this means that you still have one or more facing pages master pages. Remove these master pages and then this option will be enabled (this option only exists in QuarkXPress version 8-2025).

Even though GridTemplates should not use facing pages, output files can use facing pages, which is almost always the case.

3. Do not use sections in your GridTemplate

The problem with the use in Q++Studio of QuarkXPress or InDesign pages that belong to a section, is that, even after they are copied to the output file, they keep on thinking that their page number is the page number set in the section of the original file.

So, for example, using a 2-page GridTemplate where the first page is 55 and the second is 56, generates an output file where all the pages are either 55 or 56, instead of 1, 2, 3, 4 ...

This causes errors in tokens replacement and Saras since the entire file is only made up of pages 55 and 56.

You should therefore never create GridTemplates with sections, and if you are using an existing QuarkXPress or InDesign file, you should remove sections from any QuarkXPress or InDesign files that you want to use as GridTemplate (as well as for plain Quark Files).

4. Textboxes or groups should not straddle 2 pages

When a GridTemplate is scanned, each textbox is associated with a unique page number, and this relationship is used to convert the DayValues of each token, based on the starting date of the page that contains its textbox.

Groups of objects in QuarkXPress and InDesign are essentially a collection of objects bounded by an additional box, as shown above. Therefore groups should also not straddle 2 pages.

5. Master pages

QuarkXPress and InDesign handle the objects placed on master pages very differently:

In QuarkXPress, the objects on master pages can always be overridden and, most importantly, the overriding is managed by QuarkXPress object-by-object behind the scenes. This means that only the objects that have been modified (by token replacement or deletion, for example) are overridden, the remaining objects remaining as single instances on their master page.

But, in InDesign, objects on master pages cannot be overridden unless they have previously been located and then overridden. And, the only way to make a master page object accessible from a child page is to apply the Override All Parent Page Items options as shown on the right. But, then, all the objects of the master pages are copied to the child pages, making potentially much larger than necessary output files, in particular for main grids that may be multiplied hundreds of times.

Thus the different guidelines below.

QuarkXPress: use master pages only for margins

The tokenized pages of your GridTemplates already serve the same purpose as QuarkXPress master pages, in a much more powerful manner.

Having 2 levels of "masters" can only lead to user (and sometimes QuarkXPress) confusion.

The only information that should be specified in your QuarkXPress GridTemplate's master pages are the page margins, as shown in the image on the right.

InDesign: use master pages for margins and all fixed elements

Your InDesign GridTemplate's master pages should contain the page margins, as this is the only place where these can be set.

➢For any template of 2 or more pages, make sure to have at least one left-side and one right-side master page.

Additionally, if your generated diary contains over 200 pages, as well as many lines and images, then you should move all the fixed element of your template (lines, images, tables without tokens, textboxes without tokens, ...) to the master pages of your template, as shown on the right.

When selecting the objects to place on your master pages, remember the following:

•Do not include textboxes which contain tokens.

•Do not include objects that are part of a group that might be affected by a group delete token or command (from a macro or a sara).

•Do not include elements that are on layers that may be affected by a delete layer token or command (from a macro or a sara).

•Do not include textboxes which, though they do not contain tokens, might still be affected by Saras.

All the elements placed on your master pages should then have their Allow Parent Item Overrides setting turned off, as shown in the image on the right, to ensure that these fixed elements are not multiplied on each page that comes from that master page (this is particularly important for the main grid which can often number hundreds of pages).

Note that, if you move fixed items to the master pages of your templates, then you should use the disambiguate master pages generation option, which is turned on by default.

6. Do not mix tokens of different DayValues in the same textbox

Generally, each textbox should only contain tokens of the same DayValue.

One possible exception is when the tokens are really part of a combined token where multiple DayValues are the essence of what is being displayed, such as:

 [1Week] [1w] [1d] [1mmm] - [7d] [7mmm]

which would result in "Week 37: 7 sep - 13 sep".

7. Always rotate the text rather than the textbox

If you need to display rotated text or images, always rotate the text or image, rather than the containing textbox or picturebox.

The image on the right shows the correct way to display rotated text, by setting the text's angle (above), rather than setting the textbox's angle (below).

In the example on the right, based on the QuarkXPress user interface, both settings produce the same text and textbox, visually, but the top settings are always preferable.

➢Rotating text independently of the text frame that contains it is a bit more complex when using InDesign. See the page rotating text and text frames independently on the InDesignSecrets website for detailed examples.

This is particularly true if you are using textbox resizing functions on that textbox, because resizing a rotated textbox means rotating the textbox back to 0 degrees, resizing it, and then rotating it back to its original angle.

However this re-rotation is performed by rotating about the center of the textbox, which has changed position since the textbox has changed size.

This implies a complex coordinates transformation on the part of Q++Studio to ensure that the resulting textbox appears where and how one intuitively expects it to, and the result is not always what one expects.

For the above reasons, the message 185030 will be generated whenever you use one of the textbox resizing functions on a rotated textbox.

8. Make sure Q++Studio can guess what DayValues belong to which page

Q++Studio guesses by looking for tokens of the form [d] on each page. If there is a risk of confusion, use DayValue marker tokens.

Confusion can arise, for example, in a daily diary, where on each page you show the first and last days of the current week with the tokens [1Week] [1w] [1d] [1mmm] – [7d] [7mmm]. Q++Studio will think you have a 7 days on 2 pages diary (ie a weekly) even though you have a day on the left page and a day on the right page. By placing a [1*] token on the left page and a [2*] token on the right page, you tell Q++Studio unambiguously that DayValue 1 is on the left page and DayValue 2 on the right page.

9. Use linked textboxes only when necessary

In general, there is seldom the need to use linked textboxes in GridTemplates, and it is generally discouraged, with a few exceptions where linked boxes are useful and even sometimes necessary.

10. Try to limit grouping/locking of textboxes, in particular nested grouping

You should only group objects together when grouping is necessary (for example when wishing to group delete as the result of a zap token or a macro or a SARA).

Although Q++Studio is able to selectively delete objects that are grouped, when the grouping is nested (ie. a set of grouped objects is grouped with another set of grouped objects), then QuarkXPress or InDesign can get confused, generating strange messages during token replacement, or even causing QuarkXPress or InDesign to crash, during diary generation.

11. Make sure Style Sheet and/or Color names are unique across all the GridTemplates of your Script

During diary generation, pages, from all the QuarkXPress or InDesign documents used in the current script, are copied into the same output file. Attributes from incoming pages are added to the output file by name.

If a style sheet of a given name, such as Months, for example, already exists in the output file and pages from another Quark file are copied, which also contain the style sheet Months, then what happens is unpredictable, and often depends on the version of QuarkXPress, and to a lesser extent, InDesign, that you are using.

The same unpredictable results would occur, for colors, if 2 QuarkXPress or InDesign files used in a script both used a color of the same name.

If you are using QuarkXPress 2015-2025, or any version of InDesign, you will get warning if mixing QuarkXPress or InDesign files of same name text or paragraph style sheets or colors, but you should be pro-active and ensure your that attributes such as colors and style sheets are uniquely named across all the QuarkXPress or InDesign files used in a script.

12. Do not use textboxes for bleed

QuarkXPress can assign an unexpected page number to textboxes which extend beyond the boundaries of a page, in particular objects extending to the left of the left-most page of a spread (but this can also happen to rotated object to the right of the right-most page of a spread).

➢This is not an issue when using InDesign.

In such cases, it can make it impossible to relate the page number of a scanned token when it comes to diary generation, leading to error messages.

Therefore, if you need shade to bleed off the page, use a box of content "none" rather than a text box.

You can then put any related text in a separate textbox which should not need to bleed, as shown in the example on the right.

13. Follow the 2 Rules of MiniCalendar DayValues

You should always follow the following rules when choosing the DayValue of a minicalendar token (the number at the beginning of the minicalendar token).

1.The DayValue of any minicalendar must be one of the DayValues displayed on the current 2-page spread.

2.Whatever DayValue you choose in rules 1, you must then use that DayValue for all the minicalendars of the current 2-page spread.

The scanning messages 187540 and 187550 will be generated if the above rules are broken in one of your templates.

Concretely, looking at the example on the right, a 2 days on 2 pages grid containing DayValues 1 and 2, this means:

1.Since the current spread contains DayValues 1 and 2, you must use either 1 or 2 as DayValue for your minicalendars. You can choose either value, but it must be one of these 2 values, none other.

2.If you chose 1 as DayValue in rule 1, then all the minicalendars of the 2 pages must use the DayValue 1. So, for example, if the minicalendars of that grid were to show the current month and the next month, then, having chosen 1 as DayValue for your minicalendars, you would have [1mc+00] on the left page and [1mc+01] on the right page and not [2mc+01] (wrong).

In rule 1, which DayValue you choose only makes a difference, whenever the current 2-page spread contains a month change.

14. Do not use tables to display rules or grid lines (InDesign only)

Using InDesign tables as replacement for vertical and horizontal rules is not recommended as InDesign tables are extremely heavy and complex and can lead to slow diary generation as well as potential corruption of your InDesign templates and/or output files.

Tables containing more than 1000 cells will be treated as static (tokens located in such tables will not be processed, and saras will ignore any text in these tables).

Topic 087060, last updated on 12-Aug-2024