Copy link to clipboard
Copied
Hi all!
Using a single para style, is it possible?
Format this text [kind of "text module" of paras whose first one is particularly formatted playing with soft-returns to delimit 3 parts:
1st part (text before the first soft-return) ==> Bold, Caps, Red color
3rd part (text after the last soft-return) ==> Bold
2nd part (between the first and last soft-returns, eventually with other soft-returns) ==> smaller char size
Note the space before the text in Red!
Before:
After:
(^/)
Oups! Sorry! … Grep/Grep style!
When we want to use and build one, the more relevant approach is to test the grep code in a grep find/replace.
It's what we do! … and, alas, we see that the code find to much text parts!
Why? … In fact:
in ^[^\n]+\n , "multiline" is by default activated and this influences the behavior of the first ^ (end of para marker)!
So, each new line after a soft-return is "virtually" considered as a new para!
… but it will take in account the carriage return because it's not a so
...Copy link to clipboard
Copied
Are you trying to answer a question posed by someone or just showing off your own cleverness.
This is clever but would be more useful if you were to show HOW you do it, not just the results.
It's not a fancy trick to get that space above. Here's the format I would do to achieve this. (See, I don't just brag about what I can do. I show how.)
Start by showing the before and after:
Now here's the paragraph style formatting:
Next here's the Nested Style settings:
Now here's the settings for those Nested Styles:
First the Red. It's the increased leading that causes the space above the paragraph. That is because InDesign treats leading as a character attribute.
Next the character style for the smaller text. Instead of specifying a specific point size, I make it using the Hor and Ver Scaling so that I can change the basic point size without having to re-figure the amount for the smaller text point size.
It's probably an important example to show people. Too bad you didn't take the time to explain it yourself. I expect more from an ACP
Copy link to clipboard
Copied
Keep cool, Sandee!
… If my question was so simplistic, I wouldn't post it! … and, sorry for you, it's a real question!
You may be an "expert" or a "guru" who doesn't need to learn something! It's not my case! I'm truly happy to learn every day ... And it's not because I have an ACP status that I've no questions that puzzle me! … So, stop talking to me about my cleverness, I expert more from you!
To return to our topic, before noting yourself your answer as correct [… that frankly annoys me!], give us a correct answer taking a really better look to my text sampleI
Best regards!
(^/)
PS: I let you note your answer above as "incorrect"!
Copy link to clipboard
Copied
Sir,
If you posted the question as a real question that puzzled you, then how did you get the answer for your example. So obviously it is not a real question for you.
It may have been a real question that a student or colleague asked you. If so, congratulations on figuring out (or knowing) the answer.
And if it was a real question, you are correct that others would be interested in knowing how to do it.
BUT you haven't (and still haven't) posted how to do it.
For that I will not "keep cool". You have irritated me beyond belief.
Copy link to clipboard
Copied
No personal comment on your susceptibility (public or private)!
Back to our topic, imho much more interesting, let's say that the formatted version I showed was "manually" done!
So, go ahead! …
Besides the fact that your approach is totally irrelevant here, my first question is:
Why is ^[^\n]+\n not efficient here and doesn't allow us to find only the beginning of the para [the text part I would like to have in "Red"]?
(^/)
Copy link to clipboard
Copied
Obi-wan Kenobi wrote:
Why is ^[^\n]+\n not efficient here and doesn't allow us to find only the beginning of the para [the text part I would like to have in "Red"]?
I would love to answer your question but I have no idea where you want to put ^[^\n]+\n. If you were to show (not brag) about your technique we could have a true conversation.
Copy link to clipboard
Copied
Oups! Sorry! … Grep/Grep style!
When we want to use and build one, the more relevant approach is to test the grep code in a grep find/replace.
It's what we do! … and, alas, we see that the code find to much text parts!
Why? … In fact:
in ^[^\n]+\n , "multiline" is by default activated and this influences the behavior of the first ^ (end of para marker)!
So, each new line after a soft-return is "virtually" considered as a new para!
… but it will take in account the carriage return because it's not a soft return!
So, use: ^.+\n will be more relevant [it excludes the carriage return]
It will only find each text part between a para beginning/soft return and another soft return.
()^/)
Copy link to clipboard
Copied
… So!
Why we can't use nested styles?
… Because there're paras without soft return! [test it!]
So, Grep styles!
(^/)
Copy link to clipboard
Copied
And now you have finally explained your technique.
If only you had started your "question" as an example with this information.
One should not have to go on and on to get the information from you. Do it from the start. Your namesake would not make it so difficult to gain knowledge.
Copy link to clipboard
Copied
No! … No! and No!
It's only the beginning of an answer! …
Stop to play with "Correct/No correct answer"! There's actually no one!
I only said that it's more complex than it can be imagined!
(^/)
Copy link to clipboard
Copied
How, imho, this could be played! …
One single para style and four grep styles without interference (the following crushing the previous one).
Grep Style 1:
The code used is really interesting: (?<!\n)^.+(?=\n(.+\n)+(.+\r))
As Uwe rightly said (in another topic), a grep style doesn't take in account the previous para, only the para where it is inserted!
… However, here, as "multiline" is strictly "called" [activated by default, (?m) ] and each line that finishes by a soft-return is so considered as the beginning of a new para, the code makes indirectly reference to the para above [in green, negative lookbehind making reference to a soft return: if no SR, we have the beginning of the story or a carriage return!!]! Note the positive lookahead [in red] making reference to the first soft return and all the following text until the end of the para.
Grep Style 2:
As you see, I've "created" a virtual space before! adding a new leading only to the first char of the para!
Note this grep style is active ONLY IF a soft return is found in the para! That's why the other paras aren't touched!
Note too It's not possible to include this leading in the first grep style char style because this "Red" text could have more than 1 line!
Finally, note that 2nd grep style is just an addition to the first one!
Grep Style 3:
Grep Style 4:
To make you it clearer, I've applied different color conditions to the char styles:
Done!
(^/)
Copy link to clipboard
Copied
Reading again the last post, The first grep code could be simplified as:
The 2 first codes are similar: the 1st catching all text from the beginning until the first soft return, the 2nd only its first char!
Note:
(?<!\n)^.+(?=\n) and (?<!\n)^.+\n have not the same behavior!
(^/)
Copy link to clipboard
Copied
Hi Obi-wan,
I did not test all the versions of InDesign yet, but at least (?<!\n)^.+(?=\n) using a negative lookbehind is not working as GREP style with InDesign CS6 v8.1.0 on Mac OSX 10.6.8. First I tried also (?<!\n).+(?=\n), but that did not work either with CS6. However a positive lookbehind seems to work with soft returns. E.g. this one: (?<=\n).+(?=\n)
Will test on later…
For all lurkers here a link to a related discussion at the InDesign Scripting forum:
Regards,
Uwe
Copy link to clipboard
Copied
I still don’t get why you need GREP for this.
I haven’t seen any example that can’t be done with Nested Styles relying on the soft returns.
Show me that this works without those soft returns.
Or all this starts to resemble a circle jerk.
Copy link to clipboard
Copied
Hi Sandee,
I think, this discussion is not only about solving a specific problem, but about understanding how exactly GREP styles work in contrast to GREP Find/Replace (F/R) throughout all versions of InDesign from CS4 to CC 2017. It seems, that there are some important differences between using the GREP patterns with styles or with F/R. Also changes how and why things are working/not working in different versions of InDesign. The how and why would be important to understand.
It could be that one method is indeed working with e.g. CS6 and would fail e.g. with CC 2017. Or vice versa.
So understanding this more deeply is desirably. A CS6 version document could be opened with a later version InDesign and the GREP style will fail or the result would be different…
Regards,
Uwe
Copy link to clipboard
Copied
Then the discussion should be moved to ID GREP scripting.
Because I thought Monsier I-Bin-Know-Bi, was posting a true question that would show newcomers how to use leading in a character style to create a specific look.
What you are describing is a circle-jerk of GREP coding.
Copy link to clipboard
Copied
Uwe, don't irritate Sandee!
Sandee, maybe clearer with this:
Applying your idea to my test sample, I hope you see you have a serious problem!
… and it's totally normal: nested styles constructions are supposed to be played in really specific contexts!
Maybe someone else could make it understand if I can't!
Uwe, you're totally right! This kind of discussion is important for someone who wants to work with a professional vision!
Advanced features could generate a real mess if the op ignores their real behavior!
I see lots of people playing with soft returns in their layout! Our job is to prevent us they play with a real "time bomb"! …
(^/)
Copy link to clipboard
Copied
Too late to not irritate me Mr. I-Be-Know-it-all.
You haven’t cleared up a single thing because your “mess” simply shows what happens when my solution is applied to text without soft returns.
But if you can do what you want without soft returns (and I know you can’t) then you are simply exploding gas out an orifice in your pants.
Copy link to clipboard
Copied
Laubender wrote:
… but at least (?<!\n)^.+(?=\n) using a negative lookbehind is not working as GREP style with InDesign CS6 v8.1.0 on Mac OSX 10.6.8. …
Hi together,
I think I found the culprit for this problem.
I simply did a typo in my GREP style pattern.
(?<!\n)^.+(?=\n) indeed is working as it should!
It's catching all the text from the beginning of the paragraph up to the first soft return.
Also with InDesign CS6.
Here my test document showing:
Sorry again for my confusing reply # 12 !!
Regards,
Uwe
Copy link to clipboard
Copied
hi obi-wan,
I'm intrigued by that tomaxxiGREP panel, but the site seems to be dead
don't suppose you know of an alternative location?