Formatting field values and using patterns

Depending on the requirements of your situation, you can specify one or more of the following patterns to control how field values, such as text fields, numeric fields, and date/time fields are formatted at run time:

  • A display pattern, which describes how data will be displayed in the form. If you define an initial default value, it is formatted according to the display pattern. The display pattern is also responsible for formatting user input and any bound values retrieved at run time.

  • An edit pattern, which describes the syntax for entering data into a date/time field, numeric field, text field, or password field at run time.

  • A validation pattern, which is used to validate user input at run time.

  • A data pattern, which describes the syntax of bound or saved data.

The formatting options that you choose will depend on the purpose of your form. For example, if you are designing an interactive form, for each field you should define an edit pattern to process user input and a validation pattern to validate the input. You would only define a data pattern if the fields are bound to a data source.

Keep in mind that if you specify only an Edit pattern for a Numeric Field or Decimal fields object, form fillers can still enter alphabetic characters in the field. To avoid this behaviour, do one of the following actions:

  • Do not specify just an Edit pattern. Ensures that Acrobat and Adobe Reader filter out unwanted alphabetic characters.

  • Specify Edit and Display patterns. Ensures that the data is formatted correctly according to the Display pattern.

  • Specify Edit and Validation patterns. Ensures that the value is rejected and the field is cleared when a form filler enters an alphabetic character.

When to use patterns

Use patterns to control how field values are processed at run time. For example, users can enter letters and numbers into a text field and any special punctuation or spacing can be applied automatically according to a predefined pattern before the value is displayed.

Capturing and displaying user input

If you are creating a form to capture data, you can specify how data should be formatted. You specify how the data should appear using a display pattern. If you do not specify a display pattern, the data appears according to Designer defaults.

If users will be entering data that does not match the Designer defaults, you must specify an edit pattern. The edit pattern describes the syntax of the user input. Given the pattern, the run-time application converts the user input into a raw value and then formats the value according to the display pattern.

If you are designing an interactive form, consider what user input must be validated. For example, a text field may or may not require validation depending on usage. A multiple line text field allowing the form filler to enter a comment does not need to be validated. Similarly, a numeric field will automatically prevent the form-filler from entering any non-numeric data. However, if the data has to be restricted to a specific range of numbers, you will want to validate the user input. You can choose to display a custom message to prompt users for a correct value at run time. If you do not specify a custom message, the system generates one automatically.

Remember that by using the options on the Form Validations tab in the Form Properties dialog box, you can configure how Acrobat displays validations messages, highlights failed or mandatory fields that contain invalid data or no data, and sets the focus on the first field that fails to validate. See Displaying validation errors in Acrobat .

Note: User input can be processed through FormCalc formulas and JavaScript scripts (for example, a script can request the raw value of a field). Because formulas and scripts operate on raw and formatted values, it is important to validate those fields where input is restricted.

One example of how an edit and validation pattern may be used together is a credit card or social security number entry. You could define a text field with the following edit patterns:

text{9999-9999-9999-9999}|text{9999 9999 9999 9999} for credit cards

or

text{999-99-9999}|text{999 99 9999} for a US social security number

In both cases, the user may enter the number with hyphen(-), space ( ), or just the 16 or 9 digit number. The canonical, or simplest form of the number is the 16 or 9 digit number.

You may also choose to add the following validation pattern:

text{9999999999999999}

or

text{999999999}

In this case, only the number is stored and the validation checks for the correct number of digits. However, in this case, it might be more useful to specify a validation script rather than a pattern. There are algorithms that will checksum a credit card number to ensure that it looks like a valid credit card number and not just a random 16 digit number. An example is the Luhn Algorith for credit cards.

The result is a form that has a text field where the edit pattern allows user entry in one of three typical ways for typing a credit number, and the validation runs a script that validates that the number looks like a valid credit card number.

Retrieving and displaying bound data

If bound data will be merged with a form, you can specify how the data should be formatted for display using a display pattern. If you do not specify a display pattern, the data is displayed according to Designer defaults.

If the bound data does not match Designer defaults, you must specify a data pattern. The data pattern describes the syntax of the bound data. Given the pattern, the run-time application converts the retrieved data into raw values and then formats them for display.

Defaults for value formatting

Default values must conform to the following rules, depending on the type of field.

Field

Rule

Date/Time Field

A default date/time value must conform to the short format for the locale specified for the date/time field. However, by default, Designer displays the default value in the medium locale format at both design time and run time.

For example, consider a form with a Date/Time Field set to use the German (Germany) locale. You enter the default value for a date in the short format DD.MM.YY. After you change the focus to another field, the value specified in the field on the page is displayed in the medium format DD.MM.YYYY. The formatted value also appears in the medium format if you view the form in the Preview PDF tab.

Note: At run time, by default, form fillers must edit the value of date/time fields using the short format for the locale specified for the field. If you specify an Edit Pattern on the Edit tab in the Patterns dialog box (Field tab > Patterns), that pattern overrides the short format, and users must enter data that conforms to the Edit Pattern.

Numeric Field or Decimal Field

A default numeric value can be any integer or any decimal number that contains a single radix point. The radix character can be either a “.” (period) or “,” (comma) depending on the locale selected. Thousands separators (or grouping symbols) and currency symbols are not valid as part of the default value.

For example, if a numeric field is set to the locale English (USA), and you specify the default value $1,234.56, both the currency symbol “$” (dollar sign) and the thousands separator “,” (comma) are not valid.

Text Field

A default text value (including passwords) can be any alphanumeric text string, including spaces.

Note: Only those fields listed in the table have default values that must conform to locale-specific formatting.

To specify a default value

Date/time fields, numeric fields, and text fields can display an initial (default) value when the form is opened. The value can be derived from a run-time property, or you can specify the value explicitly in Designer. The value can also be derived from an external data source through binding. At run time, Designer formats field default values according to the locale specified for each field.

  1. Select a date/time field, decimal field, numeric field, or text field.

  2. In the Object palette, click the Field tab. Select a locale from the Locale list.

  3. In the Object palette, click the Value tab. Type the value into the Default box.

    The default value must be specified in locale-sensitive format.

    Note: If the data is bound and a data pattern has been specified, the value must match the data pattern specified in the Binding tab.

To specify a display pattern

At run time, Designer displays date, time, and numeric field values in locale-sensitive format. If you want to display a field value in a format other than the default, you can specify the custom pattern by clicking the Patterns button on the Field tab.

Note: Drop-down lists support custom user entries, but a display pattern for custom user entries cannot be specified. You can write a script to format the user input if required.

Because the display pattern describes how data will be displayed in the form, all default values, user-entered values, and values retrieved from a database are converted to the format described by the display pattern.

Note: Dates earlier than January 1, 1900 are not formatted by the display pattern.
  1. Select the date/time field, numeric field, or text field.

  2. In the Object palette, click the Field tab.

  3. Click Patterns and either select one of the predefined display patterns from the Select Type list or type a custom pattern in the Pattern box.

To prompt users to enter data

Prompts are useful for situations where users are expected to enter data or make a selection. You can write a message to prompt users to enter a value into a date/time field, numeric field, text field, password field, or drop-down list, or prompt users to select an option from a drop-down list, list box, or radio button group.

Recommending that users enter data

You can recommend that users enter data in a field but still let them submit the form if they do not. If a user enters data in the field, leaves the field and then clears it, a message box appears. A custom message appears if one written in the Empty Message box. A standard empty field message appears if you do not type a custom message. A message only appears if there was data in the field, the value was deleted, and the user exited the field without re-entering data. If the user never attempts to enter data in the field and tries to submit the form, a field is required message appears. The user can choose to ignore the message and submit the form. Choose User Entered - Recommended to recommend that users enter data in a field.

Requiring that users enter data

You can make it mandatory for users to enter data in a field before they can submit a form. If a user enters data in the field, tabs out, and then returns to clear it, a message box appears. A custom message appears if one written in the Empty Message box. A standard empty field message appears if you do not type a custom message. A message only appears if there was data in the field, the value was deleted, and the user exited the field without re-entering data. If the user never attempts to enter data in the field and tries to submit the form, a field is required message appears. Choose User Entered - Required to make it mandatory that users enter data in a field.

Remember that by using the options on the Form Validations tab in the Form Properties dialog box, you can configure how Acrobat displays validations messages, highlights failed or mandatory fields that contain invalid data or no data, and sets the focus on the first field that fails to validate. See Displaying validation errors in Acrobat .

Note: If users do not enter a value into the field and try to submit the form, the error message field is required appears. However, users can save and close a PDF form without providing recommended or required values. In this case, no messages appear to prompt users for input.
  1. Select the field, drop-down list, list box, or radio button group.

  2. In the Object palette, click the Value tab. From the Type list, select one of these options:

    • User Entered - Recommended

    • User Entered - Required

  3. In the Empty Message box, type the prompt. If applicable, the prompt should specify the required input format. For example, if you defined an edit pattern, the user input must conform to the edit pattern.

To specify an edit pattern

At run time, Designer displays date, time, numeric, and decimal field values in locale-sensitive format. If you want to permit form fillers to edit field values in a format other than the locale-sensitive default, you can specify an Edit Pattern on the Field tab. If the user’s input does not conform to the edit pattern, the data is input as-is.

If you specify only an Edit pattern for a Numeric or Decimal field object, form fillers can still enter alphabetic characters in the field.

The edit pattern can be different than the display pattern. For example, because it is easier for users to enter short dates and read long dates, you could consider specifying a short date for a date/time field’s edit pattern and a long date for its display pattern. When the display and edit patterns are different, the value is formatted to match the display pattern as soon as the user exits the field.

Note: This option is not available when the Type option in the Value tab of the Object palette is set to Protected, Calculated - Read Only or Read Only.
  1. Select the date/time field, numeric field, text field, or password field.

  2. In the Object palette, click the Field tab.

  3. Click Patterns, click the Edit tab, and either select one of the predefined display patterns from the Select Type list or type a custom pattern in the Pattern box.

To validate user input

Three separate validations are possible for any field. The order of initiation of these validations is as follows:

  • Test the field for null content.

  • Verify the format of the field value against a specific field pattern. For more information about field patterns, see Simple patterns .

  • Invoke a validation script.

You can define a validation pattern to validate user input for date/time fields, numeric fields, text fields, and password fields. By default, null entries are not accepted when a value is required. Raw values are compared to the validation pattern directly and, if the raw value matches the validation pattern, it is formatted for display.

If the user-entered value does not match the validation pattern, a programming error or warning appears. The error/warning is trapped by Acrobat, Adobe Reader, or Forms, which returns a message to the user automatically. If an edit pattern has not been specified and the user input does not match Designer defaults, validation fails.

A validation message appears if objects that require values contain null values and the user attempts to submit data to Forms.

Note: Users can save and close a PDF form without providing required values. In this case, no validation is performed.

If needed, you can write a custom validation pattern message to replace the default error or warning message.

In addition to a validation pattern, or in cases where a validation pattern is not supported (for example, for radio button groups and check boxes), you can validate user input by using a validation script. Validating input through a script ensures that the data is acceptable for your application. A custom message and run-time error or warning is also supported in this case.

Remember that by using the options on the Form Validations tab in the Form Properties dialog box, you can configure how Acrobat displays validations messages, highlights failed or mandatory fields that contain invalid data or no data, and sets the focus on the first field that fails to validate. (See Displaying validation errors in Acrobat .)

You can dynamically populate a validation pattern message with a value from a data source. This option allows you to ensure that users enter a valid value in the field.

To define a validation pattern and custom message

  1. Select the date/time field, numeric field, text field, password field, drop-down list, or list box.

  2. In the Object palette, click the Value tab.

  3. Click Validation Pattern and either select one of the predefined validation patterns from the Select Type list or type a custom pattern in the Pattern box.

  4. In the Validation Pattern Message box, type a message to prompt users to enter the correct value. The message should specify the required input format. To start a new line in the message, press Ctrl+Enter.

  5. To have a programming error to appear instead of a warning, select the Error option.

To display a message when an attached script detects unacceptable input

  1. Select the date/time field, numeric field, text field, password field, drop-down list, list box, check box, or radio button group.

  2. In the Object palette, click the Value tab. In the Validation Script Message box, type the message.

  3. To have a programming error appear instead of a warning, select the Error option.

To specify a data pattern

Data binding options enable you to build a form that captures data for enterprise infrastructures and/or use an external data source to populate a form at run time. For example, given appropriate binding information (see Binding fields to a data source ) and access to the data source (see Working with Data Sources ), Acrobat and Adobe Reader can import and display data from an OLEDB database when the form is opened. Objects can also be bound to an XML schema, an XML file, or a WSDL data source.

Acrobat, Adobe Reader, and Forms interpret the data-binding properties to store captured data and parse retrieved data. By default, an object’s data is stored and merged according to Adobe data-merging rules. When a form opens in Acrobat or Adobe Reader, or is rendered by Forms, the field values are populated from the data source. Any changes to a field’s value by the user are committed to the associated data source when the form is saved in Acrobat or Adobe Reader or the data is submitted to Forms.

If the data is not bound to a data source (for example, if the form data will be returned by email), the data pattern specifies the format that the data is saved in. If you do not create a data pattern, the data will be saved in canonical format. If a form may be filled by end users in a variety of locales or if the data may be returned to more than one locale, having the data in canonical format helps ensure that it is interpreted the same way by all users.

You can specify data patterns for date/time fields, numeric fields, text fields, and password fields. If the data pattern prevents Acrobat or Adobe Reader, or Forms from parsing a retrieved value, the value appears in the form unchanged (it is not formatted for display).

  1. Select the date/time field, numeric field, text field, or password field.

  2. In the Object palette, click the Field tab.

  3. Click Patterns, click the Data tab, and either select one of the predefined data-binding patterns from the Select Type list or type a custom pattern in the Pattern box.

Simple patterns

Simple patterns can be used to format the values of date/time fields, numeric fields, text fields, and password fields. They each have their own rules governing the valid formation of patterns. There is a limited set of characters that you can use in a pattern, and the syntax of a valid pattern differs among date/time fields, numeric fields, text fields, and password fields.

For information about the valid characters that you can use in a pattern and examples of valid constructs, see one of the sections listed below. For information about complex patterns for a date/time field, numeric field, or text field, see Complex field patterns .

Locales

A locale is a standard term used when developing international standards to identify a particular nation (language, country or region). For the purposes of FormCalc, a locale defines the format of dates, times, numeric, and currency values relevant to a specific nation or region so that users can use the formats they are accustomed to.

Each locale is comprised of a unique string of characters called a locale identifier . The composition of these strings is controlled by the international standards organization (ISO) Internet Engineering Task Force (IETF), a working group of the Internet Society ( www.isoc.org ).

Locale identifiers consist of a language part, a country or region part, or both. The following table lists valid locales for this release of Designer.

Language

Country or Region

ISO Code

Arabic

Algeria

ar_DZ

Arabic

Bahrain

ar_BH

Arabic

Egypt

ar_EG

Arabic

Iraq

ar_IQ

Arabic

Jordan

ar_JO

Arabic

Kuwait

ar_KW

Arabic

Lebanon

ar_LB

Arabic

Libya

ar_LY

Arabic

Morocco

ar_MA

Arabic

Oman

ar_OM

Arabic

Qatar

ar_QA

Arabic

Saudi Arabia

ar_SA

Arabic

Sudan

ar_SD

Arabic

Syria

ar_SY

Arabic

Tunisia

ar_TN

Arabic

United Arabian Emirates

ar_AE

Arabic

Yemen

ar_YE

Armenian

Armenia

hy_AM

Azerbaijani-Cyrillic

Azerbaijan

az_Cyrl_AZ

Azerbaijani-Latin

Azerbaijan

az_Latn_AZ

Basque

Spain

eu_ES

Bosnain

Bosnia and Herzegovina

bs_BA

Bulgarian

Bulgaria

bg_BG

Catalan

Spain

ca_ES

Chinese

People’s Republic of China (Simplified)

zh_CN

Chinese

Hong Kong S.A.R., China

zh_HK

Chinese

Taiwan (Traditional)

zh_TW

Croatian

Croatia

hr_HR

Czech

Czech Republic

cs_CZ

Danish

Denmark

da_DK

Dutch

Belgium

nl_BE

Dutch

Netherlands

nl_NL

English

Australia

en_AU

English

Belgium

en_BE

English

Canada

en_CA

English

Hong Kong S.A.R., China

en_HK

English

India

en_IN

English

India Rupee

en_IN_RUPEE

English

Ireland

en_IE

English

New Zealand

en_NZ

English

Philippines

en_PH

English

Singapore

en_SG

English

South Africa

en_ZA

English

United Kingdom

en_GB

English

United Kingdom Euro

en_GB_EURO

English

United States of America

en_US

English

U.S. Virgin Islands

en_VI

Estonian

Estonia

et_EE

Finnish

Finland

fi_FI

French

Belgium

fr_BE

French

Canada

fr_CA

French

France

fr_FR

French

Luxembourg

fr_LU

French

Switzerland

fr_CH

German

Austria

de_AT

German

Germany

de_DE

German

Luxembourg

de_LU

German

Switzerland

de_CH

Greek

Greece

el_GR

Hebrew

Israel

he_IL

Hindi

India

hi_IN

Hungarian

Hungary

hu_HU

Indonesian

Indonesia

id_ID

Italian

Italy

it_IT

Italian

Switzerland

it_CH

Japanese

Japan

ja_JP

Kazakh

Kazakhstan

kk_KZ

Khmer

Cambodia

km_KH

Korean

Korea

ko_KR

Korean

Korea Hanja

ko_KR_HANI

Lao

Laos

lo_LA

Latvian

Latvia

lv_LV

Lithuanian

Lithuania

lt_LT

Malay

Malaysia

ms_MY

Norwegian - Bokmal

Norway

nb_NO

Norwegian - Nynorsk

Norway

nn_NO

Persian

Iran

fa_IR

Polish

Poland

pl_PL

Portuguese

Brazil

pt_BR

Portuguese

Portugal

pt_PT

Romanian

Romania

ro_RO

Russian

Russia

ru_RU

Serbian-Cyrillic

Serbia and Montenegro

sr_Cyrl_CS

Serbian-Latin

Serbia and Montenegro

sr_Latn_CS

Slovak

Slovakia

sk_SK

Slovenian

Slovenia

sl_SI

Spanish

Argentina

es_AR

Spanish

Bolivia

es_BO

Spanish

Chile

es_CL

Spanish

Columbia

es_CO

Spanish

Costa Rica

es_CR

Spanish

Dominican Republic

es_DO

Spanish

Ecuador

es_EC

Spanish

El Salvador

es_SV

Spanish

Guatemala

es_GT

Spanish

Honduras

es_HN

Spanish

Mexico

es_MX

Spanish

Nicaragua

es_NI

Spanish

Panama

es_PA

Spanish

Paraguay

es_PY

Spanish

Peru

es_PE

Spanish

Puerto Rico

es_PR

Spanish

Spain

es_ES

Spanish

United States of America

es_US

Spanish

Uruguay

es_UY

Spanish

Venezuela

es_VE

Swedish

Sweden

sv_SE

Tagalog

Philippines

tl_PH

Thai

Thailand

th_TH

Thai

Thailand Traditional

th_TH_TH

Turkish

Turkey

tr_TR

Turkish (Turkey Lira)

Turkey

tr_TR_LIRA

Ukrainian

Ukraine

uk_UA

Vietnamese

Vietnam

vi_VN

Usually, both elements of a locale are important. For example, the names of weekdays and months, in English, for Canada and Great Britain are formatted identically, but dates are formatted differently. Therefore, specifying an English language locale is insufficient. Also, specifying only a country as the locale is insufficient. For example, Canada has different date formats for English and French. For information about how to set the locale in Designer, see To specify a locale (language and country or region) for an object .

In general, every application operates in an environment where a locale is present. This locale is known as the ambient locale . In some circumstances, an application might operate on a system, or within an environment, where a locale is not present. In these rare cases, the ambient locale is set to a default of English United States (en_US). This locale is known as a default locale .

Epoch

Date values and time values have an associated origin or epoch , which is a moment in time from which time begins. Any date value and any time value prior to its epoch is invalid.

The unit of value for all date functions is the number of days since the epoch. The unit of value for all time functions is the number of milliseconds since the epoch.

Designer defines day one for the epoch for all date functions as Jan 1, 1900, and millisecond one for the epoch for all time functions is midnight, 00:00:00, Greenwich Mean Time (GMT). This definition means that negative time values can be returned to users in time zones east of GMT.

Date formats

A date format is a shorthand specification of how a date appears. It consists of various punctuation marks and symbols that represent the formatting that the date must use. The following table lists examples of date formats.

Date format

Example

MM/DD/YY

11/11/78

DD/MM/YY

25/07/85

MMMM DD, YYYY

March 10, 1964

The format of dates is governed by an ISO standard. Each country or region specifies its own date formats. The four general categories of date formats are short, medium, long, and full. The following table contains examples of different date formats from different locales for each of the categories.

Locale identifier and description

Date format (Category)

Example

en_GB

English (United Kingdom)

DD/MM/YY (Short)

08/12/92

08/04/05

fr_CA

French (Canada)

YY-MM-DD (Medium)

92-08-18

de_DE

German (Germany)

D. MMMM YYYY (Long)

17. Juni 1989

fr_FR

French (France)

EEEE, ' le ' D MMMM YYYY (Full)

Lundi, le 29 Octobre, 1990

Time formats

A time format is a shorthand specification to format a time. It consists of punctuations, literals, and pattern symbols. The following table lists examples of time formats.

Time format

Example

h:MM A

7:15 PM

HH:MM:SS

21:35:26

HH:MM:SS 'o''clock' A Z

14:20:10 o’clock PM EDT

Time formats are governed by an ISO standard. Each nation specifies the form of its default, short, medium, long, and full-time formats. The locale identifies the format of times that conform to the standards of that nation.

The following table contains some examples of different date formats from different locales for each of the categories.

Locale identifier and description

Time format (Category)

Example

en_GB

English (United Kingdom)

HH:MM (Short)

14:13

fr_CA

French (Canada)

HH:MM:SS (Medium)

12:15:50

de_DE

German (Germany)

HH:MM:SS z (Long)

14:13:13 -0400

fr_FR

French (France)

HH ' h ' MM Z (Full)

14 h 13 GMT-04:00

Date and time patterns

The following symbols must be used to create date and time patterns for date/time fields. Certain date symbols are only used in Chinese, Japanese, and Korean locales. These symbols are also specified below. For more information, see Examples of date/time patterns .

Note: The comma (,), dash (-), colon (:), slash (/), period (.), and space ( ) are treated as literal values and can be included anywhere in a pattern. To include a phrase in a pattern, delimit the text string with single quotation marks ('). For example, 'Your payment is due no later than' MM-DD-YY can be specified as the display pattern.

Date symbol

Description

Formatted value for English (USA) locale where the locale-sensitive input value is 1/1/08 (which is January 1, 2008)

D

1 or 2 digit (1-31) day of the month

1

DD

Zero-padded 2 digit (01-31) day of the month

01

J

1, 2, or 3 digit (1-366) day of the year

1

JJJ

Zero-padded, three-digit (001-366) day of the year

001

M

One- or two-digit (1-12) month of the year

1

MM

Zero-padded, two-digit (01-12) month of the year

01

MMM

Abbreviated month name

Jan

MMMM

Full month name

January

E

One-digit (1-7) day of the week, where (1=Sunday)

3 (because January 1, 2008 is a Tuesday)

EEE

Abbreviated weekday name

Tue (because January 1, 2008 is a Tuesday)

EEEE

Full weekday name

Tuesday (because January 1, 2008 is a Tuesday)

YY

Two-digit year, where numbers less than 30 are considered to fall after the year 2000 and numbers 30 and higher are considered to occur before 2000. For example, 00=2000, 29=2029, 30=1930, and 99=1999

08

YYYY

Four-digit year

2008

G

Era name (BC or AD)

AD

w

One-digit (0-5) week of the month, where week 1 is the earliest set of four contiguous days ending on a Saturday

1

WW

Two-digit (01-53) ISO-8601 week of the year, where week 1 is the week containing January 4

01

Several additional date patterns are available for specifying date patterns in Chinese, Japanese, and Korean locales.

Japanese eras can be represented by several different symbols. The final four era symbols provide alternative symbols to represent Japanese eras.

CJK date symbol

Description

DDD

The locale’s ideographic numeric valued day of the month

DDDD

The locale’s tens rule ideographic numeric valued day of the month

YYY

The locale’s ideographic numeric valued year

YYYYY

The locale’s tens rule ideographic numeric valued year

g

The locale’s alternate era name. For the current Japanese era, Heisei, this pattern displays the ASCII letter H (U+48)

gg

The locale’s alternate era name. For the current Japanese era, this pattern displays the ideograph that is represented by the Unicode symbol (U+5E73)

ggg

The locale’s alternate era name. For the current Japanese era, this pattern displays the ideographs that are represented by the Unicode symbols (U+5E73 U+6210)

g

The locale’s alternate era name. For the current Japanese era, this pattern displays the full width letter H (U+FF28)

g g

The locale’s alternate era name. For the current Japanese era, this pattern displays the ideograph that is represented by the Unicode symbol (U+337B)

Time symbol

Description

Locale-sensitive input value

Formatted value for English (USA) locale

h

One- or two-digit (1-12) hour of the day (AM/PM)

12:08 AM or 2:08 PM

12 or 2

hh

Zero-padded 2 digit (01-12) hour of the day (AM/PM)

12:08 AM or 2:08 PM

12 or 02

k

One- or two-digit (0-11) hour of the day (AM/PM)

12:08 AM or 2:08 PM

0 or 2

kk

Two-digit (00-11) hour of the day (AM/PM)

12:08 AM or 2:08 PM

00 or 02

H

One- or two-digit (0-23) hour of the day

12:08 AM or 2:08 PM

0 or 14

HH

Zero-padded, two-digit (00-23) hour of the day

12:08 AM or 2:08 PM

00 or 14

K

One- or two-digit (1-24) hour of the day

12:08 AM or 2:08 PM

24 or 14

KK

Zero-padded, two-digit (01-24) hour of the day

12:08 AM or 2:08 PM

24 or 14

M

One- or two-digit (0-59) minute of the hour

Note: You must use this symbol with an hour symbol.

2:08 PM

8

MM

Zero-padded, two-digit (00-59) minute of the hour

Note: You must use this symbol with an hour symbol.

2:08 PM

08

S

One- or two-digit (0-59) second of the minute

Note: You must use this symbol with an hour and minute symbol.

2:08:09 PM

9

SS

Zero-padded, two-digit (00-59) second of the minute

Note: You must use this symbol with an hour and minute symbol.

2:08:09 PM

09

FFF

Three- digit (000-999) thousandth of the second

Note: You must use this symbol with an hour, minute, and seconds symbol.

2:08:09 PM

09

A

The part of the day that is from midnight to noon (AM) or from noon to midnight (PM)

2:08:09 PM

PM

z

ISO-8601 time-zone format (for example, Z, +0500, -0030, -01, +0100)

Note: You must use this symbol with an hour symbol.

2:08:09 PM

-0400

zz

Alternative ISO-8601 time-zone format (for example, Z, +05:00, -00:30, -01, +01:00)

Note: You must use this symbol with an hour symbol.

2:08:09 PM

-04:00

Z

Abbreviated time-zone name (for example, GMT, GMT+05:00, GMT-00:30, EST, PDT)

Note: You must use this symbol with an hour symbol.

2:08:09 PM

EDT

Reserved symbols

The following symbols have special meanings and cannot be used as literal text.

Symbol

Description

?

When submitted, the symbol matches any one character. When merged for display, it becomes a space.

*

When submitted, the symbol matches 0 or Unicode white space characters. When merged for display, it becomes a space.

+

When submitted, the symbol matches one or more Unicode white space characters. When merged for display, it becomes a space.

Complex field patterns

In addition to defining simple patterns for date/time fields, numeric fields, and text fields, you can define a locale-specific pattern or handle variable patterns.

Locale-specific patterns

If you want to force a locale on a pattern, regardless of the locale that has already been assigned to an object, you can define a locale-specific pattern. The syntax of a locale-specific pattern is defined as follows:

category_name(locale_name){pattern}

where

  • category_name can be date , time , num , or text .

  • locale_name is identified by a language and/or country or region code, as defined in RFC 1766 (Tags for the Identification of Languages, 1995).

  • pattern is the simple pattern for processing values.

For example, to force a date/time field to translate a date into the French language according to France’s country code, you would define the pattern as follows:

date(fr_FR){DD MMMM, YYYY}

Variable patterns

In cases where the user input or bound data is available in more than one format (for example, telephone numbers may or may not have a three-digit area code), you can define a pattern that accounts for the differences. The syntax for defining a number of acceptable patterns is as follows:

category_name{pattern}|category_name{pattern}|category_name{pattern}

where each pattern is separated by a vertical bar (|). You can specify an unlimited number of patterns. For example, the following construct handles two different text patterns:

text{999*9999}|text{999*999*9999}

To set a default font for values in new forms

  1. On the Tools menu, select Options.

  2. Click Default Fonts.

  3. Under Default Value Font Properties For New Forms, select Typeface, Size, and Style options. as needed.

To set a default font for values in an existing form

  1. Click File > Form Properties.

  2. Click Default Fonts.

  3. Under Default Value Font Properties, select Typeface, Size, and Style options. as needed.

// Ethnio survey code removed