PARTS OF THE LOCATOR
The core element of the locator is the page number. Sky scans the locator string left to right, and when it reaches a number it interprets that number as the page number. The page number is the chief determinant of the order of locators in a heading.
PREFIXES AND SUFFIXES
Text that precedes the page number is the prefix, that which follows is the suffix. In sorting locators, the order of precedence is (1) page number, (2) prefix, (3) suffix. To see how this works, look at the following sorted list where the page number is 22 in every locator:
a22, b22, 22b, c22, 22n7, Plate 22, 22r2d2, 22t
Note that some prefixes and suffixes appear to be meaningful--the "n" that designates a note, the "t" for a table, the "Plate" designation. Sky is entirely oblivious to these meanings; to Sky they are only prefixes and suffixes. Learning about locators in is part learning how to make Sky behave as if it understood those meanings.
Note also that suffixes can include numbers but prefixes cannot. If a prefix includes a number, that number becomes the page number since Sky scans left to right. However, if prefix numbers use Ignore Formatting they will appear in the prefix and will not be recognized in processing the locator for sorting. That is, if I enter "r2d222" with Ignore Formatting used on the numbers in "r2d2" then "rd" will be the interpreted prefix with the 2s ignored, and the locator will sort as "rd22" and print as "r2d222". The locator would appear in the list above after "22r2d2".
When Sky encounters an number in a suffix, it processes it as a number and not a series of text digits. So Sky will produce this sorted sequence: "22a3b, 22a04b, 22a5b", with the leading zero ignored in the second locator. This is the identical to the treatment of numbers in the text headings. If you define a Translation, such as <0> for the number zero, Sky will sort the character as a left bracket text character. In most cases this will produce the intended order since zero and left bracket characters are close in the sort order. Entering 22a<0>4b in the sequence above, with <0> translated to zero, will produce the sequence 22a04b, 22a3b, 22a5b.
CHAPTERS, VOLUMES, AND SECTIONS
Sky allows you to define parts of the locator so as to designate the locator as part of a group called a section. This is done with a special character called an Input Delimiter or Input Separator. When Sky encounters this character, such as a colon, it interprets the preceding text as the section. So, in "3:22" when Sky encounters the colon, it designates the "3" as a section. All locators within this section will be sorted together. After the colon, Sky continues scanning to identify multiple sections, and then eventually finds the prefix-page-suffix text after the last Input Delimiter.
The most common sections in book and journal publishing are Volumes and Chapters. In the Locators dialog, the terms Volume and Chapter are the same as Section 1 and Section 2. Any settings that you apply to Volume are automatically applied to Section 1, and likewise for Chapter and Section 2. In discussing sections, Volume always means Section 1 and Chapter always means Section 2. I will use the term section since the settings are consistent at each level. But Section 1 means Volume and Section 2 means Chapter.
Many locators with prefixes will naturally group themselves so that it is not necessary to use sections merely for sorting. But there are many advantages to using sections, such as controlling the location of the page number and controlling the display of section designators.
Another creative use is to force a particular prefix to group itself, such as forcing "Plate 22" and other plates to the end of the index. This can be done with Hidden and Ignore text, but it is considerably less tedious to merely type "Plate:22" and have Sky do the work.
Finally, defining a Section allows you to declare the section label as a particular data type, such as Alpha or Roman Numeral, and thereby control how it is treated. Data type is especially useful in date locators because you can define a month-type sections and Sky will interpret and properly sort months entered as Jan-Feb-Mar etc.
PAGE INCREMENT
Sky has a handy page increment function such that if you have a locator "45" you can use Alt+period to expand the locator to a range with the next Arabic numbered page, "45-46". In the list of page-22 locators above, the incrementer will expand every locator to page 23, e.g., a22-23, Plate 22-23, 22r2d2-23. This is because the page number is 22 in every instance, and the Arabic page that follows is 23.
Now here's a test. Question 1: without any sections defined, what would the incrementer do with this locator, "I:a.2.3.4.5"? Question 2: now enable three sections in the locator dialog with colon and periods as designators; what would the incrementer do with the same locator?
For Question 1, the page number is the first number scanning from left to right, so page 2. The colons and periods are meaningless without sections defined—they are interpreted as prefix characters. So 2 will increment to 3, and you'd have "I:a.2.3.4.5-3". For Question 2, enabling three sections means that "I.a.2" are now sections, so the page number is the next number rightward of these, so page 3, which increments to 4. So the result of incrementing in Question 2 is "I:a.2.3.4.5-4".
Note that when you increment a page number, Sky does not copy the prefix and suffix text to the new locator. Nor does Sky presume that any prefix or suffix applies to both page numbers in a range. For example, Sky behaves as if the table in 23-24t appears only on page 24. I say more about how to change this below.
NATURAL VS. UNNATURAL SUFFIXES
Consider a book that contains the following sequence of pages: 23, 23a, 23b, 23c, 24, 24a, 24b, 25, 26. From this sequence, you could identify page ranges like 23-33b or 23a-24a or 23c-26 and understand the logic of the pages each range contains. The suffixes in this sequence might be called natural suffixes because Sky locator functionality behaves as if they were actually in this kind of sequence.
Most suffixes, however, follow different logic. The locator "235n6-7" is understood by readers and indexers to be a sequence of two notes on page 235. And "23-24t" means a table that spans pages 23-24. Since Sky doesn't automatically accommodate the logic of these suffixes, the user needs to control Sky functionality so it doesn't treat the pages like a natural range.
THE HYPHEN
Using a hyphen to enter a page range in the Page field is akin to magic. Type "235-6" and watch Sky expand the range to "235-236" and in the Preview Pane format the range according to the style sheet of your press. If you like, it will repeat the Volume and Chapter
Sometimes, however, you don't want that to happen. Type "235n6-7" and watch Sky expand that to "235n6-237", an undesired result. What is happening is that in the locator "235n6-7" the hyphen appears to be a part of the suffix, it appears to represent the note range "6-7". However, a hyphen cannot be a part of a suffix--its function in Sky is to begin a new locator that will be the endpoint of a range. And the front of that range is the page number from the first locator. So in "235n6-7" Sky associates the "7" with the page number "235" from the beginning locator and expands it to "237".
USING TRANSLATIONS
Using a hyphen anywhere except between two page numbers can obviously produce unwanted results. To prevent this from happening, one solution is to use the Translation Table to substitute a non-sensitive character for the hyphen. In the Translation Manager enter in the Text field some hyphen-looking character, such as a tilde or an equals sign, that you won't otherwise need in the Page field. In the Translation field, enter the hyphen (or en-dash, depending on style rules). Check "In Page Field" but leave other field checkboxes unchecked so the translation only affects the Page field. Then retype your locator with the translation character substituted for the hyphen: "235n6~7". The locator will display the hyphen in the index but will not produce hyphen behavior.
FOOTNOTES, ENDNOTES, TABLES, AND FIGURES
Notes are tricky because, as illustrated above, they give the illusion that the hyphen pertains to the adjacent numbers in the suffix. This happens in any circumstance where suffixes are used to identify numbered items, such as numbered notes, that appear in multiples on a page. That is, the locator "235n6-7" might represent any entity that could have seven units/notes on a page.
A different sort of problem occurs when the hyphen is in the page part of the locator, indicating to readers that the suffix item spans more than one page. With a note, such as "233-34n7", it indicates a note that spans two pages. But it is more common with tables and figures, which are more often larger than notes.
Again, the illusion is that "233-34n7" means "a note that spans pages 233-34". However, Sky reads the locator as "from page 233 to the item n7 on page 234". The same is true for tables and figures, where a reader would interpret "236-37t" to mean "the tables on pages 236 and 237" or "a table that spans 236-37". Sky, however, reads the locator to mean "from page 236 to the table on page 237". That is, Sky views 236 as a separate and autonomous page number.
When these kinds of locators are clustered together, they can produce undesired filing order. One would hope to see "233n5, 233-34n7, 234n9", for example, following the "5, 7, 9" number order of the notes. But since the 233 in the range is not associated with a suffix, Sky sorts it first in the sequence: "233-34n7, 233n5, 234n9". This is clearly wrong, the note numbers are out of sequence. To achieve the correct order, you need to tell Sky that the note appears also on page 233: "233n7-234n7". You should use Hidden formatting so the first suffix (note number) doesn't appear. Then Sky will put these in the correct order, "233n5, 233-34n7, 234n9".
Likewise, with tables, Sky will file the following locators in the reverse order, "236-37t, 236-39", because it does not recognize that the table is on page 236. To indicate the table range to Sky, enter the locator as "236t-237t" and, if you like, use Hidden formatting on the "t" in 236t. This will force Sky to file the two locators in the correct order.
SI8 NOTE INDICATORS
SI8 introduced a new note designator. In the simplest terms, the letter "n" after a locator indicates that what follows is a footnote or endnote. This overrides treatment of the note text as prefix or suffix.
With note indicators enabled, Sky recognizes the "n" in "22n7" as a note indicator. The "n" as the note indicator is entered in a new section of the Index Options > Locators options panel. Normally Sky retains the designated "n" that is entered in the locator. However, if Sky detects a page range (e.g., "22n7-8") then Sky will change the note indicator to the note range indicator, normally "nn". If it detects a list (e.g., "22n2,6,7") it will use the note list indicator, also normally "nn".
One clear benefit of this is that in SI8 Sky now treats a locator like "222-223n15" as if the note were attached to both page numbers, which it is of course. Now the sequence, "222n13, 222-223n15, 223n18" sorts properly because Sky pretends to understand that page 222 is a note page. These examples illustrate the new behavior with hyphenated page ranges with notes:
SI7: 222-223n15, 222n13, 223n18 (Note 15 out of order because page 222 sorts before all 222+suffix pages)
SI8: 222n13, 222-223n15, 223n18 (New note feature recognizes 222-223n15 as Note 15 spanning two pages)
The changes also fixes behavior related to "nn" as a designator for multiple notes on a page.
SI7: 222n13, 223n18, 222nn15-16 (Note 15 out of order because "nn" sorts after single note numbers)
SI8: 222n13, 222nn15-16, 223n18 (New note feature recognizes "nn" as a note run indicator)
SI8 note indicators cannot be used for notes that appear on Roman numbered pages.
CRAZY SUFFIX SORTING (ROMAN NUMERAL SUFFIXES)
This sequence can easily have you scratching your head: 23c, 23d, 23a, 23b, 23e. The cause of this is most always that you have Sort Roman Numerals checked. Since "c" and "d" are Roman Numerals, they are interpreted and sort before the alpha characters. If you have no other use for Roman Numerals in the index, just uncheck that setting and the problem is fixed. If instead you need to keep the Sort Roman Numerals setting checked, you'll need to force sort the suffixes using Hidden and Ignore formatting or use translations for the Roman characters you don't want interpreted.
FORMATTED LOCATORS
Formatted locator characters produces different results depending on what is formatted. Formatted page numbers follow the order set in the "Format Priority" button of the Index Options > Locators tab: "5, 5, 5", etc. This setting only affects page numbers.
Formatted suffixes and prefixes such as "5a, 5a, 5a" will sort in the order entered, thus no sorting at all.
For formatted sections, there are checkboxes in the section dialog to control the formatting of the entire section. If you mean to format all characters in every instance for a particular section, so that a section level always has the same format, use these settings. So for volumes always in bold, you would use this. If you mean to format particular instances of a section, then leave the section formatting checkboxes unchecked and use manual formatting on the text, for instance, "I:5; II:4,9; IX:14; Plates: 3, 7". However, do not attempt to define sections unique only in their formatting. That is, Sky does not know how to handle locators such as "A:5, A:6, A:13".
ERROR SCAN
Look again at the page-22 sequence above and imagine the locator sequence "21, 22b, 23". This makes sense, right? How about this: "21-23, 22b"? In this case Sky considers 22b to be a page between 21 and 23. When it scans for errors, it thinks you'd want to know about this and reports it as a "reference in a range" error. Sky will also report 22t or 22f as an error. But these are probably tables or figures, so these are not real errors. Since Sky is oblivious to the meaning of the suffixes, it is just being careful and giving you information that you may choose to ignore.
With Error Scan, it's easy enough to ignore a few of these. But many indexes have numerous figure and table entries, and in each case you have to scan the locator list to find the particular sequence Sky believes is wrong. It is distressing to encounter a wall of errors knowing that most of them are false positives. This has been written up as a feature request in the Sky forums. If it's important to you, be sure to vote for it.
THE PAGE NUMBER TAKES PRECEDENCE OVER THE PREFIX
In locators such as "A2" and "B1", the letter is considered a prefix. Even though the order of appearance is always prefix-page-suffix, the order of sort precedence is page-prefix-suffix. That is, the page number always takes precedence over the prefix and suffix. Try entering these two locators and you'll see the order is "B1, A2".
To prevent this from happening, you should enable sections so that the alpha characters are defined as a section. Thus A2 would now be Section A, Page 2, with no prefix or suffix at all. To do this, choose an Input Delimiter such as a colon and leave the Output Delimiter as blank. Then enter the locators as "A:2" and "B:1" and you'll get the desired result "A2, B1". The blank Output Delimiter keeps the colon from appearing in the index.
Prefixes can have odd disguises. In the following sequence, it would appear that "Plates 3-4" should go at the end because alpha characters sort after numbers: "xii, 26, 28, 36, Plates 3-4". But this does not happen, you get "xii, Plates 3-4, 26, 28, 36". This is because "Plates" is a prefix, and the page number "3-4" takes precedence in sorting and puts the locator the correct place.
The elegant way to correct this is to enable one section and enter "Plates:3-4", with the Input Delimiter a colon and Output Delimiter a space. Now "Plates" is a section, and it sorts at the end with all other "Plates" locators.
FORCE SORTING LOCATORS (THE FIVE-DIGIT NUMBER)
It is possible to force sort a locator with Hidden Formatting just as you would main entry text. Let's say you want to force a sequence of non-paginated plates to follow the preceding page, that is, to emulate this type of page sequence: "236, Plate 1, Plate 2,...Plate 19, Plate 20, 237".
For a particular heading, your locator list might be "33, 119, 215, 295" so you'd want your Plate 2 to follow page 215. So you enter as the locator "236Plate 2" and format "236" as Hidden text. This should work because now "236" is the first number, and Sky scans left-to-right and identify it as the page number.
Try this, however, and you'll notice several things will go wrong. Because the leading number is Hidden text, Sky will bypass it and identify the unhidden "2" as the page number—the "2" will become the primary part of the sort key (meaning it will come before the hidden text that is added to the locator). The result with unhidden "2" will be "Plate 2, 33, 119, 215, 295".
That's easily fixed, though, you just format the "2" as Ignore text so it won't be sorted: "236Plate 2". But now Sky puts Plate 2 at the end of the list, "33, 119, 215, 295, Plate 2", and the reason for this is not at all obvious.
Internally, Sky converts all page numbers to five digits to sort them. So you see "33, 119, 215, 295", but Sky actually sees "00033, 00119, 00215, 00295". When Sky sees the leading 236 in Hidden formatting, it sees it as text and does not do the five digit conversion. The result of this sort is "00033, 00119, 00215, 00295, 236". So, to properly force Sky to sort it as page number 236, you must do the conversion manually and add the extra digits. Enter the locator as "00236Plate 2", with "00236" Hidden and "2" Ignored. You'll get the proper sequence "33, 119, 215, Plate 2, 295".
This will work fine in most instances. However, there's one more twist. Let's say you have two plates in this sequence, "33, 119, 215, Plate 2, Plate 5, 295". If you properly format the locators, remember that the plate numbers 2 and 5 will be in Ignore formatting. So this is what Sky will see when it sorts the locators: "00033, 00119, 00215, 00236Plate, 00236Plate, 00295". The two plates will be identical since the plate numbers are Ignored can't be used for sorting. They will sort randomly and might or might not be correct. To fully force the sort, you need to add a hidden non-numeric character, usually a letter, somewhere in the page 236 suffix. So you'd use "00236Plate a2, 00236Plate b5" with the letters (a and b) Hidden and the numbers (2 and 5) Ignored. Then Sky would see this internally as "00033, 00119, 00215, 00236Plate a, 00236Plate b, 00295" and would sort correctly.
A much easier way to force sort the plates is to format the entire locator as ignore and add another number after the page. So Plate 2 would be designed as 0023602Plate 2. This works because when Sky scans left-to-right for the page number, it stops after five digits. The characters that follow become part of the suffix no matter what they are. The suffix for this locator would be interpreted as "02Plate 2".
This is especially helpful if you want to force the plates to the beginning or end of the locator list. To force them at the beginning you'd use 0000002Plate 2, 0000003Plate 3, etc. (all on page 00000). For the end you'd use 9999902Plate 2, 9999903Plate 3, etc. (all on page 99999). Remember: for this to work there should be no unformatted text in the locator. All of the sort key should be hidden; all of the displayed locator should be ignored.
A few other tips: in some cases if you have only hidden and ignore text, the ignore text doesn't display. To fix this put a space between the hidden and ignore text. Also, when you create sort keys Sky may not immediately sort them, so you need to do an Index > Resort to get the correct order.
Remember earlier when we wanted the plates to sort at the end of the list? The solution offered was to enable a section and enter the Input Delimiter before the plate number, "Plate:2". This forces Sky to group "Plate" locators together at the end, and orders them using the plate number as the page number. Now you see why using sections was easier.
SI8 EQUALS OPERATOR
SI8 introduced a new feature that makes forced locator sorting much easier. After any locator, if you type an equals sign and any number then Sky will sort that locator in the position of the typed number. For example, let's say you have an unnumbered page with a illustration "13 Shortcuts" that would fall among numbered pages on page 44. Entering the title verbatim would result in this:
Typed text: 33, 55, "13 Shortcuts"
Result: "13 Shortcuts", 33, 55
This is because Sky assumes "13" is the page number. To force it to the correct place, use the equals operator to force sort to the correct location:
Typed text: 33, 55, "13 Shortcuts"=44
Result: 33, "13 Shortcuts", 55
Sky sorts the locator as if it were on page 44 and there is no need for any hidden or ignore formatting.
When the equals sort operator is used for a locator in a section, however, it sorts the locator among those aggregated in that section. It does not change the location of the section. In the earlier example, without section delimiters or formatting, you get this order:
Typed text: 235, 236, 237, Plate 2=236, Plate 5=236, Plate 10=236
Result: 235, 236, Plate 2, Plate 5, Plate 10, 237
Unlike in earlier Sky versions, the Plate numbers don't need to be hidden, so they follow the normal behavior triggered by the "Sort Arabic numbers" setting. Here they appear in proper numeric order among all locators forced together onto page 236. This works even if there are multiple numbers in the locator text. The locator functionality is devoted entirely to the equals-operator number. No other numbers achieve locator status at all.
In the past, if parts of a book followed their own numbering systems, you defined sections (volumes, chapters, etc.) to manage the aggregated locators. It is now possible to manage some cases of aggregated locators using the equals operator—as long as the text-and-numbers (front) part of the locator can produce the proper order on a page. But it also means you can use aggregated locators to mimic sections! So book designs that might require complex section definitions can be managed much more easily with the free-form style of text-and-numbers construction with the equals operator.
Up to this point, our examples have had no formatting. If you use hidden and ignore formatting on digits preceding the equals operator, their behavior is not entirely predictable. With hidden digits, there is no change in behavior, the digits just don't display. To see what happens with ignore (green) and hidden (blue) formatting, consider the following sequences, all coded with "=1" to force sort on page 1:
a1,
a12,
a12,
a2,
a12,
a12,
a12
a1a1, a1a2, a1a3, a1b1
one1
two2
three3
four4
a1,
a123,
a123,
a2,
a123,
a3,
a123,
a12,
a123,
a13,
a23,
a123,
a123
Sky simply skips over ignored digits and forms separate numbers from the remaining contiguous unhidden digits. So, as in the last example, "123" becomes one-three rather than thirteen. Characters with hidden formatting, however, have no effect on sorting and are treated wholly as if they don't exist.
Note that the equals operator must be followed by digits, so it is impossible to use it to force sort to Roman numbered page locations.
VOLUMES/CHAPTERS/SECTIONS
This section is an introduction to Volumes, Chapters, and Sections. This pertains mainly to book series that are organized by volume or books that are organized by chapters -- where, in each case, page numbering restarts in each volume or chapter. Thus, locators must include the volume number such as "II:34" or the chapter number such as "5.13". You can imagine that the same principles to complex paragraph-numbered documents with locators like "2.4.B.16" where the page number is the rightmost digit and is preceded, moving leftward, by sections of increasing scope.
This is what the Sky Volumes/Chapters/Sections functionality is designed to handle. Locators are divided using punctuation, such as the colon in "II:34" which separates Volume II from page 34. In "4.2.B.16" the period separates all the sections, partitioning the locator into Section 1, Section 2, Section 3, and Page.
So you see that the term "sections" is a general term that does not impose meaning on itself. In fact, Sky actually sees only sections, but calls Section 1 a Volume and Section 2 a Chapter because that's what many users know about. But in terms of functionality, Volume is the same as Section 1 and Chapter is the same as Section 2. If you enter settings in the Volume 1 dialog, you'll see they appear automatically in the Section 1 dialog.
The punctuation that identifies the partition between sections is called the Input Separator or Input Delimiter. When Sky scans the locator left-to-right, it looks for the first Input Delimiter and recognizes the characters to its left as Section 1. Then it continues, looking for the next Input Delimiter and recognizes that data as Section 2, and so on. When it runs out of Input Delimiters, it looks for the page number. To tell Sky to look for a separator, you check "Enabled" in that section and type the chosen character in the Input Delimiter box. For "2.4.B.16" you would check the "Enabled" box for the first three sections.
You see there is also an Output Delemiter, which is the character uses in the generated index. These need not be the same: the Input Delimiter is a character that is easy to type and scans properly (e.g., not used elsewhere in the locator). The Output Delimiter is the character your editor expects to see in the index. If you leave the Output Delimiter field empty, Sky will construct the locator with the two sections run together with no visible partition.
The setting "Hide Repeated" will combine "II:34, II:65" into "II:34, 65". The setting "Only in Page Runs" will combine "II:34-II:39" into "II:34-39".
As a workflow practice, indexers will sometimes index the entirety of Volume II with only the page number, so as to eliminate typing "II:" over and over again. Then at the end of the volume they use "Tools > Add Prefix" to add "II:" to all of the locators in the index.
FORCE SORTING SECTIONS
SI7. Let's say you have a book whose page numbers restart in each chapter, and at the end of the book you have a section of plates. Or a diary, with date locators and a section of notes at the end of each year. We saw that a Plate section would fall naturally after the series of page number locators. In the second case, we might want "2005: 1/13, 3/9, 11/21, Note 1".
This example will have two sections defined, one for the year with the colon as Input and Output Delimiters and another the month with the forward slash as delimiter. If we enter Note 1 as a page number "2005:Note 1" it will file before all of the of sections: "2005: Note 1, 1/13, 3/9, 11/21". This is true even if there is a hidden sort code such as "2005:99999Note 1". If we make Note 1 a section "2005:Note 1/", the locator will sort correctly but the forward slash will print.
The trick is that Sky process sort and section delimiters before it does translations. If we could somehow translate the Output Delimiter forward slash to a blank, then it wouldn't print. Open the Translation Manager and enter a translation with Text="Note/" and Translation="Note". Then enter the locator as "2005:Note/ 1". Since "Note" is a section now, Section 2 in particular, it sorts after all the months. Then, after it sorts, after the Output Delimiter is processed, the Translation is processed and the forward slash is gone. The note number becomes a page number, which is handy since we may indeed want page number behavior.
You can also Translate away the entire section label and delimiter. In the Translation Manager, enter a translation Text="ZZZ/" and Translation=nothing where forward slash is the Output Delimiter. Then enter in the index "2005:ZZZ/"Whatever You Want". The locator will sort last among 2005 sections and will print "2005:"Whatever You Want".
SI8. In SI8, you only need to use the equals operator with a high number to get the Note to sort at the end of the section locator list.
SECTIONS OF NON-SYSTEMATIC LOCATORS
In some cases you may need to use the uppermost section (Volume) as a hidden sort mechanism. Let's say you have a book with different locator designs in each chapter:
SI7. To make locators appear in the index in the same order as the book, Section One can be defined purely as a hidden sort key that can control any arrangement of locators. For example, A0=introduction, B0=Chapter 1, B1=Chapter 1 Notes..., F1=Chapter 5 notes, F2=tables..., Z0=summary section. Enable Section 1 with Input=colon and Output=blank and Mixed data. Enter the Section 1 data as hidden text and you're ready to enter hidden forced sorting. Lower sections can be added as needed. For example, "A0:G3, D0:3.3, E1:4n5" which will appear as "G3, 3.3, 4n5".
SI8. In SI8 you can use the equals operator to control the order in which locators appear.
EXPERIMENTS WITH SECTION ORDER
As an experiment, let's see what happens if the sections in a locator aren't listed in their natural hierarchal order, that is, if we list Section 2 before Section 1 in the locator. If the Section 1 delimiter is a colon and Section 2 a forward slash, Sky seems to produce this order consistently:
08/2003:, 05/2004:, 07/2004:, 03/2005:, 02/2006:, 04/2006:, 06/2006:, 09/2006:, 01/2007:
The result is that Sky sorts by Section order, not order of appearance. This behavior is handy for date locators where the client wants the month to appear first. Moreover, this order is preserved if page numbers are attached to each locator. However, further experiments reveal that this behavior works only with numeric sections. Clearly this is experimental and not something Sky supports.
COMBINE AND REPEAT WITH SECTIONS
In the Locators dialog, there is a setting to the left called "Combine" that will automatically combine two adjacent page numbers (e.g., "23, 24") into a range ("23-24"). Let's use this function with the complex locator examined above, "I:a.2.3.4.5".
First enable three sections with the default delimiters, which correspond to the punctuation in the locator, one colon followed by periods. Type the locator in the Page field with some main heading and duplicate the record. Now use the page incrementer ctrl+period to increment the page number by one. Can you guess what the result will be? Since "I:a.2" are all sections, the page number is "3", which increments to "4", leaving the result "I:a.2.4.4.5".
The heading should have two locators "I:a.2.3.4.5" and "I:a.2.4.4.5". Now check Combine, making sure that all Hide Repeated boxes are unchecked. (Hide Repeated has a box under Enabled in each Section dialog.) Now look at the locator in the Preview Pane to the right: "I:a.2.3.4.5-I:a.2.4.4.5". Does this make sense? "I:a.2" is the section and is repeated for each locator. Next is the page number, 3 for the first locator and 4 for the second. The ".4.5" that follows is a suffix, which is identical for each locator.
Now let's hide the repeated sections. Go to Section 1 and check Hide Repeated. You'll see that the "I", which was repeated in the right-side locator, has disappeared since it is no longer repeated. Go to Section 2, click Hide Repeated, and you'll see the "a" disappear. Then Section 3 and the "2" will disappear, leaving only the page number with its suffix, "I:a.2.3.4.5-4.4.5".
One final issue: what happens if you enter a range that extends to another section, e.g., "I:a.3-I:b.5". Sky seems not to be able to handle this situation at all. Any time a range spans sections, the hyphen should be replaced by a translated character to preserve the desired upper page.
PARAGRAPH NUMBERING
Section locators are designed for books where every locator has a page number and sections labels for every section enabled. That is, nothing is ever omitted--there are no Sections without Pages or Pages without Sections.
As a comparison, consider a paragraph numbering scheme where any section level can define the unit and act as if a page number. That is, you might have this sequence of paragraphs: 1, 1:1, 1:2, 1:2.1, 1:2.2, 1:3, 2, 3.
What you probably want is for "2" and "3" to be interpreted as sections and only the third level to behave like a page number. If two section levels are enabled, however, Sky will not recognize the locators as intended. In every case the rightmost digit will be considered a page number, and the sequence will file this way: "1, 2, 3, 1:1, 1:2, 1:3, 1:2.1, 1:2.2", which is pages 1-3, followed by sec 1 pages 1-3, followed by sec 1 sec 2 pages 1-2. This is not desired, so one solution is to avoid sections altogether. With sections disabled, Sky will interpret the first colon and all rightward as a suffix.
A better solution might be to define sections at all levels, with a universal Input Delimiter that triggers sections at each level. The section designator could optionally be omitted at the rightmost level in order to make the preceding number a page number, and thus trigger Combine and Hide behavior. The Output Delimiter would be empty. Colons and periods would be entered after the section designator and would be processed as prefix characters.
For example, let's enter "|" as the Input Delimiter for all sections and nothing in Output Delimiter. Then the paragraph sequence above would be coded this way: 1|, 1|:1|, 1|:2|, 1|:2|.1|, 1|:2|.2|, 1|:3|, 2|, 3|. Entering a locator with the section designator like "2|" triggers a section, and so the index now has no page numbers, only sections. Alternatively, to trigger page numbers at the third level only, just leave off the trailing "|" section designator for locators that contain all three levels. This way you can trigger Combine behavior for the locator level: "1|:2|.1, 1|:2|.2" will combine as "1:2.1-1:2.2" or, with Hide Repeated enabled, "1:2.1-2". The full locator list woud be "1, 1:1, 1:2, 1:2.1-2, 1:3, 2, 3".
NOTES IN FRONT MATTER (ROMAN NUMERAL LOCATORS WITH SUFFIXES)
Roman numeral locators do not allow prefixes or suffixes. However it appears that hidden sort numbers and ignored suffixes will produce predictable sorted results. So to produce "ivn5, ivn6", enter iv2n5 and iv3n6, with 2 and 3 in Hidden Formatting and n5 and n6 in Ignore Formatting. It is also possible to include a space after the page number (e.g., iv 2n5) for a presentation that is arguably more readable.
NUMBER SORTING IN HEADING FIELDS
Remember that all of these rules apply specifically to the Page field. In the headings fields (Main, Sub1, Sub2, etc.), Sky does not parse heading text to identify prefixes and suffixes. Numbers are treated as text characters and sorted according to ASCII character filing rules. Imagine this sequence of Main headings:
1 partridge in a pear tree
11 pipers piping
12 drummers drumming
2 turtle doves
3 French hens
It sorts in this order, "1, 11, 12, 2, 3", because all of the entries beginning with the "1" character come first.
There is an Options setting, however, that changes how this works. If you check "Sort Arabic Numbers" in Options > Index > Sorting, then Sky will see "1, 11, 12, 2, 3" as a list of numbers and the sorted sequence becomes "1, 2, 3, 11, 12". And remember it does this by converting each of them internally to a five digit number, "00001, 00002, 00003, 00011, 00012".
If you use Hidden formatting on any of the numbers, as discussed above, Sky doesn't recognize the number and convert it, so you have to provide the five digits manually. With Sort Arabic Numbers checked, the sequence "1, 11, 12, 2, 3" ("2"=hidden) will appear as "1, 3, 11, 12, 2" because Sky sees the headings as "00001, 00003, 00011, 00012, 2". So to get the correct sort, you enter the five digits manually: "1, 11, 12, 00002, 3".
Updated 5/28/2019