From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#58041: [PATCH] docview: Use svg images when using mupdf for conversion Date: Mon, 09 Jan 2023 18:02:49 -0500 Message-ID: References: <87k05t848c.fsf@gmail.com> <87eds5zhf7.fsf@gmail.com> <87v8lfy8g5.fsf@gmail.com> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24031"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 58041@debbugs.gnu.org To: Visuwesh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 10 00:03:27 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 1pF1At-00064x-0v for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 10 Jan 2023 00:03:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pF1AW-0005VE-Sb; Mon, 09 Jan 2023 18:03:04 -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 1pF1AU-0005Un-RC for bug-gnu-emacs@gnu.org; Mon, 09 Jan 2023 18:03:02 -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 1pF1AU-0002f7-Iv for bug-gnu-emacs@gnu.org; Mon, 09 Jan 2023 18:03:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pF1AU-0004hJ-8E for bug-gnu-emacs@gnu.org; Mon, 09 Jan 2023 18:03:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 09 Jan 2023 23:03:02 +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.167330538118050 (code B ref 58041); Mon, 09 Jan 2023 23:03:02 +0000 Original-Received: (at 58041) by debbugs.gnu.org; 9 Jan 2023 23:03:01 +0000 Original-Received: from localhost ([127.0.0.1]:38360 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pF1AS-0004h4-LI for submit@debbugs.gnu.org; Mon, 09 Jan 2023 18:03:01 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:10412) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pF1AQ-0004gl-Ia for 58041@debbugs.gnu.org; Mon, 09 Jan 2023 18:02:59 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 65E471000D5; Mon, 9 Jan 2023 18:02:52 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3BAC91000CC; Mon, 9 Jan 2023 18:02:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1673305370; bh=ZVo+xJTqqCqpNBMmFg6NivviK6JMUf5fHE0aoYRr3Hk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=GWFrfNNMv1cDfRQ75/CEELkrp3d3H239CoVh316cUXQ8DJNzisruZtJIQk6auyOqM bBzJjzem/mCBxG7UuDdu74Qd2PUPSyNw5XD+9FgJW9HPImUnVpRcvF4aH24RbF4Hf3 4HAxyCU8xq+8RFQAoG7sc89WTgYQ+hwEyztTmnSJVFrI4mlnympEJphuRoZa6+TnOE 8+Xu6I4JHORD0T1+mQKsBBbiV18HiIkbKm64d9XkM8CjNGXIQwSjXj79JI6YZBl55u RB/QScAfPFa4Jr5igxvMZX1wLT23xn9oOgyuKwXe3DpVg7sTS8KxHQwNBDTEs75LTX BBz/OdXpovLPA== Original-Received: from pastel (unknown [45.72.200.228]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 1235E1203DA; Mon, 9 Jan 2023 18:02:50 -0500 (EST) In-Reply-To: <87v8lfy8g5.fsf@gmail.com> (Visuwesh's message of "Mon, 09 Jan 2023 22:02:58 +0530") 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:253051 Archived-At: >>>> IIUC this means that `+` and `-` now don't need to re-process the PDF, right? >>>> I think this is particularly valuable for things like ODT where `+/-` >>>> was pretty slow (because it re-created the PDF each time before having >>>> a chance to focus on the current page). >>> It depends on the value of `doc-view-scale-internally'. The default >>> value (t) implies that we change the :width image property which leads >>> to blurry images when zooming. In my case, even without zooming in, the >>> image quality was noticeably worse. >> >> So `doc-view-scale-internally` should default to nil when we use SVGs, right? > > It should default to t, which is the case currently. 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. >>> If `doc-view-scale-internally' is nil though, what you say happens. >> 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. >> 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). > * 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). Stefan