Farben am QR-Code speichern — mit Kontrastprüfung

Bisher galten Farben nur für einen einzelnen Abruf: ?fg=1F4E79 an der Bild-URL. Jetzt kann sich ein Code seine Farben merken.

Was neu ist

curl -X PATCH https://qr3.app/v1/codes/qr_a1b2c3d4 \
  -H "Authorization: Bearer qr3_sk_..." \
  -H "Content-Type: application/json" \
  -d '{"appearance": {"foreground_color": "#1F4E79"}}'

• Gespeichert: foreground_color und background_color (#RRGGBB, der Hintergrund auch transparent). SVG und PNG zeichnen sie ab sofort ohne Parameter; PDF und EPS folgen mit einem der nächsten Releases.
• Parameter haben Vorrang: ?fg=000000 liefert weiterhin die schwarze Druckdatei desselben Codes.
• Fehlerkorrektur bleibt eine Wahl je Download (?ecc=) und wird nie am Code gespeichert.

Die Kontrastprüfung

Die API prüft jedes Farbpaar, bevor sie es speichert:

• Unter 1,5:1 — etwa Weiß auf Weiß — lehnt sie mit 422 ab.
• Knappe Paare speichert sie und meldet sie als Warnung oder als kritisch, zum Beispiel das Markenorange #F7901E auf Weiß.
• Transparenter Hintergrund ist immer kritisch, aber nie gesperrt: Ein heller Code auf dunkler Verpackung ist erlaubt. Der Untergrund muss dann den Kontrast liefern und rundum 4 Module Ruhezone frei lassen.

Was Sie tun müssen

Nichts. Ohne gespeicherte Farben liefert jeder Code dieselben Bytes wie vorher. Der MCP-Server und das TypeScript-SDK ab Version 1.2.0 kennen die neuen Felder (npm install @qr3/sdk@latest); die Farbauswahl im Dashboard folgt.

Wer ein Bild einbettet: Eine Bild-URL folgt den gespeicherten Farben, soweit sie sie nicht selbst mit fg und bg festlegt. Nach einer Farbänderung kann eine Seite, die eine solche URL einbettet, noch das alte Bild zeigen: bis zu 24 Stunden, wenn die URL bis dahin das Standardbild lieferte (Schwarz auf Weiß, Fehlerkorrektur M, kein Logo), etwa vor dem ersten Einfärben, sonst bis zu 5 Minuten. Ein eigener Parameter wie ?v=2 hilft sofort.

Alle Details stehen unter Farben am Code speichern.