newsletters - How the Braille Rules are Applied #0002

• Overview of the BrailleBase Algorithm (Current Version and Future Direction)

  1. First Generation — Basic Replace

  Model: direct character → braille substitution.

  Classic problem: numbers treated digit by digit.

  Example: 2026 → ⠼⠃⠼⠚⠼⠃⠼⠋ Correct: ⠼⠃⠚⠃⠋ (a single numeric prefix for the entire sequence).

  Conclusion: a library with no contextual awareness, relying solely on static mapping.

  2. Introduction of Contextual Rules

  Numeric Rule (Number Mode)

  Idea: enter “numeric mode” when digits are detected.

  Behavior:

  • Applies ⠼ once at the beginning of the numeric sequence.

  • Keeps numeric mode active while digits continue.

  • Exits numeric mode when encountering a non‑numeric character.

  Impact: BrailleBase stops being a simple replacer and becomes a numeric‑context interpreter.

  Uppercase Rule

  Idea: add uppercase prefixes without interfering with numbers.

  Behavior:

  • Applies the uppercase prefix to specific letters.

  • Avoids applying it inside numeric blocks.

  Impact: introduces a second local mode (uppercase) layered on top of the same string.

  Phonetic Rules (Phonetic Braille)

  Idea: handle languages and phonetic systems (CJK, pinyin, kana, etc.).

  Behavior:

  • Groups characters into phonetic units.

  • Converts these groups into phonetic braille, not just isolated characters.

  Impact: the algorithm begins working with linguistic tokens rather than simple characters.

  3. Rule Application Order (Current Pipeline)

  The sequence currently used:

  Numbers + Numeric Punctuation

  • Applies numeric prefixes and resolves punctuation that affects numeric mode.

  • Ensures numeric blocks are correct before any other transformation.

  Uppercase

  • Applies uppercase prefixes on a string already stabilized numerically.

  • Prevents conflicts between uppercase and numeric mode.

  Phonetic

  • Operates on a string where numbers and uppercase have already been resolved.

  • Simplifies phonetic tokenization by avoiding mixed prefixes.

  RTL (Right‑to‑Left)

  • Final step: determines the final direction and mixes LTR/RTL.

  • Receives the string with all modes applied (numeric, uppercase, phonetic).

  This order minimizes conflicts:

  • Numeric is global and fragile → comes first.

  • Uppercase is local → comes next.

  • Phonetic depends on a clean text without incorrect prefixes.

  • RTL requires the final version to determine direction.

  4. Parse Phase and Current Issues

  After applying all rules:

  Current phase: the final braille string is parsed. The system attempts to generate tokens (number, word, symbol, phonetic, etc.) from the already transformed string.

  Problem: sometimes a token is not generated because:

  • A rule was applied at the wrong moment.

  • Context was destroyed by a previous transformation.

  Consequence: it becomes difficult to add more complex tokens such as:

  • Bold

  • Italic

  • Other styles or metadata

  5. Future Direction — Separating Rules from Parsing

  You have already identified the correct path:

  Goal: minimize the impact of one rule on another.

  Technical approach:

  • Analysis: extract structure (number, uppercase, phonetic, RTL, style) as tokens.

  • Rules: apply logic to these tokens, not directly to the string.

  • Rendering: generate the braille string only at the end, based on the tokenized structure.

  This will allow:

• More complex tokens (bold, italic, etc.).

• Fewer side effects between rules.

• A Braille engine closer to a linguistic interpreter with styling, rather than a simple mapper.

• Get in touch through GitHub: https://github.com/DukaCrazy

  My name is Duka — and if a project isn’t crazy enough to change the world, it’s probably not mine.

  • 2026/08/17