Sigil's Infamous "colon" Error on File Split

[slowsmile]

@Toxaris...Yes indeed I have known about this problem for ages. Just to also add that I knew about this fault years ago -- even before I knew about the existence of MobileRead forum. Why should I be able to report bugs when there is no link or clear reference for reporting bugs in the Sigil app? I'm talking about a newbie using Sigil here, not about developers.

The mistake you made was to rashly assume that everyone knows how to report Sigil bugs on MobileRead forum or Git. Really? How is it possible for any newbie(who is not a developer) using Sigil to report a bug when there is no clear and obvious path within the Sigil app for doing so?

Another tentative Sigil change request for KevinH. Could a direct link be put into Sigil's Help menu -- perhaps called 'Report Bugs' -- so that people can easily report Sigil bugs and problems? Hopefully this will satisfy Toxaris's unreasonable impatience concerning people's lateness in reporting bugs.

[Toxaris]

Originally Posted by slowsmile

@Toxaris...Yes indeed I have known about this problem for ages. Just to also add that I knew about this fault years ago -- even before I knew about the existence of MobileRead forum. Why should I be able to report bugs when there is no link or clear reference for reporting bugs in the Sigil app? I'm talking about a newbie using Sigil here, not about developers.

The mistake you made was to rashly assume that everyone knows how to report Sigil bugs on MobileRead forum or Git. Really? How is it possible for any newbie(who is not a developer) using Sigil to report a bug when there is no clear and obvious path within the Sigil app for doing so?

Another tentative Sigil change request for KevinH. Could a direct link be put into Sigil's Help menu -- perhaps called 'Report Bugs' -- so that people can easily report Sigil bugs and problems? Hopefully this will satisfy Toxaris's unreasonable impatience concerning people's lateness in reporting bugs.

Who is making assumptions here? Years ago the application was hosted on Google Code and it was very easy creating issues there. You needed to go there to get the latest version anyway. Also on Git, where currently the code and the latest versions are hosted, it is very easy to report a bug.

I am not impatient (nor unreasonable). I frankly don't care when you report your bugs. What I do care about is claiming a bug is 'infamous' when you are the only one that knew about it. A strong and harsh word that is not correct. If a bug is really bugging you that much, you would have found out how to report it. That is all I am saying.

[DiapDealer]

Originally Posted by KevinH

Checking if first digit is a number is quite easy and if so prepending a non-number will work just fine.

Is checking even necessary? if a uuid is guaranteed to be unique, then prepending any non-number to the value Utility::CreateUUID()'s returns would guarantee both uniqueness and a spec compliant id value, no?

Unless a non-standard uuid would break something somewhere else in Sigil, I'm thinking that changing Utility::CreateUUID() to the following would suffice:

QString Utility::CreateUUID()
{
    return "s" + QUuid::createUuid().toString().remove("{").remove("}");
}

Or it could be done in OPFResource::GetUniqueID() if keeping Utility::CreateUUID() pure is necessary.

QString OPFResource::GetUniqueID(const QString &preferred_id, const OPFParser& p) const
{
    if (p.m_idpos.contains(preferred_id)) {
        return "s" + Utility::CreateUUID();
    }
    return preferred_id;
}

[Doitsu]

Originally Posted by DiapDealer

Unless a non-standard uuid would break something somewhere else in Sigil, I'm thinking that changing Utility::CreateUUID() to the following would suffice.

Sigil uses UUIDs as the dc identifier:

<dc:identifier opf:scheme="UUID" id="BookId">urn:uuid:8dd87b4e-79e5-4713-87e0-ae7525ab2887</dc:identifier>

If you're pre-pending it with an "s", it won't be flagged by epubcheck but it's technically no longer a valid 128-bit hex value.

Might I suggest that you simply replace the first character of the generated UUID with an a, b, c, d, e or f?

[DiapDealer]

Originally Posted by Doitsu

Sigil uses UUIDs as the dc identifier:

<dc:identifier opf:scheme="UUID" id="BookId">urn:uuid:8dd87b4e-79e5-4713-87e0-ae7525ab2887</dc:identifier>

If you're pre-pending it with an "s", it won't be flagged by epubcheck but it's technically no longer a valid 128-bit hex value.

Might I suggest that you simply replace the first character of the generated UUID with an a, b, c, d, e or f?

Good point about the dc id. We could easily replace the first character, I'm just not sure if doing so will still guarantee uniqueness 100% of the time.

My second suggestion may still work--depending on how/where the BookID is generated. Otherwise, it may come down to checking the first character and regenerating a uuid until one that starts with a valid character is generated. I'm not crazy about that idea.

[Doitsu]

Originally Posted by DiapDealer

My second suggestion may still work--depending on how/where the BookID is generated. Otherwise, it may come down to checking the first character and regenerating a uuid until one that starts with a valid character is generated. I'm not crazy about that idea.

I haven't looked at the code, but there appear to be two different id generation methods.

1. If the user presses CTRL+ENTER a random uiid is used as the id for the second file.
2. If the user inserts a split marker with CTRL+SHIFT+ENTER and selects Split At Markers, the id of the next file will be Section0001_0001.xhtml, Section0001_0002.xhtml etc.

Would it be possible to re-use the id generation code from the Split At Markers code for Split At Cursor or would that cause all kinds of other problems?

[KevinH]

Hi All,

FYI, using a uuid to create a manifest id is just a quick and dirty way of generating a probabilistically unique id for a single epub (it need not be unique outside of this epub). If need be we simply prepend any non-numeric character and we are okay. I will prepend with an 'x'.

If we replace first character with a hex char in the a-f range you are reducing the probabilistic space by a factor of 5 / 16 (there are only 5 possible values for the first char, instead of the 16 expected.

For inside the epub use (ie manifest ids) we simply prepend an a character if need be.

As Doitsu pointed out, there are other places where generating a probabilistically unique id in an exact uuid format is needed and I do not want to confuse the two nor limit its space of possible values as any change will increase the likelihood of an external collision (no matter how small).

I will fix this tonight when I get out of work and get a free minute.

Thanks,

KevinH

[HarryT]

Originally Posted by slowsmile

@Toxaris...Yes indeed I have known about this problem for ages. Just to also add that I knew about this fault years ago -- even before I knew about the existence of MobileRead forum.

So you assume that if you discover an obscure bug it's "infamous" and everyone else knows about it?

The Sigil developers are good, but they can't fix bugs whose existence is unknown to them.

[KevinH]

FYI,
Pushed a fix for this that prepends an "x" since these are only for "unique" manifest ids used only for this case. The change all fits on the same line and so will not mess up any translation information hopefully currently being updated by translators on transifex. It also will not reduce or restrict the space of probabilistic uniqueness provided by any uuid.

KevinH

[DiapDealer]

Thanks, Kevin!