Crazy eReader question

[Ken_Moorhead]

Hello all,

I've written myself a book and it has survived it first round of readers. Now it's off to it's second round of readers.

To facilitate this for those who asked I have made an epub2.0 file (several actually) and have gotten it the point where it behaves on everything it has so far been thrown at. I'm getting the hang of it, slowly!

The final ebook itself is ready, so this post is more for my own curiosity than anything else.

The question I have is more technical than practical. I am proficient at computer code, in fact it is my day job, but I am not an HTML guy. That proficiency is probably a bad thing, since it has me wondering. ePub is just HTML, or variant of HTML. This would make e-readers browsers of some sort, and as such they should, in theory, be able to do browser things. And one thing a browser can do is report environmental conditions.

With that information you could (in theory) branch which HTML files are in play, or even (possibly) branch the markup itself, to adapt to user settings or device settings.

Is this possible?

My gut says no, but it seemed within possibility, so I thought I'd ask.

TIA!
Ken

[DNSB]

There are media queries that can be used in ePub books and also some media queries used by Amazon when generating Amazon format ebooks from an ePub master.

For the most part, if you are only generating ePub and using relative measurements (em, %, etc.) instead of absolute measurements so everything autoscales to the screen size, I haven't found most media queries to be all that needed

[RbnJrg]

Originally Posted by Ken_Moorhead

...
With that information you could (in theory) branch which HTML files are in play, or even (possibly) branch the markup itself, to adapt to user settings or device settings.

Is this possible?

Ken

On epub2, no (or very poorly). On epub3 you have javascript and with it, you can know a lot of things about the device (or app) where the epub was opened (and the position and size of the elements contained in that ebook) and to adapt the layout accordingly. For example, one old epub3 ereader is Gitden; is deprecated, but even so is quite good. But it has a drawback; you can't set -with the app- the margins of the body text; with javascript you can know that the epub is being opening on Gitden and then set margin by means of css styles (those styles are only applied if the epub was opened under Gitden).

[JSWolf]

Originally Posted by RbnJrg

On epub2, no (or very poorly). On epub3 you have javascript and with it, you can know a lot of things about the device (or app) where the epub was opened (and the position and size of the elements contained in that ebook) and to adapt the layout accordingly. For example, one old epub3 ereader is Gitden; is deprecated, but even so is quite good. But it has a drawback; you can't set -with the app- the margins of the body text; with javascript you can know that the epub is being opening on Gitden and then set margin by means of css styles (those styles are only applied if the epub was opened under Gitden).

But in most cases, you have no need for javascript. As long as this eBook is just a simply formatted novel, don't use any advanced code. The simpler the code the more it's compatible.

[RbnJrg]

Originally Posted by JSWolf

But in most cases, you have no need for javascript. As long as this eBook is just a simply formatted novel, don't use any advanced code. The simpler the code the more it's compatible.

I answered the OP question; he wanted to know if it was possible to adapt an ebook to the user device.

Regarding your second statement, I wrote here many times that an epub must be an epub3 with fallback code for epub2. Your simply formatted novel to me is a challenge to convert it in somethimg more elaborated, with nice chapter headings, dropcaps, fleurons, etc., etc., etc. Here you have two screenshots of a simple novel of mines:



The dropcap is controlled by javascript so always it has a perfect size (on epu3).

[Quoth]

That is decorative and not simple. Irrelevant for people wanting to read a novel.

Even for paper it's over the top except as a facsimile of something over 200 years old.

Waste of time, breaks easily and pointless on a phone.

[Turtle91]

Originally Posted by Quoth

That is decorative and not simple. Irrelevant for people wanting to read a novel.

Even for paper it's over the top except as a facsimile of something over 200 years old.

Waste of time, breaks easily and pointless on a phone.

I totally get what you are trying to say...and you certainly have the right to your opinion that you don't care for decorative or irrelevant features...and I understand that you have the ability to make your books more decorative/complex and just choose not to.

However, I read A LOT of books. In that time I have found that I get pretty bored with just plain vanilla text on the page. Taking a little extra time to create a book that is visually appealing, as well as works on different devices is NOT necessarily a waste of time.

Books that have a little extra...something... to set them apart from just plain text...especially if it helps set the mood of the book, or helps tell the story... is great. If you know how to do that for those with ePub3 and still provide fallback coding so you can have your plain text on an ePub2 phone...then why the heck not???

It doesn't make sense to rob the people who have newer devices/apps of advanced, 'pretty', features just because older devices don't support them. Take the extra 2 minutes to put the coding in so everyone can enjoy it to the level their device can support.

[RbnJrg]

Originally Posted by Quoth

That is decorative and not simple. Irrelevant for people wanting to read a novel.

You are free to think as you like and to express it. But I want to assume that you will not have the presumption that your word is the Word of God and that everyone has to think like you and accept what you say.

For now, for example, Amazon doesn't think like you. If so, then why did it change the k7 format to the kf8? And why did it advance from the kf8 format to the KFX? If it thought like you, then it would still be with K7. I also want to assume that you are consistent with what you express, and that all your Kindle books has code only supported for the K7 format.

Even for paper it's over the top except as a facsimile of something over 200 years old.

In your opinion, yes. But only in your opinion. And remember, your opinion is yours, not everyone's. Speak for yourself and before your statements add "To me". I say, so that you don't seem presumptuous and that it gives the impression that your word is law.

Waste of time, breaks easily and pointless on a phone.

For someone who doesn't know how to work, it can be a waste of time. The code I use is reusable and I only had trouble writing it the first time; Then it's copy and paste.

No, my code doesn't break, it's rock solid and super tested on everything that supports epub3. However, I understand that someone who is not familiar with epub3 has that kind of prejudice. But my books also include epub2 code, for older devices, so no one is hurt.

Pointless on a phone? Why?

[RbnJrg]

Originally Posted by Turtle91

However, I read A LOT of books. In that time I have found that I get pretty bored with just plain vanilla text on the page. Taking a little extra time to create a book that is visually appealing, as well as works on different devices is NOT necessarily a waste of time.

Books that have a little extra...something... to set them apart from just plain text...especially if it helps set the mood of the book, or helps tell the story... is great. If you know how to do that for those with ePub3 and still provide fallback coding so you can have your plain text on an ePub2 phone...then why the heck not???

It doesn't make sense to rob the people who have newer devices/apps of advanced, 'pretty', features just because older devices don't support them. Take the extra 2 minutes to put the coding in so everyone can enjoy it to the level their device can support.

I agree with your words 100%.

[JSWolf]

Originally Posted by RbnJrg

I answered the OP question; he wanted to know if it was possible to adapt an ebook to the user device.

Regarding your second statement, I wrote here many times that an epub must be an epub3 with fallback code for epub2. Your simply formatted novel to me is a challenge to convert it in somethimg more elaborated, with nice chapter headings, dropcaps, fleurons, etc., etc., etc. Here you have two screenshots of a simple novel of mines:

Attachment 207866 Attachment 207867

The dropcap is controlled by javascript so always it has a perfect size (on epu3).

That looks awful. Javascript does not work in most cases. It will break and look even worse. The chapter header takes up way too much space. The dropcap also takes up too much space. Having it colored red is awful. It's a total disaster. There is no need to attempt to make complicated formatting when something simple can be done instead and look so much better.

[JSWolf]

Originally Posted by Turtle91

I totally get what you are trying to say...and you certainly have the right to your opinion that you don't care for decorative or irrelevant features...and I understand that you have the ability to make your books more decorative/complex and just choose not to.

However, I read A LOT of books. In that time I have found that I get pretty bored with just plain vanilla text on the page. Taking a little extra time to create a book that is visually appealing, as well as works on different devices is NOT necessarily a waste of time.

Books that have a little extra...something... to set them apart from just plain text...especially if it helps set the mood of the book, or helps tell the story... is great. If you know how to do that for those with ePub3 and still provide fallback coding so you can have your plain text on an ePub2 phone...then why the heck not???

It doesn't make sense to rob the people who have newer devices/apps of advanced, 'pretty', features just because older devices don't support them. Take the extra 2 minutes to put the coding in so everyone can enjoy it to the level their device can support.

You buy a brand new Kobo Libra Color and that Javascript WILL NOT WORK if you read the eBook as an ePub. Besides, it looks awful.

[DNSB]

Originally Posted by JSWolf

You buy a brand new Kobo Libra Color and that Javascript WILL NOT WORK if you read the eBook as an ePub. Besides, it looks awful.

But if you read it as a kepub using the WebKit based renderer, it does work.

[JSWolf]

Originally Posted by DNSB

But if you read it as a kepub using the WebKit based renderer, it does work.

I'm just saying that just because the Reader is brand new just released, it does not mean Javascript will work. So saying it's bcause of old devices it won't work is wrong.

[Turtle91]

What you are saying is that you don't like the way it is...That's fine, you are welcome to your opinion.

However, you keep forgetting the part where you have fallback coding .... if the device doesn't support the newer methods it ... wait for it ... falls back to the older styling that it can support. That is a win-win for everyone. You don't have to keep people who have the newer devices - which support the ePub3 standard, and all the bells and whistles - from using them.

[Turtle91]

Originally Posted by JSWolf

That looks awful. Javascript does not work in most cases. It will break and look even worse. The chapter header takes up way too much space. The dropcap also takes up too much space. Having it colored red is awful. It's a total disaster. There is no need to attempt to make complicated formatting when something simple can be done instead and look so much better.

You are still missing the point (I think it is actually on purpose) that is an EXAMPLE of the code possibilities. You certainly are not stuck with doing it exactly how his EXAMPLE shows every time. With this EXAMPLE you can see what the POSSIBILITIES are...