Robustness

[DiapDealer]

Originally Posted by elibrarian

which loads the imagefile nicely as well when using File Open, but *not* when rightclickling "Text" and Add file. (Well, the imagefile is loaded, but not shown. It seems, that the File Open procedure corrects the internal links to the css and imagefiles, and the rightclick and Add-file leaves them as-is)

I can verify the metadata issue. File Open does load the existing metadata where Add Existing File does not. I wasn't aware of that.

But "Add Existing File" does correct internal links in CSS and for image files. I do it all the time. I haven't tested with your example, but maybe it's just not adjusting the xlink:href on SVG image statements after importing the image. Maybe a bug. UPDATE: Even the SVG image statement worked for me as expected using Add Existing File. It imported the image and properly corrected the xlink:href attribute. Just like File Open does. *shrug*

But regardless... I agree that if it's working in a way that people are relying on, it shouldn't be messed with.

[elibrarian]

Originally Posted by DiapDealer

But "Add Existing File" does correct internal links in CSS and for image files. I do it all the time. I haven't tested, but maybe it's just not adjusting the xlink:href on SVG image statements after importing the image. Probably a bug.

You're right, tried it again (multiple times), and it worked. I don't have any idea why it didn't work the first time around.

Regards,

Kim

[DaleDe]

Originally Posted by elibrarian

You're right, tried it again (multiple times), and it worked. I don't have any idea why it didn't work the first time around.

Regards,

Kim

One reason might be if you had done something earlier. I have found that only the first import fixes the reference to CSS etc. Subsequent ones do not but I wish they did.

Dale

[meme]

Can you be more specific about what you mean by the first 'import' (open/add of same file/new file) and what works the first time then doesn't? If you have a sample zip of some file/css/images that'd help.

This is one of the reasons the consideration of Open came up. If you "Open" an HTML file, the metadata is loaded, but if you "Add Existing" an HTML file, the metadata is ignored (but the code originally suggested this should work so questions were asked). This appears to be reasonable behaviour, if undocumented. It might be that changing it so that "Add Existing" should load metadata as well - but that would have to avoid overwriting existing data and it may not be what people are expecting? Thoughts on whether it should behave as is, or be looked at to make "Add" also import metadata?

As for correction of links behaving differently, I need to look into this more to compare Open/Add and initial load/subsequent loads. There was a bug about removing filenames that has a fix, but has to be checked using Open/Add to avoid breaking something, and it may or may not be related to the css/image linking mentioned above.

[DaleDe]

what I mean is that the CSS reference is fixed on the first import but not subsequently. As the first time the CSS is copied as well but not afterwards and for that reason the CSS location in the html file is not fixed. I can't remember what else is different.

[JimLL]

Originally Posted by Hitch

Yes--because Sigil does NOT save html. If you are determined to "only" work in html, then you should be using a plain old html editor, doing your html work in that, and then importing your html into Sigil. Sigil is not an "html" editor; it is an ePUB creation tool that ONLY saves ePUBs. This means nothing more than you have to save it ONCE, as an ePUB, and then continue on, hitting save whenever you wish.

First, I am not an HTML programmer and am not determined to use HTML or whatever variations of HTML are out there. But the loaded XYZTML-whatever is altered in order to put out, via Sigil code, the epub. So it seems to me to be common sense that if something happens to the epub file it wouldn't make any sense at all to have to go back to the originally loaded HTML and start from scratch when a very simple HTML save would obviate the need. Of course there will always be those who say no such problem could arise. That's a lot like being told by a clerk that computers never make mistakes.

Actually, xhtml is the "basis" of ePUBS. Again, if you are, for some inexplicable reason, bound and determined to

Interesting little assumption you've got going there.

I don't know xhtml from qwhtml. I'm just seeing an easy fix to a possible problem and a lot of people "bound and determined" to maintain the status quo.

[Elfwreck]

Originally Posted by JimLL

I don't know xhtml from qwhtml. I'm just seeing an easy fix to a possible problem and a lot of people "bound and determined" to maintain the status quo.

I know nothing about xhtml, except that if you take a fairly plain html file, and rename it xhtml, you can import it to sigil without problems.

Presumably the difference is in options that aren't particularly relevant to most ebooks.

[JimLL]

Originally Posted by meme

This is one of the reasons the consideration of Open came up. If you "Open" an HTML file, the metadata is loaded, but if you "Add Existing" an HTML file, the metadata is ignored (but the code originally suggested this should work so questions were asked). This appears to be reasonable behaviour, if undocumented.

Since I'm the OP here I don't suppose it would hurt to ask a question about your above reply. It sounds related to something I've run into.

I don't really know if it is "kosher" to paste text into the Sigil window. Nor do I know how I would look it up.

At any rate, I have done it with varying results. Taking text from a separate document with no font formatting other than bold chapter headings, I am seeing odd displays of font. Some normal (not header) lines are bold, some are not, some are sized larger than others - a variety. This is part of what I referred to earlier as quirky.

This next probably doesn't sound "similar" to you as programmer, but it is similar in screen appearance.

Sometimes when I load an HTML file and start putting Header1 "marks" in, it ends up with the headers (Chapter 1 etc.) in the same font and size as the text only bolded.

Sometimes I lose the header mark and have to set it again - whereupon the header font jumps up 2 or 3 sizes.

Other times, when loading an HTML similarly and adding header1's the end result of it will be that the header font pops up in 16 or 20 size. "Remove formatting" the header makes the font smaller, but does not take it down to match the normal text font size.

(I don't really know what remove formatting is actually supposed to do, because searching Helps gives me nothing.)

These mixed results with fonts makes things pretty iffy/quirky. How do I know what will come out of it in the end if it varies on the screen?

[Hitch]

Originally Posted by JimLL

First, I am not an HTML programmer and am not determined to use HTML or whatever variations of HTML are out there. But the loaded XYZTML-whatever is altered in order to put out, via Sigil code, the epub. So it seems to me to be common sense that if something happens to the epub file it wouldn't make any sense at all to have to go back to the originally loaded HTML and start from scratch when a very simple HTML save would obviate the need. Of course there will always be those who say no such problem could arise. That's a lot like being told by a clerk that computers never make mistakes.

Interesting little assumption you've got going there.

I don't know xhtml from qwhtml. I'm just seeing an easy fix to a possible problem and a lot of people "bound and determined" to maintain the status quo.

Sigil doesn't save as html simply because it checks for, and saves, VALID ePUBs--not html files. That's the entire story. Whether you want to work in html, xhtml, etc.--you seem to be missing the point. All I said was, if you want to work in html, use an html editor, which Sigil isn't. This is simply square peg-round hole-ing. Does it make sense that if you want to work in html, you'd use a tool designed for html? Sigil isn't. That's all I meant. Otherwise, you upload html and what you "save as" is an ePUB. Not html. If you've read the thread, you'll see that there are a number of very good reasons why it saves as an ePUB, all of which are part of its basic functionality. It's not an "easy fix," unless we all think that throwing out Sigil's essential validity-checking is a good idea, which I suspect most of us don't. It has nothing to do with maintaining the "status quo;" everyone around here contributes, one way or the other, to improving Sigil all the time. If enough OTHER people and users agree with you, then generally speaking, if it's possible, user_none, meme, etc., will make a change to the program--but thus far, it doesn't seem like anyone but you thinks that this is a big issue.

And your snarkiness on the topic seems utterly disproportionate to the issue at hand. Want html? Use an html editor. Want an epub? Use an ePUB editor. Conflating them simply confuses the issue. In the alternative, maybe you'd be happier with Jutoh or Calibre, or, I suspect, AWP (Atlantis Word Processor). Then you really don't need to use html at all.

Lastly, you haven't explained, at ALL, why saving as an ePUB--which is nothing more than a bunch of zipped xhtml/html files--is such a big problem for you. So you save as an ePUB and keep working in Sigil? What, exactly, is the actual issue that this causes for you? You don't have to "go back to the original html" at all, after saving the epub, so, can you explain why this is so problematic? Save and keep editing. if you need to extract the file and put it back in an html editor, for whatever reason, simply explode the epub and grab the file you need and drag it into your html editor, OR, work in Sigil, OR, work in "tweak ePUB" in Calibre, depending upon your skill level. I don't think anyone understands--I certainly don't--why you find saving the file as an ePUB such a large hurdle, or how it negatively impacts your workflow.

Good luck.
Hitch

[JimLL]

Originally Posted by mrmikel

As unreasonable as JimLL is,

Exactly what is unreasonable about a couple lines of code that will do what I explained could be a backup to epub?

As for complaining about something that is free, aimed at pros and semi-pros and that no one is forcing you to use, that is an entirely different issue.

I gave up on that old saw years - decades ago. If you can't run with the big dogs stay on the porch. I have written some free software. I worked with people who wanted more in it. Free isn't an excuse, and I doubt many programmers would want to use it as such.

[JimLL]

Originally Posted by Elfwreck

I know nothing about xhtml, except that if you take a fairly plain html file, and rename it xhtml, you can import it to sigil without problems.

Presumably the difference is in options that aren't particularly relevant to most ebooks.

I haven't read this whole board, because I'm a slow reader and a quick forgetter. But I don't know what you mean by having problems loading HTML. Does something bad happen if there is no X on it? Is there something great added if you do put X on it? Is there a notice in Sigil somewhere telling about that? Or are you left in the dark if you aren't an old timer here?

[JimLL]

Originally Posted by Hitch

You don't have to "go back to the original html" at all,

1. If you don't know that things happen with computers, you haven't been in it very long.

after saving the epub, so, can you explain why this is so problematic?
Hitch

2. I'm completely in the wrong place here. I've not said anything unreasonable or untrue. I've never said a small feature is a "so problematic." I didn't realize that nothing could be done unless something was "so problematic." Small things are scoffed out of town - AFTER mere mention of them is blown out of proportion by the scoffers.

3. Sigil DOES have a quirky display. But I guess that's because it's free.

4. FREE? I made my donation before I ever posted here. I guess that's so problematic too.

[theducks]

@jimLL

html is a component of EPUB.

Your complaint is like expecting the chips that were soldered on to the Motherboard to still be just 'chips' afterwards. They are not, they are now part of something bigger (and hopefully better).

Why are you not complaining about being able to save as a JPG? You can add Pictures to your Sigil EPUB.


Notepad++ is a Free HTML (and other) code editor if you need one.

I was never satisfied with the WYSIWYG editors when I started playing with HTML(3), and never bothered since, to try and use them for my main editing mode. Sigil allow me to (mostly) check my work and is a convenient way to break or join paragraphs. For all else, I usually work in CV.

[Toxaris]

Originally Posted by JimLL

I haven't read this whole board, because I'm a slow reader and a quick forgetter.

That is almost saying it all. You don't really explain why you think it is an easy fix or why it actually should do that. You complain about a feature which is not implemented easy and you ignore everyone that is explaining why. You seem 'bound and determined' to prove a point which is not there.
Various people have explained several times that the reason is that Sigil is an ePUB editor, not an HTML editor. To make it more easy for its users, Sigil allows import of HTML. After the import, the HTML is essentially gone. It is part of the ePUB. And, don't forget, since usually an ePUB contains several XHTML files, which one to autosave?
Autosave of the ePUB is very hard to do, since Sigil only allows structurally correct ePUB's. Due to the fact that ePUB is very flexible, it is very easy being temporary in a state where the ePUB is not structurally correct because you are working on the file. I think it is one of the strong points that Sigil only allows to save structurally correct ePUB's and I would definitively not have it sacrificed for an autosave.

That being said, the other point you mention is about layout and copy/paste. Copy/paste from one program to the bookview of Sigil can be cumbersome. The results may not be what you want. I don't know why, but I assume there are several reasons for that. I use (x)HTML as input.
If you change text to headers or back to text in bookview will cause Sigil to use the defined stylesheet for the layout. If you have not assigned a stylesheet, the default HTML style is applied for headers and so on. Those are the same as in browsers. If you want to change the layout, change it in a stylesheet and apply that stylesheet. As far as I know, that can only be done in Codeview.

[Perkin]

Using Sigil is like baking a cake, you assemble the ingredients (html/stylesheets/images/fonts) and output a cake (epub), when you made a cake, you can't usually then get the ingredients back.

But if you really want the individual html (that has been altered to work IN the epub) you can open the epub with a zip program and extract the relevant files, any html etc will be altered to have any links etc. relevant to other files as though it was in a structured epub, NOT as if it was a flat html.

Does that make sense?

Saving as html from Sigil is irrelevant and would cause further bug/error reports which aren't Sigil's fault because the files are to be used INSIDE an epub.

If you want backups, just store a copy of the WHOLE epub somewhere else, then none of the individual components can't get lost/overwritten.


It made sense when I was writing it