View Single Post
Old 01-20-2019, 03:38 AM   #25
Hitch
Bookmaker & Cat Slave
Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.
 
Hitch's Avatar
 
Posts: 11,503
Karma: 158448243
Join Date: Apr 2010
Location: Phoenix, AZ
Device: K2, iPad, KFire, PPW, Voyage, NookColor. 2 Droid, Oasis, Boox Note2
Quote:
Originally Posted by DNSB View Post
To toss in my two cents worth since I vaguely seem to remember that this thread was about "Best practice to add an image", if we are talking epub, image sizing can be done as percentages or for full page images by using svg wrappers (while you can do partial page images with an svg wrapper, some ereaders are not happy with the result) with no need for media queries. Now if we want to start talking about epub3 audio and video, media queries can come back into play but for simple image sizing, they are a non-issue.

As for ADE 2.xx being old news? Even with the firmware currently loaded on my Clara HD, I needed to convert to kepub for any media queries in Klaus Schallhorn's media query test ebook to do anything. An old Kindle DX one co-worker still keeps around also lacks media query support. I also have another test ebook which has a couple of empty amzn media queries which crashes and burns on older RMSDK versions though I haven't tested it in the last 18 months or so.

Actually, the thread derailed somewhere along the line, and the conversation veered off into whether or not color images are viable on eInks, or something like that. I threw in MQs on that topic. I mean...personally, I find that most eInks--even my trusty old K2 (the battery of which is, I believe, finally going to that great Power Source in the sky....) render images remarkably well, color or otherwise. BUT, if someone is convinced that they need grayscale or B&W images, to "work" on an eInk, well...mqs.

You can easily swap out images--color for the tablet readers, B&W for the eInks, using MQs. That's what I was talking about, not the sizing, per se--although, we do, in fact, also use MQs for sizing issues, so that the KF7s render based on pixel sizes for each specific image, whilst the KF8s, etc., render using percentages/ems.

FYI, while DXes, K2's, etc., do not (themselves) have support for mqs, the Amazon rendering engine does. You can produce quite nice "old mobis" using MQs whilst simultaneously producing tasty KF8s and all that, using MQs. We use MQs all the time, at my shop, for all sorts of things. You can alter the color of text, if it's going to be seen on an eInk, for example. You can change font sizes, based on screen size.

There's even a section in Appendix C that talks about using MQs specifically for "backward compatibility with MOBI." You can target device-aspect-ratio, or device-height/width, to narrow down what you're doing, for eInks or KF7 devices over KF8, or vice-versa. The guidelines even have an example that targets 3 iPads, via the device-width. They have another that targets all Fires, using the device-aspect-ratio of 1280/800. We've been using similar coding, not to be "fancy," but to work around issues in the K4iPad/iPhone readers, for a few years now.

So, you're right, you don't use MQs on the DXes, K2s, KKeyboards, etc.--you use MQs to write the code for the Fires, the PPW, the Voyages, K4iOS, etc., and have the base code be the working code for the KF7s. :-) You just have to back into it. :-) It works.

FWIW.

Hitch
Hitch is offline   Reply With Quote