Ich suche einen GREP-Ausdruck, der ein Leerzeichen (normaler Wortzwischenraum) findet, WENN vorher (Lookbehind) entweder S. oder Anm. steht UND nachher (Lookahead) eine (oder mehrere) Ziffer(n) folgen. Ich weiss nur den Ausdruck für ODER (ein senkrechter Strich).
Hintergrund: In meinen Fussnotentexten kommen oft Seitenangaben (S. 90–95) oder Verweise auf andere Fussnoten (siehe Anm. 45) vor. Ich möchte den Leerschlag etwas unterschneiden (via Zeichenformat), damit die Zahl etwas näher zur Abk. steht. Dafür möchte ich keinen festen Leerraum (Achtelgeviert usw.) verwenden.
Für Hilfe immer dankbar, so lerne ich wieder etwas über GREP.
(?<=S\.) -> lookahead nach 'S.' | -> oder (?<=Anm\.) -> lookahead nach 'Anm.' ( ) -> Leerzeichen (geht auch ohne die Klammern) (?=\d) -> lookbehind Ziffer.
Eventuell kann man die Alternative des lookahead ((?<=S\.)|(?<=Anm\.)) noch verkürzen.
Viele Grüße Martin
(Dieser Beitrag wurde von Martin Fischer am 3. Sep 2007, 17:59 geändert)
aber das funktioniert interessanterweise nicht. Ich vermute einen Bug in InDesigns Grep, aber es kann auch sein, dass ein LookBehind mit Alternativen nicht definiert ist.
ich hatte es zunächst vergeblich mit (?<=(Anm|S)\.) (?=\d) versucht. Die Alternative 'Anm'/'S' ist aber nicht geschluckt worden. 'Anm. [Ziffer]' ist gefunden worden. Aber nicht 'S. [Ziffer]'.
Ist Dir beim Punkt nach dem 'S' der gleiche Fehler wie mir (zunächst) unterlaufen? ;-)
Weitere Tests mit den von Gerd Ewald in seinem Regex-Tutorial gegebenen Beispielen (siehe oben):
Indesign erlaubt offenbar keine Alternativen im Lookbehind bzw. Lookahead (nur für Lookbehind, also zurückschauend, getestet), auch wenn keine weiteren Klammerebenen geöffnet werden. Der Teilausdruck (?<=abc|abde) geht in Indesign also nicht.
Etwas überrascht habe ich auch festgestellt, dass Indesign im GREP-Code keine Umlaute akzeptiert! Also: (?<=Möglich)keit findet überhaupt nichts; (?<=Moglich)keit findet hingegen «keit» in den Wörtern Moglichkeit und (!) Möglichkeit.
ö wird nicht gefunden, und o ist in GREP o und ö.
Öhm, kann das stimmen? Das wäre etwas seltsam, oder?
Ich hatte auch in einem anderen Zusammenhang (Skript-Export der Dateinamen von verknüpften Bildern mit Umlauten Probleme mit Umlauten. Dort waren Umlaute nicht bestimmte Einzelzeichen, sondern eine Kombination von einem Basiszeichen (z.B. 'o') und dem diakritischen Unicode-Zeichen '¨' \u0308 (combining diaresis).
Ob zwischen dem GREP-Umlautproblem und dem o.g. Umlautproblem bei Dateinamen ein Zusammenhang besteht, kann ich nicht sagen.
Ich hab's rausgefunden: (?<=(Anm|S)\.) findet wie erwähnt nicht beides, (?<=(m|S)\.) aber schon. Daraus lässt sich ableiten:
Alternativen in Lookbehind und Lookahead funktionieren dann, wenn die Alternativen die gleiche Anzahl Zeichen aufweisen.
Weiteres Beispiel, um diese Beobachtung zu bestätigen: Gesucht sei der Leerschlag zwischen Anm. oder Abb. und nachfolgender Ziffer, also z. B. der Leerschlag in Anm. 54, Abb. 1 usw.
Der Code (?<=(Anm|Abb)\.) (?=\d) funktioniert wie erwartet, weil Anm und Abb die gleiche Zeichenzahl (3) haben.
Das war's, was ich oben mit dem vermuteten Bug meinte. Ich kann mir nicht vorstellen, dass das Backtracking von grep so einen Suchbegriff nicht eigentlich zulassen müsste. Sicher bin ich mir aber auch nicht.
Nicht ganz, mir fiel nur auf, dass die Markierung nach dem Finden (unter bestimmten Umständen, an die ich mich nicht erinnere) der Länge des ersten Alternativums entspricht, auch wenn eigentlich das zwei gefunden wurde. Das schien mir so buggy, dass ich nicht weiter hingeschaut habe. Marco hat dankenswerterweise bestätigt, dass gleich lange Alternativen wirklich funktionieren.
Two comments about things raised about GREP here. As Marco mentioned, any alternatives in a lookbehind list should be the same length. All GREP implementations have this, it's not a 'feature' of InDesign. Allegedly, allowing for different-length alternatives in lookbehind makes expressions hopelessly inefficient (see Friedl, 'Mastering Regular Expressions, O'Reilly). You can work around this limitation, though, by listing them separately:
((?<=S\.)|(?<=Anm\.))\s(?=\d)
This expression matches all spaces preceded by S. or Anm. and followed by a digit. The limitation applies only to lookbehind: in lookaheads, alternatives needn't be the same length.
As to the o+umlaut, this character can be represented by unicode 00F6 and by unicodes 006F + 0308 (the plain o followed by the umlaut from the combining diacriticals. (In InDesign you can't see the difference between the two: it shows the o+umlaut as a single character even if you enter o and 0308 separately; this is new in CS3.) You can match any of these by using a wildcard that generalises over accents, \X (capital X):
m\Xglichkeit
matches 'möglichkeit' no matter how o+umlaut was entered, as 00F6 or as 006F+0308. (\X matches any character with any number of following diacritics from the range 0300-0362.)
Read Friedl's book from cover to cover -- well, almost, anyway. And lots of practice. Then I wrote a ShortCut for O'Reilly on GREP in InDesign and was curious which aspects of other GREP implementations (Pearl etc.) would work in InDesign. It turns out that ID's GREP implementation is much richer than the interface would lead you to believe. (The ShortCut should be out any day now, I don't know what's keeping them.)
Regards,
Peter
(Dieser Beitrag wurde von Peter Kahrel am 7. Sep 2007, 11:57 geändert)
Did you find a way to set the upper-/lowercase of the replaced Text? Some grep implementations allow to replace e.g. by "\u..." to change to upper case. But I find no combination in InDesign that does not simply insert the characters.
I don't think it's possible to change case using GREP in ID. A possible workaround is (if you use an OTF font) to set the Change Format Settings to All Caps.
danke für den Link, den hatte ich seinerzeit übersehen. Aber in dem Thread geht es darum ein S im Suchfeld gegen ein s auszutauschen. Was interessant wäre, ist ein Weg (\w) gegen den entsprechenden Großbuchstaben auszutauschen. Andere grep-implementationen können das mit \u$1, aber InDesign leider nicht.
Bei mir funktioniert das nicht nur bei OTF, sondern mit allen Schriften (Ersetzen mit der Formatoption Grossbuchstaben). Zumindest für den Wechsel Kleinbuchstabe --> Grossbuchstabe gibt es also eine einfache Lösung, oder sehe ich das falsch?
wenn der gesamte ersetzte String in Großbuchstaben gesetzt werden soll, dann würde das gut funktionieren. Nimm aber mal das im englischen gebräuchliche Title Case, bei dem jedes Wort mit einem Großbuchstaben beginnen soll (was auch im Schriftmenü als Makro angeboten wird).
Da würde man nach \b(\w)(\w*)\b suchen und durch \u$1$2 ersetzen wollen.
Alle Variationen über das Thema gehen in InDesign nicht.
I hadn't realised that it worked for all fonts -- all the better!
Good idea. Your suggestion inspired me to try and find a title-caps feature that would at least marginally be less mindless than ID's title caps. ID simply (and mindlessly) capitalises the initial letter of every word, while in fact all kinds of function words need to remain in lower case (mainly conjunctions, articles, and preposions, such as and, the, a, of, on, in, to, for). This GREP does that:
\b\l(?!((nd|he|f|n|o|y|rom|or)\b)|\b)
The GREP, using negative lookahead (?!), is pretty convoluted (with the two separate \b switches at the end, but that's to ensure that single-letter words like 'a' remain in lower case). It also therefore doesn't touch I (capital i) but that would be in upper case anyway. In this sense this expression is Anglo-centric, but it can be adapted to other languages easily (see below).
This GREP ignores, in order, and, the, if/of, in/on, to, from, and for. It may overgeneralise a bit, but that could be rectified. I don't know how title caps work in German -- is every word included? If so, ID's standard feature is ok. If not, you simply list the words that should be excluded minus the first letter. For example, to ignore aus, den, der, des, and die, just use
\b\l(?!(us|en|er|es|ie)\b)
Regards,
Peter
(Dieser Beitrag wurde von Peter Kahrel am 8. Sep 2007, 21:45 geändert)
I've been playing around with this a bit more. This:
\b\l(?!((nd|he|f|n|o|y|rom|or)\b)|\b)
Can be made a bit simpler like this:
[-\s]\l(?!(f|he|nd?|o|y|rom|or)?\b)
to get rid of the second alternative. Furthermore, by using [-\s] instead of \b the Grep catches hyphenated words (second-rate, copy-edit) as well. To improve it even further, to ensure that any word following a colon (:) is changed to initial cap (e.g. in subtitles), the Grep can be changed like this:
Thank you for all these instructive examples. I think everyone who is not an expert in GREP (I am not) can learn a lot just by trying to understand why regular expressions like yours work.
No, German has no specific rules for title caps. Nouns are capitalized, verbs not etc. (as in a normal text). In the sentence: Wenn hinter Fliegen Fliegen fliegen, fliegen Fliegen Fliegen nach, the caps depend on whether the word is a noun or not. (If flies are flying behind flies [= Positive Lookbehind =;o)], flies are following flies …)
Well, we are waiting for your introduction (Shortcut for O’Reilly). Best regards Marco
So the notion 'title caps' has no significance in German, is that right? If the use of case in book titles in, say, bibliographies, and chapter titles, is no different than in any other text, what would you use title caps for in German?
I'm afraid I started this because I couldn't (?:think of | remember) a better example why one would want to change the case of parts of the search-string.