[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 11:42:34 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

YAMAMOTO Mitsuharu <address@hidden> writes:

>>>>>> On Wed, 18 May 2016 00:21:47 +0200, Mosè Giordano <address@hidden> said:
>>> Recently I posted a Retina display support patch for preview-latex
>>> to the emacs-devel list:
>>> You need Emacs Mac port, which is also mentioned in the above post.
>>> It makes Ghostscript generate PDF files instead of PNG ones, and
>>> let the Mac port render them using the `image-io' image type via
>>> PDFKit.  So moving an Emacs frame between Retina and non-Retina
>>> displays works gracefully (the Mac port re-renders PDF
>>> automatically).  As a bonus, it enables us to use LCD smoothing.
>>> So it is actually meaningful also on non-Retina displays.
>> This looks very interesting, but for installing the patch into AUCTeX
>> I would prefer it to be compatible with vanilla GNU Emacs as well.
>> Is it possible to improve it?
> It is compatible with vanilla GNU Emacs in the sense that it does not
> add any positive or negative effect.  Vanilla GNU Emacs does not
> provide us with any special support for images (as opposed to text) on
> a Retina display.

There is a reason that vanilla GNU Emacs does not have special support
for PDFKit and/or Retina displays: it is a firm policy of Emacs in
particular but also the GNU project generally that it should _not_
provide incentives to prefer non-free platforms over free ones.  So a
feature is either provided also on free platforms, or not at all.

> 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

> If you compile vanilla GNU Emacs with ImageMagick support, which can
> render PDF if built properly, then you can get the idea how my patch
> works with respect to the generation of PDF files by replacing every
> occurrence of `image-io' with `imagemagick' in the patch.  It would
> work even on other platforms.  But I don't think this is practical for
> actual use, because PDF rendering with ImageMagick is much slower.

preview-latex has an interactive rendering pipeline for both PostScript
and PDF working via Ghostscript.  It would be feasible to try
integrating stuff like cairo and/or the poppler libraries or some
similar rendering surface in there, possibly going through some

That's a worthwhile project.  If it's done modular enough, it might be
feasible even to put something based on PDFKit or so as an equivalent
renderer for Macs without having to create a separate framework/codepath
for it.

But a Mac-only solution does not really make sense to distribute by the
FSF.  If people want to promote Mac-only solutions, they are free to
create them based on the AUCTeX code base and distribute them on their
own.  The GPL allows that.

David Kastrup

reply via email to

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