Critical GUI Bug: Failure to parse alphanumeric chapter indices (e.g., EsthGrk 'A'-'F') causing blank viewport and navigation freeze in NRSVA module

[ariasrodolfo]

Technical Overview & Root Cause Analysis

The core SWORD engine backend natively supports advanced versification systems (v11n) such as NRSVA. This schema breaks traditional sequential integer indexing by using alphanumeric chapter strings for the Greek Esther book (EsthGrk), where chapters are officially ordered as: A, 1, B, 2, 3, C, D, 4, 5, E, 6, 7, 8, F, 9, 10.

The bug is not within the SWORD engine backend itself, nor is it an issue with module compilation via osis2mod. The defect lies entirely in Xiphos' front-end GUI abstraction layer (specifically the interface code bridging SWORD data structures to the GTK TreeView sidebar and the WebKit/HTML rendering engine).

Xiphos utilizes standard integer loops (int chapter = 1; chapter <= max_chapters; chapter++) to query books and build its internal navigation UI mapping. When Xiphos passes an alphanumeric chapter identifier (such as 'A' or 'F') to functions handling index ranges, the string-to-integer conversion (atoi or basic casting) evaluates to 0 or triggers an out-of-bounds array exception. This unexpected state truncates the rendering buffer, resulting in a completely blank text viewport, broken treeview nodes, or an infinite loop that freezes the navigation panel.

Why KJVA Does Not Exhibit This Bug (Technical Contrast)

It is important to note that this rendering failure does NOT occur when using the KJVA (King James Version with Apocrypha) versification profile.

The reason for this architectural difference is that the KJVA schema completely bypasses alphanumeric chapter codes. Instead of embedding additions directly within the Greek Esther text flow using letters, KJVA isolates the Greek additions into an entirely independent, standalone book index named AddEsth (Rest of Esther). Because AddEsth uses a strictly traditional, sequential integer layout (Chapters 1, 2, 3, etc.), Xiphos' integer-locked frontend loops process it without errors.

Therefore, the issue is uniquely triggered by NRSVA (or any custom v11n) when multi-character/alphanumeric tokens are inserted into a single book's chapter layout array.

Deep Dive into SWORD API Interaction Failure

1. VerseKey Increments: The SWORD engine relies on sword::VerseKey objects. For NRSVA/EsthGrk, traversing via key++ or key.setChapter() correctly cycles through alpha characters internally. However, Xiphos bypasses direct engine key iteration in favor of manual index counting for GUI optimization.
2. Key Serialization to GUI: When Xiphos attempts to synchronize the sidebar selection with the text view using key.setText(), passing standard integer increments breaks. The interface layer fails to resolve keys where chapter cannot be represented by a clean sequential integer.
3. HTML Buffer Truncation: Because the GUI loop interprets character-based chapters as invalid or empty, the internal XML/HTML translation routines fail to fetch verse nodes from the database driver, appending an empty string to the main display widget.

Steps to Reproduce

1. Compile or download any Bible module utilizing the official NRSVA versification profile, containing text under the <div type="book" osisID="EsthGrk"> tag.
2. Open Xiphos and activate this module.
3. Expand the module structure in the sidebar navigation tree. Observe that the chapter list for Greek Esther is either completely missing, flatly displays numerical values only, or crashes upon expansion.
4. Try navigating directly to Greek Esther Chapter A or F via the main dropdown menu. The main reading pane displays a completely blank page, and UI navigation becomes unresponsive.

Expected Behavior

The Xiphos UI component layer should be agnostic to integer-only chapter structures. Instead of hardcoding numerical iteration loops for chapters, it should dynamically query the SWORD engine backend for the explicit string array list representing valid chapters for the current active book. The UI navigation nodes and text fetch queries should accept valid string keys (like 'A', '1', 'B') as returned by VerseKey::getChapterText().

Codebase Components to Investigate

The rendering bug is highly likely isolated within the C/GTK interface wrappers:

• src/main/sidebar.c: Look into the loops populating the sidebar combo boxes and GtkTreeView models for module canons.
• src/main/xml.c (or the equivalent HTML viewport generator): Check how VerseKey chapter bounds are validated before calling the text extraction stream. Look for manual type castings from chapter strings to integer primitives.

Environment

• Xiphos Version: 4.2.1
• OS / Desktop Environment: Devuan GNU/Linux 4 (Chimaera)
• SWORD Backend Version: 1.9.0

[ariasrodolfo]

Additional Context: Command Line Verification (Diatheke)

To further isolate this issue, I verified the compiled NRSVA module using SWORD's official command-line utility, diatheke.

When querying the alphanumeric chapters of Greek Esther via terminal, the engine returns the text flawlessly:

diatheke -b MyNRSVAModule -k EsthGrk A:1

Result: Diatheke correctly parses the alpha-character key, hooks into the SWORD backend, and dumps the exact verse text to stdout without any indexing errors.

This behavior conclusively proves that the underlying SWORD 1.9.0 engine, the index files (.bks), and the compiled OSIS XML structure are 100% correct. The parsing and rendering failure is exclusively trapped inside the Xiphos 4.2.1 GTK frontend logic when it tries to translate these alphanumeric strings into its visual menu components.