BBOalert

Alerted calls should contain at least three text fields separated by commas :

<context>,<call>,<explanation>[,optional text ignored by BBOalert]

where "context" is the bidding sequence preceding the "call". In those two fields we use two-character self-explaining tokens :

1C 1D 1H 1S 1N Db Rd 2C 2D ....

To increase the readability of the code :

• we use '--' token for pass instead of 'Pa'
• outside of the data records free text is allowed for documentation purposes
• leading and trailing spaces and tabs are allowed in all fields.
• spaces are allowed in the context field

Examples

Opening bid

,1N,12-14p balanced

Note :

• empty "context" field in the first record, because there is no bid before the opening
• Eventual passes preceding the opening are ignored

Development

1N--,2C,Stayman can be weak
1N--2C--,2D,No 4 card major

Note : -- codes mean pass by opponents

Development with opponents overcall

1HDb,Rd,9+p misfit !H penalty redouble

Overcall

1D,2D,Major two-suiter

Advanced features

Seat-dependent openings

An empty "context" field means seat-independent opening. By using leading -- codes you can define seat-dependent opening. Placed after seat independent opening code, it will override it for the specified seat. Example

,1S,12-21p 5+!S,    This is the normal opening for all seats
----,1S,8-21 5+!S,    except after two passes. It can be weaker
----1S--,2C,Drury,    in such a case Drury is used

The alternative prefered method of coding seat-dependent openings is presented in the section "Optional code".

Continued context

If the context is identical with the previous record, the '+' character can be used in the "context" field

Example : instead of code

1N--,    2C,    Stayman
1N--,    2D,    Texas !H
1N--,    2H,    Texas !S

you can use code

1N--,    2C,    Stayman
+,       2D,    Texas !H
+,       2H,    Texas !S

Markdown lists

Bidding sequences can be coded in form a hierarchical lists. Markdown language unordered lists syntax apply. Example :

,1N,15-17p
- 2C Stayman
    - 2D no 4-card major
        - 2H weak major two-suiter
- 2D Transfer

Following rules apply :

• Starting point of the tree is to be coded in the normal way (context,call,explanation)

• Indentation

  • Level 1 must start with a hyphen with no leading spaces
  • Level N indentation = (N-1)x4 spaces (exactly multiple of 4) and a hyphen

• Within the list the call and its explanation should be separated by space(s) and/or tab(s), not by a comma

• By default opponents are assumed to pass. If they don’t, add their bid before your bid separated by a comma. Example of a 2C response after RHO’s double :

  ,1N,15-17p

  • Db,2C to play

• Asterisk may be used instead of hyphen

Continuation line

To increase the readability, it is possible to split a long record over more than one line. When a record ends with a backslash, it is cancatenated with the next record. Example : instead of

  (1N--|2N--|2C--2D--2N..),               3C,     Puppet Stayman

you can write :

  (1N--|\
   2N--|\
   2C--2D--2N..),               3C,     Puppet Stayman

Long explanation text

If you need more than 69 characters to explain the alerted call, the solution is to place in the middle of the text the '#' character. It will split the text into two parts : the first part will be used in the explanation field of the bidding box. The second part will be set in the chat box. In the second part
code may be used as line break to split the text over multiple lines when it is sent.

Example :

1S,2C,Please read chat for explanation#Natural overcall with at least a decent 5-card suit

The chat message will be sent automatically. Make sure that the chat messages are adressed to the opponents. Your partner is not supposed to read your auto-alert.

Wildcards

In the cases where the meaning of the call is not influenced by an eventual overcall, wildcards can be used in the "context" field. This can make the code more readable and more compact. Two characters are allowed as wildcard '*' or '_'. They match one character and have the same effect. In this example :

1N__,2H,Transfer->!S

the code means : whatever the opponents do, 2H remains a mandatory transfer to 2S. Otherwise code should be provided for all possible overcalls made by the opponents.

Regular Expressions - RegEx

Both, "context" and "call", fields can be also formatted as regular "RegEx" expression in the process of matching with the actual bidding context.

RegEx can be used in two forms :

• explicit by encopassing the string between slashes : the matched strings may have different length (partial match)
• implicit without slashes : the matched strings should be of the same length (full match)

RegEx is a very complex mechanisme, but in BBOalert we use primarily one type of expression : groups of string matching patterns. The example below can be used as template :

  (1N--|2N--|2C--2D--2N..),               3C,     Puppet Stayman

This means that 3C call is defined in one record, instead of 3, as Puppet Stayman in three similar situations :

• after 1NT opening
• after 2NT opening
• after 2C-2D-2NT sequence

Further development can be coded as :

  (1N--3C--|2N--3C--|2C--2D--2N--3C--),       3D,    at least one 4 card major
  +,                                          3H,    5 card !H
  +,                                          3S,    5 card !S
  +,                                          3N,    no 4+ card major

For matching a single character, brackets should be used as in the example, where after either 1H or 1S opening, Jacoby 2NT raise is used :

  1[HS]--,2N,+12HCP and 4+ card fit

Asterisk wild card must be avoided in the regular expression. It matches strings of any length and will lead to unpredictibles results. If used, asterisk (and also underscore) will be internally converted to a dot (single character match).

If the ‘context’ field starts and ends with a slash, it is interpreted as a pure RegEx. Any regular expression is allowed, but 4 patterns are relevant for context matching

  //                            match any string
  /^startString/                match starting string
  /endString$/                  match ending string
  /^startString.*endString$/    match both
  /^String$/                    exact match

Examples :

  //,4N,Blackwood 5 key cards               ,after any bidding sequence 4NT is Blackwood
  /^1N/,4N,Quantitative slam try            ,except after 1NT opening
  /4N--$/,5C,1 or 4 key cards               ,response to Blackwood
  /4N--$/,5D,0 or 3 key cards
  /4N--$/,5H,2 key cards without trump Queen
  /4N--$/,5S,2 key cards with trump Queen
  /Db$/,--,to play doubled                  ,in any case pass after double is to play
  /Db$/,Rd,forcing; may be SOS              ,but redouble is forcing
  /^(1N|1N----)$/,Db,for penalties

When the field contains a regex group containing a list of possible bids with different explanations, the explanations can be listed in the same one record in supplementary comma separated fields.

Example : 

1N--,(2C|2D|2H|2S),Stayman,Texas !H,Texas !S,Texas !C

Wildcards and regular expressions are powerfull features to get more compact code, but must be used carefully.

User definable scripts

To use this feature the knowledge of RegEx and JavaScript is required. Portions of the text can be replaced by the result returned by a user definable script. The script name is enclosed between two % characters.

Scripts may be used in fields :

• bidding context
• call
• explanation text
• shortcut text
• button text

An example of data file :

  BBOalert
  Script,X,R = C.match(makeRegExp(CR))[1];
  Script,Y,R = C.match(makeRegExp(CR))[2];
  1([HS])--,2N,+12HCP and 4+!%X%
  1([HS])2([CD]),2N,11-12HCP misfit !%X% stopper !%Y%

Note : X and Y are arbitrary script names,and there are no specific limitations.

• The script should use variables :
  • CR : field
  • C : actual bidding context
  • BR : field
  • B : actual call (bid)
  • R : string to be returned
• The script may use the makeRegExp function, which transforms the string into a RegExp object. BBOalert wildcards _ and * will be replaced by dots.
• The script may be of any complexity :
• Each statement must end with ;
• To span the script over multiple lines \ should be used at the end of the line

More information about scripting can be found in the "Scripting in BBOalert.pdf" file.

Scripting allows custom data syntax. This feature is experimental : see this folder for details

Optional code

Almost everyone on BBO is using the SAYC bidding system. But SAYC is not the world standard and some opponents will use another bidding system such as ACOL or French Standard. If you play on BBO with your partner to practice a sophisticated defense system - with particular agreements that depend on the conventions used by the opponents - you must be able to switch on-the-fly between different defense options during the game.

To solve this problem, the keyword 'Option' followed by the option name are used. The optional block of code is ended by another optional block or by bare 'Option' keyword. The selectable options will be displayed on the red "Options" panel.

The subsequent options with the common prefix word will be grouped automatically. Within the group only one option can be selected to avoid conflicting codes (mutually exclusive options). You are free to disable any option. Initially the first member of each group is enabled. This feature is typically used for :

• defensive bidding depending on the system played by the opponents. It is recommended to provide all overcalls in optional code blocks for each possible opening. This will allow you to unselect portions of code if necessary. Example :

  Option,vs1NT weak
  ... code for overcalls after weak 1NT opening
  Option,vs1NT strong
  ... code for overcalls after strong 1NT opening

• disabling by default the recorded alerts by creating two mutually exclusive options. The prefix word Recorded may be replaced by a word of your choice.

  Option,Recorded OFF
  Option,Recorded ON 

Optional blocks of data can be used also for :

• vulnerability-dependent openings by using @n or @v tags (our vulnerability) or @N or @V (opponent's vulnerability)

• seat-dependent openings by using @1 @2 @3 and @4 tags. Seat dependent overcalls must be coded explicitely as in the example :

  --1D,1H,<explanation text>

This is 3rd seat overcall not 3rd seat opening.

The selection is done automatically if the block name contains any @ tag. This selection can be then manually overridden by the user during the game. Combining tags is allowed.

Spaces should be avoided in the option names containing @ tags. I recommend to use underscores instead.

In this example :

Option,Opening_@v@3@4

the option will be enabled if vulnerable in 3rd or 4th seat.

Example :

Option,NT 15-17
    1N,Db,any 6 card suit (DONT)    
Option,NT 12-14
    1N,Db,for penalties
Option,2H weak
    ... code specific for the defense against weak-2 opening
Option,2H weak 5!H and 4+m
    ... code specific for the defense against Muiderberg opening
Option,MyOpenings_@n
    ,1N,12-14 balanced
Option,MyOpenings_@v
    ,1N,15-17 balanced
Option

In this example three separated groups of options are created.

Options can contain also other types of records (Shortcut, Button, Trusted, Untrusted, Script, Alias). Those records will be active only if the option is enabled.

Fragmentation of options is allowed. If two or more options are defined with the same label, they are all concatenated inside of BBOalert. But if you want to define partnership, you have to do with the first occurrence of an option. This way empty options can be declared in the beginning of the data. The code for each option can be provided later in the file not necessary in the same order. Example of a construct :

Option,A,me+partner1
Option,B,me+partner2
Option,C
Option
……..
Option,B
… code part 1 for option B
Option
………
Option,A
… code for option A
Option
……..
Option,B
… code part 2 for option B
Option

Sometimes it is useful to insert a separator between different groups of options. To achieve is declare a dummy option ending with the @s tag. The separator should be immediately followed by a regular option record.Example :

Option,Overcalls@s
Option,vs1NT Strong
.... some code

This will create a supplementary button with centered "Overcalls" text at cyan background.

Partnership options

Let us assume that you play different conventions with different partners. The option selector enables you to use certain options only when playing with a given partner. Example : you play weak NT with John and standard NT with Joe. This affects the NT rebid after the opening in a minor. The BBO user-id's of your partners can be specified in supplementary fields of the Options record. More than one name is allowed separated by a comma. When two user-id's separated by a + are specified with an option and both players are present, the option is activated automatically. Sample data :

  Option,  1NT 12-14,  John
  ,  1N,   12-14p balanced
  1[CD]--1*--,   1N,   balanced 15-17p
  Option,  1NT 15-17,smazur+stanmaz
  ,  1N,   15-17p balanced
  1[CD]--1*--,   1N,   balanced 12-14p
  Option

If you choose John as partner the 1NT 12-14 option will be enabled and 15-17 disabled :

If you play with a partner who is not specified with any option, you may choose options manually (first Options-All) or select the options of another partner.

It is possible to disable all options by chosing 'Options-None' from the dropbox. This feature can be used to disable also your entire bidding system if you declare it as an option.

Trusted code

The code between the keywords 'Trusted' and 'Untrusted' will not require to be confirmed, even if 'Confirm Bids' toggle switch is ON. The number of occurences of trusted code blocks is not limited. In the example below, the explanation of 1C and 1D opening will be sent immediately, whereas 1N will required confirmation by pressing the OK button.

  Trusted
  ,1C,16+HCP any distribution
  ,1D,11-15HCP not 5 card major
  Untrusted
  ,1N,13-15HCP balanced

Keyboard Shortcuts

Shortcut format :

Shortcut,<token>,<full text>

In this example :

Shortcut,TH,Texas->!H

TH string will be immediately expanded to the "Texas->!H" during text entry in the Message or Explanation text box. The tokens can be of any length , but we advise to use uppercase two-character tokens to avoid confusion during normal text entry.

You are also allowed to define Alt-key shortcuts as shown in this example :

Shortcut,AltA,this text will be inserted if you press Alt-A key

The \n token within the shortcut text will split it and each part will be sent immediately. Example :

Shortcut,WC,Welcome\nwe are playing SAYC\nItalian discard\n

This should be used only in the chat box only to increase the readabilit of the message by subdividing it separate lines.

Note : check for potential conflicts with Alt key shortcuts of the browser.

Button Shortcuts

Shortcuts can be defined as buttons displayed on a panel. Pressing a button will have the same effect as keyboard shortcut. The panel is disabled by default. To enable it press 'Shortcut' button on the blue panel. It will turn from red to green. The button panel will be displayed when clicking the explanation or chat entry text field. Clicking again will toggle button panel display.

At the top of the panel three buttons are predefined to erase single character, word the whole line of text.

The data format is similar to keyboard shortcuts :

Button,<token>,<full text>[,optional properties]

This will create a button with label. Pressing the button will append

Example

Button,Hello,Hello; We are playing ACOL

You don't need to duplicate keybord shortcuts into buttons. Keyboard shortcuts will be displayed together with button shortcuts.

The default button properties are :

• width=50% (25% for keyboard shortcuts)
• backgroundColor=white
• color=black

You can override the defaults with the optional properties. Properties should be separated by a space character. Properties can be also appplied to keyboard shortcuts. Example :

Button,Hello,Hello; We are playing ACOL,width=100% backgroundColor=green color=white
Button,♣, !C,width=18% fontSize=40px borderRadius=100%
Button,♦, !D,width=18% fontSize=40px borderRadius=100% color=red
Button,♥, !H,width=18% fontSize=40px borderRadius=100% color=red
Button,♠, !S,width=18% fontSize=40px borderRadius=100%
Button,NT, NT,borderRadius=20% width=28% fontSize=40px
Button,Texas,Texas,width=50% backgroundColor=orange
Button,Transfer,Transfer,width=50% backgroundColor=lightgreen

The list of color names can be found on page : https://www.w3schools.com/colors/colors_names.asp

The full list of property names (only a few apply to buttons) : https://www.w3schools.com/jsref/dom_obj_style.asp

Shortcut records wiil be also automatically displayed on the "Shortcuts" panel as buttons. The same attributes can be assigned to shortcuts as to buttons.

Shortcuts,HO,Hallo opps,width=50% backgroundColor=orange

If you do not want a shortcut to appear on the buttons panel you may use the "Display" attribute as in the example :

Shortcuts,HO,Hallo opps,display=none

Alias

The format of an alias record is :

  Alias,<string1>,<string2>,<tags>

If any explanation text record contains it will be replaced by . Following rules apply :

• An alias must be defined before it is used
• must not be necessarily unique
• Always the last match is used for string substitution
• The aliases should be sorted from the shortest to the longest
• In both strings case and spaces matter (leading and trailing). Note : to keep the visual control of trailing spaces in a comma may be added at the end of the record.

Optional may be used to restrict the use to a specific data field :

• @C : context field
• @B : call field
• @E : explanation field
• @G : global : String substitution on the record before parsing. This allows formatting the whole data records dynamically. As the comma is not allowed in the alias text, the HTML entity , should be used instead.
• no tag : String substitution on all fields after parsing

Examples of the use of tags :

• @C@B : prevents to substitute the character “m” in the explanation text

  Alias,m,[CD],@C@B

• The @G tag allows using the plain language to make the code more readable

  Alias,Opening 1 club : ,,1C,,@G Opening 1 club : 16+p any distribution

• The @G tag allows to use a custom field separator. E.g. : he vertical bar can be used as a field separator instead of a comma. This technique allows to present the list opening bids as a table in markdown format.

  Alias,|,,,@G | 1D | 4+!D |

The main purpose of aliases is to solve the problem of national bridge events where the usage of the local language is required. Maintaining two different data files for two different languages is not practical. The aliases can be used to translate expressions depending on the selected language. Example of code :

  BBOalert
  Option,Lang EN
  Shortcut,HH,Hello
  Option,Lang FR
  Shortcut,HH,Bonjour
  Alias,balanced,régulier
  Alias,game forcing,forcing manche
  Option,MySystem
  ,1N,15-17p balanced
  ,2C,game forcing

Sorting aliases by length is important (remember : last match counts). In the example

  Alias,without,sans
  Alias,with,avec

The word ‘without’ will be translated to ‘avecout’ which is wrong. Reversing the order will give the correct result.

Aliases may be used also in the bidding context or in the call field. Example :

  Alias,#,2C--2D--
  #2N--,3C,Puppet Stayman

Is equivalent to

  2C--2D--2N--,3C,Puppet Stayman

The same alias may be reused later in the file with a different definition.

This technique may be useful when the same long context prefix is used at different places. The alias may not be combined with + in the same context field.

Full Disclosure BSS file support

BBOalert can read BSS files in the same way as native BBOalert :

• open the BSS file with a text editor
• select all text and copy it to the clipboard
• in BBOalert use 'Import' button.

BBOalert converts BSS data internally to the BBOalert native format. Vulnerability-dependent calls are supported (@n or @v tag in the optnion name). Seat-dependent openings are set in separate optional blocks (@1 @2 @3 or @4 tag in the option name).

The converted data is available in the clipboard. You can paste it into the text editor and use it as a starting point for further modifications. Another possible scenario is to keep importing the original BSS file and to create an overriding code (in BBOalert native format) in a separate file to be appended later ('Append' button).

Using BBO convention card to share data

Note : this feature has been disabled

To share the data with your partner via the BBO server :

• make a convention card (Account+Convention Card) using "SAYC - Standard American Yellow Card" or "Simple Modern ACOL" as template
• open it for editing
• make it shareable by filling your partner's name
• press "Get from BBOalert" to append your data to the text in the "Defensive Carding" text
• press "Save Changes"

Note : while editing the "Defensive Carding" text, do not alter anything beyond the large square character which separates your text from the BBOalert data.

This convention card together with the BBOalert data will become available for your partner. To load data into BBOalert

• open the convention card for editing
• press "Send to BBOalert"

Web storage support

BBOalert allows to store data on a file hosting server and to import it dynamically at the beginning of each session. This facilitates the file sharing making sure that both partners use the same data. Actually three sites are supported with their specific limitations due to the particular data security implementation :

• GoogleDocs : The data can be formatted as a pretty readable and printable document. Both partners can edit the document online
• GoogleDrive : The data can be imported from text files stored in GoogleDrive.
• Github : only ASCII text files are supported. Both partners can edit the data online. To make the data more readable the Markdown format should be used. Markdown format is standard for documentation purposed in Github environment.
• Dropbox : only ASCII text files are supported without the possiblity of online editing
• Google Blogger https://www.blogger.com

We assume that you are familiar with the tool of your choice.

Notes :

• GoogleDocs and Github provide version control. You can easily follow the file history and eventually revert to the previous version.
• Github uses explicit static file names in the URL link. GoogleDocs and Dropbox use dynamic cryptic file ID's instead.

To access the data BBOalert needs a public URL link to the file. For each site the procedure is different.

Google Docs

GoogleDocs documents can be used to contain the data. BBOalert recognizes only paragraphs with the 'normal text' attributes. Also buletted lists may ne used to represent a hierachical bidding trees. Other document elements (headers, footers etc) are ignored.

The public URL can be obtained in the following way :

• open the data file in Google Docs
• use the “Share/Publish to the web” command from the “File” menu
• Press the “Publish” button
• the public URL link is displayed and can be used by BBOalert to import data

More details can be found in the document :

https://docs.google.com/document/d/1XTma7fZbI0pRU3TtNFOLAG0sUKyBaXFtkQAu90rwfRY/edit?usp=sharing

GoogleDrive

Support discontinued

The data can be imported from text files stored in GoogleDrive cloud. The URL link for public viewing should be used with the “Import” record. Note : the file size is limited to 260k bytes

The public URL can be obtained in the following way :

• open the GoogleDrive folder containing the file
• select the file with the right mouse button
• select the "Get link" command
• make sure that under "General Access" the "Anyone with the link" and "Viewer" options are selected
• Press the “Copy link” button

OneDrive

The data can be imported from text files stored in OneDrive cloud. The .txt file extension must be used. The URL link for public viewing should be used with the “Import” record. Note : the file size is not limited.

The public URL can be obtained in the following way :

• open the OneDrive folder containing the file
• select the file with the right mouse button
• select the "Share" command
• By default the link will allow editing the file. To avoid uncontrolled file editing by anyone, it is recommended to restrict the link to the view permission :
  • Click at the "Anyone with the link can edit"
  • In the new dialog box change “Can edit” field into “Can view” and press “Apply” button
• make sure that under "Copy Link" the "Anyone with the link can view" is selected
• Press the “Copy” button

Github

• make public the repository where you store the data
• upload the existing file from the PC or create a new data file and edit it
• to obtain the public URL link select the data file with the right mouse button and use the "Copy link" command from the pop-up menu

Dropbox

• edit your data locally as an ASCII file
• upload it to your Dropbox account
• make the file shared
• generate the public URL link for viewing only (default is editing)

Blogger

Note : This section is under development

BBOalert data

Your data can be split in separate files.

Each piece of data can be loaded into BBOalert with the Import statement as follows :

Import,<file URL>

Hierarchical nesting of linked files is allowed (Each file may contain a link to another file)

In extreme case one can define locally the whole bidding system with only two lines of code as in the example of our system :

BBOalert
Import,https://github.com/stanmaz/BBOalert/blob/master/Systems/stanmaz/wholeSystem.md

The rest of the data will be loaded by following the link above.

Handling a large data file is not easy and subdividing it into smaller linked pieces is a great help. This enables collaborative editing and easy sharing of effort. Each module can represent a convention that can be published within the users group on Facebook and reused by others.

The URL’s used in the “Import” records are long and cryptic because instead of real file names the cloud service providers use file ID’s to identify the file. It is possible to create an alias using an arbitrary short name. The advantages :

• Readability of the code
• Easy data maintenance if the URL changes

Example : instead of

Import,https://docs.google.com/document/d/e/2PACX-1vSz8gq9LwJQ2UY5El6czdaElyvzSjQMx1dvrIh9Ss_0-muXDwr9-7N8bAblEryG0QwkKcgWIivR3WXs/pub

First define an alias at the data beginning

Import,1C_Opening,https://docs.google.com/document/d/e/2PACX-1vSz8gq9LwJQ2UY5El6czdaElyvzSjQMx1dvrIh9Ss_0-muXDwr9-7N8bAblEryG0QwkKcgWIivR3WXs/pub

And then use

Import,1C_Opening

Note :

• URL aliases must be defined before they are used
• Import aliases must be defined in the root file of the hierarchical file organisation.
• Multiple definitions of the same alias (same alias, different URL’s) are allowed : the last one will be used.

Scripts

Until now all Javascript code was included in the data file. With this release it is possible to save every piece of Javascript code in separate files and use the public link in the data file as in this example:

Javascript,https://github.com/stanmaz/BBOalert/blob/master/Scripts/stanmazLib.js

Storing scripts on the web has two advantages :

• Smaller data file. Scripts are not merged with the user data but dynamically added to the BBOalert program.
• Published scripts can be shared with others

Support for the generic BBO convention card

Note : this feature has been disabled

The drawback of the generic convention card (templates : “BBO Advanced (2/1=GF)” “SAYC - Standard American Yellow Card” or “Simple Modern Acol”) is the lack of text formatting features. The problem is that BBO software removes new line characters and elimines multiple spaces or tabs. The text displayed to the opponents is very hard to read.

This problem can be solved by using underscore characters instead of spaces. BBOalert replaces then underscores by non-breaking spaces before saving data on the server. To be correctly displayed to the opponents each line of text should be approximately 25 to 40 characters long.

The BBO convention card editor is not easy to use. With BBOalert the CC text can be prepared in advance and included in the data in the format :

CC,<fieldID>,<text>

Then :

• Import your data that includes the CC records from the clipboard (the CC should not be defined in the file dynamically imported from Dropbox)
• Select Account tab
• Select Convention Cards
• Select any of the existing CC templates listed above
• Press Edit
• Press “Get from BBOalert”
• Set the BBO userid of your partner and press Save

You can use this template to prepare your data (hint : set the keyboard to overstrike mode to preserve text line length). The field ID’s are self explanatory.

CC,summary
… text for “System Summary” section
CC,ntopen
… text for “Notrump Openings” section
CC,majoropen
… text for “Minor Suit Openings” section
CC,minoropen
… text for “Minor Suit Openings” section
CC,level2open
… text for “2-Level Openings” section
CC,other
… text for “Other important notes” section
CC,doubles
… text for “Doubles” section
CC,ntocalls
… text for “Notrump Overcalls” section
CC,socalls
… text for “Simple Overcalls” section
CC,over1nt
… text for “Over 1NT Openings” section
CC,jocalls
… text for “Jump Overcalls” section
CC,overtox
...text for “Over Takeout Doubles” section
CC,directq
...text for “Over Takeout Doubles” section
CC,slam
...text for “Slam Bidding” section
CC