ich hätte gerne einmal von Euch ein Feedback, ob es eine elegantere Lösung für mein Problem gibt.
Ausgangssituation: Ich bekomme Texte aus einem PIM-System in InDesign platziert. Unter anderem handelt es sich um Maßangaben mit deren Maßeinheiten. Nun passiert es gelegentlich, dass die Maßeinheiten in nächste Zeilen umbrechen. Dies möchte ich logischerweise vermeiden. Leider ist es nicht möglich, in den Texten Änderungen vorzunehmen. D.h. das Einfügen eines geschützten Leerzeichens o.ä. ist keine Option. Ebenso ist es nicht möglich, im Absatzformat "kein Umbruch" zu aktivieren, da im Absatzformat auch regulären Fließtext exisitiert.
Mein Lösungsansatz: Ich habe ein Zeichenformat generiert, dass nur "kein Umbruch" beinhaltet. Nun weiße ich dem Absatzformat über GREP dieses Zeichenformat zu. Nur bin ich nicht glücklich mit meinem GREP-Befehl. Ich nutze "\d+ mm" was zur Folge hätte, dass ich für jegliche Kombination einen GREP-Befehl hinterlegen muss ("\d+ m", "\d+ km",....). Naja und dass noch für viele Absatzformate und auch zukünftig für alle benötigten Sprachvarianten.
Ich bin überzeugt davon, dass es eine bessere Lösung gibt, doch hat mich die Suche nicht wirklich weiter gebracht.
Ich würde mich über Eure Vorschläge freuen. ------
Abgesehen von Geralds Script, typografisch korrekt ist die Verwendung von Leerzeichen reduzierter fester Breite, etwa 1/6 Geviert. Diese festen Leerzeichen sind von haus aus umbruchgeschützt. Deshalb ist es in solchen Fällen so, dass ich über suchen und Ersetzen nach der fertigen Texteingabe ein GREP laufen lasse. Natürlich ginge es auch mit einem GREP-Stil, bei dem nicht nur der Umbruch geschützt wird, sondern die Breite reduziert. Allerdings ist damit keine feste Breite möglich, sondern nur eine prozentuale Verringerung der Breite.
Ich löse das übers "Tracking". Setze also solche Angaben per GREP-Stil auf "kein Umbruch" und lasse zusätzlich noch unterschneiden (z.B. –80):
--- Viele Grüße, Ralf --- iMac i7 (18,3) 4,2 GHz, 32 GB 10.15.7 Catalina | MacBook Pro 15" (8,2) 2,0 GHz, 16 GB, 10.13.6 High Sierra | Mac Mini (6,1) als Server 2,5 GHz, 8 GB, 10.13.6 High Sierra | CC 2021 (ID 16.3.2)
Das Problem ist ja, dass ein normales Leerzeichen ein falsches Zeichen hier ist, wie ein Rechtschreibfehler, der ausgebessert werden muss aber nun über Stile repariert werden soll, kann nicht. Denn der Abstand von Zahl und Einheit muss fix sein, auch dann, wenn durch Blocksatz die anderen Wortabstände variieren. Tracking/Laufweite verringern reduziert zwar den Wortabstand zwischen der Zahl und der Einheit, aber er variiert eben mit den Abständen der selben Zeile.
Das mag typographisch gesehen so sein. Aber nicht jedes Programm kann solche Zeichen setzen. Ich arbeite z.B. datenbankgestützt, Texte werden u.U. alle Augenblicke aktualisiert, da ist dies (fast) unmöglich. Also regle ich das über Unterschneiden. Wobei ich dazu sagen muss, dass dabei kein Blocksatz vorkommt.
Alternativ können solche Zeichen natürlich per GREP-S&E korrigiert werden. Das geht mit einem simplen Script in Sekunden mit einer Tastenkombi.
--- Viele Grüße, Ralf --- iMac i7 (18,3) 4,2 GHz, 32 GB 10.15.7 Catalina | MacBook Pro 15" (8,2) 2,0 GHz, 16 GB, 10.13.6 High Sierra | Mac Mini (6,1) als Server 2,5 GHz, 8 GB, 10.13.6 High Sierra | CC 2021 (ID 16.3.2)
generell noch eine Frage zur Grep-Lösung. Wir haben beobachtet, dass Grepstile in größerer Anzahl ein Dokument langsamer machen Liegen wir mit dieser Annahme richtig?
Wäre eine Grep-Abfrage nicht die schnellere und saubere Lösung?
Das hängt eindeutig auch von der Länge der Dokumente ab. Martin produziert Bücher, d.h. Dokumente mit Seitenzahlen vermutlich im dreistelligen Bereich.
Ich produziere (zumindest im Bereich wo GREP-Stile greifen, und ich habe davon teilweise ca. 30 Stück und mehr im Dokument) ausschließlich einseitige Dokumente. Ich spüre die Geschwindigkeit betreffend überhaupt nichts davon.
--- Viele Grüße, Ralf --- iMac i7 (18,3) 4,2 GHz, 32 GB 10.15.7 Catalina | MacBook Pro 15" (8,2) 2,0 GHz, 16 GB, 10.13.6 High Sierra | Mac Mini (6,1) als Server 2,5 GHz, 8 GB, 10.13.6 High Sierra | CC 2021 (ID 16.3.2)