Closed pgaskin closed 2 years ago
So first, a few interesting things I noticed about this version:
/usr/share/dbus-1/services/com.kobo.{foxit,myscript}.*
if we installed kobo8 firmware on non-kobo8 devices (or nickel may behave differently) (there's also more files than these, but they should not make any difference).Errors:
/home/patrick/src/kobopatch-patches/src/versions/4.28.18220/nickel.yaml/pgaskin.yaml: Remove forgot pin button from lock screen: could not apply patch "Remove forgot pin button from lock screen": line 20: inst 4: ReplaceZlib: not a zlib stream
/home/patrick/src/kobopatch-patches/src/versions/4.28.18220/libnickel.so.1.0.0.yaml/pgaskin.yaml: Customize ComfortLight settings: could not apply patch "Customize ComfortLight settings": line 599: inst 4: ReplaceInt: could not find specified bytes at offset
/home/patrick/src/kobopatch-patches/src/versions/4.28.18220/libnickel.so.1.0.0.yaml/pgaskin.yaml: ePub uniform font scale: could not apply patch "ePub uniform font scale": line 558: inst 4: ReplaceBytes: could not find specified bytes
/home/patrick/src/kobopatch-patches/src/versions/4.28.18220/libnickel.so.1.0.0.yaml/geoffr.yaml: Set font scale factor: could not apply patch "Set font scale factor": line 494: inst 3: ReplaceInt: could not find specified bytes at offset
/home/patrick/src/kobopatch-patches/src/versions/4.28.18220/libnickel.so.1.0.0.yaml/geoffr.yaml: Custom font sizes: could not apply patch "Custom font sizes": line 193: inst 4: ReplaceInt: could not find specified bytes at offset
/home/patrick/src/kobopatch-patches/src/versions/4.28.18220/nickel.yaml/oren64.yaml: New home screen subtitle custom font: could not apply patch "New home screen subtitle custom font": line 31: inst 4: ReplaceZlib: not a zlib stream
In addition to the usual:
Maybe they fixed the epub font size issue? I'll need to do some additional testing.
Resource extraction:
./qrc2zip --output "nickel.18220.qInitResources_resources.zip" --recursive --verbose "nickel" 1 $((0x12205d0 - 0x0010000)) $((0x00272a0 - 0x0010000)) $((0x12200e0 - 0x0010000)) || { echo "Error: qrc2zip failed." 1>&2; exit 1; }
./qrc2zip --output "nickel.18220.qInitResources_translations.zip" --recursive --verbose "nickel" 1 $((0x15d89a0 - 0x0010000)) $((0x12209b8 - 0x0010000)) $((0x15d8718 - 0x0010000)) || { echo "Error: qrc2zip failed." 1>&2; exit 1; }
./qrc2zip --output "nickel.18220.qInitResources_styles.zip" --recursive --verbose "nickel" 1 $((0x15f71f0 - 0x0010000)) $((0x15d8ab8 - 0x0010000)) $((0x15f4940 - 0x0010000)) || { echo "Error: qrc2zip failed." 1>&2; exit 1; }
./qrc2zip --output "nickel.18220.qInitResources_certificates.zip" --recursive --verbose "nickel" 1 $((0x161e740 - 0x0010000)) $((0x15f7d70 - 0x0010000)) $((0x161d6f0 - 0x0010000)) || { echo "Error: qrc2zip failed." 1>&2; exit 1; }
https://krc.storage.pgaskin.net/nickel.18220.qInitResources_certificates.zip https://krc.storage.pgaskin.net/nickel.18220.qInitResources_resources.zip https://krc.storage.pgaskin.net/nickel.18220.qInitResources_styles.zip https://krc.storage.pgaskin.net/nickel.18220.qInitResources_translations.zip
Doesn't appear to be any nickel changes, but does that diff mean what I think it means about Dropbox on other devices?
So, I had a look at the font stuff, and it seems that they reworked the font size/scale calculations. This will need more testing.
The EPUB calculations (below) have changed (KEPUB is the same as before):
From the Discord chat:
[17:03] sherm_p: Ok, minimum font on epub vs kepub appears to be about the same
[17:03] pgaskin: yay!
[17:04] pgaskin: they've fixed it, then
[17:04] sherm_p: (it's small enough on my glo that the epub goes into two column mode!)
[17:04] pgaskin: umm, lmao
[17:04] pgaskin: they changed the font size values, so that's probably one of the reasons
[17:05] pgaskin: it might mean that Custom font sizes is no longer necessary
[17:05] sherm_p: There's still a difference at more reasonable font sizes
[17:06] sherm_p: Although it's not huge
[17:06] pgaskin: is it better than before?
[17:08] sherm_p: I think so? I haven't read on my Glo for years, so I'd have to test on my Forma to really know for sure.
[17:08] sherm_p: Anything over halfway on the size slider in epub is kinda useless though
[17:08] pgaskin: that's always been true
[17:08] pgaskin: you should be able to downgrade safely to 16704 to test the old behaviour
[17:09] sherm_p: But smaller values seem more useful
[17:09] pgaskin: I'll also test it as soon as I finish looking at the disassembly and checking a few sync-related things for kbsync
The Custom font sizes
patch will need a rewrite if it's still necessary; too much has changed.
My ePub uniform font scale
patch (rewritten to fix the 4.28.17820 epub font size issue) may not be necessary anymore since Kobo seems to have incorporated a fix into it (see the screenshot above).
@jackiew1, can you confirm that the ePub uniform font scale
and Set font scale factor
patches aren't necessary anymore on your devices for consistent epub/kepub font sizes, and that Custom font sizes
isn't required to have smaller font sizes than on older versions?
Edit: Just tested on my Aura2v1, Mini, and ClaraHD. It seems to have indeed been fixed, with smaller font sizes added as well.
I have tested the patches, and everything seems to work fine now. The font scale patches and the Custom font sizes
patch doesn't seem to be necessary anymore.
@jackiew1, I'm ready to release this once you've tested the nickel ones, and if you have time, confirmed the font scale/size changes.
@pgaskin Seems I'm a bit late to the party, but here I am now.
Based on what you said at the top of this thread, my test Kobos (KA1, AuraHD) need to get rid of some Elipsa-only files. How do I do that?
Based on what you said at the top of this thread, my test Kobos (KA1, AuraHD) need to get rid of some Elipsa-only files. How do I do that?
That shouldn't make a difference for the patches, and it probably won't make a significant difference with anything else (the only possibility is foxit being used instead of RMSDK for PDFs, but I haven't tested that yet). If you still want to remove them, you can do it with NickelMenu: menu_item:main:Remove files:cmd_output:500:rm -fv /usr/share/dbus-1/services/com.kobo.{foxit,myscript}.*
.
Edit: I just did some testing, and it does seem like foxit will be used instead of rmsdk if it's present.
Edit 2: Don't remove it, or nickel acts up if you open any PDF files imported with it. Just be aware that PDFs will be rendered with Foxit.
@pgaskin Thanks for the NM tip. I think I'll let the dust settle before I do any remedial work on my KA1 & AuraHD just in case you make any new discoveries in the next few days.
I'll do my testing on my H2O which has only ever had official mark5 fw installed.
I think I'll let the dust settle before I do any remedial work on my KA1 & AuraHD just in case you make any new discoveries in the next few days.
I think I've discovered everything that will make a difference. On MR:post-4145522, someone reported that the font sizes are acting oddly on the KA1. On the contrary, based on @shermp and my testing, the font size/scale issues have been solved in this firmware version. Can you at least test the font sizes/scaling on the stock FW on the KA1 to see if there is actually a problem on the KA1?
I just installed 4.28.18220 on the H2O. At first glance all my nickel patches appear to be working. I disabled
Custom font-sizes
ePub uniform font scale
Set font scale factor
and cleared the database's content_settings table.
There is still a big font-size mismatch between epub/kepub. Are you saying this is not what you're seeing?
Got to stop for about 30 mins, will be back later.
After doing a bit more testing, can confirm that at higher font sizes, there's definitely a difference between epub/kepub
There is still a big font-size mismatch between epub/kepub. Are you saying this is not what you're seeing?
I was seeing around the same as when I had the patches applied (almost no difference at smaller font sizes, some difference at larger ones). The thing I'm not seeing anymore is the ridiculously large base EPUB font size from the regression in 17820.
The main thing I'm looking to confirm is whether the firmware by default now is as good or better than the previous version with my patches (which is much better than the previous version without them).
IIRC, the patches never completely fixed the font size mismatch at larger sizes, but correct me if I'm wrong.
I don't know how you define "larger sizes". Based on screenshots I see from other people I'd describe my preferred font-size as "medium".
On the H2O my "right font-size" for an epub is 26. For the kepub (same book, same font-family, zero L/R margins on both) I needed to increase it to 44 for it to look "very similar".
Personally speaking the fw is worse without any of these 3 patches, but I'll get by one way or another even if I have to go back to force-injecting a kepub font-size scale-up during send-to-device with the calibre driver options.
I can put back the two font scale patches without too much effort, but they will need to be tweaked again, and I don't have enough variety of devices to figure out the settings on. I'd rather not redo the custom font sizes patch unless absolutely necessary since that one will be a PITA to rewrite and test.
I suppose absence of Custom font-sizes
might be less of a problem if the other 2 worked. I was using it to extend the range of font-sizes in the increment-by-1 zone by reducing the increment-by-2 and increment-by-4 zones to hardly any. Even my Forma was able to always use a value in the increment-by-1 zone. If kepubs can be read at the same lower size as epub then the increment-by-4 zone may be avoided.
I've no reason to presume my usage is typical.
So, a few more people are reporting font size issues on other devices. I guess I'm going to update the font scale patches again.
So, a few more people are reporting font size issues on other devices. I guess I'm going to update the font scale patches again.
I think people are mainly reporting that their perfect font-size they had set in part-read books pre-update is no longer perfect post-update. We know the font-sizes have been re-scaled (or something) so this isn't really surprising. I'm not really sure why it's a big deal as you just have to set your "new perfect" and carry on. Eventually all new books will be back as you want them.
The bigger problem (actually annoyance, not problem) remains the epub/kepub mismatch for those who read both. Dragon device users will be familiar with this issue but for non-Dragon device users (KA1, Forma, Glo etc) it will be a new thing to get upset about.
I wonder what %age of Kobo users are epub-only, kepub-only versus mixture of both?
I wonder what %age of Kobo users are epub-only, kepub-only versus mixture of both?
We might have a stronger bias towards ePub on MR than the average Joe, but it's probably still a minority, although a possibly rather sizable one ;p.
@NiLuJe If you've still got your Elipsa please can you tell me what the min/max values are on the [Aa] menu font-size slider bar. I'm going to guess that they're the same as for KA1/Forma, i.e. min=14, max=194, but confirmation would be good.
@NiLuJe If you've still got your Elipsa please can you tell me what the min/max values are on the [Aa] menu font-size slider bar. I'm going to guess that they're the same as for KA1/Forma, i.e. min=14, max=194, but confirmation would be good.
Are those affected by the font size patches? (Because I'm currently using 'em).
Are those affected by the font size patches? (Because I'm currently using 'em).
It was possible to change them via the Custom font-sizes
patch but I don't think either ePub uniform font scale
or Set font scale factor
affect them. None of these 3 patches work in this firmware, do they? Or have I missed something?
The reason I asked the question is because I've been doing some of my own patch hacking on Custom font sizes
. As I don't have any de-compiling skills I've had to rely on guesswork using eyeball comparisons of hex-strings, but I thought there may be a possibility that some Elipsa-specific code had been added which wouldn't be apparent when comparing fw 4.28 and 4.26.
Custom font sizes
This code involved in this one has changed significantly, and will need some work (and a lot of testing) to update.
ePub uniform font scale, Set font scale factor
I could update these again, and probably will do at least one of them (I won't have any preset values though, since those seem to need to be different on each device right now).
I might have time to look at the patches again within the next few days.
I'm also removing the invert screen toggle patch.
Are those affected by the font size patches? (Because I'm currently using 'em).
It was possible to change them via the
Custom font-sizes
patch but I don't think eitherePub uniform font scale
orSet font scale factor
affect them. None of these 3 patches work in this firmware, do they? Or have I missed something?
But I'm running the previous 4.28 build on the Elipsa, where they were ;).
@NiLuJe If you've still got your Elipsa please can you tell me what the min/max values are on the [Aa] menu font-size slider bar. I'm going to guess that they're the same as for KA1/Forma, i.e. min=14, max=194, but confirmation would be good.
Err, stupid question is stupid: how do I even get to these numerical values?
@NiLuJe If you've still got your Elipsa please can you tell me what the min/max values are on the [Aa] menu font-size slider bar. I'm going to guess that they're the same as for KA1/Forma, i.e. min=14, max=194, but confirmation would be good.
Err, stupid question is stupid: how do I even get to these numerical values?
readingFontSize
in Kobo eReader.conf
[Reading] section.Right, that's what I thought, but I was mildly confused at not seeing the key at all in my current config ^^. (Sorry, long week ^^).
(Possibly because I haven't actually read anything in Nickel on that device? :D).
And apparently... 12
- 108
┌─(ROOT@europa:pts/0)──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────(~)─┐
└─(2.53:21%:23:54:97%:#)── ag readingFontSize /mnt/onboard/.kobo/Kobo/Kobo\ eReader.conf ──(Sat, Aug 14)─┘
readingFontSize=12
┌─(ROOT@europa:pts/0)──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────(~)─┐
└─(2.46:22%:23:54:97%:#)── ag readingFontSize /mnt/onboard/.kobo/Kobo/Kobo\ eReader.conf ──(Sat, Aug 14)─┘
readingFontSize=108
Hmm, well I wasn't expecting those values. I wonder why the maximum size on an Elipsa would be less than that for every other Kobo except Touch/Mini.
@pgaskin
We've had an MR request about the removed optimizeLegibility
option for the old KePub stylesheet additions
patch. I need to post my beta somewhere because it doesn't belong in the standard patch pack. Would you prefer:
kobopatch-patches
- which I can open then immediately close.A separate issue would probably be best.
Also, do you think I should just release the patches as-is and mark the font size/scale ones as missing for a future version? It wouldn't be the first time we've done something like that. I don't think I'll have enough time to look at them this week, and the patch stuff is starting to clutter the main firmware thread.
Also, do you think I should just release the patches as-is and mark the font size/scale ones as missing for a future version? It wouldn't be the first time we've done something like that. I don't think I'll have enough time to look at them this week, and the patch stuff is starting to clutter the main firmware thread.
Probably a good idea to release what we have so far if you won't have time to look at the missing patches for a while.
Re: Custom font sizes
I saw your reply to someone on MR this week where you said you thought it may no longer be needed. That may well be true because I'm not sure how many people ever took the time to understand what it actually did. However, for anyone (e.g. me) who ever used it to greatly extend the range of font-sizes where you could inc/dec by 1, rather than always being stuck in the inc/dec by 2 (for epub) or 4 (for kepub) ranges, then that "need" won't have changed. I'm not saying this to try and force the issue because the number of users who would miss it may be tiny.
The revised alpha patch I cobbled together seems to work OK for my needs for 4.28.18220 but I wouldn't want to release it to others given you say the code has changed significantly. FWIW my alpha doesn't look hugely different from the original but I've made no attempt to cater for the Elipsa.
BaseAddress: "N3FontTypeUtil::fontSizes()
still works as before.I've posted my alpha patch below in case you decide to look into it further. Taking the ClaraHD as an example, these are the default vs patched font-sizes I would expect to see on the [Aa] slider bar: Unpatched:
Alpha-patched:
Custom font sizes - jackie_w:
- Enabled: no
- Description: |
With this patch enabled you will not be able to select the very large font
sizes, but will be able to make finer adjustment to the smaller sizes.
Font sizes depend on the device's screen density. Unpatched, the sizes
increase in steps of 1 from the smallest size up to size 22, then in steps
of 2 up to size 50, then in steps of 4 up to the largest size:
#
# AuraOne/Forma: 14px - 194px (59 sizes) new
# GloHD/ClaraHD/Libra: 10px - 150px (52 sizes) new (only tested ClaraHD)
# AuraHD/H2O: 8px - 150px (54 sizes) new (only tested H2O)
# Glo/Aura: 8px - 122px (47 sizes) new (only tested Glo)
# Touch/Mini: 8px - 90px (39 sizes) ???
# Elipsa 12px - 108px (39 sizes) ??? based on NiLuJe's min/max observations
- BaseAddress: "N3FontTypeUtil::fontSizes()"
# Initial font size:
#- ReplaceInt: {Offset: 390, Find: 14, Replace: 18} # AuraOne/Forma
#- ReplaceInt: {Offset: 36, Find: 10, Replace: 18} # ClaraHD
#- ReplaceInt: {Offset: 362, Find: 8, Replace: 18} # H2O/Glo
# Increment:
- ReplaceInt: {Offset: 78, Find: 21, Replace: 59} # Add font sizes in increments of 1 until this size exceeded}
- ReplaceInt: {Offset: 88, Find: 22, Replace: 60} # Continue from this font size}
- ReplaceInt: {Offset: 218, Find: 49, Replace: 71} # Add font sizes in increments of 2 until this size exceeded}
- ReplaceInt: {Offset: 224, Find: 50, Replace: 72} # Continue from this font size}
# Now increment by +4 until final font size:
- ReplaceInt: {Offset: 386, Find: 195, Replace: 80} # AuraOne/Forma
- ReplaceInt: {Offset: 50, Find: 150, Replace: 80} # H2O/ClaraHD
- ReplaceInt: {Offset: 412, Find: 122, Replace: 80} # Glo
- ReplaceInt: {Offset: 408, Find: 90, Replace: 80} # Touch/Mini (not tested)
If I actually still read in Nickel, I'd add another vote for keeping that one, because the default granularity in the "useful" range is nigh useless ;).
For me the most important patches were the uniform scale for epub and kepub, custom font sizes and ligatures for kepub. Unfortunately with all those patches missing on newer patchset releases I have to block firmware updates.
@shermp has updated Custom font sizes
, and I'll be making a release with the two font scale patches missing for now since I don't have time to rewrite them and they've held back the release for too long already.