Unexpected positioning of cursor in CV

[philja]

Working in Sigil 2.6.2 Qt 6.8.2 in Linux using the AppImage

I've just converted a LibreOffice Writer .odt file to epub3 using the ODTImportQt plugin v0.5.0. All seemed to go pretty well but subsequent editing produced two (so far) unexpected problems.

1. When editing an xhtml file in the Code View, clicking in the Preview places the focus in CV in the paragraph below the one clicked in. If I want to edit an H2 or H3 heading between two paragraphs, I have to click in Preview in the paragraph above the heading. This is systematic in all paragraphs, headings etc.

2. a Ctrl click on the HTML tag while editing does not open the styles sheet at the appropriate entry. Even if the style sheet is already open, the Ctrl click in CV does nothing.

These two unexpected behaviours are strictly limited to the newly produced epub3 file using ODTImportQt so I suspect the plugin. Does it sound like a Qt issue?

Any ideas?

[DiapDealer]

It could just be something to do with the markup that is produced by LibreOffice. I don't believe the ODTImport plugin has much control over that--as it's primarily just a wrapper around the pre-existing Writer2xhtml tool.

Some code snippets from where you believe your cursor should be going in Code View might be helpful to tell what might be going on.

I might suspect the AppImage, but you mentioned that the problem is limited to one particular epub3.

[philja]

I've attached a code snippet from CV. You'll see the focus is on line 26 but in Preview I clicked exactly on the <h3> text. If the paragraphs are larger blocks of text, it doesn't matter where I click in Preview, the focus always goes in CV to the next paragraph.

I'm afraid there's nothing to see in the code snippet.

The original was written in Scrivener, and I've had problems before exporting from that software so I export as RTF and then copied and pasted into LibreOffice Writer section by section as plain text (Shft+Ctrl+Alt+V) making sure that each Writer style was correctly applied to the document for each paragraph.

Each Writer style is mapped to the CSS style I want applied by edits in the plugin's config.xml file and this mapping has worked perfectly.

I've used this technique before with the earlier version of ODTImport_0.4.1.zip and never noticed these odd positioning problems nor the fact that a Crtl click on the HTML tag fails to open the style sheet.

[DiapDealer]

No message in Sigil's status bar when trying to launch the css file with ctrl+click?

Any chance of seeing the very top of the xhtml file? Say from the xml declaration down to the opening body tag?

[KevinH]

The snippet won't help as any error is probably before it. These problems are typically caused by incorrect code in CV that is removed or fixed by the internal parser that is built into Preview.

So make a checkpoint then run Mend. Our gumbo parser should make a similar change to the incorrect code that will enable CV to sync properly with Preview again. You can use the checkpoint diff to see what was changed. Many times this is bare code in the body or unrecognized tags in the body that are removed by Preview or cause the html p adoption routine to run.

[DiapDealer]

I can confirm that running Mend is enough to restore order here. At first glance, I can see a few things that come straight out of writer2xhtml that Mend needs to fix:

1) No xml declaration at the top of the xhtml (possibly the cause of the one-line-off cursor problem when syncing)

2) The links to the css files are missing the type="text/css" attributes. This is definitely why CTRL+Click does not think there are any stylesheets to open.

3) Consecutive spaces from Writer2xhtml are converted to non-breaking space entities by Mend. If there are enough of them, it could account for cursor line mismatches when syncing from Preview to Code View too?

[philja]

Thanks Kevin and DiapDealer - you're spot on.

I did as Kevin suggested: made a checkpoint and then ran Mend. The epub is only small, 11 xhtml files. Every one had the same defects as shown in the attached screenshot: missing XML statement; missing type="text/css" on the stylesheet link.

Don't know about 'consecutive spaces' but the problem with opening the stylesheet with Ctrl click on an HTML tag has been remedied by the Mend and the Preview and CV are now perfectly aligned.

Curiously, the first thing I did after ODTImport produced the epub file was to run the EpubCheck plugin. And I didn't get these problems with earlier versions of the plugin. (though that was a while ago).

This epub file still needs a load of remedial work and formatting issues - you see 'lang' is not defined and Ep[ubCheck doesn't care.

[KevinH]

Mend is really safe to use. I highly recommend setting your Preferences to Mend on Open and Mend before close. Mend does exactly the same thing as Preview and Web browsers do internally, so the final consumer of your epub is going to only see the the epub as parsed by its parser, so you probably want to see and work with the same thing in the code.