Hello and thank you very much for your reply, Arash,


Thanks for your report and sorry for the late response. Does this mean
that images are not Ok (in terms of resolution) only for a scale of
200%?

 

The previews at 100% scale are acceptable, however, already pixelated compared to the source images and the main text font.
At 200% the previews look like the resolution is 2x lower than the resolution at 100%, and are blurry, making it hard to recognize smaller features like subscript letters.
 

IIUC, the only place in preview.el where `frame-monitor-attributes' is
used is:


As you can see, only the values for 'mm-size' and 'geometry' are used
for the calculation.

Looking at the above, I don't understand the values attached to the
'geometry' key, most notably, the changes for WIDTH and HEIGHT depending
on the scaling. To recap, the 'geometry' key is defined as:

  'geometry'

      Position of the top-left corner of the monitor's screen and its
      size, in pixels, as '(x y width height)'.

Maybe this is a bug in Emacs?

Best, Arash

 
I'm not sure, where the possible root of the problem is hidden.
 
The problem arises even at standard 100% scaling:
 
(1) External monitor, 24" 1920x1080
 
Previews have correct sizes.
 
(preview-get-dpi) returns correct dpi value:
(92.01509433962264 . 91.44)
 
and the (preview-scale-from-face) returns
#[0 "\300\302    !\245\207" [12.0 preview-document-pt-list preview-hook-enquiry] 3]
that corresponds to the value 1.2 scaling.
 
 
(2) Built-in laptop monitor, 14" 1920x1200
 
Preview are too large.
 
(preview-get-dpi) return correct dpi value:
(162.56 . 160.42105263157896)
 
however,  (preview-scale-from-face) returns the same value as for external monitor:
#[0 "\300\302    !\245\207" [12.0 preview-document-pt-list preview-hook-enquiry] 3]
 
Setting the scaling value manually with
(setq preview-scale-function (lambda () 0.66))
fixes the problem for this monitor.
 
Is there any additional information on my part that may help in identifying the cause of the problem?
-- 

with kind regards,
Vlad
_______________________________________________
bug-auctex mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-auctex

Reply via email to