Leafmark — I built an EPUB reader because I never got over Marvin

[DJUNGELSKOG]

Originally Posted by The Old Man

Not sure what’s happening

Claude

[The Old Man]

I notice this morning there is another update. I’m not sure a version number as the app gives no indication. The split page problem still exists making the app unusable. As you page through a book, eventually, depending on font size, part of two pages appear on the screen. This seems to occur with every book including the Frankenstein supplied by the developer.

[JSWolf]

Originally Posted by The Old Man

I notice this morning there is another update. I’m not sure a version number as the app gives no indication. The split page problem still exists making the app unusable. As you page through a book, eventually, depending on font size, part of two pages appear on the screen. This seems to occur with every book including the Frankenstein supplied by the developer.

Same issue here. The app is unusable.

[AkiraT]

Thank you both for keeping at this — the split page report is what let me find it, and I am sorry it took a version this long.

I can reproduce it now, and I know what it is.

Readium reserves a strip of vertical space above and below the page. I had assumed that reservation was there to clear an app's own toolbars, and since Leafmark draws its chrome as a transient overlay I cut it down to 20pt to reclaim the white bands in landscape. That reservation is not decoration: it is what makes a paginated column end exactly at the page boundary. With it cut, the column runs past the bottom of the page and the first line of the next page shows up under the current one. Because it depends on how the line height divides into the page height, it comes and goes with font size — which is exactly what you both described.

It has been in every build since 1.6, on every book including the bundled Frankenstein. So this was not something on your end.

The fix is to put Readium's default reservation back. I have verified on device that the overlap is gone. It is in the next submission to Apple, so it will take a couple of days to reach you.

The trade-off is that the landscape white bands come back for now. I would rather have correct pages than reclaimed margins, and I will solve the landscape spacing a different way rather than by taking that reservation again.

If you see anything still splitting after that update lands, please say so here.

[JSWolf]

Originally Posted by AkiraT

If you see anything still splitting after that update lands, please say so here.

Font weight is still broken. It does nothing from normal until bold which is again the same old wrong behavior. Font wight needs to be programmatically added to each font in small increments. So bold stays bold and it's not just using the bold or normal fonts. Every font in the family needs to be increased by a small amount. The same small amount.

[AkiraT]

You are right, and I found why.

There are two things driving that control. One is the CSS font-weight, which WebKit can only satisfy by picking a real face, so it jumps straight from normal to bold and gives you nothing in between. The other is a stroke I add around the glyphs to thicken any face continuously — that is the part meant to answer your original point. The bug is that the stroke was being baked into each chapter as it was served, so it only took effect the next time a book was opened. Changing the setting while reading did nothing to the page in front of you, and all you were left with was the normal-to-bold jump.

It now rewrites the rule in the document you are already reading, so every step of the control is visible immediately. I checked it on a page of Frankenstein: going from 100% to 140% without reopening the book increases the ink on the page by about half.

On your wider point — each face in the family getting the same added amount, so bold stays bolder than regular — that is what the stroke does, since it sits on top of whatever face is selected rather than replacing it. What it does not do is drive a variable font's weight axis, which would give a cleaner result on fonts that have one. I am leaving that open rather than claiming it is solved.

To be clear about timing: this is not in the build now with Apple. That one is the pagination fix. The weight fix comes in the one after.

[The Old Man]

Latest version, dark theme, font size 160%, Publishers font, as I scroll through Frankenstein each chapter starts out fine. As I turn more pages the screen gradually displays part of two pages. When you get to the next chapter the app corrects itself and displays correctly but then repeats the error as you scroll through that chapter. This occurs on both the Mini, iPhone 16 and 11” Pro and in any book. Page resets at a new chapter and then gradually splits pages as you move through chapter. AkiraT, don’t you see this?
https://www.pasteboard.co/quxZCbPUpVTM.png