Tim Kruse
Projekte yomikata

yomikata

Live · nur mit Zugang

Manga-Reader für Android und Browser, mit eigenem Backend vor meiner Bibliothek. Der Lesestand gilt auf beiden Geräten, Bände auch offline.

Der Leser von yomikata mit einer per KI erzeugten Manga-Seite, von rechts nach links zu lesen: Ein Mann mit Cap fragt sich, welches Design er nehmen soll, verzweifelt kurz und nimmt dann alle sechs. Darunter Seitenanzeige 91 von 197 und die Umschalter für Leserichtung und Panel-Modus. Dazu der Katalog mit erfundenen, ebenfalls erzeugten Covern wie „Kater Kommissar“, „Klartext“ und „Kapselautomat“.
Zeitraum
2025 – heute
Rolle
Allein, Konzept bis Betrieb
Zustand
Live, hinter dem Single Sign-on
Code
Repository privat

Ich lese Manga unterwegs auf dem Telefon und zu Hause auf dem Tablet, dieselbe Serie auf beiden. Die Bände liegen auf meinem eigenen Grimmory-Server, und dessen eingebauter Leser taugte dafür wenig. Die fremden Apps, die ich danach probiert habe, scheiterten am Server oder kannten keinen Lesestand, den beide Geräte teilen.

yomikata ist der Leser dafür: eine Android-App und eine Weboberfläche, beide gegen ein eigenes Backend, das seinerseits mit der Bibliothek spricht. Dazu kommt, was einen Manga-Leser von einem Comic-Leser unterscheidet: Die Leserichtung wird pro Serie gesetzt, weil eine gemischte Bibliothek beide Richtungen enthält und der Server dazu bei jeder Serie dasselbe sagt. Heruntergeladene Bände sind im Flugmodus vollständig lesbar und räumen sich nach dem Durchlesen selbst weg. Helligkeit und Warmfilter sitzen im Leser selbst, nicht drei Ebenen tief in den Einstellungen: abends ist die Mindesthelligkeit des Systems zu hell.

Der Panel-Modus ist das, was ich am liebsten vorführe. Auf dem Telefon entscheidet er, ob Lesen dort überhaupt geht. Eine Doppelseite mit sieben Panels ist auf sechs Zoll ein Suchbild: zoomen, schieben, die Leserichtung verlieren, die bei Manga von rechts nach links läuft. Deshalb kennt die Seite ihre Panels. Ein Doppeltipp schaltet um, danach führt jeder Tipp zum nächsten Panel, herangezoomt und zentriert, alles andere abgedunkelt, am Seitenende von selbst weiter auf die nächste. Die Reihenfolge steht in den Daten, schon in Leserichtung, der Leser sortiert nie selbst. Die Panels findet Magi, ein Bildmodell, das eigens für Manga trainiert wurde. Gerechnet wird auf meinem Rechner, in einem eigenen Werkzeug, das für große Läufe Grafikkarten mietet und sie hinterher wieder abschaltet.

Die App ist für wenige Leute mit je zwei Geräten gebaut, und dabei bleibt es: ein Erscheinungsbild, ein Dateiformat, keine Filter, keine Sortierung. Eigene Konten, eigene Zugänge und eigene Lesestände trägt das Backend darunter, und wer das helle Erscheinungsbild vermisst, liest im Browser. Einfach vor allgemein, das habe ich mir als Regel aufgeschrieben.

Stack
KotlinComposeRoomTypeScriptExpressSQLiteReactVitePWAPythonFastAPIPyTorch (Magi v2)RunPod

Entscheidungen

ADR 014

Den Server vermessen, statt der Beschreibung zu glauben

Die Grimmory-Instanz bietet eine Schnittstelle, hält aber nicht alles, was deren Beschreibung verspricht: ausgerechnet einen Lesestand abzulegen war nicht darunter, und zwar bei keinem einzigen Buch. Wäre das erst beim Bauen aufgefallen, hätte es die einzige Funktion gekostet, derentwegen es die App gibt. Statt auf ein Update fremder Software zu warten, ist die App auf das zugeschnitten, was der Server nachweislich kann.

ADR 004

Die höhere Seite gewinnt

Zwei Geräte melden für dasselbe Buch verschiedene Seiten, und einer der beiden Stände muss weichen. Die übliche Regel (der neuere gewinnt) wäre hier die falsche. Wer am Tablet auf Seite 80 ist und das Buch am Telefon versehentlich aufschlägt, hätte mit Seite 1 den frischeren Eintrag, und der Fortschritt wäre weg. Deshalb gewinnt die höhere Seite, und nur ein ausdrückliches Zurücksetzen darf darunter.

ADR 009

Zwischengespeichert ist nicht heruntergeladen

Gelesene Seiten bleiben auf der Platte liegen, damit Zurückblättern sofort geht. Das sieht aus wie ein Download, ist aber keiner. Und ein Zwischenspeicher, den man für eine Offline-Garantie hält, führt zum schlimmsten Fehlerbild: im Zug ein Buch öffnen, das gestern noch da war. Beide Speicher werden deshalb getrennt geführt, getrennt geräumt und getrennt angezeigt. Die Offline-Markierung trägt nur, was ausdrücklich geladen wurde.

ADR W14

Das Rechnen gehört nicht auf den Server

Die Panels müssen irgendwo entstehen, und der naheliegende Ort wäre das Backend: eine Warteschlange, ein Job je Band, fertig. Der Server ist aber ein kleiner VPS. Er trüge damit ein Job-System und eine Bildverarbeitung für eine Aufgabe, die je Band genau einmal anfällt. Stattdessen rechnet ein lokales Werkzeug, das Panel-Studio, und lädt die fertige Geometrie hoch. Der Server prüft nur, ob sie stimmt. Auch verworfen: die Rechtecke in die Dateien selbst zu legen. Dafür gibt es kein Format, das eines der beteiligten Programme liest. Und jedes Umpacken änderte die Prüfsummen der Dateien, und an denen hängt der Lesestand.

ADR 027

Grafikkarten mieten statt die eigene zu quälen

Eine Seite zu vermessen dauert auf der eigenen CPU dreieinhalb Sekunden. Achtzig neue Bände sind damit sechzehn Stunden, in denen der Rechner nichts anderes vernünftig tut. Auf einer gemieteten Karte dauert dieselbe Seite gut ein Zehntel einer Sekunde, abgerechnet wird nach Minuten. Der größte Lauf bisher waren 16.366 Seiten auf zwei Maschinen, vierzehn Minuten, fünfzig Cent. Dass fremde Hardware einen Ausweis für die eigene Bibliothek bekommt, war der eigentliche Einwand. Deshalb holen sich die gemieteten Maschinen ein zweites, kurzlebiges Token, das nach dem Lauf widerrufen wird.

Die ganze Seite in einem anderen Design

Gleiche Inhalte, andere Gestaltung. Es geht auf der Startseite los, alle Links bleiben im gewählten Design.

Was ist das? Über diese Seite →