203 lines
22 KiB
Markdown
203 lines
22 KiB
Markdown
# Teilgebiet 01: Lebenslauf-Optimierung
|
||
|
||
## Ziel
|
||
|
||
Universeller CV (eine Version) für Consulting-Agenturen, der Thomas als freiberuflichen Ingenieurdienstleister und AI Consultant positioniert. Ziellänge: 4–5 Seiten (aktuell 7). KI klar priorisiert, Elektronik-Kompetenz als wertvolles Differenzierungsmerkmal erhalten.
|
||
|
||
## Zielgruppe des CVs
|
||
|
||
Primär: Recruiting-Mitarbeiterinnen von Consulting-Agenturen (sekundäre Zielgruppe laut marketing.md). Diese scannen CVs in 30–60 Sekunden auf Keyword-Passung und entscheiden dann, ob sie weiterlesen.
|
||
|
||
## Analyse des Ist-Zustands
|
||
|
||
### Stärken
|
||
- Portraitfoto vorhanden und professionell
|
||
- Berufserfahrung chronologisch klar gegliedert
|
||
- Bei einigen Stationen bereits gute Mehrwert-Formulierungen (z.B. Infineon: "Verhinderte eine Verzögerung der IC-Evaluierung")
|
||
- KI-Projekte stehen bereits im oberen Bereich
|
||
|
||
### Schwächen
|
||
1. **Zusammenfassung nicht auf KI ausgerichtet:** Kein KI-Keyword in den Branchenaufzählungen, TÜV-Zertifikat fehlt komplett, "Hardware Design" gleichberechtigt mit KI genannt.
|
||
2. **Seitenbudget falsch verteilt:** KI-Inhalte ca. 1,5 Seiten vs. HF/Hardware ca. 4,5 Seiten. Über 60% des CVs beschreiben Tätigkeiten außerhalb des strategischen Fokus.
|
||
3. **DesTEngS-Block mischt Leistungskatalog mit Projekten:** Unterpunkte unter "Generative KI" und "Elektronik Entwicklung" lesen sich wie ein Dienstleistungskatalog, während die Projekte danach nochmals separat erscheinen → Redundanz (z.B. KI-Workshops doppelt).
|
||
4. **ASMPT Ethernet-Block (Nov 2020–Mai 2024) zu detailliert:** Ca. 2 Seiten für ein einzelnes Projekt, dessen Kerninhalt (Ethernet-Feldbus) kein strategischer Fokus ist.
|
||
5. **Stil "Angestellter" bei älteren Stationen:** "Entwicklungsingenieur bei Siemens" statt Consultant-Perspektive.
|
||
6. **Kenntnisse-Abschnitt verwässert:** Veraltete Technologien (AEL, Pascal, Ada, Assembler) stehen neben aktuellen KI-Tools. KI-Strategiebegriffe fehlen (Prompt Engineering, LLM Evaluation, KI-Strategie).
|
||
7. **Trainings-Abschnitt zu lang:** Viele veraltete Einträge (GSM-Kurse 1998, Aplac 2001).
|
||
8. **Fehlende Mehrwert-Perspektive bei ASMPT:** Längste und aktuellste Station beschreibt fast ausschließlich Tätigkeiten, kaum Kundenmehrwert.
|
||
|
||
## Optimierungsstrategie
|
||
|
||
### S1 — Zusammenfassung komplett neu schreiben
|
||
- KI und TÜV-Zertifikat in den ersten Satz
|
||
- Branchenliste ersetzen durch Kompetenz-Cluster: Generative KI, Software Design, System Integration, Test & Automatisierung
|
||
- "30+ Jahre Ingenieurerfahrung" beibehalten als Differenzierer
|
||
- "Freiberuflicher Consultant seit 2011" statt "seit 2011 ausschließlich freiberuflich tätig"
|
||
- Mehrwert-Aussage ergänzen (was der Kunde davon hat)
|
||
|
||
### S2 — DesTEngS-Block umstrukturieren
|
||
- Den generischen Leistungskatalog entfernen (diese Information gehört in den One-Pager, nicht in den CV)
|
||
- Stattdessen: KI-Projekte als eigenständige, prominente Einträge mit Kundenname, Zeitraum und Mehrwert
|
||
- KI-Workshops mit konkreten Ergebnissen/Outcomes versehen
|
||
|
||
### S3 — ASMPT-Block straffen
|
||
- ASMPT Aug 2024–Feb 2026 (KI-Workshop + ArxmlGenerator): Behalten und KI-Anteil hervorheben
|
||
- ASMPT Nov 2020–Mai 2024 (Ethernet-Feldbus): Radikal kürzen auf ca. 8–10 Zeilen. Fokus auf übertragbare Kompetenzen: Konzepterstellung, Protokoll-Evaluierung, Tool-Entwicklung, Test-Automatisierung. Tiefe HF/Ethernet-Details entfernen.
|
||
|
||
### S4 — Magna, Infineon, Kathrein: Moderat kürzen
|
||
- Magna (2018–2020): LIDAR und xDiagnostics sind aktuell relevant (Automotive, Embedded, Requirements). EMV/Signalintegrität kürzen. Ca. 6–8 Zeilen.
|
||
- Infineon (2014–2018): Signal-Integrity-Kern behalten, aber Details zu 77-GHz-Radar und EM-Feldsimulationen kürzen. Mehrwert-Beispiele behalten. Ca. 6–8 Zeilen.
|
||
- Kathrein (2015): Stark kürzen auf 2 Zeilen (HF-Tests, Automatisierung mit Matlab/Ruby).
|
||
|
||
### S5 — Alcatel-Lucent, Ubidyne, Toshiba, Siemens, Multilink, FBH, HMI: Kompakt halten
|
||
- Alcatel-Lucent (2011–2014): Kürzen auf ca. 6–8 Zeilen. LTE/WiFi-Kontext behalten, Mehrwert-Beispiele behalten, HF-Messdetails stark reduzieren.
|
||
- Ubidyne (2006–2011): Führungserfahrung und Teamaufbau hervorheben (10 MA, Prozesserstellung, Projektmanagement). HF-Details radikal kürzen. Ca. 6–8 Zeilen.
|
||
- Toshiba (2003–2006): Kürzen auf 4–5 Zeilen. OIF/MIPI-Normungsarbeit und Senior-Rolle betonen.
|
||
- Siemens (1998–2000): Kürzen auf 3–4 Zeilen. HF-Modul-Verantwortung behalten.
|
||
- Multilink (2000–2002): Kürzen auf 3–4 Zeilen. System-Level-Arbeit betonen.
|
||
- FBH Promotion (1994–1998): Kürzen auf 2–3 Zeilen. Promotion erwähnen, Details in Ausbildungs-Abschnitt.
|
||
- HMI (1990–1992): 1–2 Zeilen oder in Ausbildung integrieren.
|
||
|
||
### S6 — Kenntnisse-Abschnitt reorganisieren
|
||
- KI ganz oben, erweitert um: KI-Strategie & Potenzialanalyse, Prompt Engineering, LLM Evaluation & Benchmarking
|
||
- Software Design: Python prominent, C++/Matlab behalten, veraltete Sprachen (Ada, Pascal, AEL, Assembler, Basic) entfernen
|
||
- IT: Kürzen, nur aktuelle Tools
|
||
- Engineering Software: Kürzen, nur noch die wichtigsten
|
||
- Messtechnik: Stark kürzen oder in eine Zeile zusammenfassen
|
||
- Veraltete Einzeltechnologien entfernen
|
||
|
||
### S7 — Trainings kürzen
|
||
- Behalten: AI Consultant TÜV-Zertifikat (2025), Management (2008), Führung und Organisation (2007), Ansys SIwave (2016), Keysight ADS (2016)
|
||
- Entfernen: Erste-Hilfe, Marketing 2011, Pulsonix, HFSS, MS Project, Gedächtnistraining, Aplac, Persönlichkeitsentwicklung, ADS RF Class 1999, BWL-Seminar, Mobilfunk-Kurse
|
||
|
||
### S8 — Durchgängig Consultant-Perspektive
|
||
- Bei allen Stationen seit 2011: "Consultant bei X" beibehalten (ist bereits so)
|
||
- Bei Stationen vor 2011: Titel beibehalten (waren ja tatsächlich Anstellungen), aber in der Beschreibung wo möglich Mehrwert und Verantwortung betonen statt reine Tätigkeitsbeschreibung
|
||
|
||
## Getroffene Entscheidungen
|
||
|
||
- **Seitenumfang:** 4–5 Seiten Ziel, HF/Hardware komprimiert, KI und Software/SI in voller Detailtiefe (wegen Keyword-Matching durch Agentursoftware)
|
||
- **Stationen:** Alle Stationen beibehalten; HF-lastige Stationen (Kathrein, Siemens, FBH, HMI) nur gekürzt wo anderer Inhalt vorhanden; bei reinen HF-Stationen bleibt der Inhalt (sonst leere Station)
|
||
- **DesTEngS-Block:** Umstrukturiert zu KI-Workshops (mit Kundennamen), KI-Beratungen, KI-Anwendung, KI-gestützte Dokumentationen
|
||
- **ASMPT Ethernet (2020–2024):** Detailliert belassen, da SI/Software-Inhalte für Agentursoftware-Matching relevant; Success Stories erhalten
|
||
- **Kenntnisse KI:** Erweitert um KI-Strategieentwicklung, Prompt Engineering, Context Engineering, LLM-Evaluierung, Multimodale KI, DSGVO, NLP, Edge AI, On-Premise KI-Infrastruktur, Agentic AI, Generative AI (GenAI), RAG mit Embedding Models und Vektor-Datenbanken
|
||
- **Kenntnisse Software Design:** Prozessautomatisierung (UI.Vision, PyAutoGUI, n8n, Langflow), REST API Integration, Python KI-Module (transformers, openai, anthropic, tiktoken), IronPython aus Kenntnissen entfernt (bleibt in Infineon-Station)
|
||
- **Kenntnisse Methodik:** Neuer Abschnitt mit 7 Einträgen (Konzepterstellung, Spezifikationserstellung, Systematische Fehleranalyse, Technologie-Evaluierung und -Auswahl, Machbarkeitsstudien, Technische Dokumentation, Projektmanagement)
|
||
- **Trainings:** Gekürzt auf 6 Einträge (AI Consultant TÜV 2025, Ansys SIwave 2016, Keysight ADS 2016, Management 2008, Führung 2007, Gedächtnistraining 2006, Persönlichkeitsentwicklung 2000)
|
||
- **Suchbegriff-Optimierung:** Begriffe so formuliert, dass Agentursoftware bei gängigen Suchstrings Treffer findet (z.B. „KI-Strategie", „Prompt Engineering", „Agentic AI", „Edge AI", „GenAI", „NLP")
|
||
- **Evaluation vs. Evaluierung:** Deutsch konsequent „Evaluierung", englisch „Evaluation Board" beibehalten
|
||
- **Berufstätigkeit aufgeteilt:** „Projekte als freiberuflicher Consultant" (ab 2011) und „Berufliche Stationen vor der Selbständigkeit" (vor 2011)
|
||
- **LLM-Evaluierung:** Kein eigener Punkt mehr, sondern in den LLM-Hauptpunkt integriert
|
||
- **LinkedIn/Freelance.de:** Korrekte Profil-URLs eingebaut, als klickbare Links
|
||
- **Portraitfoto:** foto-wrba_2026_6782_1.jpg ausgewählt und eingebettet
|
||
- **Seitenumfang (final):** 7 Seiten — von Thomas akzeptiert, da Inhalt sehr gut passend
|
||
|
||
## Wendepunkt S05 — Tool-Wechsel zu Pandoc + LuaLaTeX
|
||
|
||
Die in S04 mit docx-js erstellte Version hatte strukturelle typographische Mängel (Widows/Orphans, Spalten-Layout bei Ausbildung, fehlende Kontaktlabels, Schriftsatz bei Einheiten wie „6 GHz", etc.). Eine Analyse hat ergeben, dass docx-js für den gewünschten typographischen Anspruch das falsche Werkzeug ist — die Grenzen liegen zum Teil am Tool, zum Teil strukturell am .docx-Format selbst.
|
||
|
||
**Neue Strategie 1:** Eine Quelle (Markdown), zwei Zielformate mit unterschiedlichem Anspruch:
|
||
- **PDF** via Pandoc + LuaLaTeX mit eigenem LaTeX-Template → tadellose Typographie, IBM Plex Sans (DesTEngS-neue-Hausschrift, siehe Teilgebiet 25), für Direktkanäle (Website, persönliche Bewerbungen).
|
||
- **DOCX** via Pandoc mit `reference-doc.docx` → semantisch sauber, Calibri, bewusst schlicht, für Consulting-Agenturen (die das Layout beim Umbau in ihr Template ohnehin überschreiben).
|
||
|
||
## Getroffene Entscheidungen (ergänzt in S05)
|
||
|
||
- **Quellformat:** Markdown (aufbauend auf V10-Inhalt, um Änderungen in Git lesbar zu halten und Pandoc-native Pipelines zu nutzen).
|
||
- **PDF-Toolchain:** Pandoc → LuaLaTeX (wegen fontspec/OpenType und voller `microtype`-Unterstützung).
|
||
- **DOCX-Toolchain:** Pandoc mit Reference-Doc (Starter-Version von Pandoc generiert; Styles iterativ in Word anzupassen).
|
||
- **Schriften:** PDF nutzt IBM Plex Sans (Plex Sans/Mono), DOCX nutzt Calibri (weil Agenturen eh umbauen und Calibri universell verfügbar ist — keine Font-Substitutions-Risiken).
|
||
- **TeX-Distribution:** MiKTeX (Windows, on-the-fly package installation).
|
||
- **Ordnerstruktur:** `artefakte/01-lebenslauf/` wurde in Unterordner gegliedert: `source/`, `templates/`, `build/`, `output/`, `entwuerfe/` (für die MD-Entwürfe v1–v10) und `archiv/` (für die alten docx-js-Ausgaben).
|
||
- **Foto-Umbenennung:** Die Foto-Datei wurde von `©foto-wrba_2026_6782_1.jpg` auf `foto-wrba_2026_6782_1.jpg` umbenannt, um Encoding-Probleme in Build-Pfaden zu vermeiden.
|
||
- **Draft-Marker in cv.md entfernt:** Der H1-Suffix „— Entwurf V10", die Review-Blockquote und der Platzhalter-Bullet „- Portraitfoto" wurden aus `source/cv.md` entfernt (reine Meta-Elemente, kein CV-Inhalt).
|
||
- **Status Teilgebiet 01 auf „in Bearbeitung"** gesetzt im zentral-index.md.
|
||
|
||
## Iteration A (S06) — Ausbildung als 2-Spalten-Layout
|
||
|
||
**Erster Versuch (verworfen) — Definition-List:** Quellseitig als Pandoc-Definition-List umgesetzt, im PDF mit `enumitem`-Konfiguration der `description`-Liste sauber 2-spaltig. Im DOCX rendert Pandoc Definition-Lists aber als zwei separate Absatzstile (`DefinitionTerm` und `Definition`) — Word kann zwei Absätze nicht ohne weiteres optisch in eine Zeile zwingen, ein echtes 2-Spalten-Layout im DOCX ist mit Definition-Lists nicht erreichbar. Das war beim ersten Build-Test sichtbar (Datum fett auf eigener Zeile, Inhalt darunter).
|
||
|
||
**Revision — Tabellen-Variante (aktiv):** Die Markdown-Quelle nutzt eine Pandoc-Multiline-Tabelle ohne Header (zwei Strich-Zeilen als äußere Begrenzung, vier Datenzeilen, blank-lines zwischen Einträgen). Pandoc rendert daraus eine `longtable` mit Minipage-Auto-Wrap im PDF und eine native Word-Tabelle im DOCX — beides ergibt echtes 2-Spalten-Verhalten und ist bei Agenturen mindestens so robust wie eine Definition-List (eine 4-zeilige 2-Spalten-Tabelle ist Word-Standardrepertoire).
|
||
|
||
**Quellseitig (`source/cv.md`):** Multiline-Tabelle mit Strich-Verhältnis 10:70. Pandoc berechnet daraus Spaltenbreiten von ca. 14 % (Datum) und 80 % (Inhalt) der Textbreite.
|
||
|
||
**PDF-Pfad (`templates/template.tex`):** Neuer Abschnitt „Tabellen": `booktabs` und `longtable` werden geladen, die Linienbreiten (`\heavyrulewidth`, `\lightrulewidth`, `\cmidrulewidth`) auf 0 pt gesetzt, ebenso `\aboverulesep` und `\belowrulesep`. `\LTpre`/`\LTpost` auf 0.4 em reduziert (Default ist `\bigskipamount`). Damit rendert die Tabelle rahmenlos und mit kompaktem Vertikalabstand.
|
||
|
||
**DOCX-Pfad:** Pandoc rendert die Tabelle als native Word-Tabelle (`<w:tbl>` mit vier `<w:tr>` und acht `<w:tc>`), Default-Tabellenstil ohne expliziten Pandoc-Stil. Das Feinstyling (Spaltenbreite, Rahmen aus, vertikale Abstände) erfolgt in der `reference.docx` (Iteration B), entweder über den Default-Tabellenstil oder einen benannten Tabellenstil.
|
||
|
||
**Sandbox-Verifikation der Revision:** Pandoc-LaTeX-Output zeigt `\begin{longtable}[]{@{}ll@{}}` mit vier Datenzeilen, Minipage-Spalten (0.14 + 0.80), korrekte URL-Escapung. Pandoc-DOCX-Output enthält genau eine Tabelle mit vier Zeilen und acht Zellen im Ausbildungs-Bereich, keine Reste der zwischenzeitlich genutzten Definition-List-Stile.
|
||
|
||
**Visuelle Bestätigung im PDF:** Layout im Tabellen-Format wie gewünscht (linke Spalte Datum normal, rechte Spalte Titel fett, Beschreibung normal). Visuelle Bestätigung im DOCX steht nach erstem Build der Revision aus.
|
||
|
||
**Hotfix Build-Fehler (S06, Teil 1):** Beim ersten Build der Tabellen-Revision schlug LuaLaTeX mit `! LaTeX Error: No counter 'none' defined.` in der Spaltenangabe `p{(\columnwidth - 2\tabcolsep) * \real{0.8554}}` fehl. Erste Vermutung: Thomas' Pandoc-Version (3.x) emittiert für Tabellen-Spaltenbreiten einen calc-basierten Multiplikator, der das Pandoc-Hilfsmakro `\real` und das `calc`-Paket voraussetzt. Ergänzung von `\usepackage{array}`, `\usepackage{calc}` und `\providecommand{\real}[1]{#1}` im Tabellen-Block des Templates. Sandbox-Verifikation mit synthetischem Pandoc-3.x-Spalten-Format kompilierte zu PDF ohne Fehler — die echte Ursache war damit aber noch nicht behoben.
|
||
|
||
**Hotfix Build-Fehler (S07, eigentliche Ursache):** Der Folgebuild auf Thomas' System lieferte unverändert `! LaTeX Error: No counter 'none' defined.` Recherche ([Pandoc-Issue #11201](https://github.com/jgm/pandoc/issues/11201)) zeigte den eigentlichen Auslöser: Pandoc 3.x emittiert für unnummerierte Tabellen direkt vor dem `\begin{longtable}` die Zeile `\def\LTcaptype{none}` — ohne den Counter `none` zu definieren. Pandocs eigene Default-Vorlage definiert ihn (commit d835461 in 3.8.2.1 nachgezogen), aber Custom-Templates müssen das selbst tun. Sobald longtable intern `\refstepcounter{\LTcaptype}` aufruft, bricht LaTeX ab. Behoben durch eine Zeile `\newcounter{none}` direkt nach dem `\providecommand{\real}` im Tabellen-Block. Sandbox-Reproduktion lieferte exakt den gleichen Fehlertext und wurde durch den Fix behoben. Anschließender Build auf Thomas' System: PDF erfolgreich erzeugt, Ausbildungs-Layout im PDF visuell bestätigt.
|
||
|
||
**Lehre für die Sandbox-Verifikation:** Pandocs `\def\LTcaptype{none}`-Bug tritt nur auf, wenn longtable den Counter intern referenziert. Sandbox-Pandoc 2.9 emittiert weder die calc-basierten Spaltenbreiten noch `\def\LTcaptype{none}` — die Sandbox kann diesen Bug also nicht reproduzieren, indem sie einfach pandoc auf cv.md laufen lässt. Synthetische Mini-Tex-Beispiele bleiben für Pandoc-3.x-spezifische Bugs die einzige verlässliche Verifikationsquelle.
|
||
|
||
**Visuelle Bestätigung im DOCX:** Tabelle sieht gut aus, nur die Default-Word-Tabellenrahmenlinien sind noch sichtbar; der Rahmen-Aus geht in Iteration B über die `reference.docx`.
|
||
|
||
**Visuelle Bestätigung im PDF (S07):** Ausbildungs-Layout entspricht der Vorgabe — linke Spalte Datum normal, rechte Spalte Titel fett mit Beschreibung. Iteration A damit inhaltlich abgeschlossen.
|
||
|
||
**Build-UX-Fix (S07):** `build/build.ps1` ergänzt um `Start-Sleep -Seconds 3` nach jedem fehlschlagenden Build-Schritt (Pflichtdatei-Check, PDF, DOCX). Bei Doppelklick auf `checkpoint.cmd`-artigen Aufruf schließt sich das PowerShell-Fenster sonst sofort und Fehlermeldungen sind nicht lesbar. Bei mehreren Fehlern in einem Lauf akkumulieren sich die Pausen — gewollt.
|
||
|
||
## Iteration B (S07) — `reference.docx` programmatisch bauen
|
||
|
||
**Ansatz:** Anstatt die `reference.docx` manuell in Word zu pflegen (nicht versionierbar, nicht reproduzierbar), wird sie durch ein Python-Skript `build/build-reference-docx.py` aus Pandocs Default-Reference erzeugt und gezielt angepasst. Nur Python-Stdlib (`zipfile`, `xml.etree.ElementTree`, `subprocess`, `re`) — keine pip-Abhängigkeit. Das Skript läuft unter Sandbox-Pandoc 2.9 und Thomas' Pandoc 3.x gleichermaßen, weil es die Pandoc-Default-Reference per `pandoc --print-default-data-file reference.docx` zur Laufzeit zieht. Manueller Aufruf vor jedem `build.ps1`, wenn Stile geändert wurden.
|
||
|
||
**B1 — Schriften und Tabellen:**
|
||
|
||
- Theme-Schriften `majorFont` und `minorFont` beide auf `Calibri` umgestellt (Pandoc 3.x setzt sie als Default auf `Aptos Display` und `Aptos`, Sandbox-Pandoc 2.9 auf `Calibri` und `Cambria`).
|
||
- Defensive Maßnahme: alle direkten Schriftnamen-Referenzen in `styles.xml` (z.B. `<w:rFonts w:ascii="..." />`) auf Calibri umgestellt, ausgenommen Code-Schriften (Consolas, Courier, ...). In der Pandoc-3.x-Variante kommt das mit 0 Treffern aus, in zukünftigen Pandoc-Versionen mit direkten Heading-Schriftreferenzen würde es greifen.
|
||
- Tabellen-Default-Stil `Table` bekommt explizite `<w:tblBorders>` mit `val="none"` auf allen Sides (`top`, `left`, `bottom`, `right`, `insideH`, `insideV`). Word-Editor zeigt die Default-„Tabellenbegrenzungen" weiterhin als Anzeige-Hilfe an (kein Druck-Rendering), Druckansicht und PDF-Export sind sauber rahmenlos.
|
||
|
||
**B1.5 — Schriftgrößen analog PDF:**
|
||
|
||
- DocDefault `<w:sz>` auf 22 (= 11 pt Body, analog `template.tex`).
|
||
- Heading 1/2/3 explizit auf 30/26/24 (= 15/13/12 pt). Damit ist die Heading-Hierarchie visuell ähnlich zum PDF, ohne den Word-Default-Sprung von 20 pt nach 12 pt.
|
||
- Effekt: DOCX schrumpft von 10 auf 9 Seiten (im PDF sind es 7).
|
||
|
||
**B2 — Header, Footer, Page-Setup:**
|
||
|
||
- `word/header1.xml` (Default ab Seite 2): links „Dr.-Ing. Thomas Langer", rechts „Lebenslauf" (Tab-Stop am rechten Textrand).
|
||
- `word/header2.xml` (erste Seite): leerer `<w:p/>` über `<w:titlePg/>` aktiviert.
|
||
- `word/footer1.xml`: rechtsbündig „Seite n / m" mit Word-Feldern `PAGE` und `NUMPAGES`. Wird über zwei `footerReference`-Einträge (`type="default"` und `type="first"`) auf alle Seiten inkl. Seite 1 angewendet — ohne den `type="first"`-Eintrag würde `titlePg` Seite 1 ohne Footer lassen.
|
||
- Page-Setup explizit in `<w:sectPr>`: A4 (`pgSz w:w="11906" w:h="16838"`), Ränder 2.2 cm oben/unten, 2.5 cm links/rechts (analog PDF). Damit ist der Tab-Stop an `9072 dxa` (= 16 cm Textbreite) deterministisch unabhängig von Word-Locale-Defaults; ohne explizites Page-Setup waren die Tab-Stops vorher etwa 5 mm zu weit links.
|
||
- Beziehungen werden in `word/_rels/document.xml.rels` mit dynamisch ermittelter nächster freier `rId` registriert; Content-Types-Overrides in `[Content_Types].xml` ergänzt; `<w:sectPr>` in `word/document.xml` regex-basiert ersetzt (idempotent gegenüber Pandoc-Defaults `<w:sectPr/>` und längeren Varianten). Pandoc übernimmt die letzte sectPr aus der reference.docx ins generierte DOCX — End-to-End-Test in der Sandbox bestätigt: alle Header/Footer-Refs, pgMar und titlePg sind im finalen DOCX vorhanden.
|
||
|
||
**Visuelle Bestätigung im Word (S07):**
|
||
|
||
- Body: Calibri 11 pt; Headings 1/2/3: Calibri 15/13/12 pt.
|
||
- Ausbildungs-Tabelle in Druckansicht und PDF-Export rahmenlos.
|
||
- Seite 1 ohne Header, mit Footer.
|
||
- Seite 2 ff. mit Header (Name links, „Lebenslauf" rechts) und Footer (Seite n / m).
|
||
- Tab-Stops „Lebenslauf" und Seitenzahl bündig am rechten Textrand.
|
||
|
||
## Nächste Schritte
|
||
|
||
1. **Iteration B3 — Heading-Stile mit „keep with next" und Widow/Orphan-Control:** Schusterjungen-Schutz für DOCX analog zu `\widowpenalty`/`needspace` im PDF. Auf Stilebene über `<w:keepNext/>` für Headings und `<w:widowControl w:val="true"/>` als DocDefault.
|
||
2. **Iteration B4 (optional)** — Heading-Farben auf DesTEngS-Blau und/oder Trennlinien analog PDF, falls das DOCX optisch näher ans PDF heran soll. Bei Vorlage für Consulting-Agenturen, die das Layout ohnehin überschreiben, ist das aber eher Kosmetik.
|
||
3. **Iteration C — Foto-Einbindung:** Portraitfoto in `source/cv.md` einbetten (Pandoc-Image-Syntax), Position und Größe im Template absichern (z.B. oben rechts neben Name, ca. 3 cm).
|
||
4. **Iteration D — Hyphenation-Feintuning für PDF:** Kurze Wortteile am Zeilenanfang mit höherer Penalty oder gezielten `\hyphenation`-Ausnahmen reduzieren. Iterativ.
|
||
5. Teilgebiet nach erfolgreichem Output und Freigabe durch Thomas abschließen (R2-OK von Thomas: Status auf „abgeschlossen" im zentral-index.md).
|
||
|
||
## Artefakte
|
||
|
||
### Aktive Pipeline-Dateien
|
||
|
||
- `artefakte/01-lebenslauf/source/cv.md` — **Aktive Quelldatei** (aufbauend auf V10, Draft-Marker entfernt).
|
||
- `artefakte/01-lebenslauf/source/foto-wrba_2026_6782_1.jpg` — Portraitfoto (umbenannt, noch nicht in cv.md eingebunden).
|
||
- `artefakte/01-lebenslauf/templates/template.tex` — Pandoc-LaTeX-Template für LuaLaTeX (Iteration A inkl. Pandoc-3.x-Hotfix `\newcounter{none}`).
|
||
- `artefakte/01-lebenslauf/templates/reference.docx` — Pandoc-Reference-Doc, **automatisch erzeugt** durch `build/build-reference-docx.py`. Nicht von Hand editieren — Änderungen würden beim nächsten Skript-Lauf überschrieben.
|
||
- `artefakte/01-lebenslauf/build/build-reference-docx.py` — Python-Skript zum Bauen der `reference.docx` (Iteration B1+B1.5+B2). Manuell aufrufen, wenn Stile geändert werden sollen, danach normalen `build.ps1` laufen.
|
||
- `artefakte/01-lebenslauf/build/build.ps1` — PowerShell-Build-Skript (PDF + DOCX) mit 3-Sekunden-Pause bei Fehler.
|
||
- `artefakte/01-lebenslauf/output/` — erzeugte Ausgaben plus `build.log`.
|
||
|
||
### Historische Entwürfe (unter `artefakte/01-lebenslauf/entwuerfe/`)
|
||
|
||
- `cv-entwurf-v1.md` bis `cv-entwurf-v10.md` — zehn iterative Entwürfe von Agent und Thomas, freigegeben mit V10.
|
||
|
||
### Archiv (unter `artefakte/01-lebenslauf/archiv/`)
|
||
|
||
- `Lebenslauf_Dr-Ing_Thomas_Langer.docx`, `Lebenslauf_Dr-Ing_Thomas_Langer.pdf` — alte docx-js-Ausgaben (dokumentieren die typographischen Mängel, dienen als Vergleichsreferenz für die neue Pipeline).
|
||
- Lock- und Temp-Dateien von LibreOffice/docx-js als verwaiste Reste.
|