A regex question

[theducks]

Originally Posted by PatNY

OK, ducks, I tried to adapt your formula to the specific issue I had by using this:

Find:
<text>(([A-Z])(.+) ([A-Z])(.+))</text>

Replace:
<text>\2\L\3\E \4\L\5\E</text>

And it's mostly working. However If I have more than two words in the title, then only the first and last words get the initial cap. The words in the middle are all lower case.

So, for example, your solution will result in:

<text>Ice cream Rocks</text> instead of <text>Ice Cream Rocks</text>

So, do you know how to get every word in the title to be initial caps?

You have 3 words
so you need another set of patterns (BTW you can only have 9 capture replacements

(([A-Z])(.+) ([A-Z])(.+) ([A-Z])(.+))

<text>\2\L\3\E \4\L\5\E \6\L\7\E</text>

Note that the whole capture is represented by the outermost ( ) and is available as \0

Again: work on the pages and include the Title option in the chapter headings, then autogenerate the TOC

[PatNY]

Originally Posted by theducks

(BTW you can only have 9 capture replacements

ducks, I'm not sure what you mean by "capture replacements." Do you mean it will only work for titles that are 9 words or less? Some of the titles have 5, 7 or more words in them. If the max is 9, that's fine. I can always fix by hand the few titles that over 9 words.

Again: work on the pages and include the Title option in the chapter headings, then autogenerate the TOC

ducks, see my reply to capidamonte. I explain my reasons why I want to limit editing to the toc.ncx. Also, this is not even about chapter headings. It's for subtitles in a chapter and can number in the hundreds. If I limit the changes to the toc.ncx file, I can see exactly what the regex formula has done to the file. But if I do the regex on all the html files, there is no way to easily check to see if everything has been done right or to easily correct things if something goes wrong. Because the subtitles will be scattered all over the place as opposed to being all in one single file in a toc.ncx.

[theducks]

Each word is 2 captures
([A-Z]) is the first Letter
(.+) <a space here> is the rest of the word with the space being used as a word delimiter detection

so my system works for 4 words maximum and must be crafted for
each of 4 , 3, 2 and 1 words surrounded by a <text> tag

A REGEX guru might come up with a better pattern / replacement

[Ahmad Samir]

Try doing it in two goes; open toc.ncx, and make sure the replacement setting is set to Current file.

Now first leave the first letter in in the first word capitalised and lower all the letters after it:
Find: <text>([A-Z])(.+)
Replace: <text>\1\L\2

Then capitalise the first letter of each word:
Find: <text>(.+) ([a-z])
Replace: <text>\1 \u\2

you'll need to click "Replace All" more than once (until it says "No replacements made"), the number will depend on the number of words in the longest title; not elegant, but seems to work.

I guess there'll be some corner cases, e.g. a capitalised "The" or "To", but you can replace those easily afterwards.

Note that if you re-generate the toc again in Sigil all those changes will be gone, so make sure you don't need to generate the toc again before doing that.

[Timur]

@PatNY: You can do what you want with

Search:

\b[A-Z]\K([^\s]+)(?=[^<>]*</text>)

Replace:

\L\1\E

If your text includes characters outside ASCII range(like È, Ñ, etc.) you can use the unicode-aware search pattern:

Search:

(*UCP)\b[[:upper:]]\K([^\s]+)(?=[^<>]*</text>)

Note: (*UCP) option flag is working in my Sigil, but at least one user reported in the past that it has caused Sigil to crash.

[PatNY]

Thanks to all who replied in this thread. I used Timur's solution and it works like a charm. Having all caps for TOC entries when there are hundreds of entries is just too hard to read, and using title case instead makes it so much better on my eyes.

There is just one situation left unfixed which I think could be fixed. Whenever there are hyphenated words, the second word is not capped. For example, CHOCOLATE-GLAZED will become Chocolate-glazed instead of Chocolate-Glazed.

So is there any way to construct a separate regex expression that will make every first letter after a hyphen an uppercase letter?

Also, I noticed in the latest version of Sigil, there is no search option for whole words only? I may be mistaken but I thought it had that in the past. I noticed that when I tried to use a "Replace All" to change "nut" to "Nut" that I ended up with a lot of "PeaNut" and ButterNut" results!

I may be misremembering, but I could have sworn the search options are less than before? Or maybe I am missing the option to put the search window in an advanced mode?

[Timur]

Changing this character class in the search pattern

[^\s]

to

[^\s-]

capitalizes the first letter after a hyphen too.

To make a "whole word" match enclose your search pattern between word boundary anchors \b, like this:

search: \bnut\b
replace: Nut

[PatNY]

Hello Timur, thanks very much for your last post. Both your fixes worked perfectly.

[PatNY]

\b[A-Z]\K([^\s-]+)(?=[^<>]*</text>)

The above formula continues to work perfectly in Sigil. However, when I try to use it in EditPad Pro, I get the following error message:

"Unknown regex token \K. Use backslashes to escape metacharacters."

In addition, the "\K" part of the formula is highlighted in red, so that's where the problem is.

Does anyone know how to fix this so the formula works in this editing program too?

[Jellby]

Unfortunately, RegEx is not a fixed language, and every program that supports it uses a different dialect. \K may be recognized by Sigil, but not by EditPad Pro. You'd have to read EditPad's documentation and see if there's anything equivalent to Sigil's \K.

[DiapDealer]

Originally Posted by PatNY

\b[A-Z]\K([^\s-]+)(?=[^<>]*</text>)

The above formula continues to work perfectly in Sigil. However, when I try to use it in EditPad Pro, I get the following error message:

"Unknown regex token \K. Use backslashes to escape metacharacters."

In addition, the "\K" part of the formula is highlighted in red, so that's where the problem is.

Does anyone know how to fix this so the formula works in this editing program too?

The \K just resets the match so that the characters preceding it are not included in the returned match. Since in your regex, the preceding characters are a fixed length (a requirement of PCRE for each alternative in a lookbehind), I'd suggest changing that first part to a lookbehind assertion... which will achieve the same thing. I have no experience with EditPad Pro, but I assume the lookaround syntax is the same for the JGSoft regex engine as it is for Sigil's PCRE engine. Something like:

(?<=\b[A-Z])([^\s-]+)(?=[^<>]*</text>)

I'd also suggest changing the lookbehind portion to (?<=\b\p{Lu}) so that capital unicode characters (like É or Ä) won't be excluded from the search. Making the entire new regex:

(?<=\b\p{Lu})([^\s-]+)(?=[^<>]*</text>)

I believe that should accomplish the same thing as your original expression and has (I hope) the added benefit of working with both the JGSoft and PCRE regex engines.

EDIT: Any Replace expression you were using should remain the same. The lookbehind and lookahead assertions are not capture groups like they might appear. You still only have one capture group in your entire expression.

[PatNY]

DiapDealer, thanks for your help. Your formula works well in Sigil, but not in EditPad Pro. It won't throw up an error message like before, but it doesn't give intended results. Instead, using the same replace string that Timur had provided, I will get this:

 <navPoint class="chapter" id="navpoint-2" playOrder="1">
      <navLabel>
        <t\Lext>TITLE\E P\LAGE\E</text>
      </navLabel>
      <content src="OEBPS/002-titlepage.html"/>
    </navPoint>
    <navPoint class="chapter" id="navpoint-3" playOrder="2">
      <navLabel>
        <t\Lext>DEDICATION\E</text>
      </navLabel>
      <content src="OEBPS/003-dedicationpage.html"/>
    </navPoint>

instead of this which Sigil will result in:

 <navPoint class="chapter" id="navpoint-2" playOrder="1">
      <navLabel>
        <text>Title Page</text>
      </navLabel>
      <content src="OEBPS/002-titlepage.html"/>
    </navPoint>
    <navPoint class="chapter" id="navpoint-3" playOrder="2">
      <navLabel>
        <text>Dedication</text>
      </navLabel>
      <content src="OEBPS/003-dedicationpage.html"/>
    </navPoint>

EditPad Pro seems to be using some finicky kind of Regex. I had no idea there were various forms of regex.

If someone can figure out a fix that works in EditPad Pro, great. Otherwise, I'll just continue to use Sigil to get title case in the metadata TOCs.

[DiapDealer]

Actually, it looks like the "Find" is working as expected in your EditPad Pro example. It's the replace expression that's failing you there. It appears that JGSoft's regex engine doesn't like the \L\l \U\u \E switches that PCRE's engine uses for its case transformations.

If your replace expression is \L\1\E for Sigil, try using a replace expression of \L1 for EditPad Pro. Looks like EditPad Pro uses \Un \Ln and \In instead. Where n is your backreference number, U is for uppercase, L is for lowercase and I is for Initial capital-the rest lowercase.

So to recap (I recommend copy/paste—there are no spaces in ANY of the following expressions)...
Find (for Sigil or EditPad Pro):

(?<=\b\p{Lu})([^\s-]+)(?=[^<>]*</text>)

Replace (Sigil):

\L\1\E

Replace (EditPad Pro):

\L1

I verified it works with EditPad Lite which is supposed to use the same regex engine as its big brother, EditPad Pro.

[PatNY]

DiapDealer, you are a regex genius. I tested your fix in EditPad Pro and it works fine now. As someone who has tried to comprehend regex on multiple occasions, I marvel at your ability to not only understand it but to understand and work with multiple versions of it.

Why would there be so many flavors of regex, and is one method inherently better or more versatile or powerful than the other?

I will continue to use sigil for any extensive TOC reconstruction, creation or transformations as it has a more suitable interface for those jobs than a basic text editor. But sometimes all I need to do is a simple change to title case from all caps, and it's much more efficient to do it using EditPad Pro via calibre's tweak epub feature. So, many thanks for your help!

[DiapDealer]

Cool. Glad it worked for you.

I thank you for the compliment, but I only consider my regex-fu to be passingly fair... there are some regex gods out there. I am an egg. But helping others helps me improve my skills. I actually find rexexp construction addictive in a slightly weird way.

As for "why so many?" and which is "better," I don't really have an answer. Most of their difference are fairly minor and the average user might never come across them. I prefer PCRE (Sigil), but mostly because of its widespread use (PHP, Apache, etc) and open source origins. PCRE might have a slight edge in capabilities over JGSoft in that PCRE can do recursion. And that "\K" you were initially using is a biggie as well. It allows you to get around the "fixed-length-only lookbehind hurdle."

Keep plugging away at it. A little bit will stick each time!