retoorandClaude Opus 4.8
115e403e67
Native WhatsApp Web multi-device client in C++ (src/whatsapp/, namespace detz::wa), built on OpenSSL plus a vendored public-domain ed25519 ref10 (third_party/ed25519, zlib) for XEdDSA and the nayuki QR generator (third_party/qrcodegen, MIT); no new runtime dependency. - WaCrypto, WaBinary, WaProto, WaNoise, WaSignal, WaDevice, WaSocket, WaClient, WaStore, WaQr, WaWizard. - Verified offline against golden vectors captured from the real Baileys client (tests/whatsapp_data, from jfelipesjc/wa-go, MIT): HKDF/PBKDF2 RFC vectors, XEdDSA roundtrips, codec battery 19/19, ClientPayload byte-exact, the Noise handshake, and a 4-exchange Signal session byte-exact. Unit test build/whatsapp_test (16/16), run_all step whatsapp.unit. - Verified live against web.whatsapp.com: `detz --whatsapp-link` connects, completes the Noise handshake, receives pair-device, renders a scannable QR in the terminal, and persists the device to the vault (whatsapp/<profile>.db). Also --whatsapp-status / --whatsapp-unlink. - Agent tools whatsapp_send and whatsapp_contacts (detz-only, in DetzTools). - Pairing completion after the phone scans, and the message send path (usync + prekey fetch + Signal encrypt + send node), are ported faithfully from whatsmeow but unverified in-tree (no linked account in development). send_image and own-device fan-out are not wired yet. See docs/whatsapp.md. Also in this snapshot: the terminal-screenshot tool (src/termshot/, terminal_screenshot, docs/termshot.md, research/terminal-screenshot-rendering) and a concurrent session's in-progress llm/muse failover changes carried along in the shared files. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
49 lines
1.4 KiB
Markdown
49 lines
1.4 KiB
Markdown
# jiro4989/textimg README
|
|
|
|
## Metadata
|
|
|
|
| Field | Value |
|
|
|---|---|
|
|
| Institute | Molodetz Institute — Research & Retrieval Division |
|
|
| Subject | terminal-screenshot-rendering |
|
|
| Document type | Source Dossier |
|
|
| Tier | 1 |
|
|
| Source title | jiro4989/textimg README |
|
|
| Source URL | https://github.com/jiro4989/textimg |
|
|
| Source publisher / author | jiro4989 |
|
|
| Source type | repository |
|
|
| Source date (published) | Unknown — not stated |
|
|
| Date researched | 2026-10-27 |
|
|
| Researched by | tai (agent), model: Claude Opus 5.5, on behalf of retoor |
|
|
| Research method | direct page fetch |
|
|
| Confidence | Medium |
|
|
| Status | Active |
|
|
|
|
## Summary
|
|
|
|
textimg converts ANSI or 256-color text to PNG, JPG or GIF, using a system CJK font chosen per OS.
|
|
|
|
## Key findings
|
|
|
|
- Default font on Linux `/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc`; override with TEXTIMG_FONT_FILE or -f.
|
|
- Supports 8, 256 and 24-bit SGR colors; PNG default; animated GIF option.
|
|
- Emoji need extra image files or an emoji font; not tested on Windows; MIT.
|
|
|
|
## Pros / strengths
|
|
|
|
Clear statement of color support levels a renderer must cover.
|
|
|
|
## Cons / limitations / caveats
|
|
|
|
Depends on a system font that a headless server usually lacks; external Go binary.
|
|
|
|
## Relevance to tai
|
|
|
|
Rejected; its system-font dependency is the exact failure an embedded bitmap font avoids.
|
|
|
|
## Changelog
|
|
|
|
| Date | Change |
|
|
|---|---|
|
|
| 2026-10-27 | Initial dossier created. |
|