Retina-macbook

[Konrad Podczeck]

Hi David,

some time ago it was announced that Aquamacs is "ready for Retina displays.“ So, is it possible now to do some customization in Aquamacs so that, with a Retina display, a pdf-file in doc-view-mode appears in the same quality as in Mitsuharu Yamamoto's Mac port?

Konrad

[David Reitter]

Konrad,

I have not attempted it, but in principle, Aquamacs will render certain higher-resolution images correctly on Retina screens.  Inserting such an image into a buffer (see `insert-image’) or loading a high-resolution icon works using this mechanism.  

So, for example, we can store several images with different resolutions in a TIFF file. 

This code in aquamacs/src/etc/make.sh bundles these images together:

aquamacs/src/etc/make.sh:convert aquamacs-logo\@2x.png aquamacs-logo.png aquamacs-logo.tiff 

Then, in lisp/aquamacs/aquamacs.el, you will find that we set fancy-splash-image to the resulting .tiff:

(fancy-splash-image "aquamacs-logo.tiff")

Then, the Emacs function `fancy-splash-head’, located in lisp/startup.el, uses `insert-image’ to show that file.

As for doc-view-mode, I don’t know it very well and rarely use it.  I’ve been experimenting with the doc-view version that comes with the “Mac port”, and it turns out this port implements a different approach to loading higher-resolution images:  It automatically loads files with a @2x suffix (e.g., “te...@2x.png”) in addition to the primary file.  Doc-view knows about this and generates an additional high-resolution file.  

The important bit of background information here is that image files (png, tiff) come with “DPI” information.  Normally, one would think that one would simply downsize an image depending on its stated resolution and the DPI information we have for the display.  That way, we’d always use the ideal resolution.  However, this is not how it works in “real life”: we display images as they come.   

(On top of that, MacOS pretends that Retina screens just have half their true resolution, but that’s another matter.)

Thus, when Aquamacs (or the Mac Port) load images, they do not normally rescale them.  When Aquamacs loads a multi-representation image set (TIFF), it will select the image with the best resolution.  Mac Port loads different files (PNG) depending on the file name.  These files then get scaled appropriately even though they retain their full resolution for a crisp image on Retina screens.

In Aquamacs, there is a way to rescale the image according to its true DPI, like so:

(insert-image (create-image "/tmp/te...@2x.png" 'png nil :conversion '(truedpi . 0.25)))

In any case, we can do the following things:

A) Take Mac port’s doc-view.el and add some lisp-level or c-level functionality to Aquamacs to automatically load @2x files if present, in lieu of the original ones, and specify the conversion as above

B) Rewrite doc-view to make TIFF files with multiple representations.  This seems quite wasteful.

Variant A) can be done by incorporating as much as possible from Mac port so that we create lisp-level compatibility with the Mac port.  Of course we might write a patch for Mac port to add the Aquamacs functionality (the rescale converter and the TIFF loading). 

If we do A) at the lisp level, we might get away with modifying `find-image’ and `create-image’.  I’m attaching something as a proof of concept (evaluate before loading the doc-view from Mac port).

Hayo — what do you think about this? 

[Hayo Baan]

Hi David, Konrad,

To be honest I don't ever use Aquamacs to view e.g. pdfs (if I do, it's by accident) so I hadn't noticed the resolution problem. But yes, on a Retina MacBook pdfs look quite bad. I have no idea how DocView does its work, but apparently an image is generated of the pdf, which is then shown (this also explains why you can't e.g. select anything in the pdf).

Anyway, given that the work of generating the higher resolution image version is already done by the Mac port (never even knew this version existed, is there any collaboration?), I think it's smart to make use of it. I do like the approach of using the @2x images automatically when found (looks like this is an approach used by Apple too).

Cheers,
Hayo

[Konrad Podczeck]

Hi David,

thanks for your effort. Following your instructions of first evaluating better-image-loading.el and then MacPort's doc-view.el, pdf-files look as they do in MacPort. Great! The time until the pdf-file is completely rendered is a bit longer, but then going from page to page, or reverting the pdf-buffer after tex.compiling the source, is as fast as in MacPort.

Now to what I really have in mind. There is a package "pdf-tools" in Melpa, which could be used to replace Skim as pdf-viewer. Pdf-tools is better in the sense of not exhibiting the "jumpiness" of Skim upon refreshing the pdf and, more importantly, with a much better tex-to-pdf synchronization. Out of the box, pdf-tools together with MacPort also does not show pdf's in high resolution, but with some patches (see below) provided by Yamamoto it does. Together with Aquamacs, pdf-tools displays pdf's only with the "bad" resolution, and this with or without Yamamotos patch, and unfortunately also still also after having evaluated better-image-loading.el. Could you also investigate this matter, given you have some time?

Attached the two relevant files from pdf-tools, patched versions with suffix "el", original version with sufix "el~". And here just the patch (from https://lists.gnu.org/archive/html/emacs-devel/2016-04/msg00648.html 

[David Reitter]

Well, one could check this out for sure (Hayo, do you want a job?).  

I do think that rendering the PDF into pixels externally and then loading and displaying that is not the ideal way to do it.  The right way would be to add PDF loading support to image.c / nsimage.m.  This is going to pose some conceptual problems - PDFs have multiple pages.

If you were to convert a multi-page PDF into images, I would expect significant delays with every update.  

The other issue is that doc-view uses `gs’. Ghostscript doesn’t even come with the system.  Why are we not converting with the built-in system?

- David

--
You received this message because you are subscribed to the Google Groups "aquamacs-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aquamacs-deve...@googlegroups.com.
<pdf-info.el>

--
You received this message because you are subscribed to the Google Groups "aquamacs-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aquamacs-deve...@googlegroups.com.
<pdf-info.el~>

--
You received this message because you are subscribed to the Google Groups "aquamacs-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aquamacs-deve...@googlegroups.com.
<pdf-view.el>

--
You received this message because you are subscribed to the Google Groups "aquamacs-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aquamacs-deve...@googlegroups.com.
<pdf-view.el~>

):

The patch below is a quick hack (see the "XXX" comment below) for PDF

Tools to display 2x images on Retina display.

                                     YAMAMOTO Mitsuharu

                                address@hidden

diff --git a/lisp/pdf-annot.el b/lisp/pdf-annot.el

index 32cb237..bb63a71 100644

--- a/lisp/pdf-annot.el

+++ b/lisp/pdf-annot.el

@@ -921,6 +921,7 @@ other annotations."

                (pdf-cache-renderpage-highlight

                 page (car size)

                 `("white" "steel blue" 0.35 ,@edges))

+            :width (car size)

              :map (pdf-view-apply-hotspot-functions

                    window page size))))

         (pdf-util-scroll-to-edges

diff --git a/lisp/pdf-info.el b/lisp/pdf-info.el

index 6a5edb8..62da214 100644

--- a/lisp/pdf-info.el

+++ b/lisp/pdf-info.el

@@ -1514,7 +1514,15 @@ Return the data of the corresponding PNG image."

     'renderpage

     (pdf-info--normalize-file-or-buffer file-or-buffer)

     page

-    width

+    (* width

+       ;; XXX This does not give optimal results when you have both

+       ;; Retina and non-Retina displays connected.  For true

+       ;; high-resolution support, one should use either TIFF, "@2x"

+       ;; convention, or resolution-independent formats such as PDF.

+       (or (and (memq (pdf-view-image-type) '(imagemagick image-io))

+               (fboundp 'frame-monitor-attributes)

+               (cdr (assq 'backing-scale-factor (frame-monitor-attributes))))

+          1))

     (let (transformed)

       (while (cdr commands)

         (let ((kw (pop commands))

diff --git a/lisp/pdf-isearch.el b/lisp/pdf-isearch.el

index bffbd3b..674d295 100644

--- a/lisp/pdf-isearch.el

+++ b/lisp/pdf-isearch.el

@@ -728,7 +728,7 @@ MATCH-BG LAZY-FG LAZY-BG\)."

                                  occur-hack-p)

                              (eq page (pdf-view-current-page)))

                     (pdf-view-display-image

-                     (pdf-view-create-image data))))))))

+                     (pdf-view-create-image data :width width))))))))

       (pdf-info-renderpage-text-regions

        page width t nil

        `(,fg1 ,bg1 ,@(pdf-util-scale-pixel-to-relative

diff --git a/lisp/pdf-view.el b/lisp/pdf-view.el

index 555032e..406ab98 100644

--- a/lisp/pdf-view.el

+++ b/lisp/pdf-view.el

@@ -725,7 +725,7 @@ See also `pdf-view-set-slice-from-bounding-box'."

   "Return the image-type which should be used.

 

 The return value is either imagemagick (if available and wanted

-or if png is not available) or png.

+or if png is not available), image-io (on the Mac port), or png.

 

 Signal an error, if neither imagemagick nor png is available.

 

@@ -733,6 +733,8 @@ See also `pdf-view-use-imagemagick'."

   (cond ((and pdf-view-use-imagemagick

               (fboundp 'imagemagick-types))

          'imagemagick)

+        ((image-type-available-p 'image-io)

+         'image-io)

         ((image-type-available-p 'png)

          'png)

         ((fboundp 'imagemagick-types)

@@ -741,8 +743,8 @@ See also `pdf-view-use-imagemagick'."

          (error "PNG image supported not compiled into Emacs"))))

 

 (defun pdf-view-use-scaling-p ()

-  (and (eq 'imagemagick

-           (pdf-view-image-type))

+  (and (memq (pdf-view-image-type)

+            '(imagemagick image-io))

        pdf-view-use-scaling))

 

 (defmacro pdf-view-create-image (data &rest props)

@@ -1195,7 +1197,8 @@ This is more useful for commands like

               `(,(car colors) ,(cdr colors) 0.35 ,@region))

            (pdf-info-renderpage-text-regions

             page width nil nil

-            `(,(car colors) ,(cdr colors) ,@region)))))))

+            `(,(car colors) ,(cdr colors) ,@region)))

+       :width width))))

     

 (defun pdf-view-kill-ring-save ()

   "Copy the region to the `kill-ring'."

Thenks, Konrad

--
You received this message because you are subscribed to the Google Groups "aquamacs-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aquamacs-deve...@googlegroups.com.
<better-image-loading.el>

Best,

David

--
You received this message because you are subscribed to the Google Groups "aquamacs-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aquamacs-deve...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "aquamacs-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aquamacs-deve...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "aquamacs-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aquamacs-deve...@googlegroups.com.

[Hayo Baan – IT Services]

On 22/12/16 01:24, David Reitter wrote:
> Well, one could check this out for sure (Hayo, do you want a job?).

Well, I'm currently swamped with assignments already so I really can't
take another big task on top of that I'm afraid 🙁. Besides, I don't yet
know much about the internals of emacs/aquamacs so this would really
take a lot of effort for me anyway (which could be fun, of course).

>
> I do think that rendering the PDF into pixels externally and then
> loading and displaying that is not the ideal way to do it. The right
> way would be to add PDF loading support to image.c / nsimage.m. This
> is going to pose some conceptual problems - PDFs have multiple pages.

Agreed, and yes, how to tackle the multiple-pages? (actually that
already is a problem with the current implementation: you can't scroll
through the multiple pages. heck, the scroll bars are not working
properly at all).

>
> If you were to convert a multi-page PDF into images, I would expect
> significant delays with every update.

Actually that doesn't seem too bad with the current implementation, my
guess is it pre-renders all pages into images beforehand (in the
background?).

>
> The other issue is that doc-view uses `gs’. Ghostscript doesn’t even
> come with the system. Why are we not converting with the built-in system?

Is there an emacs built in system? Wonder why the doc-view guys didn't
make use of it then. Or are you referring to MacOS pdf support? That
could then be a smart thing to make use of (hmm, would it be possible to
have a Preview window inside Aquamacs? then we could divert everything
to that and not have to worry any more 😄.