I wiew a pdf with lots of horizontal lines with a 1366x768 screen. Some lines have a 2-pixel width at every zoom value. The interline/line ratio is 12 if I zoom a lot. The result is good with a 1920x1200 screen. The result is good with Acrobat Reader. I attach a sample a of screen save
. The pdf is made with MusiXTeX, a set of TeX macros.
Can I improve the viewing with the settings?
Unlike Acrobat and Okular SumatraPDF does not mess with the authors line thickness so if from your description MusiXTex or LilyPond have set a stave thickness of 2pixels then SumatraPDF will respect that value.
The line thickness is usually controlled by the “Music size” from a range of 4 values “small” (16pt-high staves), “normal” (20pt), “large” (24pt), and “Large” (29pt) and that may be controlled during PDF compilation in the background by a .sty file, however it is best to discuss modifications on the relevant TeX forums.
The best source of info with homepage etc is https://www.ctan.org/pkg/musixtex
The output is a vector format so AFAIK there is no pixel information but intructions to draw lines with a specified thickness. And at present the line thickness is perfect when I view or print with Acrobat reader of view the PostScript, that is the source for the pdf, with GSview.
\largemusicsize or \smallmusicsize in MusiXTeX will affect the size of the staves and other musical symbols with the same proportions as the staff lines.
Can you check the rendering with the latest release of MuPDF? If MuPDF isn’t rendering vector lines the same as Adobe Reader then the problem will have to be fixed in it before the patched version can make its way to Sumatra.
Perhaps some specific values of the zoom give a perfect result, but how can I force a specific zoom value? The (+) and (-) tabs of the zoom do not even cause the current zoom value to be displayed.
from menu (ALT +Z Z) custom zoom can be set
if you find the best for your monitor (and best value may change per screen)
you can then in settings options chose a suitable default value for opening.
IF necessary you can
Thanks. When I say z so my document occupies the whole sumatra window width I can change the zoom value very gradually by changing the window width with my mouse. Then some lines change from 1 pixel to 2 pixels and other lines do the opposite and no zoom value is perfect.
You can find other similar pdf 's I made by searching “engraving files musixtex” site: imslp.org with google
mupdf has exactly the same misfeature.
Yes I tested the latest version as above, thus it is the way that MuPDF converts vectors to nearest pixel to “Improve” aliasing what we need to understand is that converting vectors of fixed thickness to screen dots that differ for each user is not going to be easy to suit every monitor on the market. if a line is 2.5 dots wide in order to be crisp it needs to be thinned to 2 dots for one user or thickened to three dots for another or else it will be 2 black dots and either one or two fuzzy dotted grey pixels on the side(s)
Due to the spacing of a stave this is more noticeable if the white space is not an integer of the strokes so using say 1.41 spacing between lines aggravates the maths. For each user and their monitor(s) there will be an optimum setting that can only be found by trial and error.
If a line is about .5 dot wide, why is is expanded to sometimes 1 dot, somtimes 2 dots? See my initial png sample.
All I will say is that if the PDFs look noticeably better in Adobe Reader on the same monitor without playing around with zoom levels, then surely there’s something Adobe’s doing better than MuPDF (Sumatra’s rendering engine) when it comes to anti-aliasing and displaying vector lines/shapes.
I would call this a roundup or quantization issue instead of a anti-aliasing issue. Is there a sumatra developer around?
I can’t tell you anything more. Rendering is done by mupdf and I don’t work on mupdf.
You could engage with mupdf developers via irc or bug tracker (more info at https://mupdf.com/)
