# Post-Generator — Regeln & Konventionen Arbeitsgrundlage für alles, was in diesem Repo an Social-Grafiken entsteht. **Stand:** 31.07.2026 Der Generator läuft lokal: `./serve.sh` → (Post 1, Carousel). --- ## 1. Wo die Wahrheit steht Alle Marken-Werte stammen aus der Website, nicht aus diesem Repo. Bei Zweifel **dort nachschauen, nicht hier raten**: | Was | Quelle | |---|---| | Farben, Radien, Abstände | `HiveGrid-Website/app/globals.css` (`:root`) | | Chamfer-Form | `HiveGrid-Website/lib/chamfer.ts` | | Schrift | `HiveGrid-Website/app/layout.tsx` | | Badge-Styling | `HiveGrid-Website/components/sections/ScreenshotAccordion.tsx` | | Feature-Texte | `HiveGrid-Website/app/playground/PlaygroundClient.tsx` → `solutionModules` | Die Werte sind hier gespiegelt, weil der Export keine Tailwind-/oklch-Farben verträgt (siehe §7). Ändert sich die Website, müssen sie **hier nachgezogen werden** — das passiert nicht automatisch. --- ## 2. Farben ### Marke | Token | Wert | Verwendung | |---|---|---| | `--accent-yellow` | `#F1B729` | Primärer Akzent, Marker, G-Marke | | `--accent-yellow-light` | `#FFE082` | Badge-Hintergrund | | `--accent-yellow-dark` | `#3E2C0A` | Badge-Text | | `--accent-teal` | `#0D6E6E` | Sekundär, aktuell ungenutzt | | `--dark-bg` | `#30313D` | Dunkle Variante + Formen-Ebene | ### Flächen & Text | Token | Wert | |---|---| | `--surface` | `#FFFFFF` | | `--bg-primary` | `#FAFAFA` | | `--text-primary` | `#1A1A1A` | | `--text-secondary` | `#555555` | | `--text-on-dark` | `#C8D0DC` | ### Pro Variante **Hell** (Grund `#FFFFFF`) ``` --head-color #1A1A1A --frame-bg #E8EBF0 --body-color #555555 --shape-fill #30313D (deckend!) --accent-on #C8901A --shape-line rgba(48,49,61,.13) --marker #F1B729 --shape-accent #F1B729 --pat-color #30313D --gmark-color rgba(48,49,61,.16) ``` **Dunkel** (Grund `#30313D`) ``` --head-color #FFFFFF --frame-bg rgba(255,255,255,.11) --body-color #B9BDC9 --shape-fill #414252 --accent-on #F1B729 --shape-line rgba(255,255,255,.10) --marker #F1B729 --shape-accent #F1B729 --pat-color #FFFFFF --gmark-color rgba(255,255,255,.13) ``` > **`--accent-on` ist nicht `#F1B729`, sondern `#C8901A` auf Hell.** Reines > Markengelb trägt auf Weiß bei kleinem Text nicht. Der abgedunkelte Ton ist > Absicht, kein Fehler. > **Der Block oben rechts ist auf Hell deckendes `#30313D`.** Das ist derselbe > Wert wie die dunkle Story-Sektion der Website. Er darf **nicht** über die > Intensitätsstufe aufgehellt werden, sonst ist es nicht mehr die Markenfarbe > (siehe §5). --- ## 3. Geometrie ### Chamfer Die Marken-Form: abgeschnittene Ecken, Echo der Honigwabe. Auf der Website 16 px, hier hochskaliert, weil die Fläche viermal so groß ist. ```css clip-path: polygon( Xpx 0, calc(100% - Xpx) 0, 100% Xpx, 100% calc(100% - Xpx), calc(100% - Xpx) 100%, Xpx 100%, 0 calc(100% - Xpx), 0 Xpx ); ``` | Element | X | |---|---| | Badge | 11 px | | Mockup-Rahmen außen | 22 px | | Mockup-Rahmen innen | 14 px | **Drei Fallstricke** (stehen auch in `chamfer.ts`): - `clip-path` beschneidet **auch den Schatten** → wäre über `filter: drop-shadow()` zu lösen, nie über `box-shadow`. Praktisch irrelevant, seit die Posts schattenfrei sind (siehe §5) - `clip-path` beschneidet **auch den Rahmen** → Rand über eine Hintergrundfläche lösen, nicht über `border` - Kinder, die aus der Box ragen (Popups, Tooltips), werden abgeschnitten → solche Elemente nicht chamfern ### Hexagon Flat-Top, also flache Ober- und Unterkante mit Spitzen links und rechts: ```css clip-path: polygon(25% 0%, 75% 0%, 100% 50%, 75% 100%, 25% 100%, 0% 50%); ``` **Seitenverhältnis 384,5 : 332,9 = 1,155 (= 2/√3).** Aus der Logomarke abgeleitet, nicht geschätzt. Wer davon abweicht, staucht das Sechseck. ### G-Marke Ein einziges Polygon, aus `logo.svg` extrahiert (dort die einzige Fläche mit `class="st3"`), auf 0,0 normalisiert: ``` 384.5,166.5 336.4,83.2 192.2,166.5 288.3,166.5 240.3,249.7 144.2,249.7 96.1,166.5 144.2,83.2 336.4,83.2 298,16.8 288.3,0 96.1,0 0,166.5 96.1,332.9 288.3,332.9 ``` Immer **inline** als SVG einsetzen, nie als `` — nur so lässt sie sich per `currentColor` pro Variante umfärben, und nur so überlebt sie den Export zuverlässig (§7). ### Wabenraster Nahtlose Kachel aus derselben G-Form. Bei Flat-Top-Hexagonen springen die Spalten um ¾ der Breite, benachbarte Spalten sitzen eine halbe Reihe versetzt. Eine Kachel = zwei Spalten breit, eine Reihe hoch. **Die über den Kachelrand hinausragenden Kopien sind Pflicht** — ohne sie sieht man die Nähte. --- ## 4. Typografie ### Die Schrift **Manrope** — dieselbe wie auf der Website. Bewusst nicht Inter: Der Kommentar in `app/layout.tsx` nennt Inter „the default AI/website-builder font"; Manrope ist eine Spur wärmer und geometrischer. ```css font-family: 'Manrope', system-ui, sans-serif; ``` | | | |---|---| | Schnitte | 400, 500, 600, 700, 800 | | Ablage | `assets/fonts/manrope.css` + 6 `.woff2` | | Subsets | latin, latin-ext, cyrillic, cyrillic-ext, greek, vietnamese | | Herkunft | Google Fonts, einmalig heruntergeladen | **Warum lokal und nicht per CDN:** Der Export darf zur Laufzeit an keiner fremden Origin hängen. Ein Font von `fonts.gstatic.com` wäre cross-origin, würde den Export vom Netz abhängig machen und im Zweifel den Canvas verunreinigen. Die URLs in `manrope.css` sind deshalb auf relative Pfade umgeschrieben. > **Vor jedem Export auf `document.fonts.ready` warten.** Sonst rendert der erste > Durchgang still in einer System-Fallback-Schrift, und man sieht es erst in der > fertigen Datei. Der Download-Button bleibt bis dahin deaktiviert. ### Größen | Element | Größe | Weight | Sonstiges | |---|---|---|---| | Headline | 74 px | 800 | `line-height: 1.06`, `letter-spacing: -0.03em` | | Titel-Tagline | 74 px | 800 | identisch zur Headline, bewusst | | Fließtext | 30 px | 500 | `line-height: 1.48`, `max-width: 830px` | | Badge | 26 px | 600 | `letter-spacing: 0.1em` | | Claim (Titel) | 31 px | 500 | `line-height: 1.44` | ### Akzent-Wörter Zwei Behandlungen, **nie beide im selben Textblock**: - **Marker** — handgezeichneter SVG-Strich als `background-image`, wellige Kanten, angeschrägtes linkes Ende. Für Headlines und Payoffs. Ein CSS-Verlauf ist hier **verboten**: er kann geometrisch nur ein perfektes Rechteck erzeugen und sieht gedruckt statt gemalt aus. - **Farbe** (`--accent-on`) — für kleinere Zeilen. Pro Slide höchstens **ein** markiertes Wort. Zwei Marker in einem Block waren schon zweimal zu viel. ### Sprache - Alles Sichtbare auf **Deutsch**, Code-Kommentare auf **Englisch** - **Keine Em-Dashes (—)** in sichtbaren Texten. Komma, Punkt oder `·` - Feature-Texte wortgleich von der Website. Headlines dürfen gekürzt und umgestellt werden, aber **keine neuen Wörter erfinden** --- ## 5. Aufbau der Slides ### Formate **Die Anzahl der Slides ist frei.** Sie kommt aus dem Deck im Projektstand, nicht aus dem Code. Das durchgehende Blatt (§5, „Durchgehend") ist deshalb `--sheet-w` breit statt fester 5400 px; die vier Sechsecke auf den Nähten sitzen weiterhin auf 1080 / 2160 / 3240 / 4320 und decken damit die ersten fünf Slides ab. Wer länger baut, bekommt dahinter nur noch das Band. **1080 × 1350 px (4:5)** — das hochkantigste offiziell unterstützte Feed-Format. Belegt: Instagram unterstützt 1.91:1 bis 4:5, Breiten 320–1080 behalten die Originalauflösung, alles außerhalb wird beschnitten. - **Alle Slides eines Carousels müssen dasselbe Seitenverhältnis haben** — die erste Slide setzt es, der Rest wird hart darauf beschnitten - Safe Zone: nichts Lesbares näher als ~92 px an den Rand - Der **Profil-Grid** zeigt seit 2025 Hochformat und beschneidet auf 3:4 — im Grid fehlen links und rechts je ~33 px. Für die drei angepinnten Cover relevant, im Feed nicht ### Layout-Template: Tag, Überschrift, Beschreibung, Bild Jede Feature-Slide besteht aus denselben vier Bausteinen in derselben Reihenfolge. Das ist keine Geschmacksfrage — Wiedererkennung über fünf Slides entsteht genau dadurch, dass sich das Gerüst nicht bewegt. ``` 92 ┌──────────────────────────────────────┐ │ ▌ TAG │ ← ausgerückt (siehe unten) │ │ │ Überschrift, zwei Zeilen │ ← dominiert die Slide │ mit einem markierten Wort │ │ │ │ Beschreibung, zwei bis drei │ ← kürzer als man denkt │ Zeilen Fließtext │ │ │ │ ┌────────────────────────────────── │ │ │ Bild │ ← ein dominanter Blickfang │ │ │ └──┴───────────────────────────────────┘ ``` **Größenverhältnisse.** Die Hierarchie muss ohne Nachdenken lesbar sein — was zuerst, was zweitens, was drittens. Bei uns: Überschrift 74 px, Fließtext 30 px, Tag 26 px. Das Verhältnis Überschrift zu Fließtext liegt bei rund **2,5 : 1**; gängige Empfehlungen für Carousels nennen Überschrift 48–72 pt gegen Fließtext 24–36 pt, also dieselbe Größenordnung. Weniger Abstand als Faktor 2 und die Hierarchie kippt. **Ein Blickfang pro Slide.** Genau ein Element, auf das das Auge sofort springt — bei uns die Überschrift, danach das Bild. Zwei gleich starke Elemente lassen den Betrachter raten und wegwischen. **Weißraum ist kein verschenkter Platz**, sondern das, was die Blöcke trennt. Der Abstand zwischen Tag und Überschrift ist deshalb größer als der zwischen Überschrift und Beschreibung: getrennte Gedanken brauchen mehr Luft als zusammengehörige. #### Das Tag wird ausgerückt Der Tag hat 20 px Innenabstand. Steht sein **Kasten** bündig zur Inhaltskante, beginnt sein **Text** 20 px weiter rechts als die Überschrift — und genau das sieht man: ``` vorher nachher 92 │▌ WORKFLOW-ENGINE 72 │▌ WORKFLOW-ENGINE 92 │Wenn-dann 92 │Wenn-dann └ Kasten bündig, └ Text bündig, Text 20 px versetzt Kasten ragt aus ``` Gelöst über `margin-left: -20px`, also genau den Innenabstand. Das ist dasselbe Prinzip wie hängende Interpunktion im Satz: Ausgerichtet wird nach der **wahrgenommenen** Kante, nicht nach der geometrischen. Der Kasten steht dann bei x 72 — immer noch weit innerhalb der Safe Zone. > Wer die Innenabstände des Tags ändert, muss das negative Margin mitziehen. > Die beiden Werte gehören zusammen. ### Ebenen (von hinten nach vorn) | z-index | Ebene | |---|---| | 0 | Hintergrund: Formen, Wabenraster, Punkte, Raster, G-Marke | | 1 | Mockup | | 2 | Inhalt: Badge, Headline, Fließtext | | 3 | Swipe-Hinweis | ### Keine Schatten **Nichts wirft einen Schatten** — weder Bilder noch Mockups, Logos, Zettel oder Text. Kein `box-shadow`, kein `filter: drop-shadow()`, kein `text-shadow`. Tiefe entsteht stattdessen über: - **Überlappung** — ein zweites Bild vor dem ersten liest sich auch ohne Schlagschatten als davor - **Rahmenfarbe** — der chamferte Rahmen (`--frame-bg`) setzt das Bild von der Fläche ab - **Versatz und Drehung** — beim Stapel und beim Notizzettel **Ausnahme, und nur diese:** Die Blätter im Stapel-Rahmen bekommen eine Haarlinie (`1px rgba(48,49,61,.18)`). Ohne sie läge auf der hellen Variante Weiß auf Weiß und der Stapel wäre nicht mehr zu erkennen. Eine Linie ist kein Schatten. Warum: Weichgezeichnete Schatten sind das erste, was einen Post nach Vorlage aussehen lässt. Flächig gesetzt wirkt es ruhiger und passt zur Website, die denselben Weg geht. Nebenbei ist es beim Export billiger — jeder unscharfe Filter muss beim 3-fachen Rendern dreifach berechnet werden. ### Was global gilt und was pro Slide | Einstellung | Geltung | Warum | |---|---|---| | Variante (Hell/Dunkel) | **global** | gemischt fällt das Carousel auseinander | | Mockup-Perspektive | **global** | dito | | Renderqualität | **global** | Exportstufe, kein Gestaltungsmittel (§7) | | Layout | pro Slide | jede Slide hat einen eigenen Katalog | | Muster | pro Slide | | | Intensität | pro Slide | | ### Durchgehendes Carousel (Panorama) Der Post ist dann kein Stapel von fünf Bildern mehr, sondern **ein einziges Blatt von 5400 × 1350 px**, das in fünf 1080er Fenster geschnitten wird. Wer swipet, sieht Elemente über die Kante hinauslaufen und auf der nächsten Slide weitergehen. ``` Slide 1 │ Slide 2 │ Slide 3 │ Slide 4 │ Slide 5 0 ─────── 1080 ────── 2160 ────── 3240 ────── 4320 ────── 5400 ↑ ↑ ↑ ↑ die vier Nähte ``` **Technisch:** Eine Ebene von 5400 px Breite liegt in jeder Slide, verschoben um `index × -1080 px`. Jede Slide zeigt dadurch ihr Fenster desselben Blatts. Kein Zuschneiden von Hand, kein Splitter-Tool — die Slides *sind* die Schnitte. **Regeln, die dabei zählen:** 1. **Slide 1 muss allein funktionieren.** Sie ist das Cover im Profil-Grid. Sie darf nicht wie „das linke Fünftel von etwas" wirken 2. **Die Naht ist nie unsichtbar.** Instagram zeigt beim Swipen ein paar Pixel Abstand zwischen den Slides. Das lässt sich nicht abstellen und ist auch nicht schlimm — der Effekt trägt trotzdem 3. **Nichts Wichtiges auf die Naht legen.** Keine Schrift, kein Gesicht, kein Logo. Der Schnitt gehört in ruhige Zonen 4. **Aber etwas Auffälliges über die Naht laufen lassen.** Eine halbierte Form zieht das Auge weiter und lenkt vom Spalt ab. Genau dafür sitzen unsere Sechsecke **mittig auf 1080 / 2160 / 3240 / 4320** — je zur Hälfte links und rechts der Naht 5. **Nur Standbilder.** Ein Video mitten im Carousel bricht den Fluss **Was bei uns auf dem Blatt liegt:** vier Sechsecke auf den vier Nähten (abwechselnd massiv und Kontur, unterschiedliche Höhen), die G-Marke auf der Naht 2|3, und ein durchgehendes Band über die volle Breite als Klammer. Das ist ein **globaler** Schalter, kein Muster pro Slide — er wirkt naturgemäß auf alle fünf. Die Muster pro Slide bleiben zusätzlich verfügbar; für den reinen Panorama-Look überall auf „Aus" stellen. > Gängige Empfehlung sind 2–4 Slides fürs Panorama. Wir haben fünf. Das > funktioniert, verlangt aber eine ruhigere Gestaltung — bei fünf Fenstern wird > jede zusätzliche Form schnell unruhig. ### Intensität Die Stufe „Dezent" (Faktor 0,55) wirkt **nur auf Nebenelemente** — Hexagon-Kontur, Waben, Punkt- und Linienraster, G-Marke. Der große Block oben rechts bleibt immer deckend, sonst wäre er nicht mehr exakt `#30313D`. --- ## 6. Mockups Kein fotorealistischer Laptop-Rahmen für die Feature-Slides: Die Website rahmt jeden Screenshot mit dem Chamfer (`.screenshot-frame` in `globals.css`). Das ist die markeneigene Mockup-Form und verbindet die Posts mit der Seite. Der Laptop auf der Titel-Slide ist die Ausnahme und bewusst ein Blickfang. ### Geometrie pro Slide Breite, Seitenverhältnis und Position sind CSS-Variablen mit Defaults: ``` --mock-w 1090px (ragt ~100 px über die rechte Kante) --mock-ar 1.6 (16:10) --mock-left 92px ``` **Regel: Das Format des Rahmens folgt dem Inhalt des Screenshots, nicht umgekehrt.** Der Form Builder ist eine schmale, zentrierte Spalte mit breiten leeren Rändern — in einem 16:10-Rahmen zeigt er vor allem Leere. Er bekommt deshalb 540 × 720 (3:4), mittig gesetzt, und einen Zoom von 3,8 direkt auf die Spalte. ### Screenshots zuschneiden Quellen sind ~2000 px breit und im Vollbild unlesbar. Jeder Screen wird auf seinen aussagekräftigen Bereich gezoomt. Die Werte sind gerechnet, nicht geraten: ``` Rahmenbreite = 1 Einheit, Bild bei scale 1 = 1 Einheit breit Bildhöhe = 1/BildAR Rahmenhöhe = 1/RahmenAR Punkt fx horizontal mittig: tx = 0.5/s − fx Punkt fy vertikal mittig: ty = (RahmenH/2)/(s · BildH) − fy ``` Mindest-Zoom zum Füllen: `RahmenH / BildH`. Darunter entstehen Lücken. **Ausnahme Titel-Slide:** Der Laptop zeigt den Screen **1:1**, ohne Zoom. Dort soll ein Bildschirm zeigen, was ein Bildschirm zeigt. Die Displayfläche misst 739 × 489 (AR 1,511), `workflow.png` hat 1,504 — passt praktisch deckungsgleich. ### Neue Geräte-Mockups einbauen 1. Braucht **echte Transparenz**. Ein Screenshot eines transparenten PNGs ist keine Transparenz — das Karomuster steckt dann als Pixel drin und lässt sich nicht sauber entfernen (einmal versucht, Ergebnis unbrauchbar) 2. Ist die Displayfläche deckend, muss sie **ausgeknockt** werden, damit der Screenshot dahinter liegen kann. Nur so bleiben Notch und Rundungen oben 3. Displayfläche ausmessen und als Prozentwerte eintragen — sie hängt am konkreten Bild 4. **Kein Schatten im PNG** — die Posts sind schattenfrei (§5), ein eingebrannter Schlagschatten im Mockup-Bild lässt sich nicht mehr abschalten ### Szenen-Mockup (Perspektive) `assets/mockups/macbook-szene.png` — Macbook Air + iPad Pro, freigestellt aus einem Pixeden-PSD. Anders als `laptop.png` steht die Szene schräg, die Displayflächen sind also **Vierecke, keine Rechtecke**. Damit reicht die übliche Prozent-Box nicht. Der Screenshot wird per `matrix3d` in die Fläche projiziert: | | Macbook | iPad | |---|---|---| | Design-Größe | 3456 × 2234 | 1438 × 2164 | | Format | 1,547 | **0,6645** | | Eckradius | 0 | 57 px | | Viereck aus | Smart-Object | vermessene Glasfläche | **Zulieferung: ein iPad-Screenshot muss 0,6645 haben** (1 : 1,505), also z. B. 1440 × 2167. Beim Macbook 1,547, dort verschwinden die unteren 15 % hinter der Tastaturschale. Die Matrizen bilden **Design-Pixel auf Bildpixel des 5742 px breiten Originals** ab; `--sk` skaliert von dort auf die Breite in der Slide und wird in `applyEdits()` gesetzt, damit eine Größenänderung mitläuft. Die Eckpunkte stammen aus dem `transform_box` der Smart-Objekte im PSD, sind also gemessen und nicht angepasst. **Beide Displays sind ausgeknockt**, der Ausschnitt am Macbook endet dort, wo das iPad davor liegt. Sonst läge der Screenshot vor dem Tablet. Der Ausschnitt kommt aus der Deckung der Screen-Ebene, **nicht** aus dem Design-Rechteck: das reicht hinter das Gehäuse und würde die Tastaturschale anschneiden. **Die Geräte standen auf einer Glasplatte.** Mit dem Hintergrund fällt die Platte weg, ihre Spiegelung bleibt aber als zweiter Körper stehen, und der Spalt dazwischen wird auf hellem Grund zur weißen Linie. **Der Spalt bekommt keinen festen Farbwert, sondern wird spaltenweise interpoliert.** Für jede Bildspalte: Medianfarbe der fünf Pixel über dem Spalt, Medianfarbe der fünf darunter, linear dazwischen. Am Display bleibt so Schwarz, am Gehäuse das Metallic, an der Kante der Verlauf. Es gibt keinen Farbsprung mehr und damit auch keinen Streifen. > Ein einheitlicher Ton reicht nicht. Der Spalt läuft quer über Displayrand > **und** Aluminium, also über zwei völlig verschiedene Töne. Jeder feste Wert > passt an einer Stelle und sitzt an der anderen als Fremdkörper. > Nicht wegschneiden: die Spiegelung hängt am Fuß des iPads, ein Schnitt nach > Zusammenhangskomponenten trennt den mit ab. Das war der erste Versuch. Die Füllung läuft über die **volle Breite**, auch unter dem iPad: dessen eigener Spalt ist sonst als weiße Linie unter dem Rahmen zu sehen. Mit einem festen Ton ging das nicht, da saß dort ein harter dunkler Block auf dem Aluminium; mit der Interpolation passt es. **Das iPad-Viereck kommt nicht aus dem Smart-Object.** Das sitzt im PSD zu hoch und lässt unten einen dreimal so breiten schwarzen Streifen stehen wie oben. Statt dessen wird die schwarze Glasfläche vermessen: 1. Randpunkte der vier Kanten sammeln, **nur im mittleren Drittel** — an den Ecken liegen sie auf den Rundungen 2. Ausgleichsgerade je Kante, benachbarte schneiden → die **echten** Ecken. Über Extrempunkte kommt ein zu kleines, verdrehtes Viereck heraus, weil die Extrema auf den Rundungen sitzen 3. Eckradius aus dem Abstand Ecke zu Glas: bei einem rechten Winkel liegt der Scheitel der Rundung bei `r · (√2 − 1)` → **Glas 1514 × 2240, r = 95** 4. **38 px** Rand nach innen (2,5 % der Breite) → Display 1438 × 2164 5. Innenradius **konzentrisch**: `95 − 38 = 57`. Nur so bleibt der schwarze Rand auch in den Ecken gleich breit Der Ausschnitt wird als gerundetes Rechteck im Design-Raum gezeichnet und dann durch die Homographie geschoben, im CSS macht `border-radius: 57px` mit `overflow: hidden` dasselbe. Ohne das stößt eine scharfe Bildecke in die runde Glasecke, und genau das sieht man sofort. Beim Macbook stimmt das Smart-Object, dort bleibt es dabei. Belegung: Kanban-Board auf dem Macbook, Projekt-Chat hochkant auf dem iPad. ### Vom Macbook-Display ist nicht alles zu sehen Oben verdeckt die Blende des Deckels samt Kameraaussparung, unten die Tastaturschale, rechts das davorstehende iPad. Die Ecken des Smart-Objekts sagen darüber nichts: daraus geschätzt kommt oben 3,8 % heraus, tatsächlich sind es **6,9 %**. Deshalb wird gemessen statt geschätzt: 1. Deckung der Screen-Ebene per **Umkehr-Homographie in den Design-Raum** zurückrechnen — dort ist die Verdeckung eine Maske, kein Rätsel 2. Darin das **größte achsenparallele Rechteck** suchen (Histogramm-Verfahren je Zeile) → **2726 × 1682 bei (74, 154)**, also 78,9 % der Breite und 75,3 % der Höhe 3. Aufnahme darin zentriert einpassen, `contain`, **nie** `cover` Daher `width: 78.877%` und der Versatz. **Nichts wird abgeschnitten und nichts gezoomt** — was frei bleibt, trägt den aus den Bildecken gemessenen Hintergrundton der Aufnahme (`#F5F4F4` Board, `#FAFAFA` Chat). Schon fünf Stufen Unterschied zeichnen die freie Fläche als Rand nach. Das Zielformat für eine Macbook-Aufnahme ist damit **1,62** statt 1,547; wer näher dran liegt, füllt mehr Fläche. Passen muss es nicht, es wird ohnehin eingepasst. **Beide liegen originalgetreu auf ihrem Display, ohne Zoom.** Sie sind flacher als der Bildschirm, es bleibt also Fläche frei; die trägt mit `#FAFAFA` den Hintergrundton der Anwendung und ist deshalb nicht als Rand zu erkennen. > **Das Board rückt 5,15 % nach unten.** Das Smart-Object des PSD ragt oben > hinter die Blende des Deckels. Ohne Versatz verschwindet genau die Kopfzeile > der Anwendung, und der Screen sieht angeschnitten aus, obwohl gar nicht > gezoomt wurde. Unten wird der Screen von der Tastaturschale beschnitten — > das ist so gewollt und im Pixeden-Original genauso. > **Lizenz beachten.** Pixeden-Ressourcen sind für kommerzielle Projekte frei > und ohne Namensnennung nutzbar, dürfen aber **nicht weitergegeben** werden. > Das PSD gehört deshalb nicht ins Repo, nur das für uns abgeleitete PNG. ### Nachgebaute UI-Bausteine Manche Produkt-Elemente liegen **nicht** als Screenshot, sondern als HTML im Generator. Bisher: der **Notizzettel** auf der Workflow-Slide. Nachbau aus `hivegrid-pitch/ui/components/StickyNote/StickyNote.tsx`, Variante `purple`: | Teil | Wert | |---|---| | Kopfleiste | `#ce93d8` | | Fläche | `#f3e5f5` | | Text | `#424242`, Gewicht 400, Zeilenhöhe 1,5 | | Menü | drei Punkte (FeatherMoreVertical), kein Balken | | Anfasser | zwei Ecken unten rechts, 45 % und 65 % Deckkraft | Die Vorlage ist 200 px breit bei 14 px Text; auf dem 1080er Blatt sind alle Maße rund 1,6× hochskaliert. **Farbwerte nicht neu erfinden** — sie stammen aus der Software und müssen wiedererkennbar bleiben. Warum HTML und nicht Screenshot: Kanten und Schrift bleiben beim 3×-Export genauso scharf wie der Rest der Slide, der Text ist austauschbar, und es gibt keine Scrollbalken oder Cursor-Reste im Bild. --- ## 7. Export & Bildqualität ### Der Export behält die gerenderte Auflösung **Gespeichert wird in 1080·k × 1350·k**, wobei k die Renderqualität ist. Bei 3× sind das 3240 × 4050. Die Datei ist damit so groß wie das, was tatsächlich gerendert wurde. ``` Renderqualität 1× → 1080 × 1350 Renderqualität 2× → 2160 × 2700 Renderqualität 3× → 3240 × 4050 ``` **Früher stand hier das Gegenteil**, und die Begründung war das Upload-Verhalten von Instagram: Breiten von 320 bis 1080 bleiben unangetastet, alles darüber wird von Instagram verkleinert und neu komprimiert, also lieber selbst sauber auf 1080 herunterrechnen. Der Preis dafür war aber, dass jede gelieferte Aufnahme auf die Breite ihres Rahmens im 1080er Blatt eingedampft wurde — eine Vorlage mit 2390 px kam mit 916 px an, obwohl sie intern schon in 2748 px vorlag. **Das wiegt schwerer als der Upload-Pfad.** Wer eine hoch aufgelöste Aufnahme liefert, muss sie im Ergebnis wiederfinden. Kleiner rechnen kann jedes Zielsystem selbst, und wer bewusst exakt 1080 × 1350 will, stellt die Renderqualität auf 1×. ### Warum das Supersampling hier hilft Nicht wegen des Textes — den rastert der Browser bei nativer Größe ohnehin sauber, teils sogar schärfer als supersampled. Der Gewinn liegt woanders: - **Transformationen** — der gekippte Laptop, gedrehte Formen, Chamfer-Kanten und Hexagon-Clips werden bei doppelter Auflösung gerastert und danach gemittelt. Das ist echtes Anti-Aliasing statt Treppenkanten - **Screenshots** — unsere Quellen sind ~2000 px breit und werden auf ~1090 px gezeigt. Bei 2× zeichnet der Browser sie näher an ihrer nativen Auflösung, das anschließende Downsampling ist unser eigenes und damit besser - **Marker und Wabenraster** — SVG-Kanten profitieren identisch > Bei reinen Textslides ohne Mockup ist der Unterschied gering bis null. Deshalb > ist die Stufe umschaltbar (1× / 2× / 3×), nicht fest verdrahtet. **2× ist der > Standard**, 3× kostet spürbar Zeit und Speicher bei kaum sichtbarem Gewinn. ### Falls doch einmal verkleinert werden muss Nicht in einem Sprung. Browser skalieren Canvas standardmäßig schnell statt gut: Pixel werden direkt übernommen, Nachbarinformationen gehen verloren, das Ergebnis rauscht. Zwei Gegenmaßnahmen, beide nötig: ```js ctx.imageSmoothingEnabled = true; ctx.imageSmoothingQuality = "high"; // Default ist "low" ``` Und **in Halbierungsschritten** verkleinern. Ein direkter Sprung von 3240 auf 1080 überspringt Zwischenpixel; zweimal halbieren mittelt jeweils über 2 × 2 und kommt einer echten Flächenmittelung nahe. `createImageBitmap()` mit `resizeQuality` wäre der elegantere Weg, ist aber in Browsern uneinheitlich umgesetzt — teils wird die Option ignoriert. `drawImage` mit `imageSmoothingQuality` ist der verlässliche Pfad. ### Format **PNG, nicht JPEG.** Instagram konvertiert am Ende ohnehin zu JPEG — aber unsere Slides sind Text, flache Flächen und UI-Screenshots mit harten Kanten. Genau die zerlegt JPEG-Kompression zuerst. Wer als PNG hochlädt, gibt Instagram ein verlustfreies Original und zahlt nur **einmal** Kompression statt zweimal. Für Fotoinhalte wäre JPEG bei 85–95 % die bessere Wahl. Haben wir hier nicht. ### Farbraum **sRGB, ausschließlich.** Instagram wirft andere Profile weg und konvertiert nach sRGB. Wer in Adobe RGB oder P3 exportiert, bekommt Farbverschiebungen bei dieser Konvertierung. Canvas-Exporte aus dem Browser sind standardmäßig sRGB — also nichts zu tun, solange niemand ein Farbprofil anfasst. ### Weiteres - Auf `document.fonts.ready` warten, sonst rendert der erste Export in einer Fallback-Schrift - Dateinamen mit `01-`…`05-` präfixen: Instagram übernimmt beim Hochladen die Dateisortierung - Dateigröße im Auge behalten. Für JPEG gilt die Faustregel „unter 1 MB", sonst komprimiert Instagram härter. Für unsere PNGs mit Screenshots ist das nicht zu halten und auch nicht nötig - Vom Desktop hochladen, wenn möglich — gilt als schonender als der mobile Upload ### Quellenlage, ehrlich **Von Meta dokumentiert:** die unterstützten Seitenverhältnisse (1.91:1 bis 4:5), die Auflösungsgrenze 320–1080, der Beschnitt außerhalb, und dass alle Carousel-Slides auf die erste beschnitten werden. **Community-Konsens, nicht offiziell:** die konkreten Kompressionsprozente, die 1-MB-Faustregel, Desktop-vs-Mobile, und PNG-vs-JPEG-Empfehlungen. Plausibel und breit reproduziert, aber von Meta nirgends bestätigt. Im Zweifel selbst gegentesten: dieselbe Slide in zwei Varianten hochladen und vergleichen. ### Vier Dinge, die den Export brechen **1. Tailwind- und `oklch()`-Farben.** Die Export-Bibliothek kann sie nicht serialisieren. Der Slide-Baum benutzt deshalb ausschließlich Hex und `rgba()`. **2. PNGs im `foreignObject`.** Der Export serialisiert die Slide in eine `data:image/svg+xml`-URL und malt sie als **ein** Bild. Raster-Kinder dekodieren asynchron und verpassen diesen Paint regelmäßig — der Screenshot fehlt dann, während der Rest stimmt. SVGs dekodieren synchron und sind immer da. > Deshalb ist der Export **verifiziert statt gehofft**: Jede Screenshot-Fläche > wird nach dem Rendern abgetastet. Eine solche Fläche ist nie glatt, sie trägt > UI und Farbe. Liegt die Luminanz-Spanne unter 12, fehlt das Bild und es wird > neu gerendert, bis zu fünf Versuche. **3. Browser-Downloads.** `data:`-URLs öffneten einen leeren Tab, `blob:`-URLs das Bild im Tab — das `download`-Attribut wurde beide Male ignoriert. Der Generator schickt die Bytes deshalb per POST an **`/save`**, und `serve.py` schreibt direkt nach `~/Downloads`. **4. Stille Skriptfehler.** Ein Fehler auf oberster Ebene (Syntax, Temporal Dead Zone) tötet das ganze Skript: Das Panel rendert aus statischem HTML weiter, aber nichts wird gebaut. Beide Seiten haben einen globalen `error`-Listener, der so etwas ins Statusfeld schreibt. **Nicht entfernen.** --- ## 8. Fallen, in die wir schon getappt sind | Symptom | Ursache | |---|---| | Logo unsichtbar auf Weiß | Sichtbarkeitsregel vertauscht — auf Hell wurde `logo-white.svg` gezeigt | | Logo bildschirmbreit statt zentriert | `.laptop-screen img` galt auch fürs Logo und hat es überschrieben. Solche Regeln **immer auf eine Klasse eingrenzen** | | Element eine Zeile zu tief | `max-width` erzwang einen zusätzlichen Umbruch. Bei gesetzten `
` gehört `white-space: nowrap` dazu | | Farbe „stimmt nicht" | Deckkraft der Ebene lag darüber. Eine Farbe ist nur exakt, wenn nichts sie multipliziert | | Muster wirkt zufällig hingeworfen | Formen liefen quer durch den Text. Dekoration bleibt in den Rändern, verankert und angeschnitten | | Nichts lädt, Bühne leer | Konstante vor ihrer Deklaration benutzt (TDZ) | --- ## 9. Ordner ``` posts/ ├── serve.py / serve.sh Statischer Server + /save-Endpunkt (Port 4321) ├── post1.html Post 1 · Lösung (Carousel, 5 Slides) ├── rules.md diese Datei ├── assets/ │ ├── logo.svg, logo-white.svg, cta-honeycomb.svg │ ├── laptop.png Mockup, Display ausgeknockt │ ├── fonts/ Manrope, lokal │ └── screens/ Software-Screenshots └── vendor/ html-to-image, JSZip (lokal, kein CDN) ``` Alles läuft **offline**. Keine CDN-Verweise, keine Google-Fonts zur Laufzeit — sonst hängt der Export an einer Netzwerkverbindung und an fremden Origins.