From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Banel Subject: Re: text-only plots Date: Tue, 10 Dec 2013 22:24:01 +0000 (UTC) Message-ID: References: <20131209121923.GD20815@kuru.dyndns-at-home.com> <20131209235539.GH20815@kuru.dyndns-at-home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqVjD-0003qw-MX for emacs-orgmode@gnu.org; Tue, 10 Dec 2013 17:24:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VqVj6-0006AZ-59 for emacs-orgmode@gnu.org; Tue, 10 Dec 2013 17:24:31 -0500 Received: from plane.gmane.org ([80.91.229.3]:56226) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqVj5-0006AP-RI for emacs-orgmode@gnu.org; Tue, 10 Dec 2013 17:24:24 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VqVj3-00020Q-PU for emacs-orgmode@gnu.org; Tue, 10 Dec 2013 23:24:21 +0100 Received: from mna75-5-82-226-29-239.fbx.proxad.net ([82.226.29.239]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Dec 2013 23:24:21 +0100 Received: from tbanelwebmin by mna75-5-82-226-29-239.fbx.proxad.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Dec 2013 23:24:21 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Suvayu Ali gmail.com> writes: > Firstly, I think the unicode bit is a terrific improvement; specially > the two options: grid and continuous. I think there are two distinct > problems here: the plot as shown in org, and export. We should not > confuse the two. > > I will suggest for the moment having the plotting bits is enough. HTML > export works, plain text export sort of works[1]. As you see, getting > it right for all (most) exporters is non-trivial, so I would say no need > for worrying about supporting past exporters. > > Handling this needs some conditional behaviour: plain text -> backend, > or unicode -> backend. You could use a standardised column title to > selectively choose/ignore columns. So ASCII export would ignore unicode > columns. LaTeX export would replace the chars with appropriate symbols > (e.g. \rule, as suggested by Ivan). Texinfo and markdown supports > unicode, so that should be fine (like HTML). > > When we have something that is acceptable, you can publish the exporter > code and the plotting code as part of the same module, say > org-ascii-plot.el (or something along those lines). Which could then go > in contrib. > > WDYT? > > Footnotes: > > [1] Sort-of, because it "lies" by including unicode chars even if you > export to ASCII only. > Thanks, Suvayu, for your insight into the export issue. So, to summarize, we have several options: 1- Keep only the Ascii version | WWWWWWh | (+) Simple. (+) No problem ahead. (-) Lose the clean look provided by unicodes. 2- Put Ascii version in org-core, Unicode version in contrib/ (+) Simple (+) The Org core is on the safe side, while contrib/ gives an advanced option which could break exporters. (-) The clean look provided by unicodes will remain mostly unknown. 3- Keep Unicode version, do nothing for exporters (+) Simple (-) Generates long threads in mailing lists: "exporter XX is broken, it does not export my table". (-) Not all fonts are able to render such unicodes, (this is true in Emacs, without even talking about exporters). 4- Mark unicode plot columns as "non-exportable", and have exporters ignore them. (+) Clean and straightforward. (-) Need a new feature in org-tables: "non-exportable column". (-) Exporters & users should be made aware of the new feature. 5- Translate unicodes to something sensible, for example - LaTeX exporter: \rule - Ascii exporter: ignore - Odt exporter: pass them on without additional processing (+) Exporters take decisions at the cell level rather than at the table level. (+) "Ignore exotic unicodes" or "do nothing special" are good default behaviors for all exporters. 6- Another option? Now we have to decide. What would be your preference, Org users? Mine would go to option 1 or 2 for the time being. Then if people like the plotter, version 2.0 would implement option 5. Why option 1 or 2 ? Because it is consistent with the rest of Org. Table are made of regular Ascii characters (plus, minus, pipe) |---+---| | a | b | although better suited unicode characters exist http://en.wikipedia.org/wiki/Box_Drawing ┌───┬───┐ │ a │ b │ We all love the vintage look of Org, while being the most advanced orginizer out there, don't we? Thierry