Found two bugs -- Related?

[eggheadbooks1]

Originally Posted by DiapDealer

You're not listening. You splitting a file named Section000x.html with the Split at Cursor feature IS the situation. It IS present.

Attached are two screenshots of ePubs made with earlier versions of Sigil. In both instances I used the Ctrl+Enter shortcut to split my files. If that is the "situation," then please tell me why Section0001 is still ID'd as Section0001 in these earlier ebooks.

And why, in the new version, do the IDs for Section0002, Section0003 and so on remain intact yet Section0001 is re-IDed? What is the difference between those older files and this new file? And what is the difference between splitting Section0001 and Section0002, etc. using the Split at Cursor method, because it's the same method but different result.

BTW, I did try reinstalling. The plugin manager autopopulated (which I don't think is a bad thing, though apparently unintended), the situation with the Content.opf has remained unchanged, and I'm still getting a Python error when re-merging.

[eggheadbooks1]

Originally Posted by KevinH

Perhaps you are confusing Split at Marker vs Split at cursor or used to simply used to insert Split marker?

I've never used the Split at Marker option, always the Split at Cursor.

[Toxaris]

Not to be blunt, why do you care what the ID is? It is only used internally. No user is going to see it and editors should almost never have to change it or even use it.

[KevinH]

If you split a file you are creating two pieces from one file. If that file has the name "Section0001.xhtml" and you split at the cursor, the file name 'Section0001.xhtml" is already being used and so is not a valid id for the newly created section. This is especially true if 'Section0002.xhtml' already exists as well.

So under these circumstances Sigil will generate a uuid with an "x" prepended to it to make it a valid unique id instead of trying some variation of 'Section0001.xhtml' and 'Section0002.xhtml' ... that could already exist.

KevinH

Originally Posted by BetterRed

Maybe it would be less confusing if the manifest id was always an 'x' preceded uuid when a split at cursor was used.

BR

[eggheadbooks1]

Originally Posted by Toxaris

Not to be blunt, why do you care what the ID is? It is only used internally. No user is going to see it and editors should almost never have to change it or even use it.

Because I would like to UNDERSTAND, rather than just be told that's the way it is, especially when it doesn't appear logical to me.

And don't forget I'm getting a Python error. Perhaps this ID change is related to the Python error when I try to re-merge? I had never seen this error before when re-merging, just as I have never seen the renaming of the ID before. Coincidence?

Does this ID change to Section0001.xhmtl happen on other systems like Linux or Mac, or even Windows 32-bit? Perhaps ... just perhaps ... when the X was added to the ID for the Split at Cursor method, a line of code was accidentally malformed in the Windows 64-bit version?

Or maybe this has something to do with the version of Visual C++ that I had to install to use this latest version of Sigil? Would it help at all to uninstall/reinstall that?

To reiterate, I'm on Windows 64-bit Professional SPK1.

[eggheadbooks1]

Originally Posted by KevinH

If you split a file you are creating two pieces from one file. If that file has the name "Section0001.xhtml" and you split at the cursor, the file name 'Section0001.xhtml" is already being used and so is not a valid id for the newly created section. This is especially true if 'Section0002.xhtml' already exists as well.

Which I understand. But when Section0002 doesn't yet exist, why would Section0001 be re-ID'd?

And why does it only happen to Section0001?

You guys say this is normal, but if so then it would happen to ALL the sections when split at cursor, not just one. So something weird is going on. As I indicated in my last post, perhaps this is related to either the Visual CC++, or to the Python error, or...? Because I'm not just having the one issue.

I will also try recreating the file right from scratch and see if the same thing happens.

[MickiTee]

Originally Posted by JustinThought

I work exclusively on Windows, and I had seen that as well. I found that just by re-opening the e-book, the symbol comes back. So I assume it's a display problem only.

I'm seeing this as well on Windows. It seems to correct itself i.e. the icons reappear, if you perform an action (delete file) which forces the Book Browser to refresh its data. I've also noticed that occasionally it corrects itself after a Save.

[BetterRed]

Originally Posted by KevinH

If you split a file you are creating two pieces from one file. If that file has the name "Section0001.xhtml" and you split at the cursor, the file name 'Section0001.xhtml" is already being used and so is not a valid id for the newly created section. This is especially true if 'Section0002.xhtml' already exists as well.

So under these circumstances Sigil will generate a uuid with an "x" prepended to it to make it a valid unique id instead of trying some variation of 'Section0001.xhtml' and 'Section0002.xhtml' ... that could already exist.

KevinH

Kevin - I'm not sure you understood - what I suggested is that when a split at cursor is done the new manifest ID would always be an 'x' preceded uuid, irrespective of what file name is used or already exists.

In other words there will never be an apparent nexus between what's in the manifest id and what's in the href.

BR

[KevinH]

Hi,
I would be okay with that but uuid's are even longer than many file names. So I would like to keep whatever is there and only revert to uuids for ids when the tested for names actually already exists.

The change is not recent but some older versions did not previously do this according to now multiple reports, so I would like to figure out why this is happening and when it first changed. And see if I can get back the old (pre 0.8.X?) behaviour.

Thanks,

KevinH

Originally Posted by BetterRed

Kevin - I'm not sure you understood - what I suggested is that when a split at cursor is done the new manifest ID would always be an 'x' preceded uuid, irrespective of what file name is used or already exists.

In other words there will never be an apparent nexus between what's in the manifest id and what's in the href.

BR

[DiapDealer]

Originally Posted by eggheadbooks1

And don't forget I'm getting a Python error. Perhaps this ID change is related to the Python error when I try to re-merge? I had never seen this error before when re-merging, just as I have never seen the renaming of the ID before. Coincidence?

Yes. It's a coincidence.

I've finally been able to consistently recreate the Python error when merging two files. And it IS unrelated. We'll get on that. It's not new to this version either. I can make the Python error happen with 0.9.6, as well.

In short, the Python error only happens when the OPF tab is open when you merge files. If the OPF tab is not open ... no Python error when merging. Thanks for reporting it.

[BetterRed]

Yes that would be better, consistency is what I was looking for. Although I find something like the following, irrespective of context, always makes me wonder - is it a coincidence that they're the same token, or is it because they have to be

<item id="somefilename" href="Text/somefilename.html" media-type="application/xhtml+xml"/>

Assuming the id only has to be unique within the document, would it be possible to generate a short random token to use as the id. Many (most ?) Sigil users would not be as intimate with the specs as yourself, DiapDealer, Doitsu etc, so we tend to notice apparent anomalies and coincidences. To which we then attach great significance, inconsequential tho' they may be

All of that said, I almost always use Split at Markers option.

BR

Originally Posted by KevinH

Hi,
I would be okay with that but uuid's are even longer than many file names. So I would like to keep whatever is there and only revert to uuids for ids when the tested for names actually already exists.

The change is not recent but some older versions did not previously do this according to now multiple reports, so I would like to figure out why this is happening and when it first changed. And see if I can get back the old (pre 0.8.X?) behaviour.

Thanks,

KevinH

[DNSB]

If you are really upset over the uuid not matching the filename. simple rename Section0001 to Section001 and then rename it back to Section0001.

I will admit that I seldom look at the contents of content.opf unless FlightCrew or EpubCheck complain so not a big deal to me.

[DiapDealer]

Even though the uuid id fail-safe generation is not bug, it has been determined that older Sigil Series' (0.8.x, 0.7.x) handled this specific scenario (using Split at Cursor to split Section0001.xhtml) differently. So in light of that, we've committed a change to Sigil's master repository so that splitting Section0001.xhtml (at a cursor) will behave like the older Sigil Series' did.

NOTE: the uuid id fail-safe generation code is still in place, and can still be triggered under rare conditions. But you'd probably have to try pretty hard to encounter one (i.e. renaming Section0001.xhtml to Section0003.xhtml; manually changing the id/idref in the OPF's manifest/spine to Section0001.xhtml, and then splitting Section0003.xhtml at a cursor). That behavior is designed and expected to ensure uniqueness and won't be altered.

The Python errors reported have also been tracked down and a potential fix has been committed. The above two issues were unrelated and not new to Sigil v0.9.7.

As of yet, the disappearing icon in the Book Browser is assumed to be a new, cosmetic-only Qt5 quirk. I tested Sigil on Windows with Qt5.6.2 and the issue was still there. If a workaround can be found, it will certainly be employed. But for now ... it is what it is.

Thanks for the reports.