Keith Fahlgren's dashboard

We've proposed that to Amazon, and will continue to suggest it, but they are the folks you need to be asking about this. They seem pretty intent on providing content that they control, and I think they see Safari as a competitor. But we'd jump on this. That being said, all of the same issues discussed previously, about the Kindle's lack of monospace font support, apply to Safari on the kindle. – timoreilly, about 12 hours ago

I see a lot of replies of getting O'Reilly books on the Kindle, but what about Safari? I wouldn't mind paying an extra 5 dollars or so a month just to access a Safari account from the Kindle.

Got it, Thanks for the info. I checked their site and it does say that Kindle supports MOBI files. This will keep my hopes up!!
Few more question: Do you know by what time frame this is going to happen? Are you going to publish only new books or old and the existing ones in the MOBI format?

Viren: Font support isn't a publisher problem, it's a device (Kindle problem).

I would be surprised if converting the PDFs with the Amazon converter yields acceptable results (mainly because of the font problems). We hope to provide .mobi files for many of our titles, which should sidestep the need for customers to convert PDF files themselves.

I understand the problem and don't know how your systems are designed, but inability to change fonts on a piece of content...that's what gets me...but you guys are publishers I have to take your word for it.

One more thing about the PDFs you were talking about..will I be able to convert these to Kindle format through Amazon's conversion program? Or, do I have to go the conventional route of opening them on a computer cauz if I have to open it on a computer then the entire argument of having a portable device such as Kindle is lost. I may as well open the pdf on my computer.

I see two problems with this situation:
1) I will have to buy the book on Kindle and then buy pdfs from Oreilly, how do you address that?
2) Now instead of one device I will have to manage 2 devices Kindle and Computer if these pdfs are not convertable through Amazon's program.

Hmm, what may work for the lacking fonts are images of rasterized fonts. It'll show up right and you can tweak out the renderer exactly for how you want the code shown. Error on the big font side and you should be good. – Lally, 7 days ago

Hi Viren,

Viren wrote:
> So, its an important aspect of your books. In my sincere opinion, could you
> guys just change the fonts if its not that big of a deal?

(reiterating what Tim wrote)
At this point, it's not the lack of a single font that bothers us, it's the lack of a whole class of (important) fonts. We certainly would use any monospace (fixed-width) font, but the Kindle doesn't provide a single one. We're currently evaluating other options to see if a different approach to code fonts and whitespace makes more sense.

> The books will not meet the practical purpose if code is unreadable.

We hope to counter some of this anxiety by making PDF versions (with good typography) available alongside any ebooks. That way, when the reader is in doubt about the meaning of a particular section they'll have another, more legible, version available.

@Keith: Thanks for the update! It's comforting to know that there is a technical reason why I can't carry around all of my tech books in my pack with me rather than a political one regarding openness of format.

I'd prefer be able to make the proprietary/open choice, but I'd rather have proprietary and closed than nothing at all :)

I'll go make my voice heard with the kindle team!

@Keith: Thanks for that explanation. It makes a lot of sense. I'm emailing kindle-feedback to add my vote for a monospace font.

@rodbegbie: One of the remaining problems preventing a full adoption of the Kindle from technical publishers like O'Reilly is the lack of any fixed-width ("monospace", Courier) font on the Kindle. We've figured out ways around most of the other constraints, but we're reluctant to sell our content without the ability to present programming code properly (no carriage returns, spacing, vertical alignment).

Hi,

> What authoring tools would you recommend for content published both
> on-line and on paper?

Without hesitation, an XML format will provide you with the best chances for re-use. That said, adopting XML workflows can be tricky and choosing the right standard (like DocBook) is important to get right & dependent on what sort of stuff you're writing.

For a more specific answer to your question, our others write DocBook in vim, emacs, oXygen, and XMLMind's XML Editor, among other pieces of software.

> I read that O'Reilly use XML, and know you have used docbook in the past.

We do indeed use DocBook inside O'Reilly as the canonical storage format for the majority of our titles. DocBook provides a rich set of semantic markup that maps well to O'Reilly's content (perhaps because we helped start the discussion that eventually led to the DocBook standard many years ago). Over the last few years, we've started pushing DocBook more heavily as an authoring and manuscript format because, like you, we've become more interested in multi-format publishing.

DocBook is very good in this regard expressly because of its rich semantics: in the XML world, it's typically easy to go to a simpler format, so the DocBook-XSL projects already have tried-and-true output into PDF (via XSL-FO), HTML Help, (X)HTML, and others. I've recently contributed another output format, the IDPF's .epub standard, which took only a couple of months on the side to get implemented.

All that said, the big downside with DocBook is the complexity of the standard (hundreds of tags) and the complexity of the toolchains (for HTML, PDF, etc). I'd suggest skimming the definitive DocBook-XSL reference, DocBook XSL: The Complete Guide (http://www.sagehill.net/docbookxsl/in...) to see if you're interested in both the rewards and the drawbacks. If you'd like to chat with others, the http://docbook.org page has instructions for joining the docbook and docbook-apps mailing list, both of which are very helpful to newcomers. Finally, if you're not in a rush, keep an eye on the work being done by the OASIS DocBook SubCommittee for Publishers, which is working on a smaller version of DocBook for non-technical folks (I'm a member of that).

For more context on choosing an XML workflow, check out:
* http://toc.oreilly.com (the place for publishers trying to innovate)
* http://xml.com/ (All things XML, search for 'publishing')
* http://www.thecontentwrangler.com/art...

> Is this a good route to go down?

Yep, but it takes a lot of work to get setup.