How to make Sigil live (in calibre)

[kovidgoyal]

It's the same one, if you want to see the changes, you have to run from source.

[jackie_w]

@kovid,

Please can I ask you have another look at the nbsp issue of unicode \xA0 vs. the &nbsp entity as raised by Perkin. I am using calibre v1.14, not running from source, so if the following is no longer relevant please ignore

The attached epub contains 14 unicode \xA0 chars. When viewed in calibre Viewer all is OK.

1. When opened in new Tweak, just as you said, the \xA0 chars are syntax highlighted.
   Problem 1: Preview is displaying them as if they were normal spaces.
   
2. Change anything in the text and File-Save.
   Problem 2: Although the \xA0 chars still appear to be syntax highlighted in the code view, after quitting Tweak and viewing the edited epub it seems that the \xA0 chars have been converted to normal spaces during the File-Save. This can be confirmed by reopening the edited epub in Tweak.

This is a similar problem to one which existed in Sigil for a very long time, although it is fixed in the current version.

A possible way to avoid both Problem 1 & 2 above may be to convert the unicode \xA0 chars to entities (&nbsp or & # 160) during Tweak's File-Open and convert them back to unicode during the File-Save. I think current Sigil does the former (and complains about 'not well formed' because DTD is missing) but not the latter.

I've done a brief test of the theory by manually converting the \xA0 chars to &nbsp before opening in Tweak. After an edit/save Tweak has converted the &nbsp to \xA0 and the edited epub displays correctly.

Obviously I have no idea of any wider ramifications to Tweak of &nbsp entities being temporarily present during the editing process, but given the high percentage of retail epubs which use 'empty &nbsp paragraphs' to create scenebreaks etc, IMHO something needs to be done to avoid the current 'silent stripping'. If I've missed something obvious which would have avoided these problems, feel free to call me an idiot

[Perkin]

Another related nbsp problem...
I tried to do a S&R by copying the nbsp character into the find box, but the find doesn't find them, just cycles through the normal space chars.
How would I enter the character to do the S&R.

Edit: seeing jackie_w's post, I used the '\xA0' in the search box and it now finds the character.

The 'Replace All' doesn't find any occurences, but the find/replace&find does

(OS X Mavericks)

[DrChiper]

Originally Posted by jackie_w

Obviously I have no idea of any wider ramifications to Tweak of &nbsp entities being temporarily present during the editing process, but given the high percentage of retail epubs which use 'empty &nbsp paragraphs' to create scenebreaks etc, IMHO something needs to be done to avoid the current 'silent stripping'.

Hmm, that would explain the many empty page constructs I'm currently seeing:

<p> <p>

some other used creating/converting software packages perhaps also "silently" strip, thus rendering the resulting empty page construct useless in (at least my) e-readers.

I used to convert them to &nbsp or & # 160 as jackie_w indicated, but that is now not valid anymore.

[kovidgoyal]

@jackie_w: You are correct, Qt's toPlainText() function replaces \xa0 with a normal space, causing the non breaking spaces to be stripped out during save. I have fixed that by replacing toPlainText() with my own implementation. https://github.com/kovidgoyal/calibr...78c463c5b4c956

[kovidgoyal]

@Perkin: Your nbsp search issues are not search issues but problems caused by the same Qt bug that causes copying of nbsp characters to not work (they are replaced by spaces).

[jackie_w]

Originally Posted by kovidgoyal

@jackie_w: You are correct, Qt's toPlainText() function replaces \xa0 with a normal space, causing the non breaking spaces to be stripped out during save. I have fixed that by replacing toPlainText() with my own implementation. https://github.com/kovidgoyal/calibr...78c463c5b4c956

I can't try out your fix for myself because I don't run from source. I'll take your word for it that it fixes Problem 2 during File-Save. Can you confirm whether it also solves Problem 1, i.e. the \xA0 chars not displaying correctly in the Preview panel?

[Katsunami]

To be sure the problem below was not caused by a problem in the calibre install, I've replaced it with a clean one (except for the settings directory). The problem still exists.

I know you've removed the ampersands, but I thought I'd post the information anyway in cause you'd want to look into this later.

The Windows-installation is a completely up to date Windows 7 x64 Professional. I haven't got anyting installed like a separate QT (only QT as part of applications, such as Sigil, and Frescobaldi), and I don't have any old Delphi-programs or runtimes installed, as was suggested some posts ago. (At least, I don't have those, as far as I know.)

Originally Posted by Katsunami

There is one thing that seems to be incorrect (cosmetic problem): The window titles have &-signs in them, presumably to denote a hotkey. Examples:

&Files Browser
&Inspector
File &Preview

If it makes any difference, the operating system is Windows 7 x64 Professional.

[davidfor]

Originally Posted by jackie_w

I can't try out your fix for myself because I don't run from source. I'll take your word for it that it fixes Problem 2 during File-Save. Can you confirm whether it also solves Problem 1, i.e. the \xA0 chars not displaying correctly in the Preview panel?

I just updated my source and tried. Everything seems to be working: The characters are there, they survive a save and reopen, the preview pane shows them correctly and works correctly when I resized the pane.

[jackie_w]

Originally Posted by davidfor

I just updated my source and tried. Everything seems to be working: The characters are there, they survive a save and reopen, the preview pane shows them correctly and works correctly when I resized the pane.

Thanks, David. and thanks Kovid for fixing so quickly, I look forward to next Friday's release.

[Perkin]

Originally Posted by jackie_w

Thanks, David. and thanks Kovid for fixing so quickly, I look forward to next Friday's release.

Ditto to all this.

[kovidgoyal]

@Katsunami: These kinds of problems are deep in Qt code and that makes debugging them a real pain. For something as trivial as this, it isn't wortht he effort. Off the top of my head, the onlything I can think of is that are you using the calibre style or the system default widget style? Preferences->Look & Feel in calibre.

[DoctorOhh]

Originally Posted by kovidgoyal

Off the top of my head, the onlything I can think of is that are you using the calibre style or the system default widget style? Preferences->Look & Feel in calibre.

FYI. I just switched to System Default and I saw the & symbols as described. Switched back to Calibre Style and they were gone.

[kovidgoyal]

Just uploaded some new betas to http://download.calibre-ebook.com/betas/

They include a new Book Check tool that finds well-formedness errors in XML/XHTML, invalid images, images in CMYK colorspaces and broken links. More checks will be added later.

Also fixed the bugs reported by arspr for css syntax highlighting and jackie_w for nbsp handling.

Finally, links in the preview panel are now clickable.

[Divingduck]

Hi Kovid,

I found two little errors (maybe you have already fixed them):

If I undock a window from the editor GUI (a nice feature in the editor), it works fine except for the inspector, what shows an empty window. If I dock it back to its place in the GUI, all code is shown again but loses the actual position and start have the position at top of the file

If there are blank lines in a text (with or without a blank character), they will not be shown in the file preview window. When I replace the blank with ‘ ’ the blank line will be shown

Edit: Ignore the last one with the blank line. You did fix it with the new beta-update. Thanks.