K4iOS & Night Mode Media Queries

[mattmc]

Okay, maybe I'll have more luck with this question than my last one

Anyone know how to target K4iOS with a media query?

Specifically, I have some text that needs to be a certain shade of gray. It renders lighter on eInks, so I'm using some media queries to make it a different shade between Kindle eInks and Kindle Fires:

/* Regular eInk Kindles get a very dark gray... */
.blah {
	color: #333333;
}

/* ...then, make it lighter for Kindle Fires */
@media screen and (device-aspect-ratio:1/1) {
	.blah {
		color: #666666;
	}
}

This media query is based on some research from dvschultz, and it seems to work great. However, I then loaded up my file on K4iOS, latest version. (Yes, I did it via AZK...)

The text in question shows up as #333333 on K4iOS. I suppose that the ultra-hacky MQ I'm using there doesn't work, which shouldn't be surprising.

So...how do I target K4iOS with an MQ?

And, bonus question, anyone know of a way to target Night Mode in K4iOS (or Kindle Fire, too, actually) with an MQ or other selector? You can do it in iBooks...

Cheers

[mattmc]

Re Kindle Night Mode CSS:

Funny, Aaron Troia asked the same thing here: if it's possible to target night mode with a media query or somesuch. After review, I don't think it's possible.

In iBooks, Apple changes between Night/Sepia/Etc. by attaching a CSS class to the root document element. So you can actually detect when it changes and so on and adjust for it in your own CSS--which is awesome, until people get around to adopting the legitimate night-mode media query. (Although, what about sepia/half-night mode/any others? Something for the CSS standards body to think about...)

[mattmc]

(The conversation with myself continues!)

Re targeting K4iOS with a media query:

I haven't been able to discover a media query that did this. K4iOS seems to answer exactly the same as Kindle e-Inks in all ways except screen dimensions.

Rewind:

In the Amazon Kindle Publishing Guidelines, it recommends that you set your default styles to apply to Kindle e-Inks, and then use the following media query to target Kindle Fires:

@media screen and (device-aspect-ratio:1280/800) {...}

Then, to target iPads, it recommends that you do a standard device-with query:

@media (device-width: 768px) {...}

Okay, so...does that work?

Sure. But then you need to do media queries for all sizes of iPad and iPhone that exist. That's doable, but not a small set of queries.

But then what about KDroid? There's no way you're going to set up media queries that will catch all the KDroid stuff. And what about on desktops? Hm...

Idea:

1. Have default styles apply to K4iOS, KDroid, and anything else.
2. Target Kindle eInks with specific media queries.
3. Target Kindle Fires with the above media query if necessary.

This seems feasible because there's actually a fairly small list of Kindle eInks. What's that query going to look like?

/*
kindle 1/kindle 2/kindle DX, 
paperwhite portrait,
paperwhite landscape,
"other kindles" portrait,
"other kindles" landscape,
voyage portrait + oasis,
voyage landscape
*/
@media amzn-mobi,
  amzn-kf8
  and (device-height:1024px) 
  and (device-width:  758px),
  amzn-kf8
  and (device-height:758px) 
  and (device-width:1024px),
  amzn-kf8 
  and (device-height: 800px) 
  and (device-width: 600px), 
  amzn-kf8 
  and (device-height: 600px) 
  and (device-width: 800px),
  amzn-kf8 
  and (device-height: 1448px) 
  and (device-width: 1072px),
  amzn-kf8 
  and (device-height: 1072px) 
  and (device-width: 1448px) {
    p {
      ...
    }
}

The above query was compiled based on an epubsecrets post by Derrick Schultz and a gist by Sanders Kleinfeld.

Note: I haven't found media queries for the Kindle Oasis. If anyone has these device metrics please let me know so I can add them.

I have tested this query on the following devices and it correctly detects them as e-Inks:

• Kindle 1st gen
• Kindle 2nd gen
• Kindle Keyboard
• Kindle PW1
• Kindle PW2
• Kindle Oasis

I tested the query on the following platforms and it correctly did not detect them as e-Inks:

• Kindle Fire 1st Gen
• Kindle Fire HDX
• Kindle for iOS 4.20 on iPad
• Kindle for iOS 4.30 on iPod Touch 5th Gen
• KDroid on Samsung Galaxy Tab 2, 7.0

Trying to get my hands on later generation Kindle Fires. I should also probably buy a Voyage...

Anyway, this basically allows me to differentiate the e-Ink kindles from the rest of their brethren! Hooray.

UPDATE: Added Oasis to the list of tested devices. 25-Jun-16

[Hitch]

Originally Posted by mattmc

(The conversation with myself continues!)



Anyway, this basically allows me to differentiate the e-Ink kindles from the rest of their brethren! Hooray.

I wish I'd seen this thread sooner; I'd have said: lotsa luck on that MQ. Although, I'm pretty sure that even if I had, you'd have gone ahead, anyway, right?

If you develop it, AND IT WORKS, I'd love to see it. (Hell, for that matter, if you make any progress, and want some help, give me a ping, and we'll throw in some time on it too.) You probably noticed that I'd said something on Derek's post..wow, two YEARS ago? Sheesh.

This is yeoman's work, Matt, the stuff you've done on the eINK MQs. Super, that. If I see something that will do the iOS trick, or we develop something, I'll return the favor, but nothing we've tried (I see that we have GMTA--Great Minds Think Alike--as we have a ton of overlap, on what you tried), has done it thus far.

Hitch

[jhowell]

I did a test using the Kindle Previewer 3 beta and found that having a media query with device-aspect-ratio, device-height, or device-width prevented the book from supporting enhanced typesetting. I don't know whether or not the same would hold true of a book sent through KDP. This could be a factor if you (or your customers) care about enhanced typesetting.

[Hitch]

Originally Posted by jhowell

I did a test using the Kindle Previewer 3 beta and found that having a media query with device-aspect-ratio, device-height, or device-width prevented the book from supporting enhanced typesetting. I don't know whether or not the same would hold true of a book sent through KDP. This could be a factor if you (or your customers) care about enhanced typesetting.

The Lord High Zon Giveth, and the Lord High Zon taketh away...

All humor aside--you saw this post-Previewer, right? The beta? And we don't know what might happen in the PW (Publishing Workflow).

Warning--apparently, more "hands-on" work is indeed being done at the PW. So, now--yeah, wait for it--we can't be 100% positive what our books will look like (fonts, enhanced typesetting, etc.) until the accursed things are live. This isn't surmisal. It's confirmed.




Hitch

[jhowell]

Originally Posted by Hitch

All humor aside--you saw this post-Previewer, right? The beta? And we don't know what might happen in the PW (Publishing Workflow).

It could just be a deficiency in the previewer. The only way to know for sure is to publish a book with this type of media query.

Originally Posted by Hitch

So, now--yeah, wait for it--we can't be 100% positive what our books will look like (fonts, enhanced typesetting, etc.) until the accursed things are live.

Truth.

[Hitch]

Originally Posted by jhowell

The only way to know for sure is to publish a book with this type of media query.

Hitch

[mattmc]

Originally Posted by Hitch

I wish I'd seen this thread sooner; I'd have said: lotsa luck on that MQ. Although, I'm pretty sure that even if I had, you'd have gone ahead, anyway, right?

Maaaaybe.

Originally Posted by Hitch

If you develop it, AND IT WORKS, I'd love to see it. (Hell, for that matter, if you make any progress, and want some help, give me a ping, and we'll throw in some time on it too.) You probably noticed that I'd said something on Derek's post..wow, two YEARS ago? Sheesh.

This is yeoman's work, Matt, the stuff you've done on the eINK MQs. Super, that. If I see something that will do the iOS trick, or we develop something, I'll return the favor, but nothing we've tried (I see that we have GMTA--Great Minds Think Alike--as we have a ton of overlap, on what you tried), has done it thus far.

Haaaaay! That's real swell of ya. Thanks, and thanks!

(And yes, I did see that post from you, hehe.)

Originally Posted by jhowell

...if you (or your customers) care about enhanced typesetting.

Nope, not a whit.

Originally Posted by Hitch

Warning--apparently, more "hands-on" work is indeed being done at the PW. So, now--yeah, wait for it--we can't be 100% positive what our books will look like (fonts, enhanced typesetting, etc.) until the accursed things are live. This isn't surmisal. It's confirmed.

Why, dear god? Just...why?

[Hitch]

Originally Posted by mattmc

Maaaaybe.



Why, dear god? Just...why?

(n.b.: I'm not sure we're all down with the "enhanced typography," either. I know that I just am not wild about Bookerly. I mean, yawn much? Although, I confess, hyphenation possibilities would be loverly.)

Now, onto the question: I don't know WHY. I'm as perplexed and vexed as anyone, I assure you. We've all known for a long time that the PW occurs after "save and publish;" we've know that the SRL can change, when messed with in the PW. We know that other things, not discussed by the Zon, can/do/may change in the PW. (For example, the wee "leave us a review before you go" thing. Believe it or not, that's been applied SELECTIVELY for years now.)

I can only surmise that something in this font's font characteristics--a descender, ascender, the metrics (weight, proportion, letter form, midline style, X-height, units above/below the baseline, internal leading...the truetype file structure, perhaps?...SOMETHING) doesn't play nicely with either KP or the other font.

The font survived the first build (KG). It survived the 2nd (mobi then loaded at KDP). We sent the post-step-7 "Preview mobi" to the client, as previously, that's been ironclad. Baked in. Immutable.

And now...it's not. And they've confirmed that this type of thing CAN CHANGE at the PW. And obviously, it's not being changed in any way that we want, not thus far. We now can't know. CAN'T know, not for sure, not before it's published. That part makes me ever so slightly nauseous, thinking about the repercussions. I can't imagine how this is going to play out. Not for us. I really can't.

grrrrrrrrrrrrrrrrrrrrrrrrrrrrr rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr


Hitch

[dgatwood]

Originally Posted by Hitch

The font survived the first build (KG). It survived the 2nd (mobi then loaded at KDP). We sent the post-step-7 "Preview mobi" to the client, as previously, that's been ironclad. Baked in. Immutable.

And now...it's not. And they've confirmed that this type of thing CAN CHANGE at the PW. And obviously, it's not being changed in any way that we want, not thus far. We now can't know. CAN'T know, not for sure, not before it's published. That part makes me ever so slightly nauseous, thinking about the repercussions. I can't imagine how this is going to play out. Not for us. I really can't.

At this point, I think we need to send this thread and the embedded fonts thread to jeff@amazon.com. KDP's publishing workflow causing content breakage has been an ongoing problem for three years now. It is well past time to light a fire under someone's you-know-what.

As a publisher, when I deliver content, I expect my customers to get precisely what I delivered to the content distributor. If Amazon's publishing workflow makes further changes (beyond trivial stuff like inserting a review page at the end or changing the start-reading marker), then our entire QA process becomes a waste of time and effort.

No other content distributor makes radical, content-altering changes to content during their ingest. That's just not acceptable in a delivery partner.

[Hitch]

Originally Posted by dgatwood

At this point, I think we need to send this thread and the embedded fonts thread to jeff@amazon.com. KDP's publishing workflow causing content breakage has been an ongoing problem for three years now. It is well past time to light a fire under someone's you-know-what.

And..you think that might actually do it? Listen, I'm all "up with Amazon." I am. I wouldn't have the biz that I do, without them, and I damn sure know it. BUT, there are those things that they'll change; those things that they'll do...and those that they won't. There are wee things--honestly, I wouldn't have thought that they'd have import to ANYONE--that I've been trying to sniff out for at least two years, and that's not going anywhere, so far. I'm not "in like Flynn" with those guys, but I do have names, emails AND real-live phone numbers, in Seattle, to gab with when the ubiquitous hits the fan...but with this type of thing (glitches that aren't explicable or expectable, that happen in the dark, with no ability to test, to prevent...to even know remotely that it will happen), I can't get much forrader than I am now.

IME, they are highly responsive to author/publisher complaints (this may be your bailiwick, DAG!), and not to working slobs like me. I'm an afterthought, if you think about it...I'm no more important than the cover designer. Hell, less. I don't make them MONEY. Publishers like you, do. I know that every author client of mine, that has reached out to them for this, or that, or the next thing, seems to get fixed damn skippy. Me? To quote The Wire, "Sheeeeeeeeeeeeeeeiiiiiiiiiittttttttt." Of course, it's also true that by the time I email them, whatever it is is some big-ass issue, that isn't easy to fix (or, hell, we'd have fixed it), OR, we've developed a workaround (hello, fonts!). So...they likely don't have the same impetus to help me...more of a "formatter, heal thyself" mindset, I suspect.

Spoiler:

n.b.: I do think that somewhere in the heap, there's also a mindset that's a bit like, "why can't you be a good girl, and go make simple books with Beginner Blue headings and no fonts, like everyone else?" in there. I can't quite put my finger on it, but every once in a while, I get a whiff of that. As in, "well, if you wouldn't keep doing X, that wouldn't keep happening to you."

Does anyone know if the might Goog sees under the spoilers? Anyone?

As a publisher, when I deliver content, I expect my customers to get precisely what I delivered to the content distributor. If Amazon's publishing workflow makes further changes (beyond trivial stuff like inserting a review page at the end or changing the start-reading marker), then our entire QA process becomes a waste of time and effort.

Yup. Funnily enough, that's how OUR publisher clients feel, too. You unreasonable bastards!

No other content distributor makes radical, content-altering changes to content during their ingest. That's just not acceptable in a delivery partner.

Well...arguably, Kobo does/can/has. But that's a different conversation.

I could email him, sure, but I genuinely don't expect anything other than, MAYBE, a form letter in return. Maybe we should have a contest and a poll: we all send it, and see WHO gets the return email, if anyone? Or who waits the longest, or...? (Lemonade from lemons, boys and girls).

That's my take.


Hitch

[dgatwood]

Originally Posted by Hitch

Well...arguably, Kobo does/can/has. But that's a different conversation.

Kobo makes extensive changes, but if I'm remembering right, they're all in the realm of noise—adding extra spans to work around bugs in their rendering engine, adding extra attributes to make it easier to maintain reading position in the book, etc. Those sorts of trivial manipulation are about as safe as you can get; even if you make a million such changes, they won't affect the customer experience other than perhaps pushing up the download size slightly.

I mean yes, pedantically, what they deliver is not a checksum-identical copy of the book, and I wish it were, because it would make certain things easier. But that doesn't really compare with chopping out chunks of your stylesheet arbitrarily....

[Hitch]

Originally Posted by dgatwood

Kobo makes extensive changes, but if I'm remembering right, they're all in the realm of noise—adding extra spans to work around bugs in their rendering engine, adding extra attributes to make it easier to maintain reading position in the book, etc. Those sorts of trivial manipulation are about as safe as you can get; even if you make a million such changes, they won't affect the customer experience other than perhaps pushing up the download size slightly.

I mean yes, pedantically, what they deliver is not a checksum-identical copy of the book, and I wish it were, because it would make certain things easier. But that doesn't really compare with chopping out chunks of your stylesheet arbitrarily....

Yeah. It's new and different. It boggles me, and I'm trying to drill-down, to see if I can find out what's what.

Hitch

[mattmc]

Originally Posted by Hitch

...more of a "formatter, heal thyself" mindset, I suspect.

<spoiler>

Or perhaps, "formatter, format thyself"?

Yes, the Mighty Goog is omniscient. But I don't think you have to worry about Goog-wielding thought police :P

Originally Posted by dgatwood

Kobo makes extensive changes, but if I'm remembering right, they're all in the realm of noise—adding extra spans to work around bugs in their rendering engine, adding extra attributes to make it easier to maintain reading position in the book, etc. Those sorts of trivial manipulation are about as safe as you can get; even if you make a million such changes, they won't affect the customer experience other than perhaps pushing up the download size slightly.

I mean yes, pedantically, what they deliver is not a checksum-identical copy of the book, and I wish it were, because it would make certain things easier. But that doesn't really compare with chopping out chunks of your stylesheet arbitrarily....

I would say it certainly compares. My experience with a Kepub and their wack rendering engine is that it eviscerated my book. Normal page-break CSS doesn't even work: https://github.com/kobolabs/epub-spec/issues/18

To me, that's actually far worse than stripping out your embedded fonts.