GitHubRulesOK

Results 779 comments of GitHubRulesOK

try not padding into leading above e.g. current ![image](https://user-images.githubusercontent.com/12754913/181653949-01fcbfd3-d773-499a-8b32-f41460a25123.png) proposed `padding: 0px 4px 6px 4px;` ![image](https://user-images.githubusercontent.com/12754913/181654078-6f9876c7-a48e-48d4-bb56-6f4cbecd6c15.png)

@HackbrettXXX ***I think this is user confusion*** thus not a FireFox or jsPDF issue (though words may differ here is the stated intent blob.save will show in ChromEdgium the blobs...

@longinius you are correct that version 97.0 behaves different but my take is that was a bug in 97 since when downloaded as suggested from your link on windows 11...

@jarmalo note I have been most careful to use /show `blobdoc.save()` (as per your usage) since save means offer to client for download and view blob or download blob according...

looks like the shift is due to MuPDF updates but since its file format content specific for the epub image issue perhaps include one sample since that format can be...

@sergsako You can convert the images to larger by using external apps so here I increased image size 250% but in compensation have also changed to zip [SarokaB.fb2.zip](https://github.com/sumatrapdfreader/sumatrapdf/files/9787036/SarokaB.fb2.zip) ![image](https://user-images.githubusercontent.com/12754913/195866364-3c3c51f4-3fb6-49a3-afa7-93431dab4415.png)

Expanded state is normally set in the PDF document, SumatraPDF should honor that (unsure how it works in other formats) then if remember is ON store a copy of current...

here is best example I can find one where in old and new SumatraPDF on first open some are expanded and some are not but the same ones in old...

unless you can provide a sample that differs from standard behavior I suggest its not an issue.

ahhh That's a different rendering methodology and without sample for comparison no way to know how exactly how it should behave. However agreed the newer MuPDF engine behavior does seem...