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
