From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Visuwesh Newsgroups: gmane.emacs.bugs Subject: bug#58041: [PATCH] docview: Use svg images when using mupdf for conversion Date: Thu, 12 Jan 2023 12:13:27 +0530 Message-ID: <87fscgxng0.fsf@gmail.com> References: <87k05t848c.fsf@gmail.com> <87eds5zhf7.fsf@gmail.com> <87v8lfy8g5.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10602"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 58041@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 12 07:44:16 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pFrJv-0002bn-UK for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 12 Jan 2023 07:44:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pFrJm-0006Qa-Di; Thu, 12 Jan 2023 01:44:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pFrJi-0006Q0-Le for bug-gnu-emacs@gnu.org; Thu, 12 Jan 2023 01:44:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pFrJi-0001sH-6s for bug-gnu-emacs@gnu.org; Thu, 12 Jan 2023 01:44:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pFrJh-0002Ur-TF for bug-gnu-emacs@gnu.org; Thu, 12 Jan 2023 01:44:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Visuwesh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Jan 2023 06:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58041 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 58041-submit@debbugs.gnu.org id=B58041.16735058279565 (code B ref 58041); Thu, 12 Jan 2023 06:44:01 +0000 Original-Received: (at 58041) by debbugs.gnu.org; 12 Jan 2023 06:43:47 +0000 Original-Received: from localhost ([127.0.0.1]:44448 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pFrJS-0002UD-UE for submit@debbugs.gnu.org; Thu, 12 Jan 2023 01:43:47 -0500 Original-Received: from mail-pl1-f195.google.com ([209.85.214.195]:38562) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pFrJP-0002Tx-IO for 58041@debbugs.gnu.org; Thu, 12 Jan 2023 01:43:45 -0500 Original-Received: by mail-pl1-f195.google.com with SMTP id s8so10960032plk.5 for <58041@debbugs.gnu.org>; Wed, 11 Jan 2023 22:43:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=6ZJZhqPteR8ff1hX9DbD+vU+62rnQO8BCyhHTooerMk=; b=cEiwZj1XLbKsKZ4FmANIaOLI6BIWR4N4KmD9MHo6z+mP0FKWvvmPc2rVx3QXrei6MI y8UI3hQcG2KEAzCmY08vugYkyRw/wCA7L3hplUGRVSSgQ6RPd4Q95sYdc6Tmb2NyOpri 5FqtzdkdPHLwqWoVwxCC13h/nwAzbwMA7kmlYKM2/cqLKRoPWyhkoto6suKUT1558Yc/ +woDFOLU0x9ykEWLJKmFrW+XRUZ//YiHGM87QBdjLcCYhS/Fp0kYqgDp2WCarxZB9UxY okI3e+Aa9DrezwT1YBlaxkD4DNBrQiR6ghH2ukdjO/QbZYoffMuvv2pOB7SYtGZnhFZ1 vG1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6ZJZhqPteR8ff1hX9DbD+vU+62rnQO8BCyhHTooerMk=; b=0Fp8GnqE6xl/gOuAJF4UMcpoE9m2ZVYYyiPC3xgLNryUfsPruBtQUldx3yxv72PcFa +VCe8LTOnZZL5DbN0nKaSy+TvBYCa8nH6NqbnC+sp+DJ4Dph1ZhO1NDKrQ3NSpWeXAqn tBAu8S4QKd0IO5D3Pf1Es0KgDvxrkwC/Tz85EwUM9KNK6oAynz96nW2+qHpCY2P51Rda n36uK8Ng7lB8M3Slu4VGwkIdks2Z+dCslMGRwh19yzFkFFMxuRwK5j07lb5UBBDO4yK1 uZK94Ipb4VgpNqTIesc0TjeEsa/Cnk9TpJ44bnbKhZGJi+C5GUvjQ289+WoiRRtCZP2V U75w== X-Gm-Message-State: AFqh2kp/tC2FWCVniK4qW/IBvpyU8SswpO7+zYV7vzruVg7zjAYMbp5o WD2P9eRnYjidlZzRsyCAf2k= X-Google-Smtp-Source: AMrXdXvI7DkWlTE4x86wL3hUpxkyAblstdeWAu+lizPDKoRKG7nFKmz0sC7EkQcqP1D4SmwTIfXjlg== X-Received: by 2002:a17:902:ef8e:b0:193:2bed:3325 with SMTP id iz14-20020a170902ef8e00b001932bed3325mr5819668plb.15.1673505816589; Wed, 11 Jan 2023 22:43:36 -0800 (PST) Original-Received: from localhost ([115.240.90.130]) by smtp.gmail.com with ESMTPSA id l16-20020a170902f69000b00177efb56475sm11365771plg.85.2023.01.11.22.43.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Jan 2023 22:43:35 -0800 (PST) In-Reply-To: (Stefan Monnier via's message of "Mon, 09 Jan 2023 18:02:49 -0500") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:253178 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [=E0=AE=A4=E0=AE=BF=E0=AE=99=E0=AF=8D=E0=AE=95=E0=AE=B3=E0=AF=8D =E0=AE=9C= =E0=AE=A9=E0=AE=B5=E0=AE=B0=E0=AE=BF 09, 2023] Stefan Monnier via "Bug repo= rts for GNU Emacs, the Swiss army knife of text editors" wrote: > Then what did you mean by: > > The default value (t) implies that we change the :width image > property which leads to blurry images when zooming. I should have said "leads to blurry images when zooming when using PNG images." My bad. It is the same as when we use +, - to zoom in on a PNG image in image-mode. >>> IIUC you're saying here that when `doc-view-scale-internally` is nil we >>> re-create the SVGs every time the users try to zoom in/out? While not >>> strictly a bug, it's a significant inefficiency we should address, no? >> I suppose so. But I'm not really sure if users out in the wild adjust >> the variable. > > I set it to nil because of the blurriness. >> If they do, then it might be worth looking into ignoring >> that variable if we're generating SVG images. > > Ah, that'd be a good option, indeed. Right, then I guess adjustment of that sort is in order. How about the following patch? It should be safe enough to go to emacs-29. --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0002-Use-internal-image-scaling-when-using-SVG-images-in-.patch >From 8e003e7127ff929306faef8e65af31cf8c7e4d08 Mon Sep 17 00:00:00 2001 From: Visuwesh Date: Thu, 12 Jan 2023 12:03:49 +0530 Subject: [PATCH 2/2] Use internal image scaling when using SVG images in doc-view * lisp/doc-view.el (doc-view-enlarge, doc-view-scale-reset): Default to changing the :width image property when using SVG images even if doc-view-scaling-internally is nil. (bug#58041) --- lisp/doc-view.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/doc-view.el b/lisp/doc-view.el index 7c272f52fb..19204f25b4 100644 --- a/lisp/doc-view.el +++ b/lisp/doc-view.el @@ -921,7 +921,7 @@ doc-view-shrink-factor (defun doc-view-enlarge (factor) "Enlarge the document by FACTOR." (interactive (list doc-view-shrink-factor)) - (if doc-view-scale-internally + (if (or doc-view-scale-internally doc-view-mupdf-use-svg) (let ((new (ceiling (* factor doc-view-image-width)))) (unless (equal new doc-view-image-width) (setq-local doc-view-image-width new) @@ -941,7 +941,7 @@ doc-view-shrink (defun doc-view-scale-reset () "Reset the document size/zoom level to the initial one." (interactive) - (if doc-view-scale-internally + (if (or doc-view-scale-internally doc-view-mupdf-use-svg) (progn (kill-local-variable 'doc-view-image-width) (doc-view-insert-image -- 2.38.1 --=-=-= Content-Type: text/plain I see that the user option is also used by doc-view-insert-image but I'm not sure if the adjustment is needed there as well. >>> Another thing that's odd now is that we use >>> `doc-view-pdf->png-converter-function` to convert to SVG, despite >>> its name. >> >> It felt like a waste to create a separate pdf->svg function since it >> would contain the same exact BODY of mupdf pdf->png function since we >> only change the PNG argument to end with a .svg extension at the caller >> site (see doc-view-set-up-single-converter). > > I wasn't thinking of duplicating the code, but of rethinking the naming > a bit. I think what we meant by "pdf->png" is actually the process that > extracts pages (which just happened to use the PNG format and now can > also use the SVG format). Indeed, it is a misleading name. This change will have to go to master, I believe? I have to look around a bit more to see where the function is being used. There's also the fact that there's more than one more program that can generate SVG files (as Gregory pointed out in this thread) so it might be nice to have pdf->png and pdf->svg "function variables" and a "super function" that actually does the job. Hopefully, this will allow to fall back gracefully to PNG if SVG generation is faulty. >> * doc-view generates SVG images when viewing PDF files if possible. >> If Emacs is built with SVG support, doc-view defaults to generating SVG >> files when using MuPDF as the converter for PDF files. To get the old >> behaviour, set 'doc-view-mupdf-use-svg' to nil. >> Note that MuPDF SVG generation is known to be buggy for certain files. > > Sounds good. In my case, it wasn't "buggy" but just very slow (the > generation of the SVG is fast, but the SVG is very slow to render), so > maybe the last line should say: > > Note that MuPDF SVG generation is known to sometimes generate > files that are buggy or can take a long time to render. > > Also, the wording suggests the new default is a poor choice, so we may > want to include a more positive note about why we choose it as a default > despite its occasional downside (i.e. better rendering). Thanks for the feedback, how about the following patch? --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-etc-NEWS-Announce-doc-view-s-SVG-support.patch >From 5b05c545eb3b974416daedcb78f3187ffb94af72 Mon Sep 17 00:00:00 2001 From: Visuwesh Date: Thu, 12 Jan 2023 11:58:29 +0530 Subject: [PATCH 1/2] * etc/NEWS: Announce doc-view's SVG support. (bug#58041) --- etc/NEWS | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/etc/NEWS b/etc/NEWS index 16d17821b7..505943ffcf 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -561,6 +561,18 @@ option) and can be set to nil to disable Just-in-time Lock mode. * Changes in Emacs 29.1 +--- +** doc-view now generates SVG images when viewing PDF files if possible. +If Emacs is built with SVG support, doc-view defaults to generating +SVG files when using MuPDF as the converter for PDF files which leads +to genearlly sharper images (especially when zooming) and +customization of background and foreground color of the page via the +new user options 'doc-view-svg-background' and +'doc-view-svg-foreground'. To get the old behaviour, set +'doc-view-mupdf-use-svg' to nil. +Note that MuPDF SVG generation is known to sometimes generate files +that are buggy or can take a long time to render. + +++ ** New user option 'major-mode-remap-alist' to specify favorite major modes. This user option lets you remap the default modes (e.g. 'perl-mode' or -- 2.38.1 --=-=-=--