Sigil-0.9.991 (1.0 Pre-release)

[KevinH]

I just made a commit to master to hopefully fix this.

Originally Posted by DiapDealer

The default value in SelectHyperlinks seems to includes some extra prefixing (OEBPS on an epub with the Sigil standard structure) that can show an incorrect href in EditTOC if the OK button is hit. Look likes it's entirely cosmetic though. The correct link/href seems to be added to the ncx regardless.

[KevinH]

Yes, this is the invalid mediatype your epub opf used for its page-template file.

else if (m_MediaType == "application/oebps-page-map+xml")  {
            routine = "performPageMapUpdates";

Adobe page maps are supposed to use the mediatype as above.

Since, the extension is "xml", Sigil can not use the extension to lookup a mediatype. So if you do a rename or move, Sigil is warning you it has no understanding of what this mediatype is and therefore can not look inside the file to update any links after a rename or move.

You should fix your OPF to use the correct mediatypes especially for .xml files that you can not derive a mediatype.

KevinH

Originally Posted by snarkophilus

Now that I've interrupted the flow of this thread with a different issue, any thoughts on the popup I get with my funny unsupported media type popup in this message https://www.mobileread.com/forums/sh...71#post3916771?

[DiapDealer]

Originally Posted by snarkophilus

Now that I've interrupted the flow of this thread with a different issue, any thoughts on the popup I get with my funny unsupported media type popup in this message https://www.mobileread.com/forums/sh...71#post3916771?

I think the point was to be able open such epubs successfully without crashing. I would think that anyone who got such a popup later would look to fix the incorrect media-type, no?

[snarkophilus]

To be clear, there's no crash. So all good there.

Should the pop up say something like "Adjust the OPF entry for this file" or similar? At the moment, the popup doesn't say which file is at fault.

I guess the counterintuitive part of this (to me at least!) is that Sigil doesn't indicate that there's a problem with the offending file until you get a message about it if you rename an unrelated file.

[KevinH]

Yes, Sigil is not a validator. Run epubcheck if you want that. Sigil doesn't need to use that mediatype until it has to update links because of a rename or a move. If you do not do either, the broken media type is just that. However once you rename or move, Sigil will be unable to update links in that file because it does not know what type of xml file it is.

Again, there is the only one place mediatypes are set, and that is in the OPF manifest. So if you see an unrecognized mediatype error message you should know to fix your OPF.

I am sure someone could easily create a plugin to validate all of the mediatypes in the opf against the file extensions and warn you about it. With .xml files that gets a bit hard but doable.

That said, only someone who knows what the contents of the xml is for, would know the correct way to fix it.

I will think about a mediatype checker plugin after Sigil 1.0 goes final.

KevinH

[KevinH]

Actually, in ImportEPUB while parsing the OPF, I could maybe check each manifest item mediatype one by one and create a load warning when either unrecognized or mismatch between the extension and mediatype exist.

I will look into that.

[oteksamptis]

From my point of view, these changes are not very applicable. Sorry.
I would be much more happy with:
1. Adding a dialog to the menu or something similar to Clips with the currently edited Stylesheet.
2. In Preview, the name of the previewed file could be useful. When I have many files open at the same time (e.g. during search and replace), sometimes I don't know what I'm looking at.
3. set Case tool and set Header level - The old solution was more ergonomic.

[KevinH]

If you are talking about BookView going away, this is not a thread about that decision, as that is cast in stone and happened about 5 releases or so ago.

This thread is about changing Sigil to not force epubs into Sigil's preferred form that we are currently in an alpha release.

Please stay on topic for this thread. To make things clear - No changes to the header tool, or case tool will be made, no file name is needed on Preview as it always shows the last html tab resource (so just look at your tab name in CodeView), etc.

[Tex2002ans]

Originally Posted by snarkophilus

I use the TOC editor reasonably often, [...] If I want to change the identing (eg chapters of parts) sometimes it's easier to do this in the TOC editor too [...]

Yep, another nice thing about Edit TOC is it doesn't actually change the heading tags like Tools > Generate Table of Contents.

Like Intros/Appendices/Indexes:

- <h2>Introduction
- <h1>Part 1
--- <h2>Chapter 1
- <h1>Part 2
--- <h2>Chapter 2
- <h2>Index

If based purely on headings, Index automatically gets put under Part 2.

It's also good for adding extra non-heading things like Dedication, Copyright Page, Backmatter... (Not that I would want that cluttering up the TOC... but some publishers want that nonsense! :P)

And I've recently ran across a Kindle issue with 3-level deep TOCs... so yeah, it's helpful to adjust levels in the TOC without actually having to change underlying code in Code View.

Originally Posted by KevinH

no file name is needed on Preview as it always shows the last html tab resource (so just look at your tab name in CodeView), etc.

Couldn't this be added to the Title Bar of the Preview window? Maybe right next to where it displays the resolution.

Current:

Preview (800x1000)

Potential:

Preview (800x1000) - Chapter01.xhtml

Preview is usually on the complete other side of the screen (or secondary monitor). Would be nice to have filename located there too.

Originally Posted by oteksamptis

3. set Case tool and set Header level - The old solution was more ergonomic.

I agree on that one.

Rarely used, but was easy in one mouse-press.

I'm mostly indifferent to the headings change, because I've been using keyboard shortcuts for years (Ctrl+1-6 for headings, Ctrl+7 for <p>).

The Title Casings though... it's an extra button click. :P

What's next, 4 Alignment buttons going to be put in its own dropdowns too?

oteksamptis Note: If you use it often, Title Casing can get their own shortcuts assigned. Here's the defaults:

• Lowercase (Alt+L)
• Uppercase (Alt+U)
• Titlecase
• Capitalize

[KevinH]

Again, please stick to the thread topic. We are not debating changes made up to 5 releases ago in this thread.

[democrite]

I haven't yet used the beta though I am wondering about something. Due to the changes, has another related change been made to links to files in the same folder? e.g., before all links were "../Text/…"; that can add a fair amount to the size of a file and I always before changed that after each edit. With this release if it hasn't been done already, maybe it is a good idea to use such a path only when needed.

[snarkophilus]

Originally Posted by KevinH

Sigil doesn't need to use that mediatype until it has to update links because of a rename or a move. If you do not do either, the broken media type is just that. However once you rename or move, Sigil will be unable to update links in that file because it does not know what type of xml file it is.

I don't think I clearly explained what I meant by the rename or move scenario. If I rename any file in the epub, I get a popup that just says:

Unsupported XML media-type: application/vnd.adobe-page-map+xml

That doesn't tell me which file in the epub doesn't have a valid media type.

Your proposal of checking each file on load/import and popping up a warning on load sounds like the best fix. If that proves to be not too easy, can you please reference the offending file's name in the popup so the user at least knows which file that they need to adjust?

[KevinH]

Yes renaming or moving any file means checking and updating any links to it in *all* files. It will not matter what you tried to rename or move.

Why can't the user just look in their OPF manifest for that mediatype. How is one character string to look up in the OPF (filename) any more useful than another character string to lookup (mediatype)?

[KevinH]

Yes, those types of links will no longer be generated by Sigil in Sigil 1.0. That said, if a link like that already exists, Sigil will not touch them as they are valid links.

Originally Posted by democrite

I haven't yet used the beta though I am wondering about something. Due to the changes, has another related change been made to links to files in the same folder? e.g., before all links were "../Text/…"; that can add a fair amount to the size of a file and I always before changed that after each edit. With this release if it hasn't been done already, maybe it is a good idea to use such a path only when needed.

[DiapDealer]

Originally Posted by KevinH

Why can't the user just look in their OPF manifest for that mediatype. How is one character string to look up in the OPF (filename) any more useful than another character string to lookup (mediatype)?

Or just run EpubCheck. That will give them more precise info about where the problem lies. It will take them to the exact line in the opf.