bfu_ua_display: Add Ukrainian text rendering library

[BrainFromUkraine]

Add bfu_ua_display package for rendering Ukrainian text on MicroPython displays.

Features:

• Full Ukrainian alphabet support (33 letters)
• 5x7 bitmap font optimized for ESP32
• Works with any display supporting pixel() method
• Tested with SSD1306 OLED displays

Package provides ua_text, ua_text_center, and ua_text_scaled functions.

[Josverl]

Дякую for the contribution.

A few initial comments:
With regards to location I think it should be in the python-ecosys/ folder as it is not part of the MicroPython firmware.
That would still allow it to be directly used by custom firmware.

Also on a first look the PR appears to be created using AI.
while the PR template in this repo does not (yet) explicitly ask this question, the contributor guidelines still apply.
I kindly ask you to add that to the initial PR comment to clarify that.

For more information, consult the MicroPython Generative AI Policy:
https://github.com/micropython/micropython/wiki/ContributorGuidelines#generative-ai-policy

[BrainFromUkraine]

Thank you for the review and feedback.

I've moved the package from micropython/bfu_ua_display to python-ecosys/bfu_ua_display as requested.

All related files were relocated while keeping the public API and functionality unchanged. All formatting, linting, and CI checks are now passing successfully.

I also want to clarify that AI tools were used during development and documentation assistance for this contribution, while the implementation, testing, fixes, and final review were performed manually.

Thanks again for the guidance and review.

[Josverl]

Thanks for clarifying.

Have you considered an optional framebuffer fast path for framebuffer-backed drivers?

Right now rendering is per-glyph/per-pixel via pixel() (and fill_rect() for scaled text), which is nicely portable.
However on common ESP32 display stacks a framebuf/blit path could reduce Python call overhead and make scaled or repeated text rendering significantly faster while keeping the existing pixel() fallback.

[BrainFromUkraine]

Thanks for the suggestion.

Yes, I have considered framebuffer-backed rendering paths as a possible future optimization, especially for ESP32 display stacks using framebuf/blit operations.

The current implementation intentionally prioritizes portability and compatibility across different MicroPython display drivers by relying on the generic pixel() fallback path.

I agree that an optional framebuffer/blit accelerated path could significantly reduce Python call overhead and improve rendering performance for scaled or repeated text rendering.

I’ll definitely explore this direction further while keeping compatibility with existing drivers.

[BrainFromUkraine]

Hi,

I checked the latest Ruff failure.

The package added in this PR passes Ruff locally:

py -m ruff check python-ecosys/bfu_ua_display
# All checks passed!

The current Ruff CI failure appears to come from pre-existing unrelated files outside this PR, for example micropython/*, unix-ffi/*, and python-stdlib/*.

I did not modify the global Ruff workflow, to keep this PR focused only on adding python-ecosys/bfu_ua_display.

Please let me know if there is anything else you would like me to adjust in the package itself.

[BrainFromUkraine]

Quick follow-up regarding the Ruff issue:

I found the actual cause and resolved it.

During debugging, I temporarily introduced a local Ruff configuration override, which unintentionally bypassed the repository exclude rules and caused unrelated legacy directories to be linted by CI.

The temporary override has been removed, the package was adjusted to fully comply with the existing repository Ruff rules, and all CI checks are now passing successfully.

Thanks again for the review and guidance.

Thank you