Quote:
Originally Posted by charleski
Plugins will certainly be a useful addition. As far as the language goes, I think that while Python may be unwieldy, it's the only scripting system with the flexibility to make it worthwhile.
I only use Book View for previewing, but spent quite a lot of time fixing some of its defects and missing features for this release, as it's clear there are many who use it extensively. I think a move to TinyMCE would address a lot of the remaining issues, but will involve a fair amount of work.
Removing Xerces will actually speed things up quite a lot, but it's so deeply ingrained into the core of Sigil that it'll be an extensive change. I think Xerces offers advantages for handling pure xml components like the opf and ncx files, but the xhtml might be a candidate for a more simple string store.
As far as the professional users you mentioned in your other blog post, I think the fact is that when it comes to ebook production many of them are vague, full stop. The publishing industry as a whole has a rather low level of technical acumen when it comes to ebooks and this process is often farmed out to external conversion services who work to a price, which is reflected in the low technical quality of the majority of commercial ePubs. A large chunk of the minority who do know what they're doing have been working with DocBook, which has been around for a long time, and they basically need XML schema translations, which is the main rationale for using OxygenXML to output ePubs (which is otherwise far inferior to Sigil as an ePub editor). |
Charleski:
Docbook and xml schema translations are all well and good for plain, narrative fiction or textbooks; but the moment you get into more complex layout, it's problematic
at best. We do a large chunk of simple paragraphic fiction, but we also do a boatload of non-fiction, self-help and political titles, the latter two replete with everything from simple fleurons to tables out the wazoo, to colums of data, graphics, diagrams, you-name-it. XML->XMSLT->ebook sounds all spiffy, but in practice, the moment you get away from plain fiction...well, at the moment, it's a pipe dream. And trust me, I wish it wasn't.
We're certainly not vague about what we do; but each of my Crews has its own way of working. One fiction crew prefers to use NTPro clips to strip and clean Word's (and OO's and WPerfect's and Works, etc.) crappy html; the other uses a Perl program written by its TL. Another prefers to use Epsilon as its editor. I don't force my Crews to do it in a singular fashion, as each has its own TL, who trains his or her own people.
One thing that we all DO have in common, though, is that the mostly-finished xhtml gets finished in Sigil. We clean the html; put it into an html/xhtml editor; regex; define the elements, add the CSS (the two things that are conformed across all teams) spell-check; add the sigil chapter breaks...and then it goes into Sigil to finish up, using it for visual checks, as well as fast way to make the ncx. We also use it for editing everything that we get back from the authors, given their endless propensity to re-write post-production.
We use it to prep (with faux tags) the V-epubs and audio-pubs that we make as well. I'd guesstimate that well over 90% of our collective time in Sigil is in CV, not BV, which has very little value to us.
So, there's naught vague about what we do; what is "vague" might be the proprietary programs, routines, macros and codes we've written to make our jobs faster and easier. But no matter how we get there, the end result is that a cleaned, spell-checked, regexed, element-defined and CSS-applied xhtml document is what gets fed to Sigil, for that final tweaking and visual check, along with ncx tweakage as needed. AND any subsequent editing. We also then use Sigil to strip out the covers and do the minor tweakage needed to create our "4 Kindlegen" epubs, which we feed to Kindlegen to make our mobis. Oh, and, of course, a quick in-process Flight Crew check, just to see if we've screwed the pooch anywhere.
HTH,
Hitch