Help Please -Problem

[Thasaidon]

Originally Posted by KevinH

As DiapDealer said. Thank you for your scrambled test case. Using the very latest build, I was easily able to open this epub in Sigil.

BTW, it still gave warnings but these are real warnings related to wrong media types for ttf fonts that have nothing to do with the extra namespace ns0: in the OPF.

The opf is now properly cleaned up on load.

So we should be good to go with the next release.

Thanks,

KevinH

ps here are those warnings:

Thank you.

Glad to be of service.

With regard to the

The OPF uses an unrecognized media type "application/octet-stream" for file "LiberationSerif-Regular.ttf" - A temporary media type of "font/ttf" has been assigned. You should edit your OPF file to fix this problem.

problem. I know about this and routinely fix it when it crops up.

The OPF is one file I need to know more about. I understand the basic structure but I do not know the fine detail. How "nsO: was being used meant nothing to me.

[KevinH]

FWIW, pure xml allows any tags and attributes anyone would want. The problem is that two or more xml projects/language variants could use the same name for different tags that mean different things. And worse yet these names could needed to be used in the same xml file. So xml adopted the use of namespaces and these namespaces had to be unique so they decided to use a url/uri to represent them since no two different websites could have the same url. (These urls need not point to functional web pages but sometimes do).

The idea was to prefix each tag with its associated project namespace (url).. However that is too cumbersome in practice and shorter namespace prefixes were used instead. Things like opf: and dc: and even ns0: are examples of these shorter namespace prefixes.

Each prefix needs to be defined by using an xmlns attribute hopefully in the root tag and where else needed by using the xmlns attribute.

So the attribute: xmlns:opf="http://www.idpf.org/2007/opf" is often seen in opf files to define the namespace associated with the opf: prefix.

To make notation even shorter a tag can define a default namespace that tells you that all tags without prefixes are using this namespace. For example:
xmlns="http://www.idpf.org/2007/opf" means that the tags in the opf namespace do not need a prefix at all.

Your epub opf defined an uncommon prefix (ns0:) for tags in the opf namespace and then needed to prefix all tags with ns0: as a result.

This made the opf much more cumbersome than usual.

Sigil's code knows the urls associated with epub namespaces and now properly simplifies (cleans) them down to the most compact (typical) form so that they can be more easily be read, written, and parsed.

Hope something here helps.

[DNSB]

Originally Posted by KevinH

Sigil's code knows the urls associated with epub namespaces and now properly simplifies (cleans) them down to the most compact (typical) form so that they can be more easily be read, written, and parsed.

Hope something here helps.

Oh, ghod! A return to the days when Sigil automatically changed the directory structure of an epub to it's standard layout.

Which I admit to still doing a lot of the time.

[DiapDealer]

Hardly a "return." Sigil has never really stopped ensuring that the opf is in state that Sigil can properly parse. Nearly every aspect of Sigil's automated processes are predicated upon the opf being in a state that's both valid (RE spec) and useable by Sigil's parsing routines.

The OPF is one of the few places where Sigil's wishes may still trump the user's. Just hopefully only in minor esoterica like this example. I've not run into too many ebook creators who have an interest in preserving technically correct, but functionally purposeless namespace prefixing schemes. *shrug*

I know you were probably posting in a primarily ironic manner. but I wanted to be sure people understand that Sigil's move towards a "hands off" approach does not extend to every single aspect of the OPF.

With regard to the uncommon prefixes in this test sample, I believe I've seen those ns0, ns1 prefixes introduced by lxml parsing where no attempt to properly manage the namespace prefixes is made. Probably some sort of in-house automated script that no one has ever revisited since epubcheck doesn't bark about it.

[DNSB]

Originally Posted by DiapDealer

I know you were probably posting in a primarily ironic manner. but I wanted to be sure people understand that Sigil's move towards a "hands off" approach does not extend to every single aspect of the OPF.

The post was not meant to be taken seriously. If only MobileRead a set of tags for sarcasm, irony, etc.

Originally Posted by DiapDealer

With regard to the uncommon prefixes in this test sample, I believe I've seen those ns0, ns1 prefixes introduced by lxml parsing where no attempt to properly manage the namespace prefixes is made. Probably some sort of in-house automated script that no one has ever revisited since epubcheck doesn't bark about it.

I've had to clean up a couple of opfs that used namespaces that were not properly managed so I have no objection to Sigil doing the clean up for me as long as I am informed that it was done.

[BetterRed]

Originally Posted by DNSB

The post was not meant to be taken seriously. If only MobileRead a set of tags for sarcasm, irony, etc.

🙃 works for me.

BR

[Thasaidon]

Originally Posted by KevinH

FWIW, pure xml allows any tags and attributes anyone would want. The problem is that two or more xml projects/language variants could use the same name for different tags that mean different things. And worse yet these names could needed to be used in the same xml file. So xml adopted the use of namespaces and these namespaces had to be unique so they decided to use a url/uri to represent them since no two different websites could have the same url. (These urls need not point to functional web pages but sometimes do).

The idea was to prefix each tag with its associated project namespace (url).. However that is too cumbersome in practice and shorter namespace prefixes were used instead. Things like opf: and dc: and even ns0: are examples of these shorter namespace prefixes.

Each prefix needs to be defined by using an xmlns attribute hopefully in the root tag and where else needed by using the xmlns attribute.

So the attribute: xmlnspf="http://www.idpf.org/2007/opf" is often seen in opf files to define the namespace associated with the opf: prefix.

To make notation even shorter a tag can define a default namespace that tells you that all tags without prefixes are using this namespace. For example:
xmlns="http://www.idpf.org/2007/opf" means that the tags in the opf namespace do not need a prefix at all.

Your epub opf defined an uncommon prefix (ns0 for tags in the opf namespace and then needed to prefix all tags with ns0: as a result.

This made the opf much more cumbersome than usual.

Sigil's code knows the urls associated with epub namespaces and now properly simplifies (cleans) them down to the most compact (typical) form so that they can be more easily be read, written, and parsed.

Hope something here helps.

Thank you.

That is one more step on my journey to learn about the OPF file and ePubs.

I bet just when I think I have learned all that is necessary it all changes.