YeShore‘s rules are not ‘preflight’ rules per se – they’re design rules, they’re about ‘during-design’ checking rather than ‘pre-flight’ (pre-output) checking. However, the InDesign CS4 Live Preflight engine is the ideal environment to implement these rules.
Unlike the built-in rules, the YeShore rules main aim is not to verify whether the document can be output. We leave that up to professional preflight solutions like Markzware’s FlightCheck or InDesign’s built-in rules for Live Preflight. Instead, the YeShore design rules help you with various aspects of document design in a more-or-less structured environment.
In the InDesign Preflight Panel, the YeShore design rules can be visually distinguished from built-in preflight rules by their name – YeShore rules will have “… (Rorohiko)” appended to their name.
Take care in case of the following scenario
- You embed a preflight profile that uses one or more YeShore rules into a document
- You send the document with the embedded profile to someone else
- The recipient will get a warning message (unless she also has the YeShore plug-in installed)
In the scenario above, make sure the recipient knows what this warning message means, and does not get alarmed by it – the message is harmless, the document is fine.
Installation
To install, you will need to add three items to your InDesign plug-ins folder – two plug-ins and one .spln file. Quit or exit InDesign before beginning the installation.
Both downloads (YeShore and APID ToolAssistant) contain separate Windows and Macintosh versions – make sure to decompress and open the proper version for your computer.
You need to install the proper version of APID ToolAssistant. There are a fair number of different versions provided (Mac/Win/CS/CS2/CS3/CS4) and you need to make sure to pick the proper one – you need either the Mac or Windows CS4 version.
Move this plug-in into the InDesign Plug-Ins folder (or a subfolder thereof – in the sample screenshot I’ve used a folder called Rorohiko inside the Plug-Ins folder, which helps keep things tidy).
Second, you need to copy both the YeShore.spln as well as the YeShoreCS4.pln (Windows) or YeShoreCS4.InDesignPlugin (Mac) into the same folder as where you put the APID ToolAssistant plug-in.
Restart InDesign, and open or create a document.
In some cases, you might get a dialog from APID ToolAssistant asking you to purchase a license, or warning it is switching to Unlicensed mode. You should ignore these warnings – YeShore will run fine for the duration of its own demo period.
An interesting video with more info on Live Preflight in general can be found here:
http://www.adobe.com/designcenter/indesign/articles/lrvid4025_id.html
Rule List
Below a list of all the rules added to InDesign’s Live Preflight. As time permits, we’ll be adding ‘how-to’ cookbook scenarios to explain how to use these new rules – check this page every so often for new info!
The ‘Rule code’ and ‘Parameters’ info is useful to scripters who need to automate the InDesign Live Preflight.
Avoid pasted graphics
Use case:
Check for pasted graphics. Pasted graphics will output as poor quality and should be avoided. Instead, properly linked graphics should be used (i.e. graphics frames that link to a disk file or an embedded image file).
Rule code:
com.rorohiko.indesign.yeshore.pastedgraphic
Parameters:
None
Make sure the page count is correct for impositioning
Use case:
Check whether the document’s page count is a multiple of some number. This is useful if the document will be impositioned later – you want the page count to be a multiple of the signature page count – i.e. a multiple of 8, 9, 16… pages
Rule code:
com.rorohiko.indesign.yeshore.impositionpagecount
Parameters:
kPRiRuleImpositionPageCount0Parameter (number, 2 – 256)
Check structured document names
Use case:
In many structured work-environments, document names need to follow a predetermined pattern. This rule can verify that the document name matches either a wildcard pattern or a GREP pattern.
By default the matching is case-insensitive, and you can specify a pattern that MUST be matched, or a pattern that CANNOT be matched, or both.
Wildcard patterns are compatible to the scheme that is used for file name patterns on Windows. They are limited, but much easier to use than GREP – there are only two ‘special’ characters – the star, and the question mark. Use a ‘*’ to mean: any zero or more characters, and a ‘?’ to mean: exactly one character.
*.indd
would mean: “zero or more characters, followed by a period, followed by ‘indd'”. This particular pattern would match “a.indd”, “testfile.indd”, “what123.indd”. It would also match “.indd” – which starts with the period without characters before the period.
To match only if there is at least a single character before the period, you’d use:
?*.indd
which would not match “.indd” but it would match “a.indd”, “testfile.indd” and so on.
To avoid accidently saving documents named ‘Untitled…’, you would set the exclude parameter to:
untitled*
If you want to use GREP, you need to keep in mind that GREP is totally incompatible with wildcards, even though they look similar at first sight. Like wildcards, GREP considers the star and question mark to be special characters, in addition to a whole lot of other characters: the period, square brackets, ^, $, and so on. The wildcard expression ‘*.indd’ would be equivalent to GREP expression ‘.*\.indd’. The wildcard ‘?*.indd’ would be equivalent to GREP ‘.+\.indd’.
An example: the document name should be the customer code (which is either ‘ROR’, ‘BLA’, ‘XXY’ or ‘TXZ’), followed by a dash, followed by a 4-digit sequence number. You’d use GREP for that and set the include parameter to:
(ROR|BLA|XXY|TXZ)-\d{4}\.indd
This would allow ‘ROR-1234.indd’, ‘TXZ-8382.indd’ but would not allow ‘ROR1-1112.indd’ or ‘TXZ-123a.indd’.
Rule code:
com.rorohiko.indesign.yeshore.docname
Parameters:
kPRiRuleDocName0IncludeParameter (string)
kPRiRuleDocName1ExcludeParameter (string)
kPRiRuleDocName2CaseSensitiveParameter (boolean)
kPRiRuleDocName3UseGREPParameter (boolean)
Check the script label on page items
Use case:
In InDesign, you can assign a script label to any page item via the ‘Window-Automation-Script Label’ palette.
Script labels are often used for semi-automated document construction – you can use them to add some additional information to particular page items.
For example, you might put a script label ‘TODO’ on each and every frame that still needs some work done (assigning a label ‘in bulk’ is easy: do a ‘Select All’ or shift-click select of the page items, and then enter a name in the scripts palette – the same script label will be attached to all selected items).
Once the work is done, you would remove the label. The rule would check that there are no more page items marked ‘TODO’.
Or you could have placeholder frames in a template document, and all placeholders carry a script label ‘PLACEHOLDER’. The idea being that you gradually replace the placeholders with ‘real’ content. The document is finished once all placeholder frames are gone.
This rule is about making sure that the script labels of all page items in the document either do or don’t match a certain pattern.
By default, page items that have an empty script label are ignored, the matching is case-insensitive, and we use simple wildcard matching (as opposed to GREP).
Sample Scenario:
See section 2.6 of this blog post for a practical application of this rule:
https://www.rorohiko.com/wordpress/2009/11/17/the-secret-life-of-script-labels-in-indesign/
Rule code:
com.rorohiko.indesign.yeshore.scriptlabel
Parameters:
kPRiRuleScriptLabel0IncludeParameter (string)
kPRiRuleScriptLabel1ExcludeParameter (string)
kPRiRuleScriptLabel2AlsoTestEmptyParameter (boolean)
kPRiRuleScriptLabel3CaseSensitiveParameter (boolean)
kPRiRuleScriptLabel4UseGREPParameter (boolean)
Avoid portrait orientation
Use case:
Flag an error if the document is in portrait orientation.
Something similar can be achieved with the built-in rule for document size, but the built-in rule requires an accurate document size to be known ahead. If the document size is not always the same, or can be variable, this rule will catch portrait orientation, independent of the actual page size.
Workflow rule code:
com.rorohiko.indesign.yeshore.portrait
Parameters:
None
Avoid landscape orientation
Use case:
Flag an error if the document is in landscape orientation.
Something similar can be achieved with the built-in rule for document size, but the built-in rule requires an accurate document size to be known
ahead. If the document size is not always the same, or can be variable, this rule will catch landscape orientation, independent of the actual page size.
Rule code:
com.rorohiko.indesign.yeshore.landscape
Parameters:
None
Avoid up- or downscaled images
Use case:
Check for scaled graphics, not at 100%. In many workflows, scaled graphics are processed through Photoshop instead of letting InDesign handle the scaling – this allows the use of various filters and unsharp mask after the scaling.
The parameter is a percentage that defines how far from 100% is still acceptable (e.g. a setting of 20 means: scaled somewhere 100 +/- 20 – between 80% and 120% scaling is allowed)
Rule code:
com.rorohiko.indesign.yeshore.scaledgraphic
Parameters:
kPRiRuleScaledGraphic0VarianceParameter (number)
Make sure there’s enough separation between page items
Use case:
Make sure page items either have sufficient overlap, or don’t overlap at all and respect a certain minimum distance.
You might want to use this for things like a photo-grid, where the various picture frames need some minimum distance between them.
The first parameter is a minimum overlap, the second parameter is a minimum distance between frames. Any two frames should either overlap by at least the minimum overlap, or else they should be separated by at least the minimum distance.
Rule code:
com.rorohiko.indesign.yeshore.mindistance
Parameters:
kPRiRuleMinDistance0MinDistance (number)
kPRiRuleMinDistance1MinOverlap (number)
Keeping to a set of agreed fonts
Use case:
Verify used fonts against a list of allowed or rejected fonts. The list is a comma-separated list of wildcard strings – so a list like
Times*, Comic*
will match any font whose name starts with either ‘Times’ or ‘Comic’.
A list like
*Italic, *Bold
will match any font whose name ends in either ‘Italic’ or ‘Bold’
When both lists are used, the ‘include’ list takes precedence – so if a font matches both the include and rejected list, it is allowed. If you set the included list to
*Bold Italic
and the rejected list to
*Italic
then a bold italic font will be accepted.
Entries in the lists are not case-sensitive, and spaces, dashes and underlines are ignored when matching font names – so a font name like “Times-Bold” will match a pattern like “timesbold”
Rule code:
com.rorohiko.indesign.yeshore.fontlist
Parameters:
kPRiRuleFontList0Include (Allowed fonts. Comma-separated font wildcard expressions)
kPRiRuleFontList1Omit (Allowed fonts. Comma-separated font wildcard expressions)