Fit Width no longer shows full page, making extraneous scrolling necessary

[jeois]

I recently updated to v3.4.6 64-bit from v3.2.x on win11. I primarily use SumatraPDF to view ebooks (.epub, .mobi) and noticed fairly significant changes that made viewing much worse from my perspective.

The main issue is that the best zoom mode for me is "Fit Width" making text fill most of the horizontal space, which is perfect for computer monitors in 1920x1080 and other wide-screen landscape resolutions. In the previous version, this also separated the page lengths such that each page fully fit the screen vertically as well, which was great for reading. Now however, the page lengths are always slightly longer than screen size, thus there's TWO levels of scrolling: first within the page, then pages of the book, which creates a bad viewing experience since it never shows the full page in one screen anymore.

Some of the other zoom and view modes create fixed length pages like I want, but their margins are extremely wasteful for horizontal screen space and makes the font too small, and I know fit width page length separation is possible because it works that way for the previous version of sumatrapdf and other ebook readers.

Perhaps someone can please help me with configuration as I used to have custom colors, margin sizes, and fonts as well; I'm not sure if the old settings affected this bug since they no longer can be applied separately for ebooks, although those are minor compared to this full page viewing issue. I tried searching for this in other threads, but haven't found anything useful yet. Thanks in advance for your consideration of this issue.

EDIT: "Fixed" Width should have been "Fit" Width

[avorobey]

I think you mean "Fit Width" (in the Zoom menu), not "Fixed Width" - just asking to make sure I'm not missing some other "Fixed Width" I'm not familiar with.

I don't often use SumatraPDF to view .epub files, but I played with one just now, with 3.2 and the latest version, and it seems like with the recent versions (that switched to using the MuPDF library for .epub/.mobi rendering) I can't change the amount of text fitting in one line. That is, the "Fit Width" option can make the font bigger to make the text fit horizontally, but no matter how I resize the window, it won't change where the linebreaks are. Whereas in the 3.2 version, SumatraPDF was definitely able to "reflow" the text and make the lines longer/shorter in terms of the text they contain. Is that what you're seeing as well?

If this is true (I'm hoping it's not and I'm just missing some obvious way to reflow epubs in recent versions; @kjk do you know/remember?), it seems like a worse deal than before, and something that ought to be fixable, in theory.

[jeois]

I think you mean "Fit Width" (in the Zoom menu), not "Fixed Width"

Right, the zoom mode I'm talking about is "Fit Width". Sorry for confusing the terminology. I think you see the issue I'm describing, thanks.

We also can't change the font in settings anymore, and this library seems to be inflexible. I'm not sure if the page and chapter horizontal scroll bar not displaying anymore is also related.

My bad if this is off-topic, but if SumatraPDF isn't targeted for ebooks anymore and is only maintaining rudimentary features from muPDF, then I'm not sure what else to use. I haven't used Windows in several years, and most similar software seems to be not open/free nor as lightweight as SumatraPDF.

[GitHubRulesOK]

@avorobey
The "Legacy" render of eBooks was specific to SumatraPDF source code that reflowed the text acording to ONE Font (like most old hardware readers) and thus had many limitations with Multiple styles and languages / fonts etc. The switch to MuPDF introduces its own limitations related to a Fixed UI and scale of fonts and which fonts are to be respected in each locality.

For a short while there was overlap but AFAIK (same as for annotations) the management of conflicting methods was too time /resource consuming. MuPDF has a concept of zoom in/out scaling as can be seen in their GL viewer. Also they have hotkey means to adjust for anti-alias and custom ebook styling but have not looked that deeply to say how that could be ported.

[jeois]

My tests with MuPDF have only displayed a single page portrait resolution with no options. Of course, the framework's reference binaries probably need many parameters for full functionality, but by default it seems to be configured for mobile screen resolutions.

SumatraPDF is already doing something to display the pages differently, and if we could only adjust that, then perhaps we can view full pages like before, although if it's only doubling and re-scaling its output without passing arguments, then that is indeed quite limiting.

[GitHubRulesOK]

@jeois
Mupdf is a powerful library designed for lightweight applications thus supplied as MuTool for Java scripting or a binary for file manipulation.

Artifex "off the shelf" viewers are primarily for Mobiles such as Android with MuPDF-GL as a basic windows key driven showcase with limited User Interface press spacebar to go forwards (F1 for functions), Hence the ideal canvas core for SumatraPDF. To control its behaviour in a programmable way there is 3rd party PyMuPDF, but used as consol editor not usually for viewing.

[kjk]

@avorobey Yes, mupdf is much better than previous engine at more complex HTML but regressed on ability to change the font size, colors etc.

Part of it is sub-optimal use of mupdf for epub. You're right that the way we use it currently it's not possible to have more text.

I think it's possible but I didn't spend enough time figuring out how to do it and how to achieve max speed.

Part of the issue is that before epub support, mupdf represented a location in the file as a single number i.e. a page.

With epub it's now abstract value fz_location that has chapter and page.

I haven't yet updated Sumatra's API's to that system which prevents getting max speed out of epub rendering (we have to render the whole book before showing a single page, as opposed to rendering just one chapter i.e. html file).

[avorobey]

@jeois, as I suspected and @kjk confirms, we should be able to use MuPDF in a smarter way, achieving more than what was possible in the older version rather than less. I think your dislike of current Fit-to-width behavior is reasonable, and this bug is a good place to track changing that. I'll try to look into improving Sumatra's use of MuPDF for epubs/mobis, though obviously can't promise any timelines etc.