Wednesday, November 24, 2010

Sigil 0.3.2

You can get the release in the downloads area. Changelog follows:

  • added a new toolbar button for turning Tidy cleaning on/off; this option is also available from the Tools menu (issue #553)
  • added support for TrueType Collection fonts with extension TTC
  • InDesign (as of CS5) refuses to list the fonts it embeds in the OPF manifest of the epub files it exports, even though the epub standard demands it. This causes Sigil to not pick up these fonts when opening such epub files. A workaround has been added that will detect such problematic epubs and then load the font files.
  • worked around a Tidy bug that added blank lines to the start of <pre> and <style> elements (issue #655)
  • fixed a rare crash issue when loading epub files

All of these fixes have been in the repo for a while now; I wanted to get a few more things in before pushing a new release, but I’m so pressed for time right now that I know I won’t be able to do it any time soon.

The most notable changes are a new toolbar button for turning off Tidy cleaning. A bare-bones version of Tidy will still run to make sure your source is valid XHTML, but there is no element rewriting or CSS extraction etc. When you turn it off, it’s off for loading, view switches… everywhere.

The second notable change is a workaround for InDesign’s crappy epubs with embedded fonts. Since ID doesn’t list them in the manifest, previous versions of Sigil wouldn’t pick them up during import (that’s what the standards say should happen). 0.3.2 will notice when such ID epubs are loaded and pick up the fonts.

Same thing goes for TrueType Collection fonts; ID puts them in the epub even though the standard only allows TTF’s and OTF’s… Sigil will pick up TTC’s too now if your epub has them. You shouldn’t use them, but Sigil shouldn’t silently drop them if you do. The choice should be up to the user.

With these and previous font de-obfuscation changes in place, support for InDesign epubs with embedded fonts should be fairly complete.

Thursday, November 11, 2010

FlightCrew 0.7.1

The release is here. Changelog follows:

  • added an automatic update checker to the GUI app
  • the GUI now displays a "No problems found" message when the epub passes all checks (issue #9)
  • fixed an issue with missing XHTML files causing the GUI to show a dialog about an std::exception and the CLI to report that the epub itself was not present (issue #8)
  • fixed an issue that was causing empty error messages for incorrect uses of XML encodings (issue #5)
  • fixed an issue with anchor links to the current file (links with fragments only) incorrectly throwing errors in the reachability analysis (issue #3)

Besides some nice bug fixes, you also get two nice features: a message is now displayed when no problems have been found (lots of people asked for that one… and I agree, it should have been there from day one) and an update checker for the GUI app. The update checker is the same module used in Sigil, so it works the same way. It will notify you when you start the app that a new version exists if it detects one on the server. The check is only performed if the last one was more than six hours ago.

This of course means that FlightCrew-gui will now access the Internet when you start it.

Also note that the installers now install everything in a “FlightCrew” folder by default, and not in “FlightCrew-gui”. This means that FC 0.7.1 will not overwrite an installation of FC 0.7.0. You should uninstall the old one before installing the new one, otherwise you’ll end up with two different versions of FC on your computer. It won’t prevent either from working correctly, it’s just annoying. Smile

Mac users will see that there is now a “FlightCrew-cli” application along with “” in the DMG. It should have been there in the first release, but I forgot to add it. Such is life.

Sunday, November 7, 2010


You know the drill. You can get the new release here, and the changelog follows:

  • added a new "Font Obfuscation" context menu for font files in the Book Browser; the user can now select (or de-select) the use of Adobe's or the IDPF's font obfuscation methods; this also resolves the problem where Sigil refused to open epub files that use such obfuscated fonts with the message that the epub has DRM
  • fixed a validation issue caused by Sigil using "application/x-font-opentype" as the OPF mimetype instead of "application/"
  • fixed a crash when opening the TOC editor for some epub files (issue #654)

There are two reasons why you are seeing a new release so soon: the first one is an unfortunate bug that causes a crash when opening the TOC editor for certain epub files. While rare, it can still happen and frankly, it’s not rare enough. This needed to be fixed pronto.

The second reason is the recent introduction of the “this epub has DRM and cannot be opened” message for epubs that have an “encryption.xml” file in the META-INF folder. The message is valid since Sigil can’t open encrypted epub files (nothing can without the key, that’s the sad point of DRM), but unfortunately Adobe InDesign obfuscates embedded font files. This, naturally, creates an entry in the “encryption.xml” and now Sigil refuses to open your epub. And the only thing you did was tell InDesign to embed a font.

As far as I know, it’s not possible to tell InDesign not to obfuscate embedded fonts. It does this by default. The sad thing is that most people don’t know this is happening; they just embed the fonts and since they appear to work fine when the epub is opened with ADE, they call it a day. Personally, I have a problem with this: if Adobe wants to placate the font foundries with some patently absurd font mangling scheme, fine. But give the user a choice of turning this crap off. Or at the very least tell them it’s happening. If I were Adobe, I’d spend less time thinking up such nonsense and more time improving their epub export option since it’s currently… somewhat unusable[1].

Don’t get me wrong, I know perfectly well why they want fonts obfuscated: licensing issues. Most font licenses don’t allow embedding a font in a way that the font itself can be easily extracted from the distributed file. Font obfuscation is thought to solve this.

It doesn’t.

De-obfuscating a font mangled in such a way is laughably trivial; a twelve-year-old could write a program in 10 minutes that de-obfuscates the font files. The same thing goes for the IDPF’s method. It doesn’t prevent anyone from doing anything. While I find the whole thing ridiculous, I understand some want to give themselves at least an illusion of legal justification. All I’m saying is that Adobe shouldn’t be forcing people who know better into using something so silly.

Little do the users of InDesign know that this scheme makes their epub files invalid and that such fonts will only work in Reading Systems that support this. It works in ADE since Adobe naturally made sure that their RS supports their font obfuscation method. While I personally think that font obfuscation is utterly pointless, lots of Sigil’s users have epubs coming from InDesign… So Sigil has to cave.

You will notice that there is now a new right-click context menu entry for font files in the Book Browser. Under the “Font Obfuscation” sub-menu, you will see two actions: “Use Adobe’s Method” and “Use IDPF’s Method”. These select which font obfuscation method to use on the font files.

By default, the state in which the font file was found when the epub was opened is preserved when saving; so if you open an epub file with InDesign-embedded fonts, you will see a check-mark next to  “Use Adobe’s Method” in the  “Font Obfuscation” sub-menu. This means that the obfuscation is in place and will be preserved after a save. You can also click on “Use Adobe’s Method” to remove the check-mark, thus un-obfuscating the font file (I highly recommend this). Same thing goes for  “Use IDPF’s Method”; clicking on a checked method unchecks it and removes the obfuscation.

Since Sigil now supports font obfuscation (and de-obfuscation), you will not see that “cannot open because of DRM” message for epubs that use such fonts.

Don’t forget that InDesign still[2] flat-out refuses to to list the embedded fonts in the OPF file, even though the specs say it has to. That means the fonts won’t be picked up when the epub is opened in Sigil. I’ll probably add yet another InDesign workaround down the line to handle this.


[1] That’s the most restraint I’ve shown in a year.

[2] As of CS5. I just checked.

Thursday, November 4, 2010

0.3.0 FINAL

So here it is, the final version of 0.3.0. The changelog from 0.3.0 FINAL follows. Don’t forget that if you’re coming from 0.2.4, changes from RC1 and RC2 also apply.

  • root rights no longer needed to install on Linux
  • fixed an issue with some child headings being attached to incorrect parent headings in the TOC if the parent was marked as "not in TOC" (issue #476)
  • fixed an issue with some UTF-8 characters outside the BMP (usually CJK characters) not being saved properly (issue #180)
  • fixed an issue with certain path types not being correctly updated as a result of the fix for issue #501 (issue #561)
  • the Book Browser now prevents adding files that already exist in the epub
  • previously, when adding external XHTML files through the Book Browser, any files (like CSS stylesheets or images) that were linked from that file were included in the epub under a different name if their original name was "taken"; this caused duplicates so this behavior has changed: files whose names are "taken" are now skipped over (issue #482)
  • fixed a rare issue that caused incorrect path updates for anchor links pointing to file names that were suffixes of other chapter file names, and the anchor had a fragment ID (issue #598)
  • fixed an issue with the image paths in background-image CSS rules not being updated when the path changes (issue #594)
  • Sigil now informs the user that DRMed files cannot be opened, instead of just crashing (issue #624)
  • this time *really* fixed the "acknowledgments" error that was reported as fixed in RC1
  • fixed a crash on load (with an error dialog) issue on Linux systems occurring when multiple users on the same machine tried to use Sigil (issue #642)
  • fixed a randomly occurring crash, usually triggered on Macs during loading (issue #643)

And now I’m off to give FlightCrew some much-needed love.