Quote:
Originally Posted by Hitch
One last comment: with regard to your unhappiness with Amazon: sure, they decided on a proprietary format. So what? It's all well and good to bitch about it, but I'd rather have them supporting ALL their Kindles, rather than have them Apple it, and throw out hundreds of thousands of buyers/users, just because they want to FORCE the person to buy a new device.
|
Quote:
Originally Posted by Trane
That seems to be exactly it. Instead of producing tablets compliant with standardized code to begin with. Or, at the least, writing conversion code that is device-specific. Yeah, I know to a degree they do that, but not if they don't allow certain things b/c the e-ink devices can't support it. The conversion code should be slick enough to do what it needs to produce a separate e-ink version
|
You can do something similar, but you need to feed it a lot of @media code (display some code in old MOBI, different code in KF8). See the Kindle Publishing Guidelines ("Appendix C: Media Queries").
That may bring about a whole other host of headaches for you.
Something similar would have to be done if you wanted formulas as PNG (MOBI) + SVG (KF8). Personally I don't bother with @media for images, BUT I created a workflow (and use consistent code) that would allow me to easily update in the future if needed.
Quote:
Originally Posted by Trane
I have a very low opinion of tech companies that take something that is standardized and make a proprietary version for greed... and then make it non-compliant on top of that. (MS IE and the browser wars of the 90s is a good example!) It screws the whole industry up. So never bought a Kindle but rooted an Android tablet with XDA custom ROM and use apps like Aldiko and Moon+ Pro.
|
lol... you complain about Amazon botching the display of the HTML/CSS, but you use Moon+ which throws all your hard-work CSS right out the window. :P
Quote:
Originally Posted by Trane
Before I redo all 130 images... a question for all. Most are intended to be only 1/4 of the page (at full width). Is 600px width adequate? The PDF says to make them twice the intended size so that can be zoomed in 2x w/o blurriness, but this would mean re-downloading larger originals, then applying the effects in PS to each one again (border contours, etc). Opinions?
|
As Hitch mentioned, that is up to you (we can't see your images).
But as a general workflow rule, you typically want to do all of your additions/changes/tweaks as close to the original resolution as possible. Then you would just be able to take the completed work and resize/export to X resolution and export... instead of having to redo multiple extra steps per resolution.
Also, when dealing with images in ebooks, you should always keep in mind the potential for a future Print edition, where you would NEED much higher resolution images (300+DPI).
Like in GrannyGrump's restorations of drawings in Public Domain books. She works directly from the source scans (300+DPI), cleans up the image as best as possible, then resizes downwards for EPUB. In the future (when better devices + future formats roll around), she could easily just drop in the higher resolution image.