Robustness

[capidamonte]

Originally Posted by meme

That looks like an issue (I created one for it), and maybe why it confused the OP. I didn't even know Sigil could open html files directly until recently

We're actually considering removing the ability to open html files directly so that would fix this

But given that someone actually uses this feature, we might have to think twice about keeping it (and fixing one or two bugs in the current process).

I haven't logged into MR for a long time, but I read the Sigil forums to keep current on using the app. I felt compelled to respond to this (and I'll probably disappear again, honestly.)

I work for Hitch at BookNook, and this particular item would seriously cramp my method.

Please don't remove the ability to load an (X)HTML file directly. My process (and I suspect others) involves opening a single, customized HTML file and having its associated files (CSS, in particular) automatically added.

Having to manually load every individual file would be something quite inconvenient. The OP doesn't really understand what he's doing; some people here are trying to help him -- which is the best solution, I think, rather than modding the app to prevent his confusion somehow.

Look above to the suggestion to modify the popup notification to provide context and explanation, please.

Aloha

cap

[theducks]

Originally Posted by cybmole

go tell that to the guys who make epub reader hardware.

I doubt there is even ONE reader device on the market that can handle raw HTML.

My PEz can.
But Why Bother (other than HTML is the underlaying part of EPUB, so the render engine is mostly, if not all there)

[DiapDealer]

Please don't remove the ability to load an (X)HTML file directly. My process (and I suspect others) involves opening a single, customized HTML file and having its associated files (CSS, in particular) automatically added.

Having to manually load every individual file would be something quite inconvenient. The OP doesn't really understand what he's doing; some people here are trying to help him -- which is the best solution, I think, rather than modding the app to prevent his confusion somehow.

I don't think eliminating that functionality was what meme was suggesting. Using the Add Existing File(s) menu item (as opposed to using File Open) will still automatically add all of the other linked files (css, images, fonts, etc...) when you select an existing (x)html file.

I'm fairly certain that meme was suggesting (possibly) that "File Open" be changed to only recognize/work with existing epub files.

[Elfwreck]

Originally Posted by theducks

My PEz can.

warning:
Does your PEz get readable text that way? Mine inflicts arbitrary and sometimes bizarre linebreaks and hyphens on raw HTML.

I would love something that reads HTML, because I have a lot of fanfic saved from older sites with not much formatting. And because I could easily get blog posts in html by viewing source code & pasting into a textbox, and saving as HTML.

(I don't want to use Calibre to get blog posts. I don't want a library cluttered with dozens of one-shot blog posts I downloaded to read on the train going home, nor do I want to try to keep Calibre synched across three different machines.)

[theducks]

Originally Posted by Elfwreck

warning:
Does your PEz get readable text that way? Mine inflicts arbitrary and sometimes bizarre linebreaks and hyphens on raw HTML.

I would love something that reads HTML, because I have a lot of fanfic saved from older sites with not much formatting. And because I could easily get blog posts in html by viewing source code & pasting into a textbox, and saving as HTML.

(I don't want to use Calibre to get blog posts. I don't want a library cluttered with dozens of one-shot blog posts I downloaded to read on the train going home, nor do I want to try to keep Calibre synched across three different machines.)

Great question
Because I usually format books my way so I never seriously put it through the HTML (only) wringer. I know it opens RAR wrapped HTML, but I tend to Calibre it, then I (Sigil) edit the base font to 1.2em which is my preferred for Zoom 3 and .5em top/bottom paragraph margins when indented.

[Hitch]

Originally Posted by theducks

Great question
Because I usually format books my way so I never seriously put it through the HTML (only) wringer. I know it opens RAR wrapped HTML, but I tend to Calibre it, then I (Sigil) edit the base font to 1.2em which is my preferred for Zoom 3 and .5em top/bottom paragraph margins when indented.

So, Ducks:

That would be a "no," then? As in, not really? ;-)

Look, killing off the html import would have major suckage, and all of us--big, little, ammie, pro, etc.--all rely heavily on a) regex, which can't have regexus interruptus with an "auto-save"--and b) knowing that we can count on Sigil, sometimes infuriatingly so, to tell us when our ePUBs aren't well-formed.

Keeping the html import as-is is very important to my gang, as Cap said. A lot of our macros, scripts, PERL bits (everyone has their own shtick) etc., use that as a step, and we'd all hate to re-write it/them. I have NO problem with an auto-prompt telling someone that they can't save html, which I honestly thought used to exist, or maybe I'm misremembering.

FWIW,
Hitch

[DiapDealer]

Originally Posted by Hitch

Look, killing off the html import would have major suckage, and all of us--big, little, ammie, pro, etc.--all rely heavily on a) regex, which can't have regexus interruptus with an "auto-save"--and b) knowing that we can count on Sigil, sometimes infuriatingly so, to tell us when our ePUBs aren't well-formed.

Keeping the html import as-is is very important to my gang, as Cap said. A lot of our macros, scripts, PERL bits (everyone has their own shtick)

Like I previously mentioned... I don't think anyone was suggesting killing off the html import, or even changing the way the current html import works. But I've been wrong before, so I'll let someone official comment on it.

[Hitch]

Diap:

You? Wrong before? Nevah!

(Just putting in my $.02, in case it starting taking root in someone's brain.)

Hitch

[elibrarian]

Originally Posted by meme

We're actually considering removing the ability to open html files directly so that would fix this

But given that someone actually uses this feature, we might have to think twice about keeping it (and fixing one or two bugs in the current process).

I hope you are joking on this. My workflow is usually to load a css-file + one single, fully spellchecked and formatted (by hand and a Notetab-macro), checked by the WC3 Validation service and including all the necessary metadata, into Sigil - if Sigil were to use that functionality it would be somewhat more difficult, because css and metadata probably would have to be added one at a time and by hand.

So please don't alter this!

Kim

[meme]

Just to keep everyone calm, I was only referring as DiapDealer said, to the File Open command (or drag and drop) not to Add Existing Files.

So of course Sigil would still be able to add html files - it wouldn't be too useful without it. It was just a question of whether Sigil should be able to open just .epub files, requiring you to use add existing to import html, css, images exactly as before.

But I think it'll probably remain for now as changing the code could be more trouble than its worth at this point.


Now, about dropping code view...

Spoiler:

No worries - neither CV or BV are going anywhere (although you will see BV become display only while you are in split view).

[Hitch]

[ETA: I typed this before Meme's post came up] : I'd like Meme's clarification on precisely what he's contemplating. I'd have to give some thought as to whether using "Add Existing Files" instead of simply using "Fle-->Open" would seriously impact our processes, but I know Cap's NOT happy about the idea.

I mean---why are we considering this? In keeping with the rest of the world, is this the advent of the dumbing-down of Sigil? What's the problem that we're actually solving here? Why not simply add a popup saying you can't save as html, only ePUB, or simply add it to the Toot? What does this really solve, and how many actual complaints have we had about it?

Or are we now considering Sigil as an authoring tool--not an ePUB-creation tool for folks who have the ability to either use it outright or at least learn how to use it? There are at least 20 really top-flight html editors out there, half of them free. There are more than few new "epub-creation" programs (AWP, Jutoh, etc.) that work for those who want a Word-Processing, spell-checking, styles-drop-down, autosaving type program.

Is there genuinely a call for this? Aren't there more important things that meme and user_none could be working on? If it ain't broke...

Just my $.02
Hitch

[cybmole]

Originally Posted by Hitch

and how many actual complaints have we had about it?



Just my $.02
Hitch

err ..... 1 so far by my reckoning ( the OP), then 50+ posts saying leave it as is.

[DiapDealer]

Originally Posted by cybmole

err ..... 1 so far by my reckoning ( the OP), then 50+ posts saying leave it as is.

Exactly. My only suggestion was that instead of throwing up the warning about "Can't save xhtml files", that it should just silently roll into the "Save As" dialog if the ePub hadn't been saved yet. Then all hell broke loose.

Spoiler:

But I understand perfectly, all the concerns.

[DaleDe]

[QUOTE=DiapDealer;2023114]Exactly. My only suggestion was that instead of throwing up the warning about "Can't save xhtml files", that it should just silently roll into the "Save As" dialog if the ePub hadn't been saved yet. Then all hell broke loose.

I think that is a good solution. Would this still require the required metadata?

Dale

[elibrarian]

Just to be sure, I tried to use the Add File-function instead of the File Open, and found, that they do NOT work the same way. In the (x)html file, I have metadata like this (sample):

<meta content="Mrs. Lirripers værelser" name="DC.title" />
<meta content="Dickens, Charles" name="DC.creator.aut" />
<meta content="2012-03-05" name="DC.date.publication" scheme="ISO8601" />
<meta content="978-87-7979-237-1" name="DC.identifier.ISBN" />
<meta content="eBibliotek 1800" name="DC.publisher" />
<meta content="eBibliotek 1800" name="DC.rights" />
<meta content="Kim N. Jensen" name="DC.contributor.edt" />
<meta content="Foreligger ikke oplyst i forlæg (ant. Ludvig Moltke, 1805-1872)" name="DC.contributor.trl" />

which loads nicely into the epub's metadata, when using File Open, but *not* when using rightclick and Add File.

Also, I have the frontpage as (sample)

<div class="svg_outer">
<div class="svg_inner">
<svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 600 800" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink">
<image height="800" width="600" xlink:href="dickens-mrs_lirripers_verelser_STOR.jpg"></image>
</svg>
</div>
</div>

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)

So, as someone else said, it a'int broke, so dont fix it

Regards,

Kim