diff --git a/cdn/dev/img/developer/ldml/layers.png b/cdn/dev/img/developer/ldml/layers.png
new file mode 100644
index 000000000..bc199f955
Binary files /dev/null and b/cdn/dev/img/developer/ldml/layers.png differ
diff --git a/cdn/dev/img/developer/ldml/layers.svg b/cdn/dev/img/developer/ldml/layers.svg
new file mode 100644
index 000000000..321cb926f
--- /dev/null
+++ b/cdn/dev/img/developer/ldml/layers.svg
@@ -0,0 +1,1136 @@
+
+
+
+
diff --git a/developer/ldml/guide/displays.md b/developer/ldml/guide/displays.md
new file mode 100644
index 000000000..eca0f1535
--- /dev/null
+++ b/developer/ldml/guide/displays.md
@@ -0,0 +1,67 @@
+---
+title: Customizing Keytop Displays
+---
+
+## Why customize the display
+
+Normally, the display of a keytop, whether in a touch environment or the
+on-screen display of a hardware keyboard, simply matches the characrer output.
+So, a key that outputs `a` will have a keytop that looks like `a`.
+
+However, there are some situations where it is desirable to customize the
+display of a key. This is where the [display] element is useful. This is an
+optional element.
+
+Some situations where you might want to customize the display are as follows.
+This isn't an exhaustive list and there may be more situations where the display
+feature is useful.
+
+- Invisible characters: A key may output invisible text of some sort, such as a
+ space, control, or a keyboard [marker](./markers.md). Such keys can have a
+ customized keycap that displays something helpful for the users. For example,
+ `sp` for a space key.
+
+- Switch keys: A key which switches layers, such as one that changes to a shift
+ or alternate layer.
+
+- Visible characters with challenging display: doubled combining marks or
+ combining marks without a base character might need special handling, such as
+ choosing a different base character. A combining circumflex U+0302 could be
+ represented by a caret `^`.
+
+## Example displays element
+
+```xml
+
+
+
+
+
+
+
+
+```
+
+## displayOptions
+
+The `displayOptions` has a single configurable option at present, the
+baseCharacter.
+
+In Lao for example, it's sometimes preferred to use `x` as the base for showing
+combining marks, rather than the dotted circle ◌.
+
+This is a hint for platforms to suggest using an alternative character. It
+doesn't require any specific behavior.
+
+```xml
+
+
+
+
+```
+
+
+With the key display customized, it's time now to arrange the keys into
+[layers](./layers).
+
+[display]: ../reference/display
diff --git a/developer/ldml/guide/glossary.md b/developer/ldml/guide/glossary.md
index 88cadf3e0..bc417835a 100644
--- a/developer/ldml/guide/glossary.md
+++ b/developer/ldml/guide/glossary.md
@@ -6,13 +6,18 @@ title: Glossary for LDML
### BCP 47 language tag
-A standardized code that is used to identify human languages on the Internet. More on [BCP 47](https://www.rfc-editor.org/info/bcp47).
+A standardized code that is used to identify human languages on the Internet.
+More on [BCP 47](https://www.rfc-editor.org/info/bcp47).
-There are many possible subtags, but only three types are currently used in most places in Keyman Developer:
+There are many possible subtags, but only three types are currently used in most
+places in Keyman Developer:
-* [language subtag](../../current-version/reference/bcp-47#toc-the-language-subtag)
+* [language
+ subtag](../../current-version/reference/bcp-47#toc-the-language-subtag)
* [script subtag](../../current-version/reference/bcp-47#toc-the-script-subtag)
* [region subtag](../../current-version/reference/bcp-47#toc-the-region-subtag)
-More information about BCP 47 language tag and full details on [how they are used in Keyman Developer](../../current-version/reference/bcp-47).
+More information about BCP 47 language tag and full details on [how they are
+used in Keyman Developer](../../current-version/reference/bcp-47).
+Now, go on to begin [planning](./planning) your LDML keyboard.
diff --git a/developer/ldml/guide/index.md b/developer/ldml/guide/index.md
index 69cf0b463..298b47a5e 100644
--- a/developer/ldml/guide/index.md
+++ b/developer/ldml/guide/index.md
@@ -2,7 +2,30 @@
title: LDML Guide
---
-## Language elements
+This guide will take you through the concepts, planning process, and structure
+needed to successfully author an LDML Keyboard used with Keyman.
-* [LDML Language Overview](overview)
+We recommend to start with [Planning](./planning) and read these pags in order,
+but you are welcome to skip around as suits your interest. The
+[reference](../reference/) is useful for details of a particular XML Element.
+
+## Getting Started
+
+* [Planning](planning) your Keyboard
+* [Overview](overview) of the LDML format
+ * [Choosing a Locale](locales)
+
+## Jumping in
+
+* The [Keybag](keybag)
+* Customizing key [Displays](displays)
+* Defining [Layers](layers)
+
+## Going further
+
+* [Settings and Options](settings)
+* [Variables](variables)
+* [Transforms](transforms)
+* [Markers](markers)
+* [Reorders](reorders)
* [Glossary](glossary)
diff --git a/developer/ldml/guide/keybag.md b/developer/ldml/guide/keybag.md
new file mode 100644
index 000000000..4fdcb5b67
--- /dev/null
+++ b/developer/ldml/guide/keybag.md
@@ -0,0 +1,123 @@
+---
+title: The Keybag
+---
+
+The first major part of authoring your keyboard consists in setting up the
+keybag.
+
+## What's in the Keybag?
+
+You can think of the keybag as if it were a literal "bag of keys" from which you
+can bring out a key and place it into the right spot in your layout.
+
+The keybag is not one-for-one with the [repertoire], due to the following
+ reasons:
+
+- There may be text which is of the repertoire which are not typed by the user
+directly at all, but are accessed via transforms. For example, suppose `œ` were
+part of the repertoire, but accessed by the user by typing `o` + `e`. There
+might not be an `œ` key, though it is in the repertoire.
+
+- There may also be more than one key which produces the same output, but has a
+ distinct identity as a key. For example, there might be a key producing `a`
+ which is used on a hardware layer, but also another key also producing `a` on
+ one of the touch layers which has gestures attached to it such as a long press
+ yielding `à`, `á`, `â` etc. The two `a` keys have diferent identities (`id=`
+ attribute) and differ in other properties.
+
+- Rarer, but it may be possible that a key producing the same output
+ intentionally has a different keycap display in two different contexts. Keys
+ are identified by a unique identifier, so unique keys can have unique key
+ [displays].
+
+## Defining keys in the Keybag
+
+Keys are defined by the [key] element within the [keys] element, as seen in a
+simple example:
+
+```xml
+
+
+
+
+
+
+
+```
+
+Note that the identifier doesn't have to be plain ASCII, as shown in the last
+key above, which has the ID of `ক`.
+
+In the following sections we will discuss more advanced uses of keys.
+
+## Switch Keys
+
+A key within a touch layout can switch to a different [layer](./layers) by use
+of the `layerId` attribute, which names another layer. For example, this key
+switches to the "numbers" layer:
+
+```xml
+
+```
+
+Such a key would by default have a blank keycap (because it doesn't produce any
+output), so it is recommended to use a [`display`](./displays) element to give
+it an identifiable appearance. See the
+[displays](./displays#example-displays-element) section for an example.
+
+## Key Geometry
+
+### Width
+
+In a touch keyboard, keys are normally the same width (width="1" or
+width="1.0"). In some cases, a key is given a larger width for layout reasons,
+such as for the shift key. Widths are in tenths of a key width.
+
+```xml
+
+```
+
+### Gap
+
+Sometimes on a key layout, it can be useful to have a blank area without any
+keys. For example, a shifted layer may not have a shifted key defined for each
+base key. The `gap="true"` attribute indicates that a key is a gap and has no
+output and no key cap display.
+
+There is a pre-defined key named `gap` that has the gap attribute set. It is
+possible to add additional gap keys if desired. The following defines `gap` as
+its normal definition, and then defines a 3-key wide gap.
+
+```xml
+
+
+```
+
+### Stretch
+
+The stretch attribute defines a key that expands to fill all available
+horizontal space. This is used, for example, with the spacebar.
+
+```xml
+
+```
+
+## Marker key
+
+Markers are discussed in more detail in [markers](./markers) and
+[transforms](./transforms). For this discussion, it's used with a key that
+doesn't generate any actual output, but represents an invisible non-text data
+item that is used for later processing.
+
+```xml
+
+```
+
+The marker's id here is `grave`.
+
+Next, we will learn about customizing key [displays].
+
+[repertoire]: ./planning#repertoire
+[displays]: ./displays
+[keys]: ../reference/keys
+[key]: ../reference/key
diff --git a/developer/ldml/guide/layers.md b/developer/ldml/guide/layers.md
new file mode 100644
index 000000000..18393f9d0
--- /dev/null
+++ b/developer/ldml/guide/layers.md
@@ -0,0 +1,79 @@
+---
+title: Defining Layers
+---
+
+A layer defines are how keys are arranged for display and use.
+For hardware layouts, a layer determines which hardware key connects to which key from the keybag.
+For touch layouts, the layer controls how the keys are displayed on the screen for interaction with the finger or mouse.
+
+## Layer Groups (`layers`)
+
+A layer group or [`layers`](../reference/layers) element occurs one or more times in the keyboard file.
+There may be at most one layer group for the hardware keyboard, and then one or more layer group for different widths (sizes) of touch layouts, such as for a phone versus a tablet.
+
+If no touch layer group is present, then the hardware layout will be used in touch devices, but a touch layout cannot be used for hardware, so we recommend starting with a hardware layout.
+
+### Hardware Layer Groups
+
+The hardware layer group has a `formId=` attribute referencing the physical layout of the keys, such as `iso` or `us` for the European 102 key layout (with a key between the shift and Z key) and the US 101 key layout (with no key between the shift and Z) respectively. Other layouts supported include `abnt2`, `jis`, and `ks`.
+
+### Touch Layer Groups
+
+Touch layer groups always have the attribute `formId="touch"`, and are distinguished from each other by the `minDeviceWidth=` attribute, which specifies a minimum width, in millimeters, that the layout group must have.
+
+## Defining a Layer
+
+Now we come to discuss the actual [`layer`](../reference/layer) element.
+
+### Layer ID
+
+The ID is required for touch layers, but is optional for hardware layers. The layer with the ID of `base` is the starting layer.
+
+Keys can switch layers by referencing this layer in their `layerId` attribute.
+
+### Modifiers
+
+The modifiers are required for hardware layers, but are optional for touch layers.
+
+Each layer has a set of modifiers defined. For hardware keyboards, this specifies which layer will be selected based on the modifiers held down. `none` is used for the layer with no modifiers.
+
+For example, `modifiers="none"` or `modifiers="shift"`. See [`layer`](../reference/layer) for further details.
+
+### Rows
+
+Each layer contains one or more [`row`](../reference/row) elements, in order from top to bottom.
+
+For example, most hardware keyboards have five rows including the space bar.
+Note that for hardware layouts, only the "alphanumeric" keys, that is, the keys which produce a character or space, are included. Shift, Control, and any other device-specific hardware keys are not included.
+
+For touch keyboards, the number of rows is completely up to the keyboard author. Different layers or layer groups do not have to have the same number of rows.
+
+The `keys` attribute of each `row` is a space-separated list of key IDs.
+
+Example:
+
+```xml
+
+
+
+
+
+
+
+```
+
+## Overview of Layers and Layer Groups
+
+Here is a reference image to help you understand layers and layer groups.
+
+
+
+-----
+
+You've now completed a brief tour of the LDML format for Keyman. See [going
+further](./index#toc-going-further) for additional topics to explore.
diff --git a/developer/ldml/guide/locales.md b/developer/ldml/guide/locales.md
new file mode 100644
index 000000000..5f96df4fc
--- /dev/null
+++ b/developer/ldml/guide/locales.md
@@ -0,0 +1,20 @@
+---
+title: Choosing a locale
+---
+
+As part of your keyboard development, you must choose one or more [BCP 47]
+locale codes to associate with the keyboard.
+
+The primary locale id is stored in the `locale` attribute of the
+[`keyboard3`][keyboard3] (outer) element, while any additional locale ids are
+stored in the optional [`locales`][locales] element.
+
+Examples:
+
+- `km` — Khmer
+- `suz-Sunu` — Sunuwar language, in the Sunuwar script
+- `fa-t-k0-isiri` — Persian ISIRI keyboard
+
+[BCP 47]: ../../current-version/reference/bcp-47
+[keyboard3]: ../reference/keyboard3
+[locales]: ../reference/locales
diff --git a/developer/ldml/guide/markers.md b/developer/ldml/guide/markers.md
new file mode 100644
index 000000000..7776c2074
--- /dev/null
+++ b/developer/ldml/guide/markers.md
@@ -0,0 +1,4 @@
+---
+title: Markers
+---
+
diff --git a/developer/ldml/guide/overview.md b/developer/ldml/guide/overview.md
index d4ad6f6d2..eabc69b08 100644
--- a/developer/ldml/guide/overview.md
+++ b/developer/ldml/guide/overview.md
@@ -2,6 +2,96 @@
title: LDML overview
---
-The LDML format …. Source files have the **.xml** extension and are text files.
+LDML is the Locale Data Markup Language. It it an XML-based format specified as
+the Unicode Consortium’s specification [UTS#35 Part 7], maintained by the
+[Common Locale Data Repository (CLDR)][CLDR] Technical Commitee.
-…
+LDML itself has several parts which describe diferent aspects of locale data.
+This document describes the part pertaining to keyboards, part 7.
+
+## File Structure
+
+Source files have the **.xml** extension and are [XML] (text) files. Any text
+editor can be used. An editor which understands XML and can highlight syntax is
+preferred, such as that built into Keyman Developer.
+
+### Attributes and Escaping
+
+The LDML structure does not use any "element text", all text is in attributes.
+Attributes are opened and closed with double quotes `"`.
+
+Many attributes support escaping. That is, if you need to use a double quote
+within an attribute, the double quote must be escaped. For example, for a string
+variable with the value `I said, "yes"` it could be accomplished as shown:
+
+```xml
+
+```
+
+This notation is described in [Unicode UTS #18 section 1.1][UTS18escaping] and
+consists of `\u{` followed by 1-6 hex digits and closed with `}`. `\u{1E8CA}`
+and `\u{1e8CA}` and `\u{1e8Ca}` all refer to U+1E8CA 𞣊 "MENDE KIKAKUI DIGIT
+FOUR". Upper and lower case does not matter.
+
+Escaping is not allowed everywhere. A double quote is not valid as the id of a
+key, for example, so the `
+
+```
+
+You can use comments to temporarily remove an element from processing. The
+following "key" element is commented out, and so is not a part of the keyboard.
+
+```xml
+
+```
+
+### XML Prologue
+
+As an XML file, the XML prologue is needed. The prologue should be exactly as
+shown. (A DTD not used.)
+
+```xml
+
+```
+
+### Outer `keyboard3` Element
+
+The root element of a keyboard file is the [`keyboard3`][keyboard3] element.
+
+Note the `xmlns` and `conformsTo` elements both refer to a version of CLDR, in
+this case v47. For compatibility, you should set these to the earliest possible
+version number.
+
+
+
+The `locale` attribute is the _primary_ [BCP 47] locale for the keyboard. See
+[choosing a locale](locales) for more information about choosing locale id(s)
+for your keyboard.
+
+```xml
+
+ …
+
+```
+
+Now that you have the outer structure in place, it's time to fill the [keybag].
+
+[CLDR]: https://cldr.unicode.org
+[UTS#35 Part 7]: https://www.unicode.org/reports/tr35/tr35-keyboards.html
+[BCP 47]: ../../current-version/reference/bcp-47
+[keyboard3]: ../reference/keyboard3
+[UTS18escaping]: https://www.unicode.org/reports/tr18/#Hex_notation
+[XML]: https://www.w3.org/XML/
+[keybag]: ./keybag
diff --git a/developer/ldml/guide/planning.md b/developer/ldml/guide/planning.md
new file mode 100644
index 000000000..e50e3ebcb
--- /dev/null
+++ b/developer/ldml/guide/planning.md
@@ -0,0 +1,42 @@
+---
+title: Planning your Keyboard
+---
+
+Whether you are building an entirely novel keyboard from zero, or implementing
+one that already exists in another environment, planning is important. Make sure
+you have all of the important information at hand so that you can begin on this
+journey.
+
+## Questions
+
+To aid you in the planning, here are a series of questions that can be asked:
+
+### Identity
+
+- What are the languages that are served by this keyboard?
+- What script or scripts will be involved in these languages?
+- Which language, if any, can be considered the primary language?
+- What is the name of the keyboard?
+
+### Form and Function
+
+- Will this be a hardware-only or touch-only keyboard? (It is recommended to
+work on the hardware format first, as a hardware keyboard can be used in touch
+but not vice versa.)
+- What is the base physical type for hardware, such as US or ISO?
+- Does the keyboard follow an existing organization of keys, such as QWERTY,
+ AZERTY, QWERTZ etc?
+- Which width(s) will you start with for the touch layout?
+- What gestures will you make use of, such as long press, flicks, and multitap?
+
+### Repertoire
+
+- What are the "characters" that will be covered by this keyboard for this
+ language? This may go beyond the usual Unicode definition of characters, on to
+ characters as the users will perceive them. For example, your language might
+ use `ch` as a single letter.
+- Which characters are the most important to access? That is, those that would
+ be right on the keyboard or on a shift layer, versus others that might be
+ reached via a gesture or multiple key combination.
+
+Next, let's take a look at an [overview](./overview) of the LDML format.
diff --git a/developer/ldml/guide/reorders.md b/developer/ldml/guide/reorders.md
new file mode 100644
index 000000000..1a9a443fc
--- /dev/null
+++ b/developer/ldml/guide/reorders.md
@@ -0,0 +1,4 @@
+---
+title: Reorders
+---
+
diff --git a/developer/ldml/guide/settings.md b/developer/ldml/guide/settings.md
new file mode 100644
index 000000000..76878ef3e
--- /dev/null
+++ b/developer/ldml/guide/settings.md
@@ -0,0 +1,4 @@
+---
+title: Settings and Options
+---
+
diff --git a/developer/ldml/guide/transforms.md b/developer/ldml/guide/transforms.md
new file mode 100644
index 000000000..95253cdb9
--- /dev/null
+++ b/developer/ldml/guide/transforms.md
@@ -0,0 +1,4 @@
+---
+title: Transforms
+---
+
diff --git a/developer/ldml/guide/variables.md b/developer/ldml/guide/variables.md
new file mode 100644
index 000000000..1895dc1ed
--- /dev/null
+++ b/developer/ldml/guide/variables.md
@@ -0,0 +1,4 @@
+---
+title: Variables
+---
+
diff --git a/developer/ldml/index.md b/developer/ldml/index.md
index c14fac630..28d75127f 100644
--- a/developer/ldml/index.md
+++ b/developer/ldml/index.md
@@ -2,9 +2,15 @@
title: LDML Format
---
-LDML is the Locale Data Markup Language. It it an XML-based format specified as the Unicode Consortium’s specification [UTS#35 Part 7], maintained by the [Common Locale Data Repository (CLDR)][CLDR] Technical Commitee.
+LDML is the Locale Data Markup Language. It it an XML-based format specified as
+the Unicode Consortium’s specification [UTS#35 Part 7], maintained by the
+[Common Locale Data Repository (CLDR)][CLDR] Technical Commitee.
-Like the [Keyman Keyboard Language (.kmn) format][kmn], the LDML Keyboard format defines how keystrokes are interpreted and how keys are laid out in a virtual keyboard. The LDML format has been defined from the beginning to become a cross-platform industry standard, with active participation from several Unicode member organizations including SIL Global.
+Like the [Keyman Keyboard Language (.kmn) format][kmn], the LDML Keyboard format
+defines how keystrokes are interpreted and how keys are laid out in a virtual
+keyboard. The LDML format has been defined from the beginning to become a
+cross-platform industry standard, with active participation from several Unicode
+member organizations including SIL Global.
[LDML guide](guide)
diff --git a/developer/ldml/reference/display.md b/developer/ldml/reference/display.md
index 1646d4f74..a6d7f22ca 100644
--- a/developer/ldml/reference/display.md
+++ b/developer/ldml/reference/display.md
@@ -15,8 +15,7 @@ The **`display`** element is used to overide the keytops for certain keys.
### Attributes
-`id`
-: The …
+`id` : The …
## Description
@@ -43,5 +42,6 @@ The `display` element was added in LDML v46
- LDML Specification: [`` in UTS#35 Part 7][tr35-element-display]
-[tr35-element-display]: https://www.unicode.org/reports/tr35/tr35-keyboards.html#element-display
+[tr35-element-display]:
+ https://www.unicode.org/reports/tr35/tr35-keyboards.html#element-display
diff --git a/developer/ldml/reference/displayOptions.md b/developer/ldml/reference/displayOptions.md
index 27e33cb8f..5e29422f8 100644
--- a/developer/ldml/reference/displayOptions.md
+++ b/developer/ldml/reference/displayOptions.md
@@ -4,7 +4,8 @@ title: displayOptions
## Summary
-The **`displayOptions`** element is used to provide setting information for keytop displays.
+The **`displayOptions`** element is used to provide setting information for
+keytop displays.
## Syntax
@@ -15,8 +16,7 @@ The **`displayOptions`** element is used to provide setting information for keyt
### Attributes
-`id`
-: The …
+`id` : The …
## Description
@@ -41,7 +41,9 @@ The `displayOptions` element was added in LDML v46
## See Also
-- LDML Specification: [`` in UTS#35 Part 7][tr35-element-displayOptions]
+- LDML Specification: [`` in UTS#35 Part
+ 7][tr35-element-displayOptions]
-[tr35-element-displayOptions]: https://www.unicode.org/reports/tr35/tr35-keyboards.html#element-displayoptions
+[tr35-element-displayOptions]:
+ https://www.unicode.org/reports/tr35/tr35-keyboards.html#element-displayoptions
diff --git a/developer/ldml/reference/displays.md b/developer/ldml/reference/displays.md
index fa2cec48a..b1f109b84 100644
--- a/developer/ldml/reference/displays.md
+++ b/developer/ldml/reference/displays.md
@@ -4,7 +4,8 @@ title: displays
## Summary
-The **`displays`** element contains a collection of [``](display) elements as well as an optional [``](displayOptions) element.
+The **`displays`** element contains a collection of [``](display)
+elements as well as an optional [``](displayOptions) element.
## Syntax
@@ -15,12 +16,13 @@ The **`displays`** element contains a collection of [``](display) eleme
### Attributes
-`id`
-: The …
+`id` : The …
## Description
-The `displays` element is used to contain all [``](key) elements and the optional [``](displayOptions) element for the keyboard. There may only be one of these elements.
+The `displays` element is used to contain all [``](key) elements and
+the optional [``](displayOptions) element for the keyboard.
+There may only be one of these elements.
## Examples
@@ -43,5 +45,6 @@ The `displays` element was added in LDML v46
- LDML Specification: [`` in UTS#35 Part 7][tr35-element-displays]
-[tr35-element-displays]: https://www.unicode.org/reports/tr35/tr35-keyboards.html#element-displays
+[tr35-element-displays]:
+ https://www.unicode.org/reports/tr35/tr35-keyboards.html#element-displays
diff --git a/developer/ldml/reference/flick.md b/developer/ldml/reference/flick.md
index 6d61e4022..c47bd306d 100644
--- a/developer/ldml/reference/flick.md
+++ b/developer/ldml/reference/flick.md
@@ -15,14 +15,16 @@ The **`flick`** element represents a set of possible flick gestures.
### Attributes
-`id`
-: The identifier for this flick. Only one flick may have this identifier, but it doesn't have to be diffrent from any other kinds of identifiers.
+`id` : The identifier for this flick. Only one flick may have this identifier,
+but it doesn't have to be diffrent from any other kinds of identifiers.
## Description
-The **`flick`** element represents a set of possible flick gestures which can result in output text.
+The **`flick`** element represents a set of possible flick gestures which can
+result in output text.
-The element is referenced by its id, allowing multiple [``](key) elements to reference and reuse the same flick set.
+The element is referenced by its id, allowing multiple [``](key) elements
+to reference and reuse the same flick set.
## Examples
@@ -45,5 +47,6 @@ The `flick` element was added in LDML v46
- LDML Specification: [`` in UTS#35 Part 7][tr35-element-flick]
-[tr35-element-flick]: https://www.unicode.org/reports/tr35/tr35-keyboards.html#element-flick
+[tr35-element-flick]:
+ https://www.unicode.org/reports/tr35/tr35-keyboards.html#element-flick
diff --git a/developer/ldml/reference/flickSegment.md b/developer/ldml/reference/flickSegment.md
index 10b7e84e8..657a5a4bd 100644
--- a/developer/ldml/reference/flickSegment.md
+++ b/developer/ldml/reference/flickSegment.md
@@ -4,7 +4,8 @@ title: flickSegment
## Summary
-The **`flickSegment`** element represents one particular set of gestures which will produce a specific output.
+The **`flickSegment`** element represents one particular set of gestures which
+will produce a specific output.
## Syntax
@@ -15,16 +16,20 @@ The **`flickSegment`** element represents one particular set of gestures which w
### Attributes
-`id`
-: The …
+`id` : The …
## Description
-The `flickSegment` element is used to represent one set of gestures (an ordered path), and their output. For example, "Sliding the touch North produces `A`". It could include more than one keyword, such as "Sliding the touch West and then South produces `B`".
+The `flickSegment` element is used to represent one set of gestures (an ordered
+path), and their output. For example, "Sliding the touch North produces `A`".
+It could include more than one keyword, such as "Sliding the touch West and then
+South produces `B`".
### Directions
-The following table attempts to show the eight directions supported by the format, relative to the center (•). So `nw` for Northwest means diagonally Up-and-Left, whereas `e` for East means directly to the right.
+The following table attempts to show the eight directions supported by the
+format, relative to the center (•). So `nw` for Northwest means diagonally
+Up-and-Left, whereas `e` for East means directly to the right.
| | | |
|------|-----|------|
@@ -51,7 +56,9 @@ The `flickSegment` element was added in LDML v46
## See Also
-- LDML Specification: [`` in UTS#35 Part 7][tr35-element-flickSegment]
+- LDML Specification: [`` in UTS#35 Part
+ 7][tr35-element-flickSegment]
-[tr35-element-flickSegment]: https://www.unicode.org/reports/tr35/tr35-keyboards.html#element-flicksegment
+[tr35-element-flickSegment]:
+ https://www.unicode.org/reports/tr35/tr35-keyboards.html#element-flicksegment
diff --git a/developer/ldml/reference/flicks.md b/developer/ldml/reference/flicks.md
index 4aaa691ac..7d07ad90c 100644
--- a/developer/ldml/reference/flicks.md
+++ b/developer/ldml/reference/flicks.md
@@ -16,12 +16,12 @@ The **`flicks`** element contains a collection of [``](flick) elements.
### Attributes
-`id`
-: The …
+`id` : The …
## Description
-The `flicks` element is used to contain all [``](flick) elements for the keyboard. There may only be one of these elements.
+The `flicks` element is used to contain all [``](flick) elements for the
+keyboard. There may only be one of these elements.
## Examples
@@ -45,5 +45,6 @@ The `flicks` element was added in LDML v46
- LDML Specification: [`` in UTS#35 Part 7][tr35-element-flicks]
-[tr35-element-flicks]: https://www.unicode.org/reports/tr35/tr35-keyboards.html#element-flicks
+[tr35-element-flicks]:
+ https://www.unicode.org/reports/tr35/tr35-keyboards.html#element-flicks
diff --git a/developer/ldml/reference/form.md b/developer/ldml/reference/form.md
index 82800f3a3..6c2cb8c71 100644
--- a/developer/ldml/reference/form.md
+++ b/developer/ldml/reference/form.md
@@ -4,7 +4,8 @@ title: form
## Summary
-The **`form`** element is used to define or override the scan code layout of a hardware keyboard.
+The **`form`** element is used to define or override the scan code layout of a
+hardware keyboard.
## Syntax
@@ -17,14 +18,15 @@ Parent Element: [``](forms)
### Attributes
-`id`
-: The …
+`id` : The …
## Description
-The `form` element is used to define or override the scan code layout of a hardware keyboard.
+The `form` element is used to define or override the scan code layout of a
+hardware keyboard.
-Note that keyboard developers will not normally need or want to use this element, but rather to use the pre-defined hardware forms.
+Note that keyboard developers will not normally need or want to use this
+element, but rather to use the pre-defined hardware forms.
## Examples
@@ -47,5 +49,6 @@ The `form` element was added in LDML v46
- LDML Specification: [`