Firmware 3.18.0 discussion

[ploum]

Hi,

Since upgrading to 3.18, the backlight sometimes does shut down when putting the book into sleep.

Am I the only one facing this issue ?

[Nick_1964]

Originally Posted by ploum

Hi,

Since upgrading to 3.18, the backlight sometimes does shut down when putting the book into sleep.

Am I the only one facing this issue ?

I think you ment: it doesn't shut down..
It doesn't when it is connected to the charger, and it doesn't get out always when the casing is closed which is rather strange because with the same casing it always did before. (as is, it doesn't detect the closure right and doesn't went into sleep modus..)
But then,as a fall safe, the timer jumps in and put the device to sleep. (and I had it several times that that didn't happened to, both random..)

[JSWolf]

Originally Posted by davidfor

Assuming you are talking about epubs, that is a long standing bug.

When you make the annotation, the percent is correctly set and displayed in the annotations list. The annotations are stored in two places, the database and a file. When you close and reopen the book, the annotations are read from the file and update those in the database. Unfortunately, when this is done, the percentage and which chapter the annotation is in is reset. A mix of annotations with 0% and an actual number should mean you made annotations in a previous reading session and in the current one.

There is a fix for this by making it so RMDSK cannot write to the file. I'll look later when I have my H2O handy and can see what it is I did to prevent this. All I can recall at the moment is that it was very simple to do.

[davidfor]

Originally Posted by JSWolf

There is a fix for this by making it so RMDSK cannot write to the file. I'll look later when I have my H2O handy and can see what it is I did to prevent this. All I can recall at the moment is that it was very simple to do.

Yes, you can replace the directory "Annotations" in "Digital Editions" with a file of the same name. I don't usually do this as with the way I use annotations, it doesn't matter much. Plus, if Kobo fix it, I want to know.

[davidfor]

Originally Posted by Jellby

Yes, I'm talking about epubs. It may be that those with 0% were done in the current session (certainly most of the annotations were done in previous sessions, and most have a non-zero percentage), but I believe I've seen the mix of zero and non-zero in fresh sessions as well: I return to the home screen, let it sleep, and next day I open the book to apply corrections in the PC.

I just noticed something that might explain some of these. Any highlights you make before doing anything else after opening or reopening an epub, will have zero as the percent into chapter. It seems to be only highlights and not annotations or bookmarks.

[Nick_1964]

Noticed something strange.. for sure there will be a setting wrong but when transferring a book (not convert) and there is the extra_css in the root of the book, it changes the lay out of the book at every <p> no matter what is in the extra css.. the stupid thing is that in both preview of Sigil and Calibre the "gaps" can't be seen... when you open the book in the reader or preview it in ADE it can be seen.
It does even with only this in the extra css:
@page { margin: 0.00em 0.00em 0.00em 0.00em!important; }

/edit total wrong topic,ignore, gonna look for what topic it belongs because it happens with both drivers,the normal and the extended.

[JSWolf]

Originally Posted by Nick_1964

Noticed something strange.. for sure there will be a setting wrong but when transferring a book (not convert) and there is the extra_css in the root of the book, it changes the lay out of the book at every <p> no matter what is in the extra css.. the stupid thing is that in both preview of Sigil and Calibre the "gaps" can't be seen... when you open the book in the reader or preview it in ADE it can be seen.
It does even with only this in the extra css:
@page { margin: 0.00em 0.00em 0.00em 0.00em!important; }

Sounds like an error in extra.css. Any error in the CSS and RMDSK will ignore it completely. Also, you don't need @page at all. You can do away with it. Just use margins of 0 in body.

body {
widows: 1;
orphans: 1;
margin-top: 0;
margin-bottom: 0;
margin-left: 0;
margin-right: 0;
text-align: justify;
}

[davidfor]

Originally Posted by Nick_1964

Noticed something strange.. for sure there will be a setting wrong but when transferring a book (not convert) and there is the extra_css in the root of the book, it changes the lay out of the book at every <p> no matter what is in the extra css.. the stupid thing is that in both preview of Sigil and Calibre the "gaps" can't be seen... when you open the book in the reader or preview it in ADE it can be seen.
It does even with only this in the extra css:
@page { margin: 0.00em 0.00em 0.00em 0.00em!important; }

/edit total wrong topic,ignore, gonna look for what topic it belongs because it happens with both drivers,the normal and the extended.

That usually means there was something wrong in the stylesheet. When the contents of the kobo_extra.css file is added, the whole stylesheet is rewritten and can find some problems. You need to pull the updated file from the device and have a look at it in other places.

[Nick_1964]

Originally Posted by davidfor

That usually means there was something wrong in the stylesheet. When the contents of the kobo_extra.css file is added, the whole stylesheet is rewritten and can find some problems. You need to pull the updated file from the device and have a look at it in other places.

Gonna try it, don't know if the function in calibre to remove blanc lines is being used while only transferred..the normal css in the book has almost all values in one line,calibre puts it below each other, the "problem" with Calibre now and with Sigil is that it isn't visible there.. when I open the transferred book with sigil directly from the reader it just look fine and when i put it back under another name in Calibre it looks fine to, so it looks that the result is okay,but in the reader and ADE not...
@JSWolf, the line with the @page was only an example.. no matter what I put there, it happens.


With Sigil and Calibre it looks okay.


But in ADE and reader not.. it looks like the RMDSK and ADE treat it different.. I gonna look where I put this,it is not really calibre or plugin related..

[davidfor]

Originally Posted by Nick_1964

Gonna try it, don't know if the function in calibre to remove blanc lines is being used while only transferred..the normal css in the book has almost all values in one line,calibre puts it below each other, the "problem" with Calibre now and with Sigil is that it isn't visible there.. when I open the transferred book with sigil directly from the reader it just look fine and when i put it back under another name in Calibre it looks fine to, so it looks that the result is okay,but in the reader and ADE not...
@JSWolf, the line with the @page was only an example.. no matter what I put there, it happens.

Attachment 143872
With Sigil and Calibre it looks okay.

Attachment 143873
But in ADE and reader not.. it looks like the RMDSK and ADE treat it different.. I gonna look where I put this,it is not really calibre or plugin related..

The calibre viewer is very forgiving of errors in epubs. Both ADE and the RMSDK are fairly strict. Both of these tend to drop the CSS if there are errors. You should use the calibre editor to and do an error check to see what it says. Sigil might work for this as well, but I haven't used it for a while, so I'm not sure how it handles this now.

The stylesheet will be reformatted. This is done by the functions used to add the contents of the kobo_extra.css. It shouldn't produce invalid CSS, but there might be a circumstance where it does. Posting the final CSS might let us see what is happening.

[jackie_w]

Originally Posted by Nick_1964

It does even with only this in the extra css:
@page { margin: 0.00em 0.00em 0.00em 0.00em!important; }

Try removing all occurrences of !important from your css file(s), including the extra_css. I don't know why but !important plus rebuilding the css file can be a toxic combination.

[jackie_w]

Originally Posted by JSWolf

Also, you don't need @page at all. You can do away with it. Just use margins of 0 in body.

body {
widows: 1;
orphans: 1;
margin-top: 0;
margin-bottom: 0;
margin-left: 0;
margin-right: 0;
text-align: justify;
}

Perhaps you're not aware but the presence of @page in extra_css is treated as a special case. It physically removes any/all existing @page(s) from all css files before inserting itself.

The same is true for widows/orphans.

The body code you've quoted, if used in extra_css will force removal of pre-existing widows/orphans but it won't remove pre-existing @pages.

[Nick_1964]

Originally Posted by davidfor

The stylesheet will be reformatted. This is done by the functions used to add the contents of the kobo_extra.css. It shouldn't produce invalid CSS, but there might be a circumstance where it does. Posting the final CSS might let us see what is happening.

Well.. every normal paragraph in this book that doesn't insert a white line at the original book is <p class="indent"> at <p class="no-indent"> it does produce a white line where it supposed to do.

In the tranferred book it produced a white line at every <p class="indent">

Including the original css, and the changed (after transferring) one.
The extra css by this example has only one line, it doesn't matter what I put there, but contains: @page {
margin: 0 0 0 0 !important
}

book-css.zip

[jackie_w]

@Nick,
In case you missed it, I'm pretty sure what I said in post #296 is your problem.

[Nick_1964]

Originally Posted by jackie_w

Try removing all occurrences of !important from your css file(s), including the extra_css. I don't know why but !important plus rebuilding the css file can be a toxic combination.

The whole goal of the extra css (in my case) is overriding values in the current stylesheet.
Now I can't find the current topic back anymore because otherwise i would had placed it there, but I was told that when I don't use the !important "flag" the values in the extra.css is just added to the normal .css of the book and if that contains other values it will follows them.
So if there is already a margin-top of 1em in it, you can only override that with a margin-top=0!important (if that isn't true, I lie because people told me that is) so that is why i use the whole extra css.. I can edit a whole lot with Sigil, but now the wsyiwyg interface seems to give another result when I open it in the book..

Originally Posted by jackie_w

Try removing all occurrences of !important from your css file(s), including the extra_css. I don't know why but !important plus rebuilding the css file can be a toxic combination.

And Davidfor, I removed the !important line from the transferred book.
Then the problem is gone indeed, but the whole goal from that flag was ovveriding.. but it seems that when it is there, it just skip the entire .css
But I can't see what is wrong with it, it seems that an !important is wrong, but Geoffr uses the same flag in a patch ??