From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Newsgroups: gmane.emacs.devel Subject: Printing Date: Sat, 28 Mar 2009 13:31:05 +0300 Message-ID: <5f0660120903280331y780c80b7i57a8115dc4b029eb@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1238241879 17201 80.91.229.12 (28 Mar 2009 12:04:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 28 Mar 2009 12:04:39 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 28 13:05:57 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LnXI9-0003W1-E8 for ged-emacs-devel@m.gmane.org; Sat, 28 Mar 2009 13:05:55 +0100 Original-Received: from localhost ([127.0.0.1]:38342 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LnXGl-0002S0-R3 for ged-emacs-devel@m.gmane.org; Sat, 28 Mar 2009 08:04:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LnVot-000186-4O for emacs-devel@gnu.org; Sat, 28 Mar 2009 06:31:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LnVoo-00013Q-2n for emacs-devel@gnu.org; Sat, 28 Mar 2009 06:31:18 -0400 Original-Received: from [199.232.76.173] (port=43210 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LnVon-00013F-Tg for emacs-devel@gnu.org; Sat, 28 Mar 2009 06:31:13 -0400 Original-Received: from mail-ew0-f160.google.com ([209.85.219.160]:53442) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LnVoj-0004yt-0k for emacs-devel@gnu.org; Sat, 28 Mar 2009 06:31:09 -0400 Original-Received: by ewy4 with SMTP id 4so1462559ewy.42 for ; Sat, 28 Mar 2009 03:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=XOZWt1G4qDKMM7+A0hSor1A3SX3O+qVJBj7pQCIqxhc=; b=CU6USxdo5lh6aJDdtoPAmOw/VFJ872BqvQCIivWcNBpoIfnuPP1M6AECOosv3XjwE2 RdGZPAJ2BDy9SP9/mvzkyje8/3oXCBLTdHijVif3cDu1LQ2MH60h04rUD+E166btRMI4 9RPsj12Owws+3Yq+OVAbM5nwB8UB5ozimUT5A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=WBUVcZT70qv7MqwpYK8MF1QmACoBtvPYp+UkteaR2UfdBOT/hY0hZne/ivW5jYGgP5 dm7fqrcflj7TMnikJGK4RLQSLVJbJ2ulLN674qru8WO5OHepH35URqHxVSBWIWA1bdYl rtMUUisZ4lc4tRQHmJBBc/eW13qYsTHDha6wQ= Original-Received: by 10.210.115.15 with SMTP id n15mr891777ebc.95.1238236265181; Sat, 28 Mar 2009 03:31:05 -0700 (PDT) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-Mailman-Approved-At: Sat, 28 Mar 2009 08:04:05 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:109887 Archived-At: Hello! I use Emacs on regular basis for a couple of years already, and I find it a great piece of software. Currently I use Emacs 23. As a user, I'm very pleased with the overall direction of development. I highly appreciate recent usability improvements, namely Xft fonts, visual line wrapping, transparent remote file access, etc. With the most important internationalisation and display issues fixed in Emacs 23, it's probably the right time to attack another long standing problem: the printing. By this post I wish to attract your attention to fundamental usability problems of Emacs printing mechanism, and initiate a discussion of how to resolve them. Emacs printing is broken -- and I mean it -- is *fundamentally*, totally broken. You have either to be a PostScript guru, restrict yourself to ASCII characters, or cheat/hack to be able to use Emacs printing. And I'm not even talking about non-GNU systems! Many users find it major pain or impossible to setup printing in Emacs (here are links to *recent* threads at gnu.emacs.help): Pretty multilingual PostScript printing: http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/4b08d4ff107d48d/ Printing with emacs: Not working: http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/c477e1561c444583/ Printing in Emacs: http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/d4c5ee0e29adcdfb/ To reproduce the problem you only need Emacs, X and a printer: 1) C-h h; the 'Hello' buffer with international characters shows up. If you don't see anything except Latin characters, please install the TTF version of unifont. 2) M-x ps-print-buffer-faces; the buffer is printed, but every non-Latin character is replaced with '?'. However, if the 'Hello' buffer contents is printed via as simple editor as GEdit, *all* the characters are printed, and appear smooth and nice! Having analysed mine and other users' experience, and having examined how the printing works in modern applications, I propose the following requirements for the Emacs printing mechanism: 1) Simple printing configuration should require no or almost no knowledge and effort. The only user input that might be required is the printer name. 2) It should not be necessary to install additional packages/files solely for the Emacs printing. 3) Printing functionality should work equally good on PostScript and non-PostScript printers. I can think of the following ways of how these requirements may be achieved: a) Try to improve current functionality, making no or almost no modifications to the current printing engine. This includes simplifying the configuration interface. Not sure points 2) and 3) can be fixed this way though. b) Use standard GTK+ printing facilities as GEdit and many other applications do. Emacs is built with GTK+ interface for quite some time now, so I suppose there should be no architectural problem in using GTK+ for printing as well. Please correct me if I'm wrong. c) Utilise superior rendering capabilities of some other application, like it is done by package hfyview.el: http://www.emacswiki.org/emacs/PrintWithWebBrowser . This approach doesn't conform to 2) though. >From the user perspective, I like b) because I think it would solve 3) and would present a nice user interface. I call you to discuss the pros and contras of the proposed approaches from the programmer perspective and/or propose other solutions. Thanks for your effort, Andrey Paramonov To reproduce the problem you only need Emacs, X and a printer: 1) C-h h; the 'Hello' buffer with international characters shows up. If you don't see anything except latin characters, please install the TTF version of unifont. 2) M-x ps-print-buffer-faces; the buffer is printed, but every non-latin character is replaced with '?'. However, if the 'Hello' buffer contents is printed via as simple editor as GEdit, *all* the characters are printed, and appear smooth and nice! Having analyzed mine and other users' experience, and having examined how the printing works in modern applications, I propose the following requirements for the Emacs printing mechanism: 1) Simple printing configuration should require no or almost no knowledge and effort. The only user input that might be required is the printer name. 2) It should not be necessary to install additional packages/files solely for the Emacs printing. 3) Printing functionality should work equally good on PostScript and non-PostScript printers. I can think of the following ways of how these requirements may be achieved: a) Try to improve current functionality, making no or almost no modifications to the current printing engine. This includes simplifying the configuration interface. Not sure points 2) and 3) can be fixed this way though. b) Use standard GTK+ printing facilities as GEdit and many other applications do. Emacs is built with GTK+ interface for quite some time now, so I suppose there should be no architectural problem in using GTK+ for printing as well. Please correct me if I'm wrong. c) Utilize superior rendering capabilities of some other application, like it is done by package hfyview.el: http://www.emacswiki.org/emacs/PrintWithWebBrowser . This approach doesn't conform to 2) though. >From the user perspective, I like b) because I think it would solve 3) and would present a nice user interface. I call you to discuss the pros and contras of the proposed approaches from the programmer perspective and/or propose other solutions. Thanks for your effort, Andrey Paramonov