Re: [O] text-only plots

[Thierry Banel]

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