Sigil 0.4.1 Released

[user_none]

It looks like I'll be doing a 0.4.2 release in about a week to resolve this plus any other issues that come up between now and then. I want to make 0.4.x super stable because it might be a while before 0.5.0 is ready.

[user_none]

Originally Posted by Rand Brittain

Hm, Code View still seems a bit ambivalent about whether it wants to display emdashes with an mdash or with "—", which makes it a bit hard for me to use find/replace on them still. Troubling!

Just mdash? Are you seeing this intermediately or is it always happening in a particular test case? Any issues with ndash or shy?

[Rand Brittain]

Originally Posted by user_none

Just mdash? Are you seeing this intermediately or is it always happening in a particular test case? Any issues with ndash or shy?

I don't really use either of those, but I'll try to experiment and discover.

[Rand Brittain]

Hm--the only one that seems to be still there--possibly the only one that was actually there at all--occurred where I had placed two emdashes simultaneously.

I also seem to have all my hellips displayed as themselves and not as HTML code; not sure if that's intentional or not.

[charleski]

Originally Posted by Rand Brittain

Hm--the only one that seems to be still there--possibly the only one that was actually there at all--occurred where I had placed two emdashes simultaneously.

I also seem to have all my hellips displayed as themselves and not as HTML code; not sure if that's intentional or not.

Hmm, that's strange. There was a problem with a typo which caused en dashes not to be translated back into the entity, but em dashes seem fine, no matter how many there are.

I didn't translate horizontal ellipses because then it becomes a question of where do you stop. Em and en dashes look very similar in the font used for Code View, and soft hyphens (being soft) wouldn't display at all unless they came at a line-break, so those were good candidates for special handling. The … character in Consolas looks sufficiently different to three consecutive periods that it's easy to pick them out, and you can grab the character by copying it from the view.

[Jabby]

The line numbers in code view are now really hard to read (the contrast is poor). I thought it was just me but I pulled up v3.4 on the same screen to compare and it has changed.

Regard -John

[Kendal]

Does anyone still have a copy of 3.4? I really dislike 4 -- everything I do creates an error that 3.4 never did. Unfortunately, I cleaned off my computer several weeks ago and I can't find my copy. Any help would be greatly appreciated.

[user_none]

Originally Posted by Kendal

Does anyone still have a copy of 3.4?

Go to the Google Code download page and change the filter to all downloads. Every version of Sigil is available but only the current version is displayed by default.

Originally Posted by Kendal

I really dislike 4 -- everything I do creates an error that 3.4 never did.

The difference between 0.3 and 0.4 in this regard is 0.3 wouldn't inform you of the error and silently "fix" them for you. If you use "auto correct" when you get the malformed dialog you are getting the same behavior as 0.3. The issue with 0.3 was auto fixing can lead to data loss.

[user_none]

Originally Posted by Jabby

The line numbers in code view are now really hard to read (the contrast is poor). I thought it was just me but I pulled up v3.4 on the same screen to compare and it has changed.

The contrast has changed. I changed it to be the same as QtCreator which I use to code Sigil with. It's intentionally supposed to be poor to make the line numbers subtle and not draw as much attention to them.

Now, there is a difference between poor and unreadable. I'm okay with poor (as I said that's intentional) but if people are having trouble distinguishing the numbers, that's a different story.

[user_none]

Originally Posted by Rand Brittain

I don't really use either of those, but I'll try to experiment and discover.

I've figured out the issue. This will be fixed for 0.4.2. If the file itself has m/ndash or shy characters in the file itself (not translated) when you open the EPUB it isn't translating them upon loading.

[Kendal]

Thanks, user_none. I know 3.4 fixed it for me in the background, but I never had any data loss and it was much nicer not having to constantly say fix automatically, fix automatically, fix.... Maybe version 4 needs a setting so you can tell it to "always fix automatically"?

Anyway, thanks again.

[st_albert]

Originally Posted by Kendal

I really dislike 4 -- everything I do creates an error that 3.4 never did.

I don't know if this is the issue you're having, but I am experiencing something similar re: difference between 0.3.4 and 0.4.1.

First a bit of background. I've been using 0.3.4 as my "production" version, and my workflow involves a final edit of the content.opf file (outside of Sigil 0.3.4, of course) to add several pieces of metadata. It is easier to expand the epub, copy and paste the metadata from a textfile supplied by the editor, and re-zip the epub than to pick each metadata element from the list in Sigil and fill in the data.

With Sigil 0.4.0 and above, I can edit the content.opf file directly; and that's a big time-saver. But there's a difference between 0.3.4 and 0.4 in that 0.3.4 will add the xml namespace references for opf and dc to the <metadata> tag if they aren't already there. Thus,

<metadata>

becomes

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:opf="http://www.idpf.org/2007/opf">

version 0.4.0+ does not do this.

That means that while editing in 0.4.1 when I paste a metadata element such as

<dc:contributor opf:role="art" opf:file-as="Scott, Ardy M.">Ardy M. Scott</dc:contributor>

(perfectly valid in an 0.3.4-created content.opf) into the .opf, as soon as focus switches away from the editor window, Sigil complains about an error because it doesn't recognize the opf elements.

If, instead of editing and pasting, you use Sigil's meta editor tool (F8) to add the same metadata, Sigil adds:

<dc:contributor xmlns:opf="http://www.idpf.org/2007/opf" opf:file-as="Scott, Ardy M." opf:role="art">Ardy M. Scott</dc:contributor>

in other words, it adds the xml namespace reference to the dc metadata element itself.

My workaround is to just paste in the modified <metadata xmlns:dc="http: ... > tag at first, just like 0.3.4 would have done. Then, no more errors from pasting (otherwise well-formed) metadata elements into the content.opf.

BTW, I tried "automatic fix" once, and it completely re-wrote the opf file, with LOTS of data loss. Good thing I save frequently.

[user_none]

Originally Posted by st_albert

With Sigil 0.4.0 and above, I can edit the content.opf file directly; and that's a big time-saver. But there's a difference between 0.3.4 and 0.4 in that 0.3.4 will add the xml namespace references for opf and dc to the <metadata> tag if they aren't already there.

I'm having trouble recreating this issue. Are you opening an EPUB that doesn't already have xmlnspf="http://www.idpf.org/2007/opf" in the metadata element? Do you have an example file I can play with?

Originally Posted by st_albert

BTW, I tried "automatic fix" once, and it completely re-wrote the opf file, with LOTS of data loss. Good thing I save frequently.

This is why it now prompts and doesn't try to fix it automatically.

[Rand Brittain]

Originally Posted by user_none

I've figured out the issue. This will be fixed for 0.4.2. If the file itself has m/ndash or shy characters in the file itself (not translated) when you open the EPUB it isn't translating them upon loading.

That makes sense. I commend your diligence!

[st_albert]

Originally Posted by user_none

I'm having trouble recreating this issue. Are you opening an EPUB that doesn't already have xmlnspf="http://www.idpf.org/2007/opf" in the metadata element? Do you have an example file I can play with?

OK, here's a zip file that contains (1) valleytest.epub, with content.opf as written by InDesign 4.0 epub export; (2) content.opf.034, content.opf after opening and save-as in Sigil-0.3.4; and (3) content.opf.041 after opening, fixing date metadata, and save-as in Sigil-0.4.1

The epub from indesign contains one error per FlightCrew, namely a malformed date. This is a known bug in ID4. Sigil 034 fixes this in passing, silently. Sigil 041 does not. (Not that it should, necessarily.)