Firmware 3.18.0 discussion

[JSWolf]

Originally Posted by frostschutz

@JSWolf: now if only the device itself was white instead of black, it would be perfect for me. But with black I need a bit of a border...

If you do increase the font size, you will get a slightly larger space before the footer as a full line won't fit. And the line height also makes a difference in the spacing. I just happen to have the font size and the line height set such that it runs close. And you can set the left/right margins via the UI easily if you want larger.

[JSWolf]

Here are the patches for my custom footer style/size for 3.18.0.

<Patch>
patch_name = `Custom reading footer style`
patch_enable = `yes`
# Multi-version patch: 3.15.0 - 3.18.0+
#
# This patch customises the following properties of the reading footer:
#
#  * Footer height (the amount of the screen reserved for the footer.)
#  * Caption font size (Caption = page number or other progress indicator)
#  * Caption top margin, which changes its vertical position within the footer.
#
# When editing the replacement values below, BE CAREFUL NOT TO CHANGE THE LENGTH
# OF THE REPLACEMENT STRING! If a replacement string is too long you will get
# an error when making the patch, but if one is too short then there will be no
# error, but strange things will happen to the reading footer.
#
find_base_address = `ReadingFooter {\n\tmin-height: 70px;`
#
# Replacement footer height values: Touch/Mini
replace_string = 0011, `min-height: 70px;`, `min-height: 32px;`
replace_string = 0024, `max-height: 70px;`, `max-height: 32px;`
# Replacement footer height values: Glo/Aura
replace_string = 0085, `min-height: 82px;`, `min-height: 40px;`
replace_string = 0098, `max-height: 82px;`, `max-height: 40px;`
# Replacement footer height values: AuraHD/H2O/GloHD
replace_string = 00DA, `min-height: 120px;`, `min-height: 030px;`
replace_string = 00EE, `max-height: 120px;`, `max-height: 030px;`
#
#
find_base_address = `#caption {\n\tfont-size: 16px;`
Replace_string = 0000, `#caption {\n\tfont-size: 16px;\n}\n\n#caption[qApp_deviceIsPhoenix="true"] {\n\tfont-size: 20px;\n}\n\n#caption[qApp_deviceIsDragon="true"] {\n\tfont-size: 26px;\n}\n\n#caption[qApp_deviceIsAlyssum="true"] {\n\tfont-size: 30px;\n}\n\n#caption[qApp_localeName="ja_JP"] {\n\tfont-family: Sans-SerifJP;\n}`, `#caption {font-size: 16px;margin-top: 00px;}\n#caption[qApp_deviceIsPhoenix="true"] {font-size: 20px;}\n#caption[qApp_deviceIsDragon="true"] {font-size: 26px;}\n#caption[qApp_deviceIsAlyssum="true"] {font-size: 30px;}\n#caption[qApp_localeName="ja_JP"] {font-family: Sans-SerifJP;}`
#
# Replacement caption font size value for Touch/Mini:
replace_string = 000A, `font-size: 16px;`, `font-size: 16px;`
# Replacement caption font size value for Glo/Aura:
replace_string = 0054, `font-size: 20px;`, `font-size: 20px;`
# Replacement caption font size value for AuraHD/H2O:
replace_string = 008C, `font-size: 26px;`, `font-size: 26px;`
# Replacement caption font size value for GloHD:
replace_string = 00C5, `font-size: 30px;`, `font-size: 30px;`
#
# Replacement caption top margin value for all devices:
# (A negative top margin moves the caption text upwards,
# further from the bezel and closer to the page content.)
replace_string = 001A, `margin-top: 00px;`, `margin-top:-10px;`
#
# Uncomment to use a fixed replacement caption font family, for all devices:
# (You can change Avenir to another font name of your choice, but Avenir or
# Georgia are recommended because other fonts may not be loaded when the book
# is first opened and so might cause problems. Unlike other strings it is OK
# if this replacement string is a bit longer or shorter than the original.)
#replace_string = 00D7, `#caption[qApp_localeName="ja_JP"] {font-family: Sans-SerifJP;}`, `#caption {font-family: Avenir;}
</Patch>


<Patch>
patch_name = `Custom footer`
patch_enable = `yes`
# Multi-version patch: 2.8.1 - 3.18.0+
#
# Changes the footer text with something shorter
# (not sure how it affects translations)
#
find_base_address = `Page %1 <i>of</i> %2`
replace_string = 0000, `Page %1 <i>of</i> %2`, `%1 / %2`
</Patch>

[davidfor]

Originally Posted by melovesflying

If I do downgrade my FW, will the reading stats be affected? I read that a factory reset is recommended for that but I don't really want to reset my stats, unless the backup by Calibre will still work even if the downgraded FW is different from the FW of the backup.

When downgrading firmware, you should do a factory reset. But, in most cases, if you are only going back a version or two, you are safe. In this case there is a database change between 3.17.3 and 3.18.0 that could cause a problem. A column was removed from the user table. If the 3.17.3 might fail if it attempts to use that column. But, looking back, it looks like you are planning to go back to 3.12. In that case, I would recommend the factory reset.

Oh Kobo, your releases are getting buggier and buggier.

I will have to disagree with you on that. Looking back at your post about bugs, you mention one that no-one else has reported for a very long time, something that I just checked and doesn't happen here, a definite bug that has been in several firmware versions, a change that might be deliberate (people have complained about something and this would be a solution) and a fix to a recent cosmetic problem. Based on that, I can't agree with you.

[murg]

Originally Posted by Nick_1964

John F want to make a sort of summary in every firmware thread and reserve a post for it.. I think the right place isn't here but in the firmware thread but that is already maintained by Murg,and I agree that the one will started the threat is also the one who maintains it..but John F wants to do it also because he doesn't like it that persons need to read the whole firmware thread to know all "ups and downs".

I won't be using the Direct Links thread to keep track of the contents of the releases. That thread is only for accessing the releases. And listing major issues with a release.

It is a lot of work to maintain the first post, and it will be even a lotter more work to try to keep track of the changes, especially as some people seem to have problems while others are problem-free.

[murg]

Originally Posted by GeoffR

Here are some other things that are not officially supported by Kobo:

* Using the built-in web browser
* Sideloading KePubs
* Using Calibre to sideload (and much more)
* Installing third-party software
* Patching the firmware

How many people here don't depend on at least one of those things to make their reading experience better?

I don't.

[Rand Brittain]

Let's not argue about which features are most important. Plenty of people use things like FullScreenReading=true, and plenty of people get along without it. It's not a race!

[JSWolf]

Originally Posted by Rand Brittain

Let's not argue about which features are most important. Plenty of people use things like FullScreenReading=true, and plenty of people get along without it. It's not a race!

The issue is not who uses FullScreenReading=true or not but that some are calling bugs when it doesn't work as expected when it's not even a beta feature.

It's not a bug when it's not beta and not meant to be used. Find some other term to call it because bug is incorrect.

[davidfor]

Originally Posted by JSWolf

The issue is not who uses FullScreenReading=true or not but that some are calling bugs when it doesn't work as expected when it's not even a beta feature.

It's not a bug when it's not beta and not meant to be used. Find some other term to call it because bug is incorrect.

No, it is still a bug. It is just not one that Kobo will pay any official attention to.

[Nick_1964]

Originally Posted by JSWolf

The issue is not who uses FullScreenReading=true or not but that some are calling bugs when it doesn't work as expected when it's not even a beta feature.

It's not a bug when it's not beta and not meant to be used. Find some other term to call it because bug is incorrect.

Not discussing again,but even when you use an undocumented option that causes a device to act this strange, you can still call it a bug,because it wasn't there before, since a lot of functions are integrated into each other,you can never know which "legal" option can trigger it to as the resfresh part is used a lot more then only by reading.
Imagine how much (more sigh) disaster by example Windows would be if the Microsoft designers are acting the same "oh it is not documented so don't bother it.. "
"Messing around" and find something that is not intended to be found but still can let,in the worse case scenario and not with this "bug", crash the device is something that must be told to the developers.
A bug is a bug,even when it isn't in a documented part of the software, we can not know which else it does,and what else can trigger it.

Kobo build it into their software so they are going to do something with it, a lot of other options in the config file doesn't work anymore,this option is still there and we have no idea if it can be triggered by a normal feature of the device until someone discovers it.
If a never used software routine would be still in the I.S.S. station (i know there are some) and an action of one of the astronauts by accident trigger it,and the whole station vaporised.. i know for sure the developers down here would call it a bug, documented or not.

[Josieb1]

I like using Charis on my Glo HD but I'm getting problems with split lines of text, like the text is cut off, the top half of the words are at the bottom of the page with the bottom of the words on the top of the next page. It's only happening with Charis, not the stock fonts.

Any idea how I can stop that?

[GeoffR]

Originally Posted by Josieb1

I like using Charis on my Glo HD but I'm getting problems with split lines of text, like the text is cut off, the top half of the words are at the bottom of the page with the bottom of the words on the top of the next page. It's only happening with Charis, not the stock fonts.

Any idea how I can stop that?

Try increasing the line spacing until it stops happening. The KEPUB reader can't handle it when the lines are too close together, but how close depends on the font being used.

[Josieb1]

Originally Posted by GeoffR

Try increasing the line spacing until it stops happening. The KEPUB reader can't handle it when the lines are too close together, but how close depends on the font being used.

Thank you, I'll try that.

[outlandos]

Originally Posted by davidfor

No, it is still a bug. It is just not one that Kobo will pay any official attention to.

I really agree with davidfor here.

[murg]

Originally Posted by JSWolf

It's not a bug when it's not beta and not meant to be used. Find some other term to call it because bug is incorrect.

A feature is a bug in a tuxedo.

[melovesflying]

Originally Posted by davidfor

I will have to disagree with you on that. Looking back at your post about bugs, you mention one that no-one else has reported for a very long time, something that I just checked and doesn't happen here, a definite bug that has been in several firmware versions, a change that might be deliberate (people have complained about something and this would be a solution) and a fix to a recent cosmetic problem. Based on that, I can't agree with you.

Then let's just agree to disagree because that's what I've been feeling with the last several firmware updates, at least on my Aura. And thank you for all your help.