More on TechnologyTell: Gadget News | Apple News
Online editor helps you create your first book for dotReader
December 8, 2006 | 5:17 am
|
By David Rothman
You’ll now be able to export from Drupal‘s FCKEditor into documents fit for dotReader–and eventually into OpenReader format. The details are at the dotReader site.
For small publishers, educators and manual-producers, this will be an especially cool wrinkle. OSoft‘s use of the FCKEditor allows you to rearrange chapters effortlessly and do Word-easy editing for dotReader.
You can even choose from one of three style sheets.
As is the case with dotReader itself, this dot-optimized FCKEditor will be adding more features, so feel free to share your wishlist in the dotReader forum.
|
Previous
SUBSCRIBE TO RSS
Comments:
Is there going to be a stand-alone off-line content creation tool for dotReader?
I can’t answer what the OSoft folk intend to do in the future, but since dotReader, OpenReader, and other formats like OEBPS, LIT and Mobipocket are fundamentally based on XHTML, we have all kinds of options to produce dotReader-ready publications. For example, a few of us are working on the “Simple Book” system (to be soon renamed) which provides a uniform framework by which several existing authoring tools can be used.
Yes – but we are probably not going to make it. Instead, we are creating plug-ins for EXISTING content creation tools like OpenOffice and MS Word that would allow the creation of dotReader-enabled content.
Third parties have expressed interest in creating a stand-alone XML content creation tool with a WYSIWYG interface but we do not know where they are in development yet.
Mark Carey
CEO, OSoft
Interesting that none of the Teleread crowd has dinged dotReader beta for using proprietary eBook markup and JAR-based packaging for their “dotReader enabled” content. Instead they get the kid-gloves treatment.
Jon, David: you jumped all over Adobe for minor compliance nits in the beta of Digital Editions, which is standards-based and on track to be fully compatible with the next version of OEPBS, OPS, once it is standardized. In fact we publicly demonstrated last week at an AAP meeting in NYC content-level interoperability across multiple vendors.
Are you determined to play favorites and don’t care that dotReader would make the “Tower of eBabel” even worse ? Oh, BTW, what happened to the much-touted “friendlier DRM”?
Hello Bill, I find it refreshing that two guys working out of their homes in Washington can draw so much attention from a distinguished executive from Adobe. We are honored!
It is obvious that you have not been following ALL of the announcements and other news releases on the http://www.dotreader.com Web site. Had you done so, you would know:
Finally Bill, you will notice that at the top of the http://www.dotreader.com home page, we list what are planned development activities are for each week. This is an open source project. It’s easy to criticize. Would you care to volunteer or make a donation of two licenses for the Adobe Creative Suite 2.3 Premium?
Mark Carey
CEO, OSoft
P.S. If you would like to stay informed, please join the dotReader newsletter.
Bill, I’m happy Adobe has made substantial progress on Digital Editions. Does Adobe plan to open source the source code to Digital Editions?
The reason I ask is that dotReader itself (not including the DRM component) is open source, allowing anyone to adapt the code to his or her reading systems.
That’s the difference between what OSoft is doing, and what Adobe is doing. One has to be careful not to compare apples to oranges.
And don’t forget that if OpenReader and/or OEBPS become common digital publication formats (they both are very compatible with each other), others can join the fun, and quite easily. For example, Opera could make one hell of an OpenReader/OEBPS platform that would be as advanced (I believe more advanced) as anything Adobe could produce (Opera 9 is at the cutting edge of CSS 2.1 and 3.0 support.) And don’t forget Firefox/Mozilla. (This is not the same ball game we see with the Adobe Acrobat Reader.)
Regarding my jumping on Adobe as you describe. Well, Adobe is the closed source code, proprietary company best described as an 800# gorilla. Adobe, like any other 800# gorilla (e.g. Microsoft), must be jumped on whenever they do anything that falls even slightly outside an open industrywide specification. My comments were made in my capacity as an invited expert to the IDPF working groups to assure Adobe strictly followed the IDPF specs which it has enthusiastically embraced. I’m disappointed you took this personally since my only intent was to make sure Adobe stayed on the straight and narrow, which will, in the long run, benefit Adobe.
In addition, as has been explained before, the dotReader format is the “machine-level” format used by the dotReader architecture — other formats, like OpenReader and OEBPS, will be internally and virtually interpreted into dotReader. Since OSoft doesn’t have the effectively unlimited resources that Adobe has, and has chosen a business model built substantially upon open source, they have to prioritize development and get the core components working. Then the modules to interpret other formats, like OpenReader and the IDPF OEBPS (to name just two), are added on.
So publishers who, for example, develop OEBPS Publications for Digital Editions (since they will completely conform to the OEBPS spec) will know their publications will also be rendered nicely on dotReader — by the time publishers produce OEBPS-Next publications, dotReader will already be able to render them. (And hopefully Firefox and Opera will join in the fun, too — imagine what they could do!)
Thus, I would think Adobe would welcome the development of dotReader.
About Jar: Jar is itself quite an open format — it’s just another name for ZIP, just as the OCF is also just a ZIP file. One must not get too hung up on the container format — it is what is inside which determines compatibility and reading system coding difficulty.
I’m advising OSoft, since I’m familiar with OCF, about how its next-gen container can be fully compatible with the IDPF OCF Container, just as Adobe has said its container will be compatible with OCF. Note that Mark Carey, the CEO of OSoft, himself has said they will support the OCF — it is actually trivial to do so. After all, we are simply talking about ZIP. Whoop-dee-doo. The OCF is being blown way out of proportion with a lot of marketing fluff — when one really analyzes its purpose and impact in the digital publication universe it’s just not that important. ZIP is ZIP no matter how it is sliced and diced.
Mark,
Hey, I’m working out of my home in Washington too (today, anyway). So we’re even.
Re: dotReader “not creating another format” – when I looked at a sample eBook from your beta it was a bunch of markup in your own namespace. And you were using JAR in a unique-to-dotReader way to package this content. So this sample eBooks would be useless to any other reading system unless they implement your proprietary format and packaging approach. If that’s not creating another format, what is?
Jon,
Re: Adobe being a “closed source proprietary company” – well we just made the largest open source contribution to Mozilla Foundation in its history, in the form of our next-generation JavaScript interpreter technology. That’s only one of a number of open source activities going on.
As a commercial SW company we don’t open source everything – but I thought the main objective of the OpenReader manifesto was to push for a common eBook format, to eliminate the “Tower of eBabel” and help publishers and users. I’m all in favor of this, hence scratching my head at the “editorial stance” towards what appears to be a step in the other direction.
Bill,
The current packages available for the dotReader are based on the Thout 1.0 markup. This was done initially in order to be backwards compatible with the 200+ titles for the ThoutReader. We have made no inferences otherwise. Now, about the donated software…
Mark Carey
CEO, OSoft