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).
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 Quark pages as info pages.
all 3 boxes should be un-checked
When creating a new QuarkXPress document to be used as a GridTemplate, always make sure that the 3 options shown on the right are un-checked.
➢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 and above).
Even though GridTemplates should not use facing pages, output files can use facing pages, which is almost always the case.
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 file, you should remove sections from any QuarkXPress files that you want to use as GridTemplate (as well as for plain Quark Files).
Groups of objects in QuarkXPress are essentially a collection of objects bounded by an additional box, as shown above. Therefore groups should also not straddle 2 pages.
Having 2 levels of "masters" can only lead to user (and sometimes QuarkXPress) confusion.
The only information that should be specified in your GridTemplate's master pages are the page margins, as shown in the image on the right.
Generally, each textbox should only contain tokens of the same DayValue.
[1Week] [1w] [1d] [1mmm] - [7d] [7mmm]
which would result in "Week 37: 7 sep - 13 sep".
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.
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 can get confused, generating strange messages during token replacement, or even causing QuarkXPress to crash, during diary generation.
During diary generation, pages, from all the Quark 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 that you are using.
The same unpredictable results would occur, for colors, if 2 Quark files used in a script both used a color of the same name.
If you are using QuarkXPress 2015 or above, you will get warning if mixing Quark 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 Quark files used in a script.
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.
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.
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 make a difference, whenever the current 2-page spread contains a month change.