regex - issue with spaces?

[cybmole]

OK - that is is interesting but strange. yes I saw "yellow" - as per Jackie's picture - but did not understand the significance.

But copying and pasting into find box did NOT work for me. calibre 1.16 win 7 64 bit versions. I tried with both text mode & with regex mode. "find" insisted there were NO matches - hence this thread.

Maybe jackie & I do not populate the "find" box in exactly the same way. I use windows copy + paste - is there another way ?

UPDATE - yes that's it. I restored the original-epub backup for more testing. windows copy + paste fails like I said. BUT select text then open find/replace ( which populates the box for you) works.
So why is that. & can it be fixed for consistency ?

PS I did not know about the select, then find method, I am used to doing things "the sigil way" & am trying to self-teach how to get same results with calibre editor instead. ( select in order to find does not work in sigil)

[Toxaris]

Originally Posted by jackie_w

Isn't that exactly what you already see in the pic I attached above?

Yes, I see the yellow block. But I cannot see what kind of space it is. It could be a normal non-breakable space or a non-breakable thin-space or perhaps even others. I would need to rely on the preview or a hex-editor to try to identify them.
The same applies for dashes. They are all displayed as a hyphen in a yellow box, regardless if it is an ndash or an mdash.

That is less than practical in my opinion.

[arspr]

Originally Posted by cybmole

But copying and pasting into find box did NOT work for me. calibre 1.16 win 7 64 bit versions. I tried with both text mode & with regex mode. "find" insisted there were NO matches - hence this thread.

UPDATE - yes that's it. I restored the original-epub backup for more testing. windows copy + paste fails like I said. BUT select text then open find/replace ( which populates the box for you) works.

I cannot reproduce the issue. See attached screenshot. I'm with Calibre Portable 1.17 (outside home ) on a W7-64bit laptop.

It doesn't matter how I fill the box (either Ctrl-C + Ctrl-V or directly Ctrl-F over the selected text).

Two suggestions:

• Update to 1.17
• Please perform more tests with other strings. I think that there's something weird hidden about S&R. Please, if possible, check this bug I reported to Kovid, which he cannot reproduce either. (It's normally "hidden" in the Calibre Bugtracker as it is marked as Invalid for the time being. From the start bugtracker page you have to go to advanced search and check "Invalid" items in order to make it shown, or you can directly reach it through the posted link)

[arspr]

Originally Posted by Toxaris

Yes, I see the yellow block. But I cannot see what kind of space it is. It could be a normal non-breakable space or a non-breakable thin-space or perhaps even others. I would need to rely on the preview or a hex-editor to try to identify them.
The same applies for dashes. They are all displayed as a hyphen in a yellow box, regardless if it is an ndash or an mdash.

That is less than practical in my opinion.

As said before, update to 1.17 which comes with a really handy feature about "identification":

• Edit book: Show the name of the current character to the left of the cursor in the status bar. Can be turned off via Preferences.

Editor is just taking off. Therefore we must stay FULLY tuned...

[BobC]

A suggestion -have you checked that there isn't a <space> character either before or after the string you have pasted into the S&R dialogue.

I have hit this issue before and usually discovered that there is an extra <space> outside the pasted string.

BobC

[DoctorOhh]

Originally Posted by arspr

I cannot reproduce the issue. See attached screenshot. I'm with Calibre Portable 1.17 (outside home ) on a W7-64bit laptop.

It doesn't matter how I fill the box (either Ctrl-C + Ctrl-V or directly Ctrl-F over the selected text).

I have the exact same setup as you yet I can not get it to find anything during a search. It will show a NO-BREAK SPACE in the bottom right corner if I place the cursor to the right of the space.

[BobC]

Originally Posted by cybmole

PS I did not know about the select, then find method, I am used to doing things "the sigil way" & am trying to self-teach how to get same results with calibre editor instead. ( select in order to find does not work in sigil)

Actually it does - close the S&R dialogue, highlight a word in the text then use the menu to bring up the S&R dialogue and hey presto - the word highlighted is in the "find" box. This is in Sigil.

As far as I can tell the two behave exactly the same in this respect - the "find" box is populated if and only if a string is selected BEFORE the S&R dialogue is invoked. In Calibre's editor what will not work is trying this in the preview rather than the code window whereas in Sigil it will work in both views.

BobC

[mrmikel]

I am with DoctorOhh, Windows7, 64 bit, Calibre 64 bit. It can not be selected, or if you somehow do select it, it finds ordinary spaces.

It does show and it can be gotten rid of, but only through Regex using the code for it, which is something of a pain. But those of us who been banging around epubs a bit have seen that paragraph, plain space, paragraph will be ignored a lot of the time and will change it to one entity or the other.

It would be a very good thing though for Kovid to get rid of all of these hidden characters if he can. They do nothing but cause a lot of annoyance until one figures they are there in first place. They are not part of HTML either, as far as I know.

[DoctorOhh]

Originally Posted by mrmikel

I am with DoctorOhh, Windows7, 64 bit, Calibre 64 bit. It can not be selected, or if you somehow do select it, it finds ordinary spaces.

I am not running calibre 64 bit, I am running calibre portable version 1.17 which is 32 bit just like arspr.

[BetterRed]

Originally Posted by mrmikel

It would be a very good thing though for Kovid to get rid of all of these hidden characters if he can. They do nothing but cause a lot of annoyance until one figures they are there in first place. They are not part of HTML either, as far as I know.

I like to have two spaces between sentences, especially for foreign (for me) language texts. Currently I achieve this via putting a 'space' followed by a 'nbsp' between sentences.

Some of my colleagues whose first language is not English also like to have double space an the end of sentences in English text. For the same reason as me - it makes reading foreign language texts easier.

If 'nbsp' is banished - because "[its] not part of HTML" - how would I get two spaces between sentences, most (all ?) viewers seem to ignore a second 'space'.

BR

[jackie_w]

Originally Posted by BetterRed

If 'nbsp' is banished - because "[its] not part of HTML" - how would I get two spaces between sentences, most (all ?) viewers seem to ignore a second 'space'.

It's not banished in that way. You can type the &nbsp entity in the calibre editor if you want or use it as part of the Replace box contents.

If you type it, the editor default is to change it to the unicode char on completion. If you don't like that behaviour, then change the option in Edit - Prefs - Editor settings.

If you run a Check then you'll get a warning about Named Entities but if you click 'Try to correct all fixable errors automatically' or 'Replace all named entities ...' then the named entities will be auto converted to their unicode equivalents.

[mrmikel]

Numbered entity 160 and nbsp are absolutely the same, just expressed a different way. So put in as many spaces as you like.

The non breaking spaces are just the same as regular spaces except in two ways. They will be honored as spaces all the time and they join together the two words on either side. This can be desirable, when the words are one thought. It can be undesirable if they are used indiscriminately and cause the reader to leave huge spaces on one side (the right in English) because two words can not be broken because they have the non-breaking space in between them.

[theducks]

Originally Posted by BobC

Actually it does - close the S&R dialogue, highlight a word in the text then use the menu to bring up the S&R dialogue and hey presto - the word highlighted is in the "find" box. This is in Sigil.

As far as I can tell the two behave exactly the same in this respect - the "find" box is populated if and only if a string is selected BEFORE the S&R dialogue is invoked. In Calibre's editor what will not work is trying this in the preview rather than the code window whereas in Sigil it will work in both views.

BobC

In sigil: You don't even have to do the close-select-open. Select: then Ctrl-f and it behaves just as if you jumped thru those hoops

[theducks]

Originally Posted by BetterRed

I like to have two spaces between sentences, especially for foreign (for me) language texts. Currently I achieve this via putting a 'space' followed by a 'nbsp' between sentences.

Some of my colleagues whose first language is not English also like to have double space an the end of sentences in English text. For the same reason as me - it makes reading foreign language texts easier.

If 'nbsp' is banished - because "[its] not part of HTML" - how would I get two spaces between sentences, most (all ?) viewers seem to ignore a second 'space'.

BR

It only applies to (friendly) Named entities. You can still use their entity-numbered ,ISO-8859-1 versions Again & #160 is a NBSP
just like & #62 is a >

It is just a PITA to have to keep a chart handy

[cybmole]

Originally Posted by BobC

Actually it does - close the S&R dialogue, highlight a word in the text then use the menu to bring up the S&R dialogue and hey presto - the word highlighted is in the "find" box. This is in Sigil.

As far as I can tell the two behave exactly the same in this respect - the "find" box is populated if and only if a string is selected BEFORE the S&R dialogue is invoked. In Calibre's editor what will not work is trying this in the preview rather than the code window whereas in Sigil it will work in both views.

BobC

ok -
1. I have F&R always open in sigil, that is why i thought they behaved differently, but..

2. there is different behaviour - see my initial posts. with the example that we are discussing I can use windows copy + paste in sigil to populate the find box & find will work after that, but calibre editor will NOT work when the same sequence of operations are applied. so I think calibre code is doing something that "edits" the copy/ paste data.

PS I think that in ADE/ Sony readers. those single space-like character lines are suppressed anyway, when the book is rendered, so wanting to zap that code is a bit OCD on my part but hey, I like to tinker, then read. FYI That story is very short & it is sneakily set with line height of 1.75em throughout , to hide how short it really is.

Anyway, with my new T2, I was surprised to find that it could locate & connect to my local UK library web page, so I did try the "proper" route for library loans, i.e. installed Sony reader software to authorise the gadget ( because Sony T2 is invisible to all versions of ADE ) then downloaded the DRMd version from the library direct to reader & read that.

Well, the 1st loan was not too bad, but the next loan had paragraph spacings that really annoyed me & the 3rd was even worse...& that is without mentioning the frustration of seeing indents / justified text suddenly go haywire part way through the book because someone has assigned a wrong class or added 3 layers of block quotes for no logical reason. The terms "retail epub" & "quality control" don't seem to belong in the same sentence, unless you add in "lack of "...

So I have reverted to borrow, hack, tweak, read, return, delete - much more satisfying.