Instructions for patching firmware 4.12.12111

[NiLuJe]

And, for reference, my actual setup, with @jcn363's footer-killing patch .

Dec 19 20:31:41 nickel: (    99.991 @ 0x553010 / ui.debug) draw widget:  46 QStackedWidget QRect(0,11 1080x1429) 
Dec 19 20:31:41 nickel: (    99.991 @ 0x553010 / ui.debug) ===> parent widget:  AbstractMainWindow 
Dec 19 20:31:41 nickel: (   100.036 @ 0x553010 / ui.debug) draw widget:  46 QFrame QRect(0,55 1080x1385) 
Dec 19 20:31:41 nickel: (   100.036 @ 0x553010 / ui.debug) ===> parent widget:  ReadingView

(Which confirms the 44px we got back from the footer, compared to #72).

[davidfor]

Originally Posted by JIPG-reader

I have just installed the fw 4.12.12111 and added some new patches I didn´t have before:

Enable rotation on all devices: It works, but when you rotate to landscape, you only can turn pages. Yo cannot select any menu item (including coming back to portrait!) and you cannot connect to the PC (you cannot confirm the question about connection yes/no!). Here I started to be very afraid that I have to full reset the ereader (I had no way to put another patch), but switching OFF and ON the ereader, luckly it returns to the menu in portrait position . Then, you can patch again to remove this option ... What a pity ...

Note: I have an H2O Ed2 v1

This isn't the case here. All my devices, including an Aura H2O, have generally worked well in the landscape mode. But, there have been occasional problems like you describe. And once I worked out how to get back to portrait mode, I could restart the device and landscape mode worked correctly the next time I tried it.

And remember, you are using a hack to enable a function only available by turning on a developers option. You shouldn't be to surprised when there are problems.

[GeoffR]

Thanks for the testing jcn363 and NiLuJe. The results make me think the blank header/booter space is not being set by directly adjusting the viewport height, and I haven't been able to find anywhere in the code where the viewport height is being calculated, which makes me think it might be done via CSS properties.

Had anyone tried changing the heights or top/bottom margin/padding of likely objects in the compressed CSS streams in nickel? One to try mught be MediumVertSpacer which has the right heights, but it is probably being used for a lot of different things.

E.g. a patch to halve MediumVertSpacer height (nickel.yaml)

Spoiler:

Decrease MediumVertSpacer:
  - Enabled: yes
  - FindZlib: "* {\n  background-color: white;\n}\nQWidget[smallIconHeight=true][qApp_deviceIsTrilogy=true]"
  - ReplaceZlib: {Offset: 0, Find: "MediumVertSpacer[qApp_deviceIsTrilogy=true] {\n  min-height: 24px;\n  max-height: 24px;\n}", Replace: "MediumVertSpacer[qApp_deviceIsTrilogy=true] {\n  min-height: 12px;\n  max-height: 12px;\n}"}
  - ReplaceZlib: {Offset: 0, Find: "MediumVertSpacer[qApp_deviceIsPhoenix=true] {\n  min-height: 32px;\n  max-height: 32px;\n}", Replace: "MediumVertSpacer[qApp_deviceIsPhoenix=true] {\n  min-height: 16px;\n  max-height: 16px;\n}"}
  - ReplaceZlib: {Offset: 0, Find: "MediumVertSpacer[qApp_deviceIsDragon=true] {\n  min-height: 44px;\n  max-height: 44px;\n}", Replace: "MediumVertSpacer[qApp_deviceIsDragon=true] {\n  min-height: 22px;\n  max-height: 22px;\n}"}
  - ReplaceZlib: {Offset: 0, Find: "MediumVertSpacer[qApp_deviceIsDaylight=true] {\n  min-height: 56px;\n  max-height: 56px;\n}", Replace: "MediumVertSpacer[qApp_deviceIsDaylight=true] {\n  min-height: 28px;\n  max-height: 28px;\n}"}

[NiLuJe]

@GeoffR: A quick glance at stuff with a 44px size (both in zlib streams and in literals) indeed yields quite a few things. Some stuff can easily be discarded as "probably not it" given the context, and I was indeed afraid what was left would be one of those spacers, which do look like they might be used in quite a few places...

I hadn't yet gone around to actually try it though, so all of this was theoretical so far .

But I'll see how that behaves tomorrow, thanks for keeping at it! .

EDIT: Out of curiosity, besides this example, has anyone tried any of those other ones? (Ideally so I don't spend my time testing stuff that someone already checked ).

[NiLuJe]

The other approach I can see (correct/stop me if I'm wrong, this is way out of my wheelhouse) would be to figure out where the final computation of that ReadingView QFrame/QRect is being done, and brute-force an adjustment in there somehow. Could the offset pointed out in the logs be used to step into the memory at runtime via gdb to help figure this out? Or is this a vain effort without debug symbols?

[Semwize]

Originally Posted by GeoffR

patch to halve MediumVertSpacer height (nickel.yaml)

It works, margin top is smaller (epub)

[GeoffR]

Originally Posted by Semwize

It works, margin top is smaller (epub)

Great, that is progress then. So the questions are:
- Does it affect the footer too? (when the "Show footer" option is unticked.)
- Does it affect KePub books in the same way?
- Does it cause problems elsewhere in the UI?

I guess the next step will be to find whereabouts in the code this particular MediumVertSpacer is being constructed, so it can be changed without affecting other places that type of spacer is used.

[Semwize]

Originally Posted by GeoffR

- Does it affect the footer too? (when the "Show footer" option is unticked.)
- Does it affect KePub books in the same way?
- Does it cause problems elsewhere in the UI?

1. Yes (tried 00px). Footer decreased
2. Yes
3. Not yet noticed

ePub fixed top/bottom margins

In my opinion, this patch does not affect anything at the moment.

- ReplaceString: {Offset: 0x0E, Find: "00px", Replace: "00px"} # TOP MARGIN
- ReplaceString: {Offset: 0x18, Find: "00px", Replace: "00px"} # BOTTOM MARGIN

I tried to change, 0 effect

Correct if I'm wrong.

[GeoffR]

Originally Posted by Semwize

In my opinion, this patch does not affect anything at the moment.

In my opinion, this patch does not affect anything at the moment.
I tried to change, 0 effect

Correct if I'm wrong.

If the publisher has set a @page margin in the book's stylesheet then the `ePub fixed top/bottom margins` patch should override it, and if you change the Replace: values then the top/bottom margins should increase by the amount you set.

But perhaps something has changed and @page doesn't work anymore, or maybe the patch can no longer overrides the @page margin set in the book's stylesheet? If that has happened then it would break the `ePub fixed/adjustable top/bottom margins` patch too.

[Semwize]

I put 00px in the patch

Decrease MediumVertSpacer

and 12px in

- ReplaceString: {Offset: 0x0E, Find: "00px", Replace: "12px"} # TOP MARGIN

0 effect

[GeoffR]

Attached is a small ePub book that has a large (100px) page margin set in its stylesheet. The first page is a thin rectangle, following pages are Lorum Ipsum text. Sideload it as an ePub (don't convert to KePub)

If you don't have either of the `ePub fixed top/bottom margins` or `ePub fixed/adjustable top/bottom margins` patches enabled, then the book should display with all four page margins 100px wide (in addition to any header footer.)

If you have one of the above patches enabled then the book's large page margins should be ignored and the page margins should be whatever you have set in the patch.

Just interested to know if @page is still working as it did in previous firmware versions.

[Semwize]

Yes, patches work, remove the margin.

[GeoffR]

Originally Posted by Semwize

Yes, patches work, remove the margin.

Did you test it without the patches enabled? I.e. do you know that the margin removed because of the patches, or could it be that @page no longer works in ePubs?

[Semwize]

GeoffR,
first checked with disabled patch, then turned on, margin was remove.

patches work

[GeoffR]

Originally Posted by Semwize

GeoffR,
first checked with disabled patch, then turned on, margin was remove.

Okay thanks, so @page is working as it did before.

But then I can't explain why the `ePub fixed top/bottom margins` patch doesn't increase the top margin when you changed the value from 00px to 12px.