YAMAMOTO Mitsuharu <[email protected]> writes: >>>>>> On Wed, 18 May 2016 00:21:47 +0200, Mosè Giordano <[email protected]> said: > >>> Recently I posted a Retina display support patch for preview-latex >>> to the emacs-devel list: >>> >>> http://lists.gnu.org/archive/html/emacs-devel/2016-04/msg00890.html >>> >>> 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 tackle. > 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 widgetry. 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 _______________________________________________ auctex mailing list [email protected] https://lists.gnu.org/mailman/listinfo/auctex
