Hi Avdi,
The .mobi renders pretty well on my Kindle when I view horizontally - the code wraps too often in vertical orientation to be useful.
I've noticed a few problems:
- Figure 2.1 "What this is not" is rendered differently to the PDF, with the .mobi using indentation instead of bold for line separation.
- There's incorrect escaping of some symbols on code captions e.g. Exhibit.applicable\_to? should be Exhibit.applicable_to?, or Delegating \#exhibit instead of Delegating #exhibit.
- Links appear to work correctly, as do images. However, there are occasions where image captions come through on a page on their own, for example "Validation error message" at the end of Chapter 10. I suspect there's little that can be done about that.
All in all though, it looks great!
On Thu, Mar 8, 2012 at 10:11 PM, Rob Sharp <r...@sharp.id.au> wrote:Hi Avdi,
The .mobi renders pretty well on my Kindle when I view horizontally - the code wraps too often in vertical orientation to be useful.Hmm. Good to know. I'm not sure how much control I have for Kindle output; but on the off chance I can actually control the code font size, would making it smaller leave it still readable?
All in all though, it looks great!Thanks again for the feedback. I probably can't fix many of the issues above; the Mobi format is... how to put this... really, really awful to work with as a technical ebook author. It's basically HTML circa the 1990s and then stripped down for viewing on a PalmPilot. But I may fiddle with it a bit on the Kindle previewer.
I think so - the 'code' font is significantly larger than the font used for text, even when I set the system font size to it's smallest setting.
Something weird with the cover image in the android kindle app. In the
'Home' view I see the cover image, but in the 'On Device' view I just
get the placeholder image instead.
As with most epubs/mobi, the code is quite hard to read on small devices due
to linebreaks. If there's any chance to get the code font smaller, I'd
give that a try.
In the 'Summary' on the 2nd point you write 'Your need business
objects...'. This should be 'You need...'.
The 'List of Figures' in the PDF seems broken, I can only click on links
2, 3 and 5 in ezPDF.
With Aldiko, the epub's images don't scale down, they are all a little
too wide in portrait view.
HTH,
Nikolay
--
"It's all part of my Can't-Do approach to life." Wally
Some other minor glitches with the Mobi rendering:
* The captions for code blocks are shown in italics, but those for images aren't.
* All underscores and hash symbols in captions have backslashes before them, eg "stub\_module" or "The \#picture? predicate"
* Where the text refers to a specific line in a code sample, the line number is missing, eg "Note the use of stub! at line nil" in the "adding timestamps" section. Oddly, there's one (the last bullet point in section 12.2) that says "line entrysave", with the "save" being subscript.
* Incidentally, was it intentional for the Mobi to show section numbers but not figure or listing numbers, but vice versa in the PDF?
* In section 12.3, "after_save hook" renders with no underscore and "save" as subscript (this is true in the PDF too).
I also spotted a few typos as I was reading through the latest version:
* On p17 of the PDF, in the first paragraph of "a note on scale", you use an en dash, rather than the em dashes used elsewhere.
* On p27 there's a missing space in "else'spost".
* At the top of p43, shouldn't that be the Post model, rather than Posts?
* In several places you refer to dependencies being "inject-able", even though injectable (without the hyphen) is a real word.
* A couple of rogue apostrophes have crept in: "in it's place" on p86, and "that's it's purpose" on p146.
* There might be some inconsistency in the way you refer to methods in the text (or more likely it's context-dependent and I've just missed the context). Mostly you use the #method_name convention, but sometimes you omit the hash (eg render_body on p150) or use parens instead (eg exhibit() on p152).
* On p155, I'm pretty sure the possessive of class should be class's, not class'.
One comment on the actual content: when you introduce the stub_module helper, you talk about how, if you just dumbly stubbed out the module, the real one might not get loaded in later tests. Am I right in thinking that for this to work, the Rails autoloader needs to be active before the first time you use stub_module? I've had problems in the past running rspec on a directory with a mixture of isolated and integration tests – Rails isn't loaded until it reaches the first file to include spec_helper, by which time it might be too late. I might be wrong, but I don't think stub_module would help in this case.
Thanks for writing this book, and for giving access to it as a work-in-progress. The incremental versions gave me the impetus to read most parts of the book two or three times, which I think helped the ideas sink in much better than if I'd just read the final version once.
Kerry