1abe307f20490815b3d86d57f46febbaf865a88d
10
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Uri TauberandZach Nelson
|
1abe307f20 |
perf: Optimize HTML entities lookup to O(log(n)) (#1194)
## Summary **What is the goal of this PR?** Replace the linear scan of `lookupHtmlEntity` with a simple binary search to improve lookup performance. **What changes are included?** `lib/Epub/Epub/Entities/htmlEntities.cpp`: - Sorted the `ENTITY_LOOKUP` array. - Added a compile-time assertion to guarantee the array remains sorted. - Rewrote `lookupHtmlEntity` to use a binary search. ## Additional Context Benchmarked on my x64 laptop (probably will be different on RISC-V) ``` === Benchmark (53 entities x 10000 iterations) === Version Total time Avg per lookup ---------------------------------------------- linear 236.97 ms total 447.11 ns/lookup binary search 22.09 ms total 41.68 ns/lookup === Summary === Binary search is 10.73x faster than linear scan. ``` This is a simplified alternative to #1180, focused on keeping the implementation clean, and maintainable. ### AI Usage Did you use AI tools to help write this code? _**< NO >**_ --------- Co-authored-by: Zach Nelson <zach@zdnelson.com> |
||
|
Uri TauberandArthur Tazhitdinov
|
30d8a8d011 |
feat: slim footnotes support (#1031)
## Summary **What is the goal of this PR?** Implement support for footnotes in epub files. It is based on #553, but simplified — removed the parts which complicated the code and burden the CPU/RAM. This version supports basic footnotes and lets the user jump from location to location inside the epub. **What changes are included?** - `FootnoteEntry` struct — A small POD struct (number[24], href[64]) shared between parser, page storage, and UI. - Parser: `<a href>` detection (`ChapterHtmlSlimParser`) — During a single parsing pass, internal epub links are detected and collected as footnotes. The link text is underlined to hint navigability. Bracket/whitespace normalization is applied to the display label (e.g. [1] → 1). - Footnote-to-page assignment (`ChapterHtmlSlimParser`, `Page`) — Footnotes are attached to the exact page where their anchor word appears, tracked via a cumulative word counter during layout, surviving paragraph splits and the 750-word mid-paragraph safety flush. - Page serialization (`Page`, `Section`) — Footnotes are serialized/deserialized per page (max 16 per page). Section cache version bumped to 14 to force a clean rebuild. - Href → spine resolution (`Epub`) — `resolveHrefToSpineIndex()` maps an href (e.g. `chapter2.xhtml#note1`) to its spine index by filename matching. - Footnotes menu + activity (`EpubReaderMenuActivity`, `EpubReaderFootnotesActivity`) — A new "Footnotes" entry in the reader menu lists all footnote links found on the current page. The user scrolls and selects to navigate. - Navigate & restore (`EpubReaderActivity`) — `navigateToHref()` saves the current spine index and page number, then jumps to the target. The Back button restores the saved position when the user is done reading the footnote. **Additional Context** **What was removed vs #553:** virtual spine items (`addVirtualSpineItem`, `isVirtualSpineItem`), two-pass parsing, `<aside>` content extraction to temp HTML files, `<p class="note">` paragraph note extraction, `replaceHtmlEntities` (master already has `lookupHtmlEntity`), `footnotePages` / `buildFilteredChapterList`, `noterefCallback` / `Noteref` struct, and the stack size increase from 8 KB to 24 KB (not needed without two-pass parsing and virtual file I/O on the render task). **Performance:** Single-pass parsing. No new heap allocations in the hot path — footnote text is collected into fixed stack buffers (char[24], char[64]). Active runtime memory is ~2.8 KB worst-case (one page × 16 footnotes × 88 bytes, mirrored in `currentPageFootnotes`). Flash usage is unchanged at 97.4%; RAM stays at 31%. **Known limitations:** When clicking a footnote, it jumps to the start of the HTML file instead of the specific anchor. This could be problematic for books that don't have separate files for each footnote. (no element-id-to-page mapping yet - will be another PR soon). --- ### AI Usage Did you use AI tools to help write this code? _**< PARTIALLY>**_ Claude Opus 4.6 was used to do most of the migration, I checked manually its work, and fixed some stuff, but I haven't review all the changes yet, so feedback is welcomed. --------- Co-authored-by: Arthur Tazhitdinov <lisnake@gmail.com> |
||
|
Uri Tauber
|
588984ec30 |
fix: Fix dangling pointer (#1010)
## Summary * **What is the goal of this PR?** Small fix for bug I found. ## Additional Context 1. `RecentBooksActivity::loop()` calls `onSelectBook(recentBooks[selectorIndex].path)` - passing a **reference** to the path 2. `onSelectBook` is `onGoToReader` which first calls `exitActivity()` 3. `exitActivity()` triggers `RecentBooksActivity::onExit()` which call `recentBooks.clear()` 4. The string reference `initialEpubPath` is now a **dangling reference** - the underlying string has been destroyed 5. When the reference is then used in `new ReaderActivity(...)`, it reads garbage memory 6. The same issue occurs in `HomeActivity` at line 200 with the same pattern The fix is to make a copy of the string in `onGoToReader` before calling `exitActivity()`, so the path data persists even after the activity clears its data structures. --- ### AI Usage Did you use AI tools to help write this code? _**< YES >**_ Claude found the bug, after I shared with it a serial log. |
||
|
Uri Tauber
|
63b2643534 |
fix: Fix dangling pointer (#1010)
## Summary * **What is the goal of this PR?** Small fix for bug I found. ## Additional Context 1. `RecentBooksActivity::loop()` calls `onSelectBook(recentBooks[selectorIndex].path)` - passing a **reference** to the path 2. `onSelectBook` is `onGoToReader` which first calls `exitActivity()` 3. `exitActivity()` triggers `RecentBooksActivity::onExit()` which call `recentBooks.clear()` 4. The string reference `initialEpubPath` is now a **dangling reference** - the underlying string has been destroyed 5. When the reference is then used in `new ReaderActivity(...)`, it reads garbage memory 6. The same issue occurs in `HomeActivity` at line 200 with the same pattern The fix is to make a copy of the string in `onGoToReader` before calling `exitActivity()`, so the path data persists even after the activity clears its data structures. --- ### AI Usage Did you use AI tools to help write this code? _**< YES >**_ Claude found the bug, after I shared with it a serial log. |
||
|
Uri Tauber
|
3e2c518b8e |
fix: Crash (Load access fault) when indexing chapters containing characters unsupported by bold/italic font variants (#997)
## Summary * **What is the goal of this PR?** I flashed the last revision before commit |
||
|
Uri Tauber
|
ca89e41636 |
fix: Crash (Load access fault) when indexing chapters containing characters unsupported by bold/italic font variants (#997)
## Summary * **What is the goal of this PR?** I flashed the last revision before commit |
||
|
Uri Tauber
|
dc6562a51c |
fix: Fix a dangling pointer (#939)
## Summary * **What is the goal of this PR?** Fix a dangling pointer issue caused by using `.c_str()` on a temporary `std::string`. `basepath.substr()` creates a temporary `std::string`, and calling `.c_str()` on it returns a pointer to its internal buffer (not a copy). Since the temporary string is destroyed at the end of the full expression, `folderName` ends up holding a dangling pointer, leading to undefined behavior. To solve this, we stores the result in a persistent `std::string` object, ensuring the underlying buffer remains valid for the duration of its use. A similar pattern caused the behavior reported in https://github.com/crosspoint-reader/crosspoint-reader/pull/728#issuecomment-3902529697 --- ### AI Usage While CrossPoint doesn't have restrictions on AI tools in contributing, please be transparent about their usage as it helps set the right context for reviewers. Did you use AI tools to help write this code? _**< NO >**_ |
||
|
Uri Tauber
|
530d43997b |
fix: Update Translators list (#927)
## Summary * **What is the goal of this PR?** Update translators.md to include all the contributors from #728 --- ### AI Usage While CrossPoint doesn't have restrictions on AI tools in contributing, please be transparent about their usage as it helps set the right context for reviewers. Did you use AI tools to help write this code? _**< NO >**_ |
||
|
|
7ba5978848 |
feat: User-Interface I18n System (#728)
## Summary **What is the goal of this PR?** This PR introduces Internationalization (i18n) support, enabling users to switch the UI language dynamically. **What changes are included?** - Core Logic: Added I18n class (`lib/I18n/I18n.h/cpp`) to manage language state and string retrieval. - Data Structures: - `lib/I18n/I18nStrings.h/cpp`: Static string arrays for each supported language. - `lib/I18n/I18nKeys.h`: Enum definitions for type-safe string access. - `lib/I18n/translations.csv`: single source of truth. - Documentation: Added `docs/i18n.md` detailing the workflow for developers and translators. - New Settings activity: `src/activities/settings/LanguageSelectActivity.h/cpp` ## Additional Context This implementation (building on concepts from #505) prioritizes performance and memory efficiency. The core approach is to store all localized strings for each language in dedicated arrays and access them via enums. This provides O(1) access with zero runtime overhead, and avoids the heap allocations, hashing, and collision handling required by `std::map` or `std::unordered_map`. The main trade-off is that enums and string arrays must remain perfectly synchronized—any mismatch would result in incorrect strings being displayed in the UI. To eliminate this risk, I added a Python script that automatically generates `I18nStrings.h/.cpp` and `I18nKeys.h` from a CSV file, which will serve as the single source of truth for all translations. The full design and workflow are documented in `docs/i18n.md`. ### Next Steps - [x] Python script `generate_i18n.py` to auto-generate C++ files from CSV - [x] Populate translations.csv with initial translations. Currently available translations: English, Español, Français, Deutsch, Čeština, Português (Brasil), Русский, Svenska. Thanks, community! **Status:** EDIT: ready to be merged. As a proof of concept, the SPANISH strings currently mirror the English ones, but are fully uppercased. --- ### AI Usage Did you use AI tools to help write this code? _**< PARTIALLY >**_ I used AI for the black work of replacing strings with I18n references across the project, and for generating the documentation. EDIT: also some help with merging changes from master. --------- Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com> Co-authored-by: yeyeto2788 <juanernestobiondi@gmail.com> |
||
|
Uri Tauber
|
e5c0ddc9fa |
feat: Debugging monitor script (#555)
## Summary * **What is the goal of this PR?** Add a debugging script to help developers monitor the ESP32 serial port directly from a PC. * **What changes are included?** Added a new script: scripts/debugging_monitor.py ## Additional Context While working on a new Crosspoint-Reader feature, it quickly became clear that watching the ESP32 serial output without any visual cues was inconvenient and easy to mess up. This script improves the debugging experience by reading data from the serial port and providing: 1. A timestamp prefix for every log line (instead of milliseconds since power-up) 2. Color-coded output for different message types 3. A secondary window displaying a live graph of RAM usage, which is especially useful for tracking the memory impact of new features <img width="1916" height="1049" alt="Screenshot_20260126_183811" src="https://github.com/user-attachments/assets/6291887f-ac17-43ac-9e43-f5dec8a7097e" /> --- ### AI Usage Did you use AI tools to help write this code? _**< PARTIALLY >**_ I wrote the initial version of the script. Gemini was used to help add the Matplotlib-based graphing and threading logic. |