From: Thierry Banel <tbanelwebmin@free.fr>
To: emacs-orgmode@gnu.org
Subject: Re: text-only plots
Date: Tue, 10 Dec 2013 22:24:01 +0000 (UTC) [thread overview]
Message-ID: <loom.20131210T230400-659@post.gmane.org> (raw)
In-Reply-To: 20131209235539.GH20815@kuru.dyndns-at-home.com
Suvayu Ali <fatkasuvayu+linux <at> 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
next prev parent reply other threads:[~2013-12-10 22:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-07 19:48 text-only plots Thierry Banel
2013-12-08 11:00 ` Suvayu Ali
2013-12-08 11:27 ` Michael Brand
2013-12-08 12:28 ` Michael Brand
2013-12-08 12:58 ` Thierry Banel
2013-12-08 17:43 ` Thierry Banel
2013-12-08 19:48 ` Carsten Dominik
2013-12-08 23:10 ` Thierry Banel
2013-12-09 12:19 ` Suvayu Ali
2013-12-09 14:30 ` Ivan Andrus
2013-12-09 22:48 ` Thierry Banel
2013-12-09 23:55 ` Suvayu Ali
2013-12-10 22:24 ` Thierry Banel [this message]
2013-12-08 22:16 ` Michael Brand
2013-12-08 23:15 ` Thierry Banel
2013-12-08 13:34 ` Achim Gratz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=loom.20131210T230400-659@post.gmane.org \
--to=tbanelwebmin@free.fr \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).