[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AUCTeX] Embedded previews in high-DPI?

From: David Kastrup
Subject: Re: [AUCTeX] Embedded previews in high-DPI?
Date: Wed, 18 May 2016 16:46:05 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

address@hidden writes:

>> YAMAMOTO Mitsuharu <address@hidden> writes:
>>>>> So they are always magnified and look blurry.  This cannot be
>>>>> solved at the Lisp level.
>>>> That does not make a lot of sense: preview-latex queries the
>>>> resolution of the device and generates images matching the device
>>>> resolution.  If Retina displays are lying about their resolution,
>>>> that is the problem to tackle.
>>> That's exactly what the OP tried and resulted in failure, i.e., large
>>> blurry images.  Just giving a large resolution value to Ghostscript at
>>> the Lisp level might work on other platforms, but that is not enough
>>> to display images in a non-blurry way on OS X Retina display.
>> Getting the OS X Retina display to display one pixel per image pixel is
>> not a new feature: fixing this (probably requires fixing in the Emacs
>> source rather than in AUCTeX) to get the platform to behave like others
>> is pretty uncontroversial.  I see no non-technical roadblocks there.
> What happens when a user moves an Emacs frame from a Retina
> display to a non-Retina display?  The window system on OS X keeps
> the logical (point) size rather than the physical (pixel,
> actually backing store) size.

Feel free to work out a framework where rerendering for changed geometry
(like for changing the size of a frame's default font) provides benefits
for free operating systems and see how you can fit the specific problems
of MacOSX into such a framework.

It's imaginable to implement such on-demand rerendering with different
resolution/size as a preview-latex-only component, but it certainly
would make sense for Emacs' general image support.

But as long as you are targeting MacOSX-only benefits, the GNU project
is the wrong place to provide them.  That's one of the reasons that
there are several separate feature-enhanced forks for Mac (I haven't
kept track/count of them) and Windows that cater specifically for
features only implemented on those platforms.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]