Updating ePub from updated HTML?

[FlaSheridn]

I’m working on a ePub from the Anglo-Saxon Poetic Records HTML files, and need to create a new ePub after updating the HTML. When I do this naively, the new ePub reflects the old HTML. The documentation says

“If you want to edit the input document a little before having calibre convert it, the best thing to do is edit the files in the input sub-directory, then zip it up, and use the zip file as the input format for subsequent conversions. To do this use the Edit meta information dialog to add the zip file as a format for the book and then, in the top left corner of the conversion dialog, select ZIP as the input format.”

That seems to assume you’ve used the debug option and want to tweak the intermediate output. (It also seemed to lose much of the structure, e.g., the output started with Beowulf, not the transcriber’s comments and table of contents.) Am I missing something?

[Starson17]

Originally Posted by FlaSheridn

[FONT="Times New Roman"]I’m working on a ePub from the Anglo-Saxon Poetic Records HTML files, and need to create a new ePub after updating the HTML. When I do this naively, the new ePub reflects the old HTML.

It shouldn't. You open the epub with the "T" Tweak option, edit and save, or open the EPUB file from the library with "O" and edit with Sigil. Either one changes the original. If you're working on a copy, then change the copy, open the record with "E" and drag the new version to overwrite the old EPUB. All of those should end up with the new version appearing in Calibre.

[FlaSheridn]

Originally Posted by Starson17

It shouldn't.

I’m afraid it does, but that seems to be a design decision rather than a bug.

Originally Posted by Starson17

If you're working on a copy, then change the copy, open the record with "E" and drag the new version to overwrite the old ….

Thanks, that did it. (I ended up overwriting the head HTML file (not named index.html); using the zip turned out oddly.)

[Starson17]

Originally Posted by FlaSheridn

I’m afraid it does, but that seems to be a design decision rather than a bug.

No it doesn't. It's true that Calibre doesn't overwrite an EPUB with a drag/drop, but you said you updated the HTML in the EPUB. There are several ways to update the HTML in an EPUB - I gave you several - but all of them result in the new HTML being used, not the old.

Thanks, that did it.

I'm glad it worked for you.

[FlaSheridn]

Originally Posted by Starson17

No it doesn't. … but you said you updated the HTML in the EPUB.

Oops, no I didn’t. I updated the HTML source files; they’re not mine, but they needed a lot of changes. I expected Calibre to notice the change in the source. I can accept that this is a design decision, not a bug as such, but I disagree with it.

[itimpi]

Originally Posted by FlaSheridn

Oops, no I didn’t. I updated the HTML source files; they’re not mine, but they needed a lot of changes. I expected Calibre to notice the change in the source. I can accept that this is a design decision, not a bug as such, but I disagree with it.

If you updated the HTML files in the Calibre library, but then want the change to be reflected in the ePUB files, you would have to rerun the HTML->EPUB conversion. There is a design philosophy that Calibre only makes changes to your files that you tell it to make.

[Starson17]

Originally Posted by FlaSheridn

I updated the HTML source files; they’re not mine, but they needed a lot of changes. I expected Calibre to notice the change in the source. I can accept that this is a design decision, not a bug as such, but I disagree with it.

Calibre did notice the change in the source files. If you'd viewed the html format, it would have shown the changes. It just didn't modify the content of your EPUB and that's because your EPUB format could have come from any one of a dozen or more different possible "source" files in the book record. They're all independent formats.

[FlaSheridn]

Originally Posted by Starson17

It just didn't modify the content of your EPUB and that's because your EPUB format could have come from any one of a dozen or more different possible "source" files in the book record.

Ouch. I see why that makes sense from the developer’s point of view, but from the user’s perspective it’s a serious design mistake, since in the base case there aren’t a dozen formats. The user has only used one input format; the rest are an internal implementation detail. It’s also a user interface bug, since it ends up requiring different actions to achieve the same result a second time. Even if it’s not fixed, both behaviors need to be documented conspicuously.

[Manichean]

Originally Posted by FlaSheridn

Ouch. I see why that makes sense from the developer’s point of view, but from the user’s perspective it’s a serious design mistake, since in the base case there aren’t a dozen formats. The user has only used one input format; the rest are an internal implementation detail. It’s also a user interface bug, since it ends up requiring different actions to achieve the same result a second time. Even if it’s not fixed, both behaviors need to be documented conspicuously.

It's not a design mistake. I have a device that supports ePub and one that supports Mobipocket. For some books, both formats are available from the publisher, in which case I get both if I intend to read on both devices. In this case, for a conversion to a third format, both would be valid source formats. I also disagree that every format except for the originally imported one are "internal implementation details". Instead, they are what you could call instances or implementations of the same book, consolidated in the logical book unit. Depending on the users intentions, which Calibre, as I'm sure you'll agree, cannot know, different source formats may be appropriate for different tasks. Calibre gives the user the freedom to choose the format instead of imposing an arbitrary "master" format.
Apart from that, I'm sure you'll find the conversion process quite well documented in it's behaviours. It was the last time I looked.

[Starson17]

Originally Posted by FlaSheridn

in the base case there aren’t a dozen formats. The user has only used one input format

You imply a connection source->converted format that you think should be long lasting, but which for most users is transitory.

Many times I need an EPUB format, an HTML format and a TXT format. If I don't have the EPUB format I may make it out of either the HTML or the TXT, whichever I think will get me closest to the desired EPUB, but I still usually need to edit the EPUB to create the final appearance that I want for that format.

The last thing I want is for Calibre to write over my tuned EPUB just because I later tweaked the TXT or HTML format for my other readers. Even if I started with the HTML as the "source" for my EPUB, it does not mean I want subsequent changes to that format reflected in my EPUB. If I do want them reflected, I can easily convert again.

IMO, permanent links between a source and a converted book are not desirable and I'm surprised that anyone would expect permanent links of the type you propose.

[DoctorOhh]

Originally Posted by FlaSheridn

Ouch. I see why that makes sense from the developer’s point of view, but from the user’s perspective it’s a serious design mistake, since in the base case there aren’t a dozen formats.

The only mistake here is responding to these messages using this small font. I don't know if it is an automatic function of your browser or you go out of your way to change the default font. You are the only one here that I see using a small font. Nevermind, I guess your just selecting a different font via the forum tool. You're welcome to do this but since it ends up with a reduced size font I won't be responding in the future.

Originally Posted by FlaSheridn

The user has only used one input format; the rest are an internal implementation detail.

Calibre is a ebook management tool not a content/document management system, there is a difference. If I want my epub edited, I edit my epub. It is extremely rare that the various formats I have for a specific book come from the same source file.

Originally Posted by FlaSheridn

It’s also a user interface bug, since it ends up requiring different actions to achieve the same result a second time. Even if it’s not fixed, both behaviors need to be documented conspicuously.

Again you're thinking of calibre as a content/document management tool, since calibre is not in the content management business there is no bug or requirement for documentation explaining why it doesn't do content management.

[FlaSheridn]

Originally Posted by FlaSheridn

from the user’s perspective it’s a serious design mistake, since in the base case there aren’t a dozen formats. The user has only used one input format; the rest are an internal implementation detail.

Originally Posted by Starson17

Many times I need an EPUB format, an HTML format and a TXT format. … but I still usually need to edit the EPUB to create the final appearance that I want for that format.

The last thing I want is for Calibre to write over my tuned EPUB just because I later tweaked the TXT or HTML format for my other readers.

Originally Posted by Manichean

I have a device that supports ePub and one that supports Mobipocket. For some books, both formats are available from the publisher, in which case I get both if I intend to read on both devices. In this case, for a conversion to a third format, both would be valid source formats.

These are hardly the base case.

If I do want them reflected, I can easily convert again.

Hardly easy for the normal user, since the interface obscures it and the documentation neglects it.

Originally Posted by dwanthny

Nevermind, I guess your just selecting a different font via the forum tool. You're welcome to do this but since it ends up with a reduced size font …

I selected Times New Roman from the font menu, leaving the text size at the default. If your browser can’t usably handle the most common real text font, you’ve got problems that transcend this discussion.

Originally Posted by dwanthny

You're welcome to do this but since it ends up with a reduced size font I won't be responding in the future.

Agreed.

[Manichean]

Originally Posted by FlaSheridn

These are hardly the base case.

Well, your concept of what a base case would be obviously differs from what the Calibre developers and most of the users have. Most people seem to be happy with the way Calibre works. It does it's job well. Thus, the base design choices won't change anytime soon.

I selected Times New Roman from the font menu, leaving the text size at the default. If your browser can’t usably handle the most common real text font, you’ve got problems that transcend this discussion.

It may be the most commonly used font for printed text. For on-screen text, I've almost exclusively seen sans serif fonts. Apart from that, I personally find it annoying to see font changes in the midsts of a text, which is what your use of Times NR causes. Also, the font is being rendered at a smaller default size, which doesn't improve readability...

[DoctorOhh]

You have still failed to understand that calibre is not a content management system, it is a ebook management tool and as such does not claim a base source and updated workflow to all documents.

This is not a bug or something that needs to be documented, if we documented everything calibre doesn't claim to do or plain can not do it would be a astronomically large manual.

Originally Posted by FlaSheridn

I selected Times New Roman from the font menu, leaving the text size at the default. If your browser can’t usably handle the most common real text font, you’ve got problems that transcend this discussion.

It may be the most common font style elsewhere but on this forum leaving the default font (whatever that is) is the most common and has Manichean stated the font is being rendered at a smaller scale, whether you use IE or Firefox. Being rendered as a font size so small does reduce readability for us old folks who use a liquid forum style to increase font size.