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

DJUNGELSKOG · 07-22-2026, 09:13 AM

Quote:

Originally Posted by The Old Man

Not sure what’s happening

Claude

The Old Man · 07-24-2026, 07:56 AM

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 · 07-24-2026, 07:57 AM

Quote:

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 · Yesterday, 02:02 PM

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 · Yesterday, 02:12 PM

Quote:

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 · Yesterday, 07:44 PM

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.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
justRead.app – Native iOS EPUB Reader (Built for Power Readers)	petrjahoda	Apple Devices	163	03-12-2026 01:16 PM
[Archived] Marvin ePub reader for iPad	Jessica Lares	Marvin	1789	08-27-2013 10:38 AM
iPad users: Meet Marvin, an iOS ePub reader	GRiker	Devices	4	06-20-2013 10:16 AM
Workflows to use Calibre with iOS Apps: Good Reader-PDFs, Marvin-epub, Kindle-mobi?	crashnburn	Calibre	4	06-14-2013 04:49 PM
Built in EPUB reader in Calibre	Cpl Punishment	Calibre	12	02-04-2011 08:59 AM

07-24-2026, 07:56 AM	#32
The Old Man Guru Posts: 636 Karma: 1606819 Join Date: Jan 2008 Location: New Hampshire Device: iPad Mini	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.

Yesterday, 02:02 PM	#34
AkiraT Member Posts: 15 Karma: 224 Join Date: Jul 2026 Device: none	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.

Yesterday, 07:44 PM	#36
AkiraT Member Posts: 15 Karma: 224 Join Date: Jul 2026 Device: none	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.

Advert

Advert