Editing EPUBs in the post-Sigil world
Editor’s Note: Today’s guest post comes from Anthony Levings, who runs the SketchyTech blog. Today he has a look at the bumpy post-Sigil environment for EPUB creators.
The Sigil editor was not used by everyone in the #eprdctn world and there are those who wouldn’t admit to doing so in public even if behind the scenes they used it to fix things up once in a while. The truth is, however, that with its official demise it marks yet another #eprdctn tool that has failed to move from EPUB 2 to EPUB 3.
As commonly happens with small open source projects, the weight of development ended up falling on the shoulders of one person, and no doubt the overwhelming task of deciding how to handle the many facets of EPUB 3 forced the development to a standstill.
When EPUB was first on the scene, tools popped up in gold-rush fashion and it seemed that before long reliable EPUB creation would make our technical skills irrelevant. But over the years we’ve seen Writer2Epub plug-in for OpenOffice left without an update for over 2 years we’ve seen projects like Mylyn for Eclipse left in obscurity, and promises of EPUB editor suites go unfulfilled.
Meanwhile, the once celebrated FlightCrew has befallen a similar fate to all the rest, and BookGlutton source code was posted to GitHub in 2011 with the hope that “other developers [would] use and improve it as a basis for creating Epub 3 workflows” but this simply didn’t happen. The code has languished for two years without being forked and instead of being updated sits like a museum piece in a glass cabinet.
Sigil: The Golden Years
Sigil provided convenience to the user when InDesign let them down. For instance they no longer were required to unzip and rezip for every revision of the file, and by using Apple’s Book Proofer every save in Sigil would send the book to a connected iPad for re-checking. It also took away the necessity of changing the OPF and TOC code manually. But with support gone, annoying bugs in OS X Mavericks unfixed, and EPUB3 support not scheduled to arrive it is time to move our workflows forward.
Note: Those who didn’t use Sigil must be warned that the subtitle to this section is a little tongue-in-cheek. It was, in my view, an ambitious project that is to be respected and congratulated. At the same time, it was the cause of frustration to people who were not in favour of its tidying of files and code creation.
So we’ve exported our EPUB 3 from InDesign or Pages, or some other app, and there’s some errors that have arisen in epubcheck. Or perhaps there aren’t errors, but we want to change the way that the app has arranged something for us, something which we weren’t afforded enough control over.
Working on a Mac, the options are thus:
- we unzip with StuffIt Expander, open in a text editor like TextWrangler and get to work on the markup, then rezip in the Terminal
- having paid £30+ we own a copy of BBEdit and don’t need to dirty our hands with unzipping, we also have the luxury of live preview, but we still need to understand the ins and outs of the IDPF documentation so that we know how to fix things when they go wrong
- we look to Calibre, whose developer (Kovid) was passed the baton by the final Sigil developer (Schember) to continue development of a similar tool inside Calibre’s existing app
- we decide we can’t live without the luxury of Dreamweaver-style editing and handholding, so put down £200+ for a copy of oXygen Author and it assists us with construction of the OPF and the EPUB 3 Navigation Document and feels like the most sophisticated option on the market today
Missing in most of these solutions, with Sigil gone, is the structure and organisation that guided us into approaching EPUBs in a way that reflected their form, and for the most part kept us out of trouble, especially thanks to the assistance of in-built FlightCrew checks.
The parallel present (and associated anxieties)
In the parallel present, there are those who have turned their backs on what has become the tradition of book production that embraces the Word -> InDesign (-> EPUB) mindset and focus instead on getting the XHTML5 prepared first and automate its transition into electronic and print forms.
Online tools like PressBooks exist to assist us in this type of creation, but there remain a number of sticking points. The foremost of which is that we lose the ability to page by page edit and manipulate in the way we do in InDesign and rely instead on CSS (or other programmatic) transformations for our final layout.
Of course, we already depend upon CSS for websites and electronic books, but it troubles our minds when it comes to the print side of things that we must hand over so much control. Print aims for perfection. We worry about widows and orphans, word breaks and rivers, not to mention excessive white space of the kind forced upon us in EPUB and Kindle by figures and headings. And although we might have expected back in 2011 that by now the print book would’ve largely had its day, it is still a major part of publishing and the possibility of a print version cannot be ignored in most workflows.
For CMS and XHTML first options to become the norm for publishers, we need them to achieve two main goals:
- to match the abilities of current tools (or come very very close to matching those tools)
- allow us to retain control of our content beyond the lifespan of the system
In essence what publishers demand is freedom and flexibility in the handling of content. If those are missing, it is very difficult for economic incentives to compensate for their loss.
It’s hard to predict what the future holds, but one thing is certain and that is no matter how many versions of a book we produce we want them to remain in sync with one another in terms of corrections and revisions, and we want to reduce the amount of work required as much as possible so that with the print book finished, the ebook is as well, or vice versa. It is also clear from past experience that we cannot rely on open source tools to meet our every need.
One logical answer for those publishers currently using Adobe apps would seem to be that once an EPUB is created in InDesign we should be able to open it in Dreamweaver, and without unzipping have an oXygen like experience of editing and adding interactivity. But then maybe it’s time we all put the money down on oXygen and stop holding back, stop waiting for Adobe to make everything we demand, or something free and fabulous to arrive.
This said, I have a few issues with reliance on GUI editors for editing EPUBs in general:
- when our dependence on them grows, knowledge of the underlying mark-up is quickly lost. We find this with designers using Dreamweaver, who might know how to use the app and have a superficial grasp of HTML based on it, but who don’t understand the overall structure, conventions and pitfalls in programming websites
- there is room for typos and changes to occur that mean the electronic version differs from the print version of the book
In the idealised world GUI and WYSIWYG editors are not required, because outputs are perfect, but in the real-world it is convenient to have EPUB editing tools. The question is: Are we willing to pay for the convenience in the real-world? YES/NO/MAYBE
The other question, given that people complained quite a bit about Sigil’s eagerness to change their markup (as noted, even during the golden years), is whether we are willing to trust developers to write the tools we need in the EPUB editing space. After all, a bad tool can create more work than it saves and we’ve had to tolerate a good deal of imperfection, even from the big names, over the course of the last four years.
And then there’s the parallel present, maybe we should embrace the vision that is being set out and let the sophisticated computers on our desks and living in the clouds do more of the work for us rather than imprisoning ourselves in the laborious task of print thinking in a digital world. But it takes time to learn systems and build trust relationships, and who do we trust to stick around while all this happens? We don’t want to jump from one latest and greatest system to the next like over-eager coders. We need reliability and to know that we are not being sold hype, as is so often the case in the world of technology, but systems that really cover all of our needs.
There is no conclusion, some of us sit and wait for Adobe and Apple to meet our every need, some pray for Sigil to come back, some save their pennies for a copy of oXygen, others wander around looking at ways to create their own workflow solutions or embrace the forward-thinking solutions of others.
My prediction is that EPUB will go one of two ways. Either we’ll create EPUBs of the future in the same way that we create PDFs with ease and gone will be the inconsistencies of display and variation of markup. Or, pushes to evolve the standard and what it is capable of doing will lead to features being inconsistently supported, as is the case with HTML5 and modern browsers, and we’ll forever have our heads under the bonnet trying to figure out how to make the damn thing work.
Anthony Levings (@anthonylevings) is Managing Editor at Gylphi Limited, an academic publisher focused on the arts and humanities of the twentieth century and beyond. He writes posts for the sketchyTech blog and has provided technology training and consultancy to publishers and authors in the area of eBooks (ePUB and Kindle). Recently he was the architect for an iOS app called The Waking Prince.
You can follow the @sketchyTech blog on twitter.
I used Sigil when I was learning to construct EPUBs, but it was too buggy to use in a professional e-production workflow—and I already did have that BBEdit license and am used to working directly with code. Mostly I liked Sigil because it created the NCX and OPF for me, and I’m lazy.
So lazy that seeing your “we unzip with StuffIt Expander, open in a text editor like TextWrangler and get to work on the markup, then rezip in the Terminal” makes me shudder. Unless you get your thrills from using the command line, I’d recommend that you invest all of $0 (that’s £0, to you) in pagina EPUB-Checker
which validates and zips (assuming your file *passes* validation) in a single step.
Also worth noting is the equally free EPUB Zip/Unzip Applescript
(People really still use Stuffit?!)
I am surprised there is no mention of Jutoh here. Jutoh developer Julian Smart has taken Jutoh way beyond Sigil and charges a modest fee for the program to ensure his efforts can continue. He is also demonstrating interest in advancing to ePub3 compatibility.
Bonnie, thanks for your comment. I had completely forgotten about Jutoh, but now I see the logo I remember visiting the site a while ago. I will download and give it a try.
Right now, Jutoh is the best option, presentation and code wise. I think I have tried everything else.
What about BlueGriffon EPUB Edition?
Thanks for the response. Sigil did evolve and wasn’t a source of errors so much in later releases, especially if you did the coding and weren’t tempted by the WYSIWYG editing.
I’ve never really thought about StuffIt Expander, I started using it when Apple’s inbuilt unzip started not working very well and continued when I discovered it could open EPUBs without renaming.
Thanks also for the links. These are things I’ve seen before but just have never got around to trying. There’s always such an investment of time and energy if things don’t work perfectly at the end of the process. And in truth I’d rather use the command line than an Apple Script. (Despite having learnt how to program Objective-C, I’ve never got to grips with Automator or Apple Script!)
I see that if you go for the plug-ins this is another app in the Jutoh price range. Have you used it? Would you recommend it?
I think as a community we need to really share with one another our findings on how well these mid-price apps do the job.
I own a copy of BlueGriffon EPUB Edition. It isn’t a plug in. It’s a standalone app.
It’s also highly intended for WYSIWYG use. which means it does what it think should be done under the hood and woe be to the person who thinks they know better than the software (which, BTW, is designed and developed by one of the CSS working group members – a co-chair if I remember correctly).
There’s another scenario completely for EPUB construction in the future: No Indesign and No print to EPUB. Most of the large conversion houses do _not_ use Indesign to create EPUBs now. They use in house, purpose built conversion tools that either extract text directly from Indesign, or existing print ready PDFs. Indesign > EPUB doesn’t scale well when you do a few hundred books a month over 5-10, and there’s very little value in going through all the steps to get a “we have to hack it anyway” EPUB out the other end.
Adobe is working to add features and tromp less on people’s under the hood efforts, but when it comes to economies of scale, I highly doubt that conversion houses will do away with their custom built scripts and purpose built tools to the Indesign route.
I purchased Oxygen Author years ago and it’s been worth every cent! (My background was in print book design.)
OK, Anthony. This is my experience. I can recommend Jutoh for ease of use, an informative manual, timely and thoughtful tech support by the collegial developer, Julian Smart, of Edinburgh, Scotland, along with regular updates to tweak and improve the program at no additional cost. After editing my clients’ books, which is the real work, I lay them out in InDesign and send them to the various printers. Then I import the same Word file previously placed in InDesign to Jutoh. What’s especially nice about Jutoh is that the program asks for the meta or descriptive data along with the eBook cover before the import. In a pinch, you can even fashion the cover in Jutoh. After importing carefully formatted text, I place figures, graphics, and tables in Jutoh, and then generate a simple or complex ToC from within the program. Then I test output after generating an ePub and then a Mobi edition from within Jutoh. When first setting up the program, the user is prompted to download Kindle Gen, which ties in perfectly with Jutoh. There’s no zipping or unzipping. I can tweak any element, including text, HTML, or CSS from within the mostly intuitive Jutoh interface. If there’s an issue, I go back to the source doc in Jutoh and fix it there, then regenerate the ePub and Mobi files. I love InDesign for print. I read Elizabeth Castro’s books and upgraded to InDesign 5.5 and then to 6 for the purpose of exporting eBooks. I find Jutoh easier to use and upgrades are frequent, substantive, and free. The developer is making a real effort to make Jutoh adaptable to ePub3, which leads me to believe this stable program is the one to beat. Jutoh gives me complete control over what each eBook looks like. I upload Jutoh-generated ebooks to the Apple store, to Kobo, Amazon, bn.com, and so on, and they look stylish on the different devices.
Thank you both for sharing. This is valuable information.
Jennifer, thanks for your comment. If you’ve got time, I’d be really interested to hear about your workflow, the time it took to become familiar with the interface, and whether you use only the EPUB side of the app or whether you also take advantage of the central XML side of things.
Currently there is a disconnect among what the various reading devices can handle. For example, only the iPad can interact with Jim Dwyer’s stunning new eBook3 and so, it is available only at iTunes. Here’s an interactive sample.
When consumer device capability improves, the software displaying interactive elements will improve along with it. At the moment, Apple has the clear lead. In February, the Book Industry Study Group opened an ePub3 support grid at http://www.epubtest.org/
to summarize e-book app, device, and reading system performance evaluations for features. While that site appears to be down at the moment, when it was properly operational, it contained a handy grid displaying the capabilities of the various devices. (I hope the performance evaluations are being updated during this downtime.)
I had the ‘brilliant’ idea that I could just make an e-pub picture book. After falling down numerous tech rabbit holes, I found that the only way I could do fixed format on my budget was to work in a combination of Dreamweaver, Notepad and a Firefox browser.
Pagina was absolutely the most useful tool I ran across. I could not have been prouder when I finally got my e-pub to validate.
And then I could not have been more disappointed when why lovely validated e-pub crashed and burned in the Kindle Previewer.
As an illustrator, I’m already heavily invested in Adobe products whether I like them or not because they are “industry standard” for handing off art files to certain clients.
I am grateful for opensource, but I absolutely expect that most programmers will move on and I don’t think any business model can rely on using it long-term. I won’t be surprised that when I am ready to publish my next picture book in six months, the whole tech landscape will have changed. I expect that I’ll be out shopping again for some odd variety of tools to get the job done.
[…] [Read the full article] […]
Arlene, many of us are heavily invested in Adobe products. At this time, only ePubs on iBooks support fixed layout. I also thought Dreamweaver might logically be the right tool to produce an eBook but I have found it is not. In my experience, conversion from HTML to ePub (or Mobi) lead to least desirable results. Here are three free (or nearly free) resources that might aid in your quest: Aaron Shepard’s Pictures on Kindle; Charles Spender’s Formatting of Children’s Books and Comics for Kindle; and finally, surprisingly, Amazon’s free Kindle Comic Creator.
This is a great article! The quest to make high-quality eBook files that are not just valid but will work well across all of the different reading systems is no small matter. It’s great to see so many people talking about these issues and trying to come up with solid workflows.
I think one of the best points you made was: “The other question… is whether we are willing to trust developers to write the tools we need in the EPUB editing space. After all, a bad tool can create more work than it saves…”.
This is a problem my team and I have been talking about for a long time. Like most professional eBook developers, we have created a proprietary workflow that we can use for almost any project that comes our way, so we have a lot of control over our final output. Most WYSIWYG tools do not give developers that kind of control, though, and relying on the output of Sigil, calibre, InDesign, or any other tool can be problematic.
We decided to tackle the problem by giving eBook developers a tool that will allow them to validate their files against all of the industry standards, to see how their files match up to best practices, and to make necessary edits without completely overriding their own code.
The tool is in early alpha testing, and should be released for a closed beta next month. We’re starting off with some of the more foundational functionality, but will be adding lots of powerful features in the future. I don’t envision it necessarily becoming a conversion tool that makes your EPUB files for you, but I do envision it becoming the best tool to use when doing QA and updating EPUB files created anywhere else. It is designed to help developers and publishers polish their EPUB files to a shine.
If anyone wants to be included in the beta test group, please email me (firstname.lastname@example.org).
Thank you for these tips.
I have to say that this is yet another good example of different tools working for different workflows. There is no one toolset that is going to work for everyone and I encourage everyone to keep an open mind when exploring the different options.
For instance, I know many developers (myself included) who use Dreamweaver and do not depend on it for WYSIWYG or “handholding.” In fact, AnneMarie Concepcion has a section in her lynda.com EPUB course regarding Dreamweaver and how it can be a useful tool for ebook developers.
I agree that Dreamweaver is the (current) logical choice for Adobe to extend into an official EPUB editing tool, but I’m not sure whether it would still be better to have a new app (with cross compatibility) that is both a creation and editing tool for EPUB rather than adding functionality on to other already large and complex apps.
For those already using Adobe apps, it’s good for familiarity but for new users I imagine the learning curve to arrive at an EPUB must be a bit bewildering.
Thank you for taking the time to respond. It’s good to hear that I’ve managed to capture something of what others have been thinking.
I look forward to seeing your new tool come to life. Entrepreneurs are very much needed in this space.
… my apologies for silly mistake. I couldn’t go back and edit.
Ha, that’s okay! Plenty of people spell my name like that.
I 100% agree with what you’re saying, thanks for sharing your thoughts.
“both a creation and editing tool” – so many of us jump from tool to app to script to tool that the thought of one tool “to rule them all” seems too good to be true
“learning curve” – absolutely true that those of us with Adobe experience might feel at home with Dreamweaver but it is probably too much of a learning curve (and an investment of $) for anybody else. I’ve heard talk from Adobe developers who are thinking of extending DW’s capabilities beyond web to EPUB but that remains to be seen.
Sometimes I have to remind myself that we are still in the beginning stages of creating ebooks and figuring out the best digital formats for “books”. And then I cringe at the thought of so many backlists (ours included!) already converted (hastily) into EPUB2! Then I think about so many people who are reading–print or digital–and I think that as long as people are reading, as long as we ebook devs put our best efforts forward all is not lost.
It’s a confusing and exciting time in book publishing! But I am so happy to see this EPUB Secrets revived and to see the conversation continuing. Thanks Anthony!
I’m weeks late to this article, but thank you for taking on the Sigil project for as long as you did. I’m very sorry to see it stop. I’ve found no other tool as useful/intuitive for creating TOC/NCX files, and the validators were nice. More generally, I love that there is (was) a program that served as a bridge between completely hand-coded books and WYSIWYG editors.
My company used Dreamweaver, Calibre, and Kindle Previewer for our first E-book, and then switched to Dreamweaver, Sigil, and Kindle Previewer for our second and third once we saw that Amazon had grown increasingly picky about Calibre files.
We’re literally days away from posting a how-to blog project so that other poetry publishers can see/adapt/adopt our workflow. We do our print books in InDesign and our E-books in Dreamweaver, but we expected many self-published authors would be able to follow along in Sigil for the split-code views. Obviously, they still can do so, but now it feels as though we’re teaching them to embrace a dead-end.
I’ve played around a bit with Jutoh, and my typesetter is experimenting with BlueGriffon. Chances are, we’ll still start our tutorials off with Sigil, as we’ve already written most of the copy and taken the screen shots.
Thank you again, Anthony, for keeping it going in the face of what may have appeared to have been complete indifference. My tiny publishing company could not have managed our spring titles without Sigil.
& The Yellow Buick Review (coming in May)
[…] the slow death of Sigil, eBook Architects realized that the ebook community needed a new tool to QA and make small edits to […]
[…] It’s not a full-fledged HTML editor, and it’s always risky to invest time learning a discontinued program, but it’s still a valid option for what we’ll be doing. In fact, we’ll use Sigil […]
[…] It’s not a full-fledged HTML editor, and it’s always risky to invest time learning a discontinued program, but it’s still a valid option for what we’ll be doing. In fact, we’ll use Sigil […]
If Jutoh is anything like Julian Smart’s other epub offering, then I can’t recommend that you stay the hell away from it enough! eCub is so horrible, and before anyone says “You get what you pay for”, Jutoh is also available for free.
We’re not in a post-Sigil world after all! I know many of you who follow the #eprdctn hashtag on Twitter already know the news, but Sigil is back! Go check out the progress over at
http://sigildev.blogspot.com/2014/09/sigil-status-update.html ; as of this writing they have a new build and are looking for all the help/feedback/donations they can get.
I am delighted that Sigil is back in the game. Bicycle Comics has donated a tiny sum to help them out; those of you who work for well-heeled publishers might ask your art directors/ production managers if there is any money in the budget for more donations. Point out that a solid, robust, open-source EPUB editor for the #eprdctn community gives publishers large and small added leverage in their dealings with Amazon, which would prefer we all use proprietary editors and just make KF8/mobi7 books.
& The Yellow Buick Review (coming in May)
[…] in good faith. But when Sigil went quiet in Spring 2014, I felt as if I were leading people down a path I knew to be a dead end. It was hard to be enthusiastic about documenting Step […]
I purchased BlueGriffon Epub Edition and it’s useless for working in epub3 files. When you open the book it immediately changes code in the book and if you save it no longer passes epubcheck validation. I have tried to get a resolution from them without any response whatsoever.
I am now using Oxygen which is great. A bit of getting used to after Sigil, but working well.
From Italy: http://www.epubeditor.it/home/home/
english version (coff coff): http://www.epubeditor.it/home/home-en/
I’m joining the conversation late. I come at this problem from the content creation side, not publication, so my comments will reflect that perspective.
I abandoned Word for writing long documents many years ago after it corrupted yet another book length document for the last time. For several years I used LyX as a WYSIWYMean editor and was very satisfied with it. The abundant number of document classes generate truly beautiful PDFs. The memoir class in particular is absolutely fantastic for books.
However, time marches on and EPUB is now by far the format that I care about. The support for the EPUB format in LyX is limited to generating XHTML, which in turn required additional tools such as Sigil in order to get to a good looking EPUB document. It’s a somewhat clumsy way to get to good looking documentation.
I have been exploring the use of the MultiMarkdown text format as the place to do my initial writing. Using MultiMarkdown as the text file format allows me to use any editor that I want while I write and yet, still insert images, footnotes, what have you where I need to. That is handy when I am writing using several different devices and syncing back to a private git repository. I use Kwrite at my Linux Desktop, vim, vim Touch, or JotterPad.
After that, I am feeding that output into LyX for a print ready publication as a PDF and Sigil for EPUB. I pay some attention to document layout as I write but I certainly don’t obsess over it. So far, this solution is working for me with a minimal amount of tweaking.
I should note that all of the apps listed above are open source, or at least free for the download. There are ways to minimize the cost of your toolchain and not give up as much in the way of productivity as is implied in this post.
I find it quite dangerous to rely on proprietary EPUB creation tools because everyone should be enabled to produce EPUBs, not only a few selected ones, especially as EPUB is an open standard and needs to be defended against proprietary “extensions” and proprietary dependencies. Sigil demonstrated that it can’t really “die”, because its free licensing allows for a revival every time a developer gets interested in it. To produce such interest, it would be a good idea to save the money spent on proprietary tools and invest this very amount into Sigil, but this idea doesn’t occur in most people. Regarding EPUB3, it is relatively simple to convert an EPUB2 to EPUB3, so Sigil could have at least some basic EPUB3 support, the main problem is implementing all the multimedia and interactive features. Does anyone already need such features, especially in an application as Sigil, with full support? Just give it some time to gradually implement those features and maybe even advanced ones someone would like to see in an EPUB IDE (Integrated Development Environment).
It does not occur to most people because it does not make sense to “invest” in a tool that has scant development happening, no apparent concrete plans for development releases, and lots of issues that make using it difficult. Publishers need workflows that do not rely on sub-standard tools, and that can integrate both their print and ebook creation processes. That’s why InDesign is so often the tool of choice, despite its own limitations. The InDesign team is actively working on the EPUB export, and it is making progress where Sigil is not.
This is a misleading statement. While it is not hard to convert an EPUB 2 package into an EPUB 3 package, that does not mean that it is a good quality EPUB 3 file. There is a lot more built into the EPUB 3 spec than just “multimedia and interactive features”. Semantic markup is where most EPUB 3 creation falters, and that is not an easy task for Sigil to fix. So, while Sigil can support the creation of an EPUB 3 file (and supposedly will in the 0.9 release), that does not mean that it will actually create a good quality EPUB 3 file, any more than it does with EPUB 2.
Sigil has had three and a half years to support EPUB 3 basics. It has fallen well behind the times, and development is slow at best. We can give it all the time in the world, but the rest of the ebook world has moved on — including all the retailers, which now accept EPUB 3 files, and other tool makers like Adobe. If Sigil ever makes it to a 1.0 release, and fixes the problems and limitations that it currently has, then maybe it will have a place in professional workflows. Until then, I think it should be relegated to the back burner and ignored by serious ebook creation experts.
scant development happening, no apparent concrete plans for development releases, and lots of issues that make using it difficult
Don’t you think that’s circular? Sigil developers don’t work on it professionally, because – people rather spend their money on proprietary software instead. If money would be invested into Sigil, more effort would be put into it, there would be a concrete plan for sure, and more issues would get fixed. While the result would still be freely licensed.
that can integrate both their print and ebook creation processes
That’s true. As Sigil aims at manual editing, it doesn’t do well as part of an automated workflow, other tools are needed for cross media publishing.
that does not mean that it is a good quality EPUB 3 file
If the Sigil output isn’t a good quality EPUB2 file, of course that’s not a good source to convert it into EPUB3. But wouldn’t you agree that a good EPUB2 could easily be converted into a good EPUB3 in general, and if not, why not? If this is the case, Sigil developers should at first fix the EPUB2 output instead of implementing native EPUB3 support, because then a good conversion could take place and at least basic EPUB3 support could be made available this way.
We can give it all the time in the world, but the rest of the ebook world has moved on
That may be true too, but for the free world it’s still valuable to have a solution late instead of never, because that will enable independent publishing in relevant formats, even if not all of the new fancy features are supported right away.
Sigil is currently under development again. EPUB2 vs EPUB3, not much different if you just want to read. To have read along text, etc, etc.,you have to have EPUB3.
There are still many EPUB2 readers out there. Want to leave them in the dust?
Thank you for this great article about epub editing.
After years of self-publishing ebooks for Apple iBooks, Kindle, Kobo, Sony, Nook Press, etc. I decided to create the simplest online tool to create beautiful ebooks. We have just launched ebook leap – we would love for you to give it a try (it’s free to try) and share any feedback you have with us.
We are looking forward to hearing from you!
Hello,I read your new stuff named “Editing EPUBs in the post-Sigil world | EPUBSecrets” regularly.Your writing style is witty, keep it up! And you can look our website about proxy list.
Note: Sigil appears to be back–the latest release was a week ago.