Regex examples

[DNSB]

Originally Posted by CubGeek

So, if my learning how to properly show varying types of emphasis to help convey nuances for someone who's relying on a screen-reader or similar (on the very infinitesimal chance they access something that I put together) then it was time well-spent.

Sounds very much like why I now pay attention to accessibility features. It takes me very little time and may make life more enjoyable for those who are not able to read text for whatever reason.

[Tex2002ans]

Originally Posted by CubGeek

So, if my learning how to properly show varying types of emphasis to help convey nuances for someone who's relying on a screen-reader or similar (on the very infinitesimal chance they access something that I put together) then it was time well-spent.

Fantastic.

You may also be very interested in the DAISY Consortium (they're one of the reasons why EPUB exists!).

I highly recommend checking out their Youtube channel where they have lots of webinars explaining:

• How blind people actually read.
  
  • "Ways People with Print Disabilities Read"
    
    • A little post I wrote about (with exact timestamps + some discussion on Braille).
      
  • Also Ron McCallum: "How Technology Allowed Me to Read" (TEDxSydney).
    
    • This is the great one that started me down a lot of that Accessibility journey back in 2013.
  • Also ebookcraft 2019: "The User's Perspective: Accessibility Features in Action"
    
• How to use programs/tools you're already using more efficiently.
  
  • DAISY Consortium: "Word Document Accessibility 101"
    
  • DAISY Consortium: "Leveraging InDesign for Accessible EPUB Creation"
    
• How to make your ebooks more accessible.
  
  • 3 fantastic webinars about alt tags + describing images.
    
  • See my 2021: "Automation of scanning on phone or tablet". (Scroll allllll the way down to where I wrote "On universities digitizing".)
    

Originally Posted by DNSB

Sounds very much like why I now pay attention to accessibility features. It takes me very little time and may make life more enjoyable for those who are not able to read text for whatever reason.

Well, most of the enhancements take very little time + add big benefits right away.

Many take up extra labor for smaller benefit, but better/faster workflows are coming out all the time.

And on the benefits front, new programs/tools are coming out all the time, taking advantage of those enhancements. (So if you baked it into your ebook already, you instantly get the extras! )

For more on that, see my posts from last month:

• 2022: "Best way to do three-line space/pause, for accessibility?" (Post #65+)
  
  • Imagine an Accessibility spectrum from 0 to 100. You can easily get to 80/90 by just using basic Headings, Paragraphs, Tables, [...].
    
• 2022: "What's Going on with this Class/Style?"
  
  • I explained advanced methods in a near-future version of Sigil which will help drastically speed up cleaning an HTML+CSS mess.
    
    • (Like doing complex search/replaces similar to Spellcheck Lists—like <i> -> <em> will become as easy as scrolling/searching through a list and clicking some boxes!)
• Post #237 in a super-famous thread.
  
  • I summarized many of the enhancements + how they've gotten even better since 2016.
    

Originally Posted by CubGeek

Having spent 5 years working for a boss who was blind and who used a screen-reader, I hope that I now have a better empathy for the difficulties she encountered than before my time there. Not only with official communications, but with webpage navigation, with poorly-implemented accessibility "functions," and also with the simple pleasure of "reading" a book over her lunch break.

Fantastic.

I haven't had the pleasure of meeting a blind person yet (in-person), but I love digitizing all this stuff and writing about Accessibility.

If you want to find my 300+ posts about it, type this in your favorite search engine:

Accessibility Tex2002ans site:mobileread.com

[CubGeek]

Originally Posted by Tex2002ans

And I don't know if you caught this topic:

• 2021: "Italics and Bold"

where I explained differences between <i> + <em> even further.

I'm replying here since this is where the conversation happened at the time, but if this makes more sense in that linked topic, lemme know and I'll delete and post it there.

I've run into a condundrum. The author of my current project has several characters who use an "internal monologue," so I've been using the <i> tag for those. For words that need emphasis it's the <em> tag. Simple so far.

However, the author also has words in the internal monologue that need emphasizing... For just visuals I'd take the emphasized word out of the <i> tags and restart the <i> tag after the word:

Well, Dylan thought to himself, the very least they could do is drop the price of gas a bit.

However, if I use the <em> tag for emphasizing the word "least" to ensure that accessibility programs can convey the correct tone/meaning/nuance, the tag italicizes the visual:

Well, Dylan thought to himself, the very least they could do is drop the price of gas a bit.

So, while the accessibility is correct, sighted readers may not have the emphasis conveyed visually.

Would nested <i> and <em> tags like this this be a case for the <strong> tag, instead? That way the sighted readers still get the emphasis (via boldface text) and accessibility readers can convey the audio emphasis?

<i>Well</i>, Dylan thought to himself, <i>the very <strong>least</strong> they could do is drop the price of gas a bit</i>.

Well, Dylan thought to himself, the very least they could do is drop the price of gas a bit.

[isarl]

Originally Posted by CubGeek

Would nested <i> and <em> tags like this this be a case for the <strong> tag, instead? That way the sighted readers still get the emphasis (via boldface text) and accessibility readers can convey the audio emphasis?

You are conflating semantics and style. If the meaning of the tag is that its contents are emphasized, then you use <em></em>.

What you can do is add a style rule in your CSS, like:

i em {
    font-style: normal;
}

This preserves the semantic meaning of the tags while allowing you to control the presentation/style.

[CubGeek]

Thank you! I appreciate it!

[isarl]

Originally Posted by CubGeek

Thank you! I appreciate it!

Happy styling and reading!

[Tex2002ans]

Originally Posted by CubGeek

I'm replying here since this is where the conversation happened at the time, but if this makes more sense in that linked topic, lemme know and I'll delete and post it there.

You can always create a separate thread, then reference the original topic/posts.

(This specific thread is mostly for Regex help.)

Originally Posted by CubGeek

I've run into a condundrum. The author of my current project has several characters who use an "internal monologue," so I've been using the <i> tag for those. For words that need emphasis it's the <em> tag. Simple so far.

However, the author also has words in the internal monologue that need emphasizing... For just visuals I'd take the emphasized word out of the <i> tags and restart the <i> tag after the word:

I agree with isarl's solution completely.

Italics-within-italics or emphasis-within-emphasis is like an ON/OFF switch. You just flip it to its opposite:

i i {
        font-style: normal;
}

em em {
        font-style: normal;
}

i em {
        font-style: normal;
}

- - -

The first one says:

"IF there's an italics inside an italics... make it normal."

Example:

<i class="monologue">That damn ship, the <i>USS Liberty</i>, was like a spooky ghost ship.<i>

Usually, ship names would be in italics... but since it's buried in a thought, the ship will become roman/normal/un-italic temporarily to distinguish it from the surrounding text.

Similar situation with the other 2 CSS rules.

[Skydancer]

Greetings,
I would really appreciate all the help I can get on this problem. I have a lot of texts similar to the the example below that I need to edit from this:

བསོད་ནམས་འདི་ཡིས་ཐམས་ཅད་གཟིགས་པ་ཉིད། །

sö-nam di-ji tam-če zig-pa-nji

Z močjo teh vrlin naj dosežem vsevednost,

ཐོབ་ནས་ཉེས་པའི་དགྲ་རྣམས་ཕམ་བྱས་ནས། །

tob-ne nje-pe dra-nam pam-dže-ne

naj premagam sovražnike – negativna dejanja –

... into this:

བསོད་ནམས་འདི་ཡིས་ཐམས་ཅད་གཟིགས་པ་ཉིད། །  
sö-nam di-ji tam-če zig-pa-nji  
    Z močjo teh vrlin naj dosežem vsevednost,

ཐོབ་ནས་ཉེས་པའི་དགྲ་རྣམས་ཕམ་བྱས་ནས། །  
tob-ne nje-pe dra-nam pam-dže-ne  
    naj premagam sovražnike – negativna dejanja –

Each line has to end with a double space (see the example I provided), except the last line of each paragraph.

I need the text to be in plain text format, not in (x)HTML and CSS.

[Leonatus]

Maybe it's a beginner's request, but anyway...
My text has lots of <h1>...</h1> tags, followed by subtitles, only that they are tagged by <p> tags. I would like to maintain the <h1> headers and the following paragraph changed to <h2>, like this:

<h1>text, text</h1>
<p>text, text</p>

should move to:

<h1>text, text</h1>
<h2>text, text</h2>

The following regular paragraphs should remain untouched.
I tried:

(/h1>)\n^(\<p\>)(.*?)(\</p\>)$

but this returns the </h1> until the last occurrence of </p> in the whole section. I'm sure that there is a quite simple solution, but I can't find it.

[KevinH]

Try checking the "Minimal Match" in Regex Options.

Also if the subtitle paragraph never has nested tags you can change things to look for anything but a tag begin. Then you will not need to check Minimal Match (greediness control)

Effectively all characters not a < and as many as you want to be followed by ending p tag

[^<]*</p>

[Leonatus]

Minimal Match is checked.
As to the rest, sincerely, I do not quite understand what I have to do.

[Turtle91]

‘Greediness’ refers to how much of the string to be searched gets matched.

If you say you want </h1>(.*)</p> it would capture EVERYTHING from the end of the </h1> to the LAST </p> in your file …. very greedy.

You can specify a minimal capture that would only capture up to the FIRST occurrence of </p>. There are a couple ways of doing that: clicking minimal match like KevinH mentioned, my favorite is to add a question mark to the capture group. </h1>(.*?)</p>

If you want a minimal capture of the first line (paragraph) after your heading you could try this:

Find: </h1>\s*<p.*?>(.*?)</p>
Replace: </h1>\n<h2>\1</h2>

That looks for the closing header tag followed by any amount of white space followed by an opening paragraph tag with anything in it (classes, styles, etc.) then it captures anything within that paragraph up to the first paragraph closing tag. It then replaces all of that with the closing header tag, and it inserts what it captured, using the \1, into a new heading (level 2) tag.

[Leonatus]

I knew about the "greediness" you mentioned, and I was desperately looking for a method to make it "lazy", but I didn't find it. Well, thank you for your clarifying, that works!

[KevinH]

But checking "Minimal Match" did not help? They should do the same thing except the ? approach can give you more fined grained control.

[Leonatus]

I cannot say any more. The "Minimal Match" was checked from the beginning. But it didn't help.