Search function not working

[Ruskie_it]

Originally Posted by arspr

But I really hope he could make some magic... (If MS Word is capable, why is not Calibre going to be?)

Not only MS Word... I use Total Commander for everyday work (best money ever spent on a piece of software), and I just tried to open an html of a soft-hypenated book with its small internal listener. The hypens are visible and marked by a dash.

[eschwartz]

Originally Posted by Ruskie_it

Not only MS Word... I use Total Commander for everyday work (best money ever spent on a piece of software), and I just tried to open an html of a soft-hypenated book with its small internal listener. The hypens are visible and marked by a dash.

And neither of them are based off of Qt.

Although either one could afford more than Kovid to spend time fixing Qt, in order to polish tiny details of the UI.

[eschwartz]

Originally Posted by arspr

And yet another brainstorming about making non-printable characters visible: through named entities.

• Calibre does prefer the usage of unicode characters over named entities. But this case could be the exception to that general rule.
• I propose something like a "white-list" of named entities/"black-list" of their associated unicode characters. (Also fully customizable?)
• Then some options which could cause:
  • Nothing. As Calibre currently beheaves. The default option.
  • Warn me. Whenever a new editor window is opened an automatic search is launched against the black-list. And you get a warning. But nothing else is done.
  • Automatically change when opening but revert on save. The black-listed unicode chars are automatically changed by entities. This procedure is reverted when saving. I mean that the epub/azw3 file on the HDD always contains unicode chars but the opened editor shows entities.
  • Preserve entities. The same as above but entities are preserved when saving.

Of course this scheme needs some polishing and those white-listed entities would also affect other areas of the code, like the main named entities check or the automated change into Unicode when typing the ending ";" ... But I think the general idea is more or less clear.

As I said just brainstorming mode.

Sounds like an idea for an editor plugin.

[shamanNS]

@eschwartz: Any idea if QT is also to blame for both Sigil and Calibre Editor search/replace fields (or into html code itself) not excepting that same soft hyphen character when I input it using Autohotkey's hotkey/hotstring? Or even using Alt+0173 shortcut.

I know I could use: "Insert special character"> Shy, but that is not as convenient.

Easiest workaround so far for me is to open Notepad via Autohotkey shortcut, input special character via hotstring (.sh for soft hyphen, .mdash for — etc), and then select and copy character from Notepad to Calibre/Sigil search or code view.

Of the ones that I regularly use "Shy" is so far the first one that both editors ignore.


Because hyphenated footnotes/endnotes text looks awful in PW1 & PW2 pop out window (because of forced left alignment) usually after using HyphenateThis plugin I manually remove soft hyphens using search/replace just for endnotes html file.

[eschwartz]

At least in calibre, I just type the entity and have it autoconvert. That works for the HTML code and you can paste into the search field.

I have never had problems with alt codes, which makes sense as it is part of the keyboard/OS system support and would anyway tend to be well integrated.
I do not know why AutoHotKey, wouldn't work, as I have never used it.

[shamanNS]

Other alt codes (say for single curly quotes, ‘) work inside Calibre Editor's code view and search field. Also "typing" the same Alt code via Autohotkey works in all other programs except Calibre & Sigil which both use QT. So far only U+00AD/Alt+0173 doesn't work. For html code workaround is typing the entity * but for Search field we still must use copy/paste.

[eschwartz]

Well, I definitely don't know why &shy ; specifically would spaz out.

[DiapDealer]

Originally Posted by Ruskie_it

anyway it means to me that soft hypenation kinda breaks search functions, isn't it?

Yes. That's the bottom line.

And not only for editing, it prevents readers from using their device's/app's search function effectively on the finished product.

My advice would be to do all editing/searching/replacing you deem necessary before adding the soft hyphens (with "Hyphenate This" or otherwise) for your personal viewing pleasure. And to allow other readers the chance to do the very same thing, by never running "Hyphenate This" on an ebook that's going into production. Because ...

Originally Posted by Ruskie_it

anyway it means to me that soft hypenation kinda breaks search functions, isn't it?

[Ruskie_it]

Originally Posted by DiapDealer

And not only for editing, it prevents readers from using their device's/app's search function effectively on the finished product.

I have just searched a word on my soft-hypenated epub (kindle pw2 fw 5.4.5.1): it finds it. Although it finds all related words as well.
That is: I searched for "correre", it found "correvano", "correva", "correndo", "corriamo", "corre", all verbal form for the verb "correre".
Same for the noun "strano", it found also the adverb "stranamente".
Which is - in fact - "strano".
But it seems not to break device search functions completely, at least.

[DiapDealer]

Sorry...
Breaks most standard epub ereader search functions.

But I would still not recommend using "Hyphenate This" on a production ebook. Some may value an accurate search function more than they mind a little white-space here and there.

Personal use?... knock yourself out. But if I bought an ebook that was littered with invisible soft-hyphens (or their entity equivalent), I'd probably be asking for a refund.

[Ruskie_it]

Originally Posted by DiapDealer

Sorry...
Breaks most standard epub ereader search functions.

But I would still not recommend using "Hyphenate This" on a production ebook. Some may value an accurate search function more than they mind a little white-space here and there.

Personal use?... knock yourself out. But if I bought an ebook that was littered with invisible soft-hyphens (or their entity equivalent), I'd probably be asking for a refund.

Well, ebooks in azw format are proprietary to the kindle world. Kindle does not hypenate itself but it manages soft-hypenation AND search functions. In the .epub world shy may break device's search (I'll take your words), but they are also unnecessary because (I believe) all epub e-reader can handle hypenation, can't they?
So, it seems they are two well separated worlds.

In any case, no worries: I'm not a publisher, just a reader. It's that I value, for the pleasure of reading, much much much more a well balanced "written page" that I "use" 99.9% of the time while using my reader, than a search function that I use only sometimes, to say the least.
But that's just me. I agree that the approach of demanding to an ebook reader to be able to hypenate itself makes much more sense.

[roger64]

Originally Posted by shamanNS

Other alt codes (say for single curly quotes, ‘) work inside Calibre Editor's code view and search field. Also "typing" the same Alt code via Autohotkey works in all other programs except Calibre & Sigil which both use QT. So far only U+00AD/Alt+0173 doesn't work. For html code workaround is typing the entity * but for Search field we still must use copy/paste.

Typing \u00ad should allow to find them using the search window of the Calibre editor (provided the shy entity is not used, but this one should be visible...)

[arspr]

Originally Posted by eschwartz

Sounds like an idea for an editor plugin.

Any volunteers??? (DiapDealer I'm looking at you )