Instructions for patching firmware 4.24.15676

[Mrs_Often]

Originally Posted by jackie_w

I meant to reply to this earlier. It's not just widows/orphans which can cause a variable number of lines per page. In addition I think widows/orphans are ignored in kepubs.

It will also happen if the book's CSS styling for its standard paragraph has a non-zero top margin (however small). Compare the vertical gap between
- lines 1 and 2 of the same paragraph
- the last line of one paragraph and the first line of the next paragraph

If they're different then the number of visible lines-per-page will be more on a page containing just one very long paragraph versus a page full of conversational dialogue with a lot of short paragraphs.

The first line of every page always starts in exactly the same place but the last line on each page is going to vary in the scenario I outlined above.

Oh! That makes perfect sense! And the pics I shared show perfectly that the page with more paragraphs (and thus more before/after paragraph space) is the one that has less lines. Why didn't I think of that Stupid.

I don't like before/after paragraph space, also not in documents that I write myself, I always remove them. Would that be something your custom beta KePub stylesheet anchor style patch that you shared in the request patches thread could get rid of too?

EDIT to add: Haha, that's a really stupid question, seeing your beta patch is for the anchor style specifically. Somehow, I'd got it into my head that the patch was for changing kepub CSS in general

To compensate you might want to reduce the height even further in the Reduce new header/footer height patch. What values are you currently using and for which device?

I just have the standard 33% reduction for Clara HD:

        # AuraHD/H2O/GloHD/ClaraHD (Dragon)
      - Find:    "ReadingFooter[qApp_deviceIsDragon=true] {\n  min-height: 101px;\n  max-height: 101px;\n}"
        Replace: "ReadingFooter[qApp_deviceIsDragon=true] {\n  min-height: 66px;\n  max-height: 66px;\n}"

I didn't dare make it smaller because that would make the header smaller too... did I understand that correctly? Or would it not show as much as a possible extra line on the bottom would show? What values do you suggest I try? I don't fully understand how to change the values, because the comments also state "Keep min-height=max-height", whatever that means...

[Mrs_Often]

Originally Posted by Mrs_Often

I don't fully understand how to change the values, because the comments also state "Keep min-height=max-height", whatever that means...

I was stupid again, having looked at it it's rather obvious

However, I've also had a think, and there's of course two separate things:
- The header & footer heights
- The distance of the text between header/footer and the text.

I actually quite like the header & footer heights in reduced state (33% at the moment, though I might increase it slightly so the footer text doesn't touch the progress bar*). What I don't like is the distance of the text to the header/footer.

--> Would it be possible to make a padding patch or something to influence distance between the text and the top of the screen/header and the bottom of the screen/footer in (real and pretend) kepubs, preferably separately from each other?

EDITS: Nevermind the request, I'll move it to the patch request thread

*Yep, increased from 66px to 70px, and with re-aligned Mini Clock the footer is now a lot better

[jackie_w]

Originally Posted by Mrs_Often

However, I've also had a think, and there's of course two separate things:
- The header & footer heights
- The distance of the text between header/footer and the text.

I actually quite like the header & footer heights in reduced state (33% at the moment, though I might increase it slightly so the footer text doesn't touch the progress bar*). What I don't like is the distance of the text to the header/footer.

--> Would it be possible to make a padding patch or something to influence distance between the text and the top of the screen/header and the bottom of the screen/footer in (real and pretend) kepubs, preferably separately from each other?

Maybe this is too late ... I don't know whether you're aware but there are 2 Find/Replace options in nickel.yaml patch Custom new header/footer font to fine-tune the relative positions of:
- header caption and first line of page text
- footer caption and last line of page text

Spoiler:

        # 2b. All models (optional): Fine-tune footer position by adjusting margin-top value
        #     A negative margin-top (e.g -10px) moves the footer text slightly upwards
        #     further from the bottom bezel/progressbar, closer to the page content
        - Find:    "#caption[newFooter=true][qApp_deviceIsTrilogy=true] {\n  font-size: 14px;\n}"
          Replace: "#caption[newFooter=true] {\n  font-size: 14px; margin-top: 0px;}"
        
        # 2b. All models (optional): Fine-tune header position by adjusting margin-bottom value.
        #     A negative margin-bottom (e.g -10px) moves the header text slightly downwards
        #     further from the top bezel, closer to the page content
        - Find:    "#caption[newHeader=true][qApp_deviceIsTrilogy=true] {\n  font-size: 14px;\n}"
          Replace: "#caption[newHeader=true] {\n  font-size: 14px; margin-bottom: 0px;}"

E.g. as outlined in the help notes, using a negative px-value for margin-top in the first of the above Find/Replaces will allow you to set the header/footer smaller in patch Reduce new header/footer height without the footer caption cutting into the progressbar along the bottom. See screenshots 3 & 4 in this post.

[jackie_w]

Following up on my previous message:

Originally Posted by jackie_w

As fw 4.24.15672 was so short-lived I should probably repeat my previous message here:

Today I committed a new version of this patch to @geek1011's GitHub site. Assuming he probably won't want to do a full re-release because of a single patch, you can copy the new version from here. Be careful when copy/pasting, this page contains 2 patches, so make sure you only copy the first - i.e. everything except the last 4 lines.

If you're already using this patch and you're experiencing problems with a headword (bigger bolder lookup word on first line) being clipped at the left edge then updating might help.

I can't be 100% sure I've finished tweaking this patch yet so if today's new dictionaries aren't causing you any problems with this patch then maybe leave it alone for the time being. I need to see whether any new problems arise as more people get the new dictionaries.

If you have any problems after updating, please report them here.

[Phil_C]

This dictionary patch works perfectly on Clara HD. Thanks, @jackie_w.

[jackie_w]

Originally Posted by Phil_C

This dictionary patch works perfectly on Clara HD. Thanks, @jackie_w.

Thanks for confirming, Phil_C

[anacreon]

Originally Posted by jackie_w

Following up on my previous message:
Today I committed a new version of this patch to @geek1011's GitHub site. Assuming he probably won't want to do a full re-release because of a single patch, you can copy the new version from here. Be careful when copy/pasting, this page contains 2 patches, so make sure you only copy the first - i.e. everything except the last 4 lines.

If you're already using this patch and you're experiencing problems with a headword (bigger bolder lookup word on first line) being clipped at the left edge then updating might help.

I can't be 100% sure I've finished tweaking this patch yet so if today's new dictionaries aren't causing you any problems with this patch then maybe leave it alone for the time being. I need to see whether any new problems arise as more people get the new dictionaries.

If you have any problems after updating, please report them here.

Rereading what I wrote in another thread, I erred saying I used the "increase available text area" patch. What I did use was the "shorten dictionary entry not found message", not "Dictionary text font-family/font-size/line-height".

So, I'll just change yes to no in the first name patch, and report here whether it solves my problem with the new dictionaries.

[anacreon]

It didn't work. So I'll go back to the FW thread and say that the problem doesn't seem due to patching, which I already intuited, since there was no problem with Deutsch or Français.

[Malletta]

hi, has anyone an updated patch for not syncing dictionarys?
for could not apply patch "Never sync dictionaries"?
This
https://pgaskin.net/dictutil/dicthtml/install.html
doesnt' work anymore

[ps67]

Originally Posted by Malletta

hi, has anyone an updated patch for not syncing dictionarys?
for could not apply patch "Never sync dictionaries"?
This
https://pgaskin.net/dictutil/dicthtml/install.html
doesnt' work anymore

Now You can insert Your custom dictionary in the folder .kobo/custom-dict without they been cancelled wen sync. So it seems that the patch is not no more necessary.

More information provided by @geek1011 here:

https://github.com/pgaskin/dictutil/issues/14

The fundamental thing to remember is to name the dictionary file dicthtml* otherwise it won't be recognized.

[Malletta]

Originally Posted by ps67

Now You can insert Your custom dictionary in the folder .kobo/custom-dict without they been cancelled wen sync. So it seems that the patch is not no more necessary.

More information provided by @geek1011 here:

https://github.com/pgaskin/dictutil/issues/14

The fundamental thing to remember is to name the dictionary file dicthtml* otherwise it won't be recognized.

thank you very much!

[jackie_w]

Originally Posted by anacreon

It didn't work. So I'll go back to the FW thread and say that the problem doesn't seem due to patching, which I already intuited, since there was no problem with Deutsch or Français.

Although your assumption is reasonable, it isn't necessarily valid. Not all the dictionaries have the same HTML construction in their internal content files. Some of them, including dicthtml-en-fr.zip and dicthtml-en-de.zip, are using HTML/CSS to make the headword big & bold. Others, including dicthtml-fr.zip and dicthtml-de.zip, are not.

I believe it's the "big & bold" aspect that is causing your problem, but if you don't have any of the existing dictionary patches enabled then I wouldn't expect to see any problems.

To pursue this further I would need to have access to all your current .yaml files - kobopatch.yaml plus all the .yaml files in the kobopatch /src/ subdirectory. If you gather them all together into a .zip file you should be able to attach it here.

[Malletta]

so i placed the dictionaries under the custom folder and they work, but...
Kobo doesn't remember the last dictionary I used, and it picks the default one (English in my case). Previously when I switched to a certain dictionary (They all were multiple English dictionaries but I renamed them, for example, as EN-PT, EN-JAP, etc) this last one would stick. Can I somehow reverse the situation so the last dictionary I use would be the default one?

[jackie_w]

Originally Posted by Malletta

so i placed the dictionaries under the custom folder and they work, but...
Kobo doesn't remember the last dictionary I used, and it picks the default one (English in my case). Previously when I switched to a certain dictionary (They all were multiple English dictionaries but I renamed them, for example, as EN-PT, EN-JAP, etc) this last one would stick. Can I somehow reverse the situation so the last dictionary I use would be the default one?

The rules for custom dictionary naming are not published but trial & error makes me think the following ...

When you do a dictionary lookup part of the latest dictionary's name is stored in the Kobo database for that particular book. If a dictionary in .kobo/custom-dict/ has the same filename as one in .kobo/dict/ the database does not distinguish between the 2 versions. Hence when you do the next lookup it assumes the one from the .kobo/dict directory.

A quick and dirty fix for one of your custom English dictionaries is to name it .kobo/custom-dict/dicthtml-en-en.zip. That should get "remembered" correctly for the next lookup because the database will store "-en-en" (without the quotes) after a successful lookup. It will appear as "English - English" in the dictionary drop-down list.

If you've got several more English-only dictionaries I can only suggest doing what I've done which is to name them descriptively e.g.

dicthtml-Collins.zip (for Collins English complete & unabridged)
dicthtml-COE.zip (for Concise Oxford)
dicthtml-Web1913.zip (for Webster's 1913)
dicthtml-MWC.zip (for Merriam-Webster Collegiate)
dicthtml-Chambers.zip (for Chambers 1908)
dicthtml-Wiktionary.zip (for English Wiktionary)

Don't use spaces in the filename. In addition you'll need to experiment with the filenames because the firmware will try to use the first 2 (or 3 ???) chars (after "dicthtml-") to lookup the name in an international language code table. If it finds a "hit" it will try to display a "user-friendly" expanded version of that language name (in that language's alphabet) as the dictionary's name in the drop-down list. However, it may not be user-friendly to an English reader, especially if the Kobo default Georgia font doesn't contain characters from that language's alphabet.

[anacreon]

Error.