summaryrefslogtreecommitdiff
path: root/Master/texmf-dist/doc/latex/pgfplots/todo.txt
blob: 780eb01a8a024edbc84162f1a6c20650ed4211f5 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
todo legend:
'-' means: not yet processed, is still to do
'+' means: processed
'X' means: has been checked and deleted
'~' means: partially processed

-------------------------------------------------------------
Testing
-------------------------------------------------------------

last test verifications:
						pgf	CVS		pgf	2.00	pgf 2.00+compat=default
pgfplotstests			2009-12-30	2009-12-30	2009-12-30					
manual					2009-12-29	2009-12-30			
example	latex			for 1.3		2009-12-30					
example	context			for 1.3		2009-12-30				
example	plain tex		for 1.3		2009-12-30				
tests context			2009-12-30	

I NEED MORE TESTS!
The test suite needs to be developed!

+ tests for scan line length stuff for all input methods
+ tests for the placement of tick scale labels
+ test whether title placement works as it ought to do in previous versions
- test 'colormap access=direct'
+ test all z buffer variants
+ test gnuplot and log sampling 3D
- test log sampling in 3D
+ verify mesh/ordering=colwise
- test of compat keys
	-> can they be used as arguments for an axis?
+ test those tickpos num keys! especially in combination with axis line
  variations. Also test ticklabel pos 

-------------------------------------------------------------
USER INTERFACE DECISIONS
-------------------------------------------------------------

- the axis line combination styles can't be adjusted for 3D because they are
  evaluated too early.

-------------------------------------------------------------
MISC
-------------------------------------------------------------

+ disable pgfplots CVS?

- documentation todo:
	+ table + error bar expr
	+ document examples for 3d LINE plots.
	+ the 'tick label anchor' is something which I do not understand myselfes.
	  It was some ad-hoc fix for something, but for what!?
	  there is a fixme in the manual
	+ document the external lib -- it is now part of pgfplots!
		also document the file href thing
	+ the '\x mode' key is hard to find. The same holds for 'log basis \x'.
	+ docs of clickable lib is not up to date (for log basis \x)
	+ document the trafo shift of scatter/@pre marker code.
	+ compat mode
		-> perhaps in preliminary section.
	+ 'variable y'
	- label placement methods:
	  	+ '[xyz]label shift',
		+ 'ticklabel cs',
		+ '[xyz]ticklabel cs',
		+ special anchors
		  	+ 'near ticklabel',
			+ 'near [xyz]ticklabel',
		+ special 'sloped' feature
			+ '/tikz/sloped' for labels,
			+ '/tikz/sloped like [xyz] axis'
		+ every 3d description
		+ every 3d view {<h>}{<v>}/.try
	+ the legend feature for mesh/surf plots:
		'every mesh legend' style and the default 'legend image code'
	+ document how to make line plots in 3d
	- perhaps: display KNOWN key paths in key definitions in gray, not in red?
	+ check if area cycle list is documented
	+ nodes near coords
	+ the 'cube' mark and its parameters 'cube/size [xyz]'
	+ provide a TEXMF config file which sets appropriate limits!
	+ document the anchors which are only local to an axis!
	- document how to fix problems with overlapping axis labels.
	+ add 3D scatter plot examples 
	+ there are still several FIXMEs in the docs
	+ provide sample config file for miktex and document how to enable it
		-> necessary if someone wants to use the external lib!
	X document which is the default view of matlab or gnuplot!
	+ document the 'to listener' feature.
	+ \pgfplotsmathviewdepthxyz and \pgfplotsmathfloatviewdepthxyz
	+ document the trafo shift of scatter/@pre marker code.
	+ provide direct pdf link to pgfplotstable.pdf as in hyperref?
	+ check if area cycle list is documented
	+ nodes near coords
	+ the 'cube' mark and its parameters 'cube/size [xyz]'
	+ provide a TEXMF config file which sets appropriate limits!
	+ the 'surf' and 'mesh' plots belong to /pgfplots, not /tikz.
	+ it is not documented how to provide braces exactly in parametric plots
	+ the key prefix checker in docs is broken, see /pgfplots//tikz/sloped like x axis
	+ finish the auto-generation of hyperlinks:
		+ something like |\pgfplotsset{|  doesn't work properly:
			+ the argument will become ''
			+ the UI introduces closed braces
		+ replace \declaretext and |...| things by appropriate macros.
		+ disable this expensive stuff during image externalization
		+ generate labels for command keys, commands and environments automatically
		+ check if it is possible to create links within codeexamples automatically or semiautomatically
		+ document the macros
		+ verify that the spacing is not affected by the new labels
		- the cycle list args could be highlighted -- but leads to bug!
		+ document some important pgf macros somewhere:
				\pgfmathparse, \pgfmathresult, \node, \matrix, \tikzset, \pgfeov, \pgfkeysvalueof, \pgfkeysgetvalue,
				/tikz/xshift, /tikz/yshift
		+ it would be interesting to parse coordinates '(...)'.
		+ the \pgfplotsshortxystylekey things need to be adapted.
	+ optimize manual for display speed by reducing complicated 3D plots (interp shadings)
		-> the old shader=interp values are still there, with comment signs!
		Check them!
	+ document 'allow reversal of rel axis cs'
	+ document unbounded coords key
	+ document z buffer
	+ document 'plot box ratio={<x>}{<y>}{<z>}' (for 3D axes)
	+ document support for nonuniform colormap specs
	+ |log basis [xyz]| key
  	+ scatter src vs point meta
	+ 3D
	+ view and its subkeys az and el
	+ color bars
	+ document that 'shader=interp' produces smaller pdfs, requires less time to
	  typeset in TeX and produces less time to display in acroread.
	  At least for large grids.
	+ \addplot now detects behavior options and style options automatically
	+ there are a lot of reference to behavior (or behaviour) options in the text
	+ document expression plotting in plot table
	+ meta expr (does that need another name!?)
	+ 'axis description cs'
	+ colormap access=map|direct key.
	+ document simplified format of colormaps
	+ changes in alignment
	+ end-of-scanline markers 
	+ 'rel axis cs'
	+ API for \pgfplotspointouternormalvectorofaxis
	+ API for 
	+	\pgfplotsqpointoutsideofaxis
	+	\pgfplotsqpointoutsideofaxisrel
	X	\pgfplotsqpointoutsideofaxistransformed
	X	\pgfplotspointoutsideofticklabelaxis
	X API for \pgfplotspointticklabelcs
	+ API for \pgfplotsvalueoflargesttickdimen
	+ API for \pgfplotsticklabelaxisspec
	+ API for \pgfplotspointunit[xyz]
	+ API for \pgfplotsconvertunittocoordinate{[xyz]}{dimen}
	X API for \pgfplotsqpointxyzabsolutesize
	+ API for \pgfplotsunit[xyz]length
	+ API for \pgfplotsunit[xyz]invlength
	+ API for \pgfplotspointaxisorigin
	+ API for \pgfplotspointdescriptionxy and the q variant
	+ API for \pgfplotspointaxisxy
	+ API for \pgfplotspointrelaxisxy
	X API for surf shading library
		-> document the problems with pdf2ps for surf shading! pdf2ps samples
		that stuff manually instead of producing level3 postscript!

- clickable lib:
	I have the impression that acroread fires warnings only for the manual - not always when the clickable lib is used. Why!?

-------------------------------------------------------------
PGF / TikZ Development: 
-------------------------------------------------------------
	- external lib: 'list and make' does not work together with \include (aux files!) or other file writing things -- at least not if one tries to do that in parallel.
	+ consider the "plot function" patch from Andy Schlaikjer
	+ it seems fadings don't work correctly with externalization!? 
	- include addition of Christophe Jorssen for MD5 checksums in external lib
	+ write new sub-package 'pgfmanual.sty' which contains a good user interface to the manual styles, environments and all that.
	+ external lib: catcode changes inside of pictures do not work properly.
	- the fpu can't be used inside of paths. That should be fixed.
		-> the problem is that paths may use \pgfmath... routines directly.
		-> this should work! At least with the public math macros \pgfmathadd.
		The \pgfmathadd@ might be implemented differently.
  	+ in the manual, the first two arguments of
	  pgfqkeysactivatesinglefamilyandfilteroptions were inverted.
	+ some predefined filters do not process unknown options correctly
	- external lib in pgf: think whether 'empty image extension' is a bug or a
	  feature.
	- fix landscape bug (pdflscape) in external lib (PGF)
	+ the pgf math parser has wrong precedence for '-' prefix op:
		exp(-x^2) is wrong.
  	- pack the default 'system call' for dvips etc into drivers!
	- active '|' characters result in compilation bugs (\usepackage{program})
	- 'text height=1em' realisieren mit [node font units]1em 

- compatiblity code todo:
  	- the example for plot graphics (with view=0{90}) doesn't work.
	-> that's the 'exp(0-x^2)' bug which is still in pgf 2.00!

-------------------------------------------------------------
BUGS / FIXES
-------------------------------------------------------------

+ the tick pos stuff works (puh!)
  However, there is an inconsistency with the axis lines stuff:
  	'axis lines=left,tick pos=right'
  will yield almost the same effect as 'axis lines=right'. However, the
  'axislinesnum' still assumes it is at the left.
  Thus, there are potentially some inconsistencies...
  -> BUT THAT'S LOW PRIORITY

+ tick align=outside doesn't seem to affect the ticklabel cs although it
  probably should (tests in pgfplotstest.axislines.tex).
  -> check also display styles for labels!

- manual: 'label style' and 'xticklabel style' are not auto-crossrefed

+ extra ticks do not work with '3d box=complete'

- the FPU has somewhere spaces; at least it treats them differently from \pgfmathparse.

- I have seen that 'plot table' with very large files can produce pool size problems -- even if the coordinates are all filtered away.
	In other words: the code can't simply read a file and throw its contents away.
	The problem appears to be some math parsing using the table/x expr and friends.
	'pool size = names of control sequences and file name'
	-> the math parser could be improved with \ifcsname

+ I had just a problem with 'log basis y=2' : the x axis also used basis 2, but minor ticks basis 10.
	It was the second plot; the first had also log basis x=2
	-> the problem is the 'log basis ticks' style which changes 'log number
	format code' globally for the axis.

- axis lines and 3D: some tick lines are not drawn, see manual examples

- check for placement of tick scale label for compat=newest
	-> I improved them for 2d and 3d
	-> needs some further checks, I guess

- the every colorbar style is more or less unusable because it is redefined by
  the 'color horizontal' styles etc. Is there something more intelligent?

+ reversed axes:
	+ color bars can't be reversed; the shading disappears
	+ reversed axes and centered axis lines:
	  	the label placement style is incompatible.
	- axis lines=center + reversed axes: the tick labels are placed somewhat
	  too near the axis... see the test in alignment subsection of testcases
		-> perhaps the "normal vector" points into the wrong direction?
			-> It is the tick@offset computed in the tick label placement
			routines. I have implemented special handling for this case, but I
			do not really understand the problem.
			FIXME
	- tickpos is wrong

- coordinate filters for log axis are not as documented: the 'unbounded coords' key won't be processed correctly.
	

- providing zmin/xmax to an axis activates 3D mode, ok -- but lower dimensional input routines appear to fail.

- one can't provide 'scale' as argument to a (3d) axis


+ axis line variations: they pose problems for 
  	a) 3d axes
	b) reversed axes.


+  The Adobe Reader crashes on p 68 of the manual (while Foxit shows and
prints without complaint).  27.11.2009 reported by J. Goebel

+ check the old code with 'pgfplotsautoanchor' for tick labels.
	Is that still up-to-date? NO
	Perhaps it should be replaced with something better? YES

- |xlabel near ticks| links to |xlabel| in manual

- recently, I used \pgfplots@command@to@string.  But: for arguments like `\table' this yields `\table ' including a space. Check if that poses harm.

+ the pretty printer appends '{}' to known csnames.
+ the pretty printer appends ')' to |(|
+ the xref to |scatter src| is broken... why?

+ \thisrow inside of column creation does not respect aliases
- \getthisrow still has to be fixed

+ the \pgfplotsretval key is uses globally and locally. Fix that.
	There is also \pgfplotslocretval which should be eliminated.
	Better: use \pgfplotsretval for local ret vals and
	\pgfplotsglobretval for global ones. Better still: avoid global return values if possible.

- it may still happen that log-axes get only *one* tick label (in my case 10^{-0.2}). That should never happen.
	The range is about ymin=4.7e-1, ymax=9.5e-1

+ 3D and special axis lines doesn't work at all.

+ sanitize 'plot file' by appending '0' coordinates at the end of the current line

+ the 'z buffer=auto' key in every mesh is stupid. What if I don't want it!?
- log samples in plot expression for 3D plots
- different log bases and gnuplot
+ 3D gnuplot: z buffer fails (see tests)

- I tried placing a named coordinate inside one axis and using it in
	another. It failed.
	% CF: The axis is drawn inside of its own picture which will only be shifted if everything has been drawn. That will be the origin of this problem I guess

	Miraculously I can use the coordinate outside axis env. So I have
	reached the following solution:

+ allocate a \newread for input files to avoid compatibility problems with other packages.

- the compatibility things should be enabled automatically for some parts:
	- 3D
	- color bars
	- reversed axes

- plot coordinates doesn't check too well if 
	1. \addplot3 is used but only two coords are given
	2. \addplot is given but three coordinates are provided (also for plot expression)

+ gnuplot: set terminal table seems to be deprecated.
- gnuplot and 3D
	-> I need a shared interface to prepare the required keys for expression plotting
+ scatter/pre mark styles should OVERWRITE the current setting instead of append. Provide additional keys with suffix '*' which provide the "append" feature.

+ if view leads to ||e_i| == 0, this results in an error somewhere (infty
  occurs)

X change UI of ticklabel cs: provide an option 'ticklabel cs:[<interpreter>]<coord>,<dist>' which specifies how to understand "<coord>". Choices:
	- 'display'
	- 'rel coord'
	- 'abs coord'
	is that really useful ?

+ plot3 table: the scanline detection does not always work (seems to need an empty line as last line)

+ the \pgfplotsdeclareborderanchorforticklabelaxis does not work if someone changes the shape! The shape changes occur AFTER my command.
	-> solution idea: implement some sort of "unknown shape handler"!

+ 3D: very long labels are not completely correct: they may run into the axis. 

- the compat things are not yet complete: I wanted to check when it is really necessary (for example if 'x dir' is used)

+  the 'check tick show thing doesn't work for non-boxed axes!

+ BUG IN \jobname with " --->> IS INVALID
+ there is 'samples y' and 'variable y' but 'y domain'!

+ ich habe gerade das Problem, dass ich fuer einen Plot nur eine
	y Achse moechte. Ich habe "axis y line=right" gesetzt. Nur sobald
	ich "axis x line=none" einfuege, verschwinden die Tickmarken an
	der y Achse...

- the nodes near coords feature produces unexpected results when used together
  with markers -> this is due to the default configuration of scatter plots.


+ provide a meaningful error message when mesh plots fail due to unbounded
  coords - I don't want to waste time with checks. (could I optimize the
  checks??)

+ I have removed the 'surf' option from \addplot3 {...};  -> check it ! it
  should be moved to some default style; maybe cycle list or so?

+ the auto z buffer may lead to errors if cols and/or rows is empty.

+ FPU and '<' operator didn't work!?

+ the 'prepare@#1coord' doesn't check for unbounded coords. Besides, it appears
  to be wrong - maybe I should rewrite it.

+ one my recent changes leads to 'meta data 25.000' is unbounded for whatever
  reasons. Furthermore, \addplot3 {x^2}; lead to a bunch or error messages.

+ forget plot and legends do not work

- check whether /pgfplots/ keys are processed properly in legends. This is
  certainly not the case for the \label/\ref legend!
  -> which ones are the problem?
- the ybar style won't be set inside of \label{}


- fix the bug-related FIXMEs in src
	-> collect them:
		-

+ providing 'ybar stacked' to the axis and 'ybar' to each plot seems to cause
  problems (see test case per Mail)
  -> that's because the '\addplot' ybar can't distinguish between /tikz and
  /pgfplots paths!
  + To stay compatible, I need to make sure that \addplot[ybar] actually uses
	\addplot[/tikz/ybar]. That's how it is documented.

+ colorbar impl:
  	+ determine correct height such that it has the same as its parent.
	+ determine all styles which need to be inherited.
	+ fix the style-restore routine! It eats too many '#' chars!


+ the 'plot table' detection of gnuplot files is buggy - it can fail for example
  if there are 2 comment lines and 3 columns (with headers)

+ the xtick=data feature doesn't check for double occurances.

+ It appears the (new) placement of tick scale labels is wrong for 2d axes.

+ the '[xyz]ticklabels' key does NOT work any longer! It fails if some of the
  ticks fall outside of limits.

+ the meta stuff is not sanitized: check for NaN or INF.

+ z buffer=sort does not respect LOG axes properly!

+ z buffer=auto should be added.

+ table package and unbalanced columns appears to be buggy.
	-> need use 'nan'

+ I observed problems with the 'title' placement in 3D plots!?

- axis equal for semilog plots is not correct (?)
+ something is wrong with the log basis stuff. Did I mess something up!?
	+ fix this! For reasons of compatibility, it might suffice to modify the
	clickable lib since the display of the plots is correct (base 10). Any
	internal UI special cases might still rely on base e (and it might be more
	efficient to rescale just tick labels!)
	- document that special handling to reduce confusion!

+ context incompatibility: \definecolor is defined differently in context, leading to bugs (occurs for 'mapped color')

+ 
	\pgfplotsset{every axis/.append style={font=\footnotesize},
				 tick label style={/pgf/number format/1000 sep=},
				 xticklabel={\pgfkeys{/pgf/fpu}%
							 \pgfmathparse{round(exp(\tick))}%
							 \pgfmathprintnumber{\pgfmathresult}}}

	to see the real tick numbers in a semilogxaxis, but when I use the former
	fake plot as the first of my plots, it behaves as if I hadn't used these
	options. When written in any other position it works as expected.

	More specifically, this only happens when using xtick=data. If the ticks are
	specified as a list, the bug doesn't show up.


+ there is 'ticklabel dist' and 'label shift'. Use the same naming convention!

+ 'shader=interp' still does not support 'ordering=colwise'

+ 'view={0}{90}' does not set label styles correctly

- backwards compatibility problem:
  	axis descriptions can't contain /pgfplots/ styles any longer! This is a key
	path issue :-(

+ the clickable lib output is shifted somehow (at least for log plots). It
  appears it does not respect the new alignment stuff properly.

+ the 3d labels still need a good initial style - and a user interface to set
  it.
  idea: 'every 3d axis' is a style which can set axis descriptions or tikz keys.
  + all descriptions styles need to be set up before they are used.
  + changes to these styles may only be done when the axis' dimension (d=2 or
	d=3) is clear - and the associated initial styles are installed. Then,
	modifications may be applied.
  Idea: implement all that stuff when 'every axis' is used. But that has
  '/tikz/' has default search path...

- I fear plot gnuplot may not reflect the latest changes - at least not for 3D!
	- log basis
	- plots R^1 -> R^3 (parametric)
	+ plots R^2 -> R^3 (parametric)
		-> may require 'u' and 'v'
	- using other variable names (see 'set dummy')
	+ ydomain is not set
	
+ the \x, \y, \z etc. macros in the table expression plotter should be
  eliminated! They pose name conflicts.

+ the '/tikz/variable' key can't be provided as argument to an axis (missing
  family)

+ the tick scale labels need to be placed with 'ticklabel cs'. That's difficult,
  but necessary.
  	+ 2D
		needs to be improved!
  	+ 3D

+ the color bar is an "axis description" -- but it can't be placed like other
  axis descriptions!

- BACKWARDS COMPATIBILITY BREAKDOWNS:
  	1. reversed axes with "manual hacks":
 	 	- the description cs won't be reversed for negative axes,
		- the anchors won't be reversed for negative axes,
		- the 'ticklabel pos' key is no longer reversed for reversed axes,
	2. Skewed axes
		- the description cs won't be skewed for skewed axes (and it should not),
	3. the tick label positioning may not work as before.
		- possible solution: write the required "activation" option into every code example!

- the backwards-compatibility issue can be solved by
	- a '/pgfplots/labels near ticks' style whichs sets [xy]label style
  	- a '/pgfplots/labels absolute' style for the "classical" default
	- small text below (above?) every code example 
	  "% preamble: \pgfplotsset{labels near ticks,width=7cm}" 
- the "reversed axis" backwards compatibility problem could be solved by
  a special mode which restores the old, deprecated handling of 
  	- anchors,
	- description cs,
	- tick label positioning,
	- ...
  this could be checked easily: if x<0pt (or y<0pt), the backwards compatibility modes must
  be enabled otherwise it is an error.
- Ideas:
  	restore ALL OLD features and provide them using a compatibility interface!
	- The compatibiltiy interface operates using pgfkeys and simply exchanges
	implementations with \let.
	- I should derive conditions which require a choice between compatibility
	  mode and normal mode.
	+ UI:
	  	compatibility/<feature name>=before 1.3|newest
		compatibility=before 1.3|newest (a style which sets all)
	+ I suppose this affects 
	  	+ \pgfplotspointdescriptionxy
		+ the "real" anchors
	
+ I need a solution to rotate labels correctly and make alignment in a good way
  -> probably the "sloped" method of pgf?


+ I fear the 'plot gnuplot[<opts>]' thing does not properly process <opts>.

+ what happens if 'point meta [min,max]' is provided inside of \addplot?

+ it appears the recent changes update the bounding box - disabling overlay for
  tick labels 

+ the 'legend image code' is again buggy! Try ybar! This here is the reason: one
  can't set draw/fill mode from within a scope!
	\begin{tikzpicture}
		\scope[fill=blue,draw=red]
		\path (0,0) circle (10pt);
		\endscope
	\end{tikzpicture}


+ the 'x={(x1,x2)}' option(s) are buggy: the complete vector length needs to be
  scaled by the datascaling routine, not the single components.

+ ticklabel interval stuff doesn't work properly

+ potential problem with stacked y bar and semilogyaxis, see bug report per Mail

+ stacked plots do not sanitize the input arguments: it may happen that too few
  (or too much) coordinates are given.

+ Memory limitations in MikTeX:
  	see http://blog.antiblau.de/2009/04/21/speicherlimits-von-miktex-erhoehen/

+ shader=faceted must be provided after 'surf'. That's not what I wanted.
	ideas to fix the problem:
		1. introduce a further 'mode' which enables drawing and/or
		   filling for meshmode.
		   So, 'mesh' would set fill to false and the fill color is irrelevant.
		   For 'surf', the state could depend on the current shader - either
		   only the fill color or both, fill and draw color will be used.

+ BUG: empty axes and one of my newer changes (bblowerleft) conflicts.

- BUG: in empty axes, 'xtick=\empty' is ignored.

- finish impl of ticklabel pos.
  I should use the same thing for tickpos as well.
  And: the default arg processing which uses ticklabel pos = tickpos needs to be
  fixed.
  the 2D axes are wrong.


- The automatic tick labeling sometimes produces inconsistent or confusing
  labels:
  	1. engineering and fixed number style are mixed up. 
	2. If range of an axis is so small that the labels differ only on the third
	   decimal, still only two decimals are used. 

+ axis y line=right, FAILS to produce correctly placed tick
  labels -> only in manual!?

+ ymin=0.9 is ok while ymin=.9 is not ok -- update number parser.

+ legends are currently broken!

+ the tick labels on axis boundaries are often missing. I suppose this is due to
  rounding inaccuracies or '<' instead of '<='. check that!

+ new alignment: origin anchors for unfinished axis is not updated.

- 3D: axis equal implementation might not be correct (at least not for view
  special cases)

X perhaps the ASCIIHexEncode would be a useful addition for the pdftex driver of
  surfshading as well...?
  no, it isn't. pdf2ps still generates huge sampled postscript files.

- 3D:
  	error bars and 
	stacked plots
	need to be updated.

- the \thisrow commands in the table package does not (always) respect aliases!

+ check for the @non@legend@options - I suppose they are deprecated now and
  waste computation time.

+ the new key processing which skips every /tikz option in \addplot might not be
  correct - there are several plot related exceptions like /tikz/id etc which
  SHOULD be processed. Make sure I have all of them.
  Besides: what happens if someone uses /tikz/draw explicitly? I am not sure if
  that hurts...
+ the recent search path construction WILL also set tikz options during
  \addplot.
  There won't be any paths during \addplot - but I am not sure if there can be
  any scoping problems related to the graphics state.
	-> that stuff produces problems with /tikz/ybar vs. /pgfplots/ybar!



+ the view argument should be similar to gnuplot /matlab. I fear I have
  exchanged some of the directions.
  In matlab, the argument is '{yaw}{pitch}' instead of '{pitch}{yaw}'
  Furthermore, the rotation axes are different. view={0}{0} in matlab shows
  the x axis horizontally and the z axis vertically - the view direction is
  (0,1,0) -- for me, this would be (0,0,1).

+ pdf2ps still fails for interp shader - it has a limitcheck exception. Perhaps
  the number of bits is too large for ps?
  -> a very small stupid test with 8 bits per coordinate and 8 bits per cdata
  worked

- interp shader is displayed transparently in evince

+ clickable plot lib produces visual artefacts in acroread
	-> the 'hidden' flag appears to be incompatible with figure environments!?
	- fixed in recent hyperref drivers of pdftex; was actually a bug of hyperref

- 3D:  the use of \addplot3 and \addplot is not sanitized properly
	Possibilities:
	-  used \addplot  when \addplot3 should have been used
	-  used \addplot3 where \addplot should have been used.
	 What can happen here!? Shouldn't this work in every case?


+ the 'current axis' node is not defined until the first axis descriptions are
  drawn. That should be fixed by defining the low-weight shape before processing
  the stored path commands.

+ The following fails:
   \addplot+[
   black] plot coordinates { (0,0) (1,1) };
 
- The "xtick" value is not applied unless there is a coordinate in the x range:
	-> that's the handling of empty figures...

	not working:

	  \begin{axis}[xtick=0]
	  \end{axis}

	not working:

	  \begin{axis}[xmin=-5,xmax=5,xtick=0]
	  \end{axis}

	not working:

	  \begin{axis}[xmin=-5,xmax=5,xtick=0]
		\addplot coordinates { (-10, 0) };
	  \end{axis}


	working:

	  \begin{axis}[xmin=-5,xmax=5,xtick=0]
		\addplot coordinates { (0, 0) };
	  \end{axis}

- think about basic level commands for the axis lines -- this should also allow
  \pgfpathclose !


- the arguments to plot file[#1] and plot table[#1] are not consistent with
  rest. They need to be treated as behavior options (maybe in a different key
  path).
- check behavior options provided to table[] and file[] and so - is that
  correct?


+ the \ref command should be \protect'ed in LaTeX captions

+ the ticklable dist feature NEEDS anchors.


- the plot mark code invokes a lot of math parsing routines - which is a waste
  of time in my opinion. All expressions etc. have already been parsed.
  Potential for optimization!

- verify that 'draw=none' works! Is something broken here?
	-> write tests!
	+ it appears to be desired that (at least some) markers invoke
	  \pgfusepathqfillstroke
	  -> they always 'draw', regardless of tikz color settings.
	  -> ok, I patched that in my marker code... (hackery :-( )
	- no, it works only partially:
	  	draw=none or fill=none works as expected.
		But 'blue' disables filling!?
	- Possible fix:
	  	Overwrite \filltrue \fillfalse, \drawtrue, \drawfalse:
			they should set a further boolean '\drawbooleanhasbeenset' and
			'\fillbooleanhasbeenset'.
		-> Replace the \pgfusepathqfillstroke if and only if the respective
		booleans have been set *explicitly*. If they are unchanged, fall back to
		a "reasonable" default.
	  

+ provide example for colormap changes - that should also verify the correctness
  of the method

+ provide sanity checking in scatter plots - for example missing explicit
  scatter src.

+ improve docs for scatter plots: 
  	+ 'only marks' is also a scatter plot!

+ something with the table package appears to be buggy!?

+ the plot table[] search path is not good - it should include /pgfplots

+ introduce backwards compatibility with old pgfmathfloat.code.tex file
	[ not interesting for pgfplots 1.2, only for pgfplots 1.1 !]

+ there is a bug related with empty axes - I suppose in conjunction with the
  tickmin/max feature (it won't be reset properly)


X there is a space too much in some behavior messages (occured in test
  processing)

X introduce backwards compatibility with old pgfmathfloat.code.tex file

- the auto-generated tick labels for non-unit-distance log axes could be better.

+ verify that the domain key always accepts the extended data range

+ I observed problems with opacity set for just one plot which was used for
  every plot in the axes!? 


+ the stacked plots impl is not yet in logical coords - that means it 
  won't work with non-standard unit vectors!

+ The floating point math routines should be put into a separate library.
  Provide compatibility support for that in pgfplots!

+ empty plots cause bugs.
+ empty plots and the named nodes may not work correctly -> check that

+ newlines in plot coordinates cause an error.
  + provide sanity checking and correct error messages!

+ 'domain' can't be used to increase the data range, even when combined with fp.
+ huge 'domain' arguments for 'plot function' lead to an 'dimension too large' error 
  although everything works fine
 
+ the float math methods should be affected by the fixedpoint library, but they
  are (because the underlying pgf math routines are exchanged).

X scaled ticks is not properly implemented for log axes
	+ it is not available for log axes, so that's ok

+ pgfplotstable and \rowcolor and 'sci sep align' in conjunction produces
  overwritten digits! The color seems to be on top of the numbers left of the
  sci separator.
  -> This is caused by the left/right overhang of the colortbl package and my
  implementation of 'sci sep align' as an extra column. That's bad.
  -> Idea:
  - manually overwrite \rowcolor/\columncolor/\cellcolor in a portable way such
	that overhangs are made properly.
	Maybe there is a macro in colortbl?
	[fixed for \rowcolor]


+ stacked plots + error bars don't work correctly together: I need to shift the
  error bars

+ error bars should be drawn on top of the plot to avoid conflicts with filling.

+ [xy]ticklabel pos  values 'top' and 'bottom' are somewhat inconsistent with
  the actual placement

+ the auto-disable-feature for logarithmic minor ticks can be overruled (of
  minor grid lines) which should not be possible
  -> provide a good policy how to deal with user inputs:
  		1. draw minor tick/grids if requested
		2. provide error message

+ scatter is disabled if no default mark has been set.

+ filter warnings are broken because they don't output the input coordinates

+ tick align=center is broken since last revision. Possibly tick align=outside
  as well.

+ clickable lib is broken somehow

+ check for clickable lib if multiple axes are in the same tikzpicture
	-> doesn't work. Why!?
	- I can't reproduce that bug. Maybe it is fixed in the meantime?

+ the case
		ymin=629.65,
		ymax=629.70,
  FAILS with math errors because the affine data transformation is deactivated
  for the automatic tick computation! Providing tick labels manually works.
  -> FIX THAT! Ticks should be computed without this restriction (if necessary,
  in float arithmetics)!
  	
+ it is not possible to provide '[xy]mode' in styles.
	-> ok, provided error message.

+ check whether there are any plots before processing something like
  'xtick=data' or so

+ the clipping of tick/grid lines is currently disabled due to the change to 
  logical coordinates and needs attention.

- In 3D case axis [xyz] line != box, there is just ONE hyperplane.
  My implementation works only if either ALL are box or ALL are 'middle'.

+ 3D case : which hyperplane gets tick LABELS?
  The current implementation based on  '[xzy]ticklabel pos' is not sufficient

+ 3D case: something fails with disabledatascaling

+ 3D case : grid lines work correctly, but they are not satisfactory.
  I'd like grid lines in the background only.

- 3D case : tick/grid lines are on top of the axis lines. This leads to 
  poor quality.

+ '\coordinate (<aname>) at (axis cs:0,0);'  does NOT work;
  '\node[name=<aname>] at ... ' DOES work.
  -> I can't hook into the 'at' syntax; I can only override the 'name'
  key. 

+ check whether the \label/\ref construction requires \protect\tikz and
  \protect\path etc. if it is placed inside of \caption...
  -> no; it has catcode 12

+ check whether named nodes are still ok. Since the 'fill opacity' bugfix, these
  may be broken...
	maybe the scoping needs to be improved
	-> there is still need for scopes in case 'clip markers'!

+ error messages if the PGF version is wrong should be added
  -> check for \pgfkeys
  	-> I should also check whether the float routines are available!
	Maybe they will migrate to a tikz library someday.


+ \addplot [fill opacity=...]  is not scoped properly!
+  I suppose the same problem holds true for dotted line styles.
+ setting mark options to dashed also changes the legend's appearance


+ the clickable library does *not* work inside of figure environments
	-> yes. That's fixed; was a bug in hyperref.
	- I could try to re-implement it without insdljs. 
	  	Ideas: 
		- the document catalog's names dictionary needs to '/JavaScript
		[(<arbitrary script name>) <dictionary with JS>]' entry.
		The <dictionary with JS> contains document level javascript.
		- it is very simple to generate these entries for my case.
		  Unfortunately, this may be incompatible with 'insdljs' or other tools
		  which write DLJS.
		- I am not sure why the floating figures of TeX produce an
		  incompatibility here. It appears the 'hidden' flag in the form fields
		  are the problem - if that is the case, I'd need to reimplement the
		  form annotations (which could be more difficult).

- javascript stuff does not work if the complete figure is rotated (sidewaysfigure).

- javascript: incompatiblity with external library:
  	1. filenames: \jobname contains characters with incompatible catcodes and
		that funny insdljs package tries to assemble macros with these
		characters.
		-> fixed; I simply use pgfplotsJS as temporary file name.
	2. the images as such have corrupted forms
	  -> Can be fixed if 
		\usepackage{eforms} 
		is used BEFORE loading pgf. The reason: \begin{Form} and the shipout-hackery
		of the pgf externalization bite each other. 
		\begin{Form} must come before the shipout hackery of pgf.
	3. \includegraphics does not preserve PDF forms.




+ renormalization bug in 
	log(9.999998e-01) = 4.70201 != 0 

X Bug in table input: if colnames contain (some?) UTF8 characters, \csname <colname>\endcsname FAILS.
  That means table column names can't use UTF8 characters.
  Possible solution: for each character in <colname>, check whether it is active. If yes, change its meaning.
  I am not sure if that's acceptable...

X error recovery: it is sometimes almost impossible to find errors in
  key-value-settings because \end{axis} or \pgfplotstabletypesetfile does not
  is NOT the correct context.
	-> possibly with \errorcontextlines=10?

+ the error message for gnuplot invocation is wrong; gnuplot should be called on
  the '.gnuplot' file instead of the '.table' file

+ there are still plain TeX loops in the legend code!?

+ javascript stuff is incompatible with a lot of active characters, 
  for example the german package:
	+ bug in insdljs: workaround introduced.
	+ bug in my code fixed

- the interrupt bounding box feature should still update the data bounding box.
  Otherwise, transformations may fail.

+ to check: it *could* be possible that errorbars + stacked plots are
  incompatible.

+ the 'alias' and 'create on use' features may lead to errors. Check it!

+ variables which are used both globally and locally seem to fill TeX's save
  stack to due retained restores

+ I have introduced incompatiblities with the 'log identify minor ticks' option.
  Check how to solve that. Side conditions:
  	- compatibility with the modified log tick labels for small range
	- compatibility with extra ticks
	- compatibility with the manual

+ check whether 'clip limits' works properly if only one data point falls into
  the final region

+ add '-halt-on-error' to externalize command

+ handle rare case that auto limit computation leads to min > max (only possible
  for clip limits=false)

+ evaluate 'every axis plot' inside of \addplot command, even if that means a
  small inefficiency because it is evaluated in the \draw command as well.
  -> allows to get id, prefix, samples and other behaviorual options.
  -> attention: then, every axis plot would contain BOTH display and behavioral
  options; take care with key paths

+ \addplot plot[#1] does not use /pgfplots as search path
+ 'every axis plot' does not use /pgfplots as search path


+ implement partial limit specification, for example 'xmin=5' -> only compute
  'xmax'

+ check gnuplot on windows - there appear to be semicolon problems!?

+ again, the disabledatascaletrafo key does not seem to work correctly. Check it!

X active semicolons may be a problem

+ [ CF: for tikzlibraryexternal : use double quotes instead of single quotes in
  system calls -> win32 doesn't support single quotes ]

+ problem with context: even simple images do not work correctly. Why does the example work!?

+ table package: 'array' required for some examples -> document

+ handle 'nan' and +-inf in plots

+ 'every axis plot post' is not reflected in legend (at least not properly)

+ plot function: incompatibility with 'german' package and "  catcodes

+ improve error recovery

+ grid lines and tick lines can obscure the axis lines, especially when used
  with different colors.
  -> draw axis lines on top of tick/grid lines!?
  Or more generally: change drawing sequence to
  	1. grid lines
	2. tick lines
	3. axis lines
	4. tick labels?

- extra ticks can be disabled by the tick special cases for axis lines (when two
  axis lines cross each other)

+ eliminate any public reference to the '\\'-lists. They are inconsistent with PGF.

+ use '{}' for sci  'e' style - looks better

+ the tick scale labels are inadequate.
   1. Formatting
   2. maybe they should be disabled at all!?

+ specifying axis limits for X should also limit those for Y (some sort of
  clipping)

X the text height of every axis x tick should be adjusted to allow tick scale
  labels on the same vertical alignment
  -> bug in pgf: text height does not properly respect to the current font!?

+ the new \pgfkeys framework:
  	+ I have re-implemented all options with \pgfkeys. 
	  this allows styles and mixing of TikZ/pgfplots options.
	+ BUG: if someone provides FULL keynames, the method WILL FAIL.
	+ the style= option fails.
	+ the 'x=' and 'y=' options fail.
	+ every option which exists in both, pgf and tikz, will fail!
	+ 'legend style' fails
	+ the 'legend style, grid style, x label style etc. options' test fails

+ axis limits of zero width are not fixed causing division by zero

+ ytick=\empty is broken again :-(

+ if a logplot has very small axis ranges, only ONE tick label will be placed.
  Thats not enough.
  In such a case, tick labels should be placed at MINOR TICKS [2-9]*10^i.
  BTW:
    if someone places tick marks at [1-9]*10^i, the minor ticks should NOT be
	disabled. 
	Instead, tick positions should be RECOGNISED AS MINOR TICKS (which is not
	that simple).

+ die legend[font=] variable ist doch dasselbe wie in dem tikzstyle zu legenden,
  oder? warum funktioniert es dann anders?

+ implementiere enlargelimits fuer log-achsen

+ markers werden rausgeclipped, wenn die achsen TIGHT sind.

+ man kann keine leeren listen an tick labels uebergeben!

+ width/height produziert NICHT die gewuenschte breite.
  Man sollte ne zusatzoption haben, die die labels grundsaetzlich NICHT
  beruecksichtigt.

X Fix the scaling estimations.
  Problem: I don't know sizes of labels, legends, titles and tick labels.
  Idea: 
  	-Create a temporary picture
		\hbox{%
			\begin{tikzpicture}[xshift=...,yshift=...] % skaliere auf (0,0)--(1,1)
			\draw (0,0) rectangle (1,1)
			plaziere labels + legende + vllt. ein tick auf jede achse (?)
			\end{tikzpicture}
		}%
	- measure and remember its size
	- throw it away
	-> 9.2.2008:
	 ATTEMPT FAILED.
	 Reasons:
	 	1. it is not possible to place a tikzpicture into a tikzpicture.
		   And it can't be because Tikz updates bounding box parameters GLOBALLY.
		2. I could use a combination of 
			- scope,
			- the 'current bounding box' node,
			- \pgfpointanchor{current bounding box}{ anchor name },
			- drawing commands for labels,legend etc.
		   Effect: bounding box is determined correctly. BUT:
		   	- bounding box of real picture may be affected,
			- every output is drawn because nodes can't be 'thrown away'.
			  At least I do not know how.


+ enlargelimits muss RELATIV nicht ABSOLUT gemacht werden.

+ es gibt einen fehler in der achsen skalierung, wenn 
  man sehr grosse limits hat (normale achsen)

+ default ticks muessen besser an achsenlimits angepasst werden
   -> bei sehr grossen oder sehr kleinen limits schlaegt die derzeitige
   einschraenkung der step sizes fehl

+ addplot plot coordinates { (235 , 43252) }
  								 ^
  funzt nicht wegen dem leerzeichen vor dem komma

X verschiebung des ylabels ist komisch, wegen der rotate option

+ that first/last coord detection doesn't work for 3D

-------------------------------------------------------------
FEATURES
-------------------------------------------------------------

- \addplot coordinates {\macro};

- precise width calculation idea:
	- Problem: total width depends on width of axis descriptions
	- width of axis descriptions depends on position of axis descriptions
	- position of axis descriptions depends on width of axis
	- width of axis depends on width of axis descriptions
	-> non-linearly coupled system.
	- Idea: introduce a loop. 
		- details: 
			1. place axis descriptions + the axis rectangle into a box. 
			1.1 Measure box'es width, throw it away if it is too bad. Keep it and stop iteration otherwise.
			2. recompute the complete scaling.
			3. go back to step 1.) and iterate
		-> one or two iterations should be enough .
		-> it's not necessary to recompute the prepared and stored plots. Just keep them in main memory until the scaling is fixed.
	
- bar plots:
	- bar interval plot handler which *assumes* uniform distances. This allows to eliminate the last, superfluos grid point (because it can be generated automatically as replication x_last + h for known h)
	- in fact, I could also implement
		x_last + h_last
	and introduce a new name like 'bar interval*' or something like that

- Mails from Stefan Ruhstorfer:
		2.
	Gruppierte Säulendiagramme sind nach meinem Wissenstand nur dann möglich wenn man in der Axis-Definiton die Bedindung ybar angibt. Ich finde diese Ausrichtung sehr unflexible, da ich sehr oft über das Problem stolpere, dass ich in meinem gruppierten Säulendiagramm noch eine waagrechte Linie oder ähnlichs einzeichnen möchte um z.B. meine obere Toleranzgrenze einzuzeichnen. Bis jetzt mache ich das über den normalen \draw Modus, was auch ausgezeichnet funktioniert. Jedoch habe ich dann das Problem, dass ich keinen schönen Legendeintrag mehr bekomme. Hier häte ich 2 Vorschläge. Zum einen die Legende "freier" zu gestalten. Also so, dass man beliebig (ggf. auch ohne Plot) ein Legendenelement hinzufüen kann und vllt. noch das zugehörige Symbol festlegen kann. (Bis jetzt habe ich das Problem, das ich mit tricksen zwar meine Obere Tolerangrenze in die Legende bekomme, dann jedoch mit einem Säulenzeichnen davor).
	Der andere Vorschlag ist, dass Säulendiagramm anders zu definiern. So das ich auch noch einen Plot hinzufügen kann, der mir eine waagrechte Linie ohne zu tricksen einzeichnen lässt.


	3. Eine Gruppierung von stacked bars ist nach meinem Wissen nicht möglich. Es ist zwar schwer sich ein Anwendungsgebiet dafür vorzustellen, aber wenn sie danach mal suchen (speziell im Excelbereich) werden sie sehen, dass viele Leute so eine Funktion benutzen. 
	
	-> siehe auch folgemails mit Beispielskizzen
	-> beachte: Fall 2.) erfordert mehr arbeit als lediglich 'line legend', weil ybar ja den koordinatenindex verarbeitet!

- 3D + axis line variants: someone might prefer GRID LINES as for the boxed case
  combined with axis line=left...

- the table package uses a lot of logs -- but it can't change the log basis.

- automatically choose a predefined scaling style depending on width/height (?)

- my elementary data structures always use \string to support macros as data structure names. I fear this might be ineffective.
 Perhaps its better to check if the argument is a macro (at creation time, thus only once) and call \edef#1{\string#1} to assign some sort of name to it.
 This will invoke \string only once. Is this faster?

- implement 'point meta=symbolic command:<cmd>' and 'point meta=command:<cmd>'
	the command should assign '\pgfplotsretval'

+ It would be a valueable addition if the external lib would be available for the next stable release.

+ the scatter/classes feature needs a legend. 

- the following keys should process their argument with \pgfmathparse:
  	- [xyz]tick,
	- min/max
	- tickmin/max
	- meta min/max
	- domain/ y domain,
	- error bar arguments,
	- without FPU: width/height/ view
	-> check optimizations of the math parser!
	-> check if I can activate the FPU during the survey phase!

- check y tick scale label for 2nd y axis

+ provide a '3d box' boolean which draws the full box.
	-> should use the correct drawing sequence (foreground/backgraound)
	-> should use the decoration things

+ there is no possibility to provide a background color for the axis only
  (should be a fill/draw style for the clip area).

+  -> perhaps 'plot box aspect ratio=<x> <y> <z>' ?
  And I still have the stretch-to-fill thing as in matlab.

+ finish the 'unbounded coords=jump' method.
  	Ideas:
		+ mesh plots should use a special method here:
		  	+ they should proceed as usual - and eliminate complete patches
			   with special treatment.
			+ the use of shader=interp should throw an exception in case of
			  unbounded coords.
		~ all other plots work reasonably well with it, I suppose.
		+ plot graphics should throw an exception as well.
		+ should the user filter results be filtered by 'unbounded coords' as
		  well?? They are not unbounded - they have been discarded...

- idea to improve rel. accuracy: do not simply invoke 'pgfmath@basic@...' but
  allow an arbitrary suffix. Maybe one could allow to use the FP package.

+ reverse axis=true ideas for 3D:
  	+ this flips the normal vector in some sense. Since the "foreground"
	  algorithm simply queries the sign of the normal vectors, I only need to
	  check for a "-1" in the right places. If I am not mistaken, changes in the
	  following components should be enough:
	  	- decision which is foreground/background
		- 'ticklabel cs' and 'rel axis cs'
		  -> these may require a design decision! What does the "0" coordinate
		  mean: the lower limit or the lower part of the figure?

+ z buffer implementation ideas:
  	+ reverse: is already implemented
	+ reverse x:
	  	A_ij := a_{i,n-j}
		for ordering=rowwise: trivial: reverse rowwise
		for ordering=colwise: same technique as for transposal: collect
		colvectors in fast applist; reverse this colvectors
	+ reverse y: the same with exchanged roles.
	+ auto: I need to know: 
	  	+ How are the coordinates sorted?
		  	If ascending in x and ascending in y, everything is ok. Otherwise, I
			need to remember signs.
			-> it should suffice to check the FIRST and LAST coordinate to get
			these signs!
		+ If both are ascending: I can decide per axis if coordinate reversal is
		  necessary:
		  	If "0vv" is background -> ok, change nothing.
			If "0vv" is foreground -> reverse in x.
		  The same should also work for y -> allows very fast decision.


+ I have the following request. Is it possible to also provide a domain  
key for file and table plots. I have a file containing data points  
where only the points in a certain range shall be plotted. I first  
thought that filters might be a solution, but it seems that they apply  
to the whole axis, not only to one specific plot.

+ I have a suggestion for the next release of the pgfplots package.
Now it seems to be so, that the major tick lines are drawn before the minor tick
lines, which can lead to unwanted results, if somebody redefines the color of
the minor grid only. So it would be better to draw then the other way round.
Does somebody else agree?
- that's not solved yet! Try it out for grid lines!

+ the UI to provide point meta is complicated.
  Why 
  point meta=explicit,table/meta={<colname>}
  instead of
  point meta=\thisrow{<colname>} ??
  [ ADDED SANITY CHECK AND ERROR MESSAGE]

  The reason is technical: My code separates the table reading and the
  coordinate processing. I'd like to discard this separation.... but I hesitate
  to do so because this might lead to scoping problems...
  Work-around idea:  check if the '\thisrow' macro occurs and set then
  'explicit,table/meta=...' accordingly.

- log plots: minor tick num would be useful here! If tick labels are placed at
  '1e-5, 1e0',  minor tick num= 4 would lead to the minor tick lines at
  '1e-4,1e-3,1e-2,1e-1'  which is useful.
  So:allow minor tick num for log axes.
  ->
  	need to adjust the check for "uniform log ticks"

- is there a way to get the current row/col index during \addplot?

- plot shell:
  	- It would be nice if the standard shell interpreter could be replaced.
	  Idea:
	  \pgfkeys{/pgfplots/plot shell/interpreter/.code 2 args={sh #1 > #2}}
	  then in the code
	  \pgfkeysvalueof{/pgfplots/plot shell/interpreter/.@cmd}{#1.sh}{#1.out}\pgfeov
	- the \pgfshell macro is quite general and could be added to pgf (as
	  suggested by you, Stefan). However, this would also need modifications in
	  tikz.code.tex to get some sort of high-level user interface.
	  I find plot shell very useful, and it could be added easily. My
	  suggestion:
	  	Either write a high level user interface for tikz or rename the command
		to \pgfplotsshell and put it into pgfplotscoordprocessing.code.tex.
	  In the meantime, I added it to pgfplotscoordprocessing.code.tex (bottom).
	- there is a potential difficulty with the '\addplot table shell' command
	  (which is a good solution!):  the semicolon in this routine will have a
	  fixed catcode. But packages like babel with french language will change it
	  to active, so french people can't use \addplot table shell. The solution
	  is technical and I am not proude of my own anyway... we'll just have to
	  think about one.
	- documentation for the 'table shell' feature is missing yet.
	- I am not sure if the replication of /tikz/prefix and /tikz/id is helpful
	  or confusing....
	


+ provide a possibility to get the maximum tick width (for use in ticklabel cs)

- > Is it possible to shade the area between two curves, using pgfplots, such as 
	> in this example: http://www.mathworks.com/matlabcentral/fileexchange/13188
	> The only shading I could find is between one curve and the x axis... Shading 
	> between curves seems to be possible, but only with stacked curves. Is is 
	> possible to disable stacking somehow, but keep the \closedcycle behavior?

+ provide a possibility to draw gaps. Maybe using nan or inf coordinates? 
  Currently, NaNs and infs are skipped and pgfplots simply interpolates over
  the gaps. Perhaps it would be better to explicitly form a gap? I am not sure
  about that, but it appears to be a good idea. Requires a lot of special
  handling

+ provide a 'y variable' key?

+ provide other log bases

+ implement colorbars. I have a running prototype; it just needs some tuning.
  Ideas:
  	+ place it as a separate axis besides the original one.
	+ make sure that named nodes like 'current axis' stay correct - as if there
	  was no extra axis.
	+ provide all required variables locally in pgfkeys - the meta limits and
	  style arguments etc.
	+ I need to communicate:
	  	+ the current color map,
		+ styles for ticks, tick labels and axis lines (?)
		  (at least the tikz ones?)
		+ create a style for the new axis.

- re-implement sampling loops. I should discard the compatibility with \foreach
  internally in order to gain accuracy! Maybe it is necessary to invoke
  different loops - one for tikz \foreach (samples at) and one "standard"
  sampling routine.

- 3D: assume default plot type when used with \addplot3 without plot style
  (perhaps a special cycle list)


+When working with markers on the plots, the nomenclature is inconsistent. There
is 'mark size', 'mark=*' and 'only marks', but 'no markers'.

+I created several cycle lists to be consistent in different types of plots. For
example I have a cycle list with markers and no lines for raw data points and a
cycle list with only lines in corresponding color. Now if I want to have raw
data points and fits in one axis, I cannot use these. Ok, I could make a
cyclelist where raw data and fit styles take turns, but this would break down
when I have more than one fit for a set of raw data. This is probably something
that has to go into pgf, but would it be possible to add a easy way 
+ to switch to different cycle list between two addplots, 
- and to navigate in it (go to a specific position in the cycle list, go n steps back/forth)?

+When I first tried to combine plots with only symbols and plots with only a
line in one plot, I had difficulties to figure out how to do it. Having worked
with pgf before, I intuitively tried to activate no marks/only marks for the
whole axis and then override it explicitly for some plots, by adding [only
marks/no marks] to addplot.

+I would find it convenient, if there was a key to indicate legend placement,
for example 'legend position=south west' as shorthand for 'legend
style={at={(0.05,0.05)},anchor=south west}' or something similar.


- replace \pgfpointscale with a 'q' version -> it invokes the expensive math parser.

- optimization ideas:
	- pgfmultipartnode evaluates every anchor twice
  	- implement a cache for expensive, repeated math operations like 'view'
	  directions or common results of 1/||e_i|| .
	- search for unnecessary math parser invocations; replace with 'q' versions
	  if possible.
	- implement a hierarchical generalization of the 'applist' container (a tree
	  applist of arbitrary length)
	- eliminate the deprecated 'non-legend-option' processing.
	- remove the different (empty) paths of the axis node -- it appears they are
	  not necessary and waste only time and mem.
	- try implementing an abstract 'serialize' and 'unserialize' method - it
	  might be faster to re-process input streams instead of generating
	  preprocessed coordinate lists.
	- try to reduce invocations of pgfkeys
	- optimize the filtered pgfkeys invocations - the filter is slower than
	  necessary!
	- eliminate the 'veclength' invocations for single axes - they can be
	  replaced with "inverse unit length * (max-min)"
	- the key setting things can be optimized with \pgfkeysdef
	- create the /pgfplots/.unknown handler (.search also=/tikz) once and remember it.
	- the (new) tick label code might be very expensive:
	  	- check for (unnecessary) calls to \pgfpointnormalised -- the normal
		  vectors are already normalised!
		- check the cost for bounding box size control of the tick labels --
		  maybe this can be optimized away if it is not used. But this decision
		  is not easy.

+ provide a simpler method to replace the '\cdot' in tick scale labels with a
  different sign, for example '\times'.

- provide a feature for bar plots which add the bar value as node on top of the
  bar.
  Idea: provide some sort of "every coordinate path" - an optional feature which
  has access to both, the logical coordinates and the low level path coordinates
  and can do something. One application would be to place nodes "above" of the
  low level coordinate and use number formatting routines to display the number.
  This shouldn't be difficult (with the exception of logs ... or user
  transformations... hm.).
  -> think about it.
  -> log can be visualized with 10^{<tick>} as before!
  -> the 'inv trafo' can be applied if and only if needed. Idea: provide macros
  like '\x', '\y' and '\z'. This should do it.

- use the new \pgfplotspointoutsideofticklabelaxis things to place axis labels.
  -> this needs a further variant which allows 'relative' axis coordinates
  (0=lower limits, 1=upper limit and everything between)

- I need a clean interface to distinguish between R^1 -> R^3 and R^2 -> R^3
  visualization.
  Maybe a boolean 'matrixinput' or something like that? 
  -> the 'mesh' plot handler is also useful for line visualization!
  - the '/pgfplots/mesh' key could set matrixinputtrue
  - a style 1dmesh or so could set the plot handler and disable meshmode?
	Of course, I could also try to evaluate the 'rows' and 'cols' values.
	If cols=1, I have line visualization.

+ allow changes to `legend image code' in plot styles. Maybe the 'legend image
  code' or some other preparation commands can be remembered explicitly such
  that they are set before 'legend image code' is already running?

- legends need a better key path to process pgfplots plot handlers.
+ I need legends for mesh/surface plots.

- the tick anchor=auto feature could work like this:
  	- "use paraxial whenever possible - unless the user requests "tikz"
	  explicitly or implicitly".
	- "explicit" request: the user says "tick anchor=tikz".
	- "implicit" request: the user says "anchor=..." for a tick label.
	- realization: 
	  	- use \scope to set the tick label styles, overwrite
		  '/tikz/anchor' inside of this scope's pgfkeys statement.
		  -> that doesn't work. I NEED to adjust 'every node'.
		- move the processing of 'tick anchor' inside of that scope
	- effect: 2D axes will also be processed by means of 'paraxial' (unless the
	  user doesn't want it).
	  -> reversed axes work automatically!

+ provide the axis bounding box as coordinate system (for description placement).


- provide a \pgfplotspathcube command as generalization from the cube marker.
  The cube command should work similar to pathrectangle or rectanglecorners.

- write a public math interface which provides access to axis internals like
  limits, the 'dimen-to-coordinate' method and so on.
  -> it might be useful to use pgfmathparse for any numerical input argument as
  well.

+ write public interface \pgfplotsdepthofxyz#1#2#3
- consider renaming that one to pgfmath... or pgfplotsmath... ?

+ reverse legend 
	-> CF: implementation of Tom Cashman per mail

- what about in-text-input of tables like
	\pgfplotstableread\data{<data>....<data>}{\macro}
	\pgfplotstableread\data{<data>....<data>} to listener \listener

- I have just added '* expr' for plot table. 
  ideas todo:
  	+ implement it for plot table structure as well,
	- document plot file such that users know how to add expressions, or, even
	  better, automatically switch to plot table if someone uses x expr..

- maybe some sort of 'point meta=map' would be interesting.
  The idea is to provide a mapping
   (x,y,z,singlemeta,additionalinfo) -> f_1,f_2,f_3,f_4,f_5,...,f_n
  and each f_n has a name and a value. 
  The additionalinfo could be further rows in a table or the current plot
  context. Then, each f_i could be a symbol, maybe a number or something like
  that. There should be one designated f_i which is used as "the" cdata source
  and which is mapped to [0,1000].

- optimize the z buffer=sort impl of mesh mode: use preallocation (doesn't yield
  much, but at least a bit)

+ it could be interesting to provide customizations to the cube marker. For
  example different lengths for each side... could be used as basis for a 3D bar
  plot implementation.

- there are applications in which BOTH untransformed meta AND transformed meta
  are required. In this case, the untransformed meta should be provided in a
  more convenient way - perhaps as fixed point number?

- in scatter point public interface: it would be interesting to know if we are
  currently processing the first/last coordinate. is that information available?

+ write default styles for "string coordinates" which maps a set of
user defined strings somehow into a numeric range (using a simple
dictionary)

- It is certainly possible to write some sort of CELL-BASED 'mesh/surf' shader -
  a combination of 'flat corner' and cell based rectangles:
  - every coordinate denotes a CELL instead of a corner,
  - the "shader" maps the cdata into the colormap to determine the cell color
  - details?
  		- to get well-defined cells, I have to enforce either a non-parametric
		  lattice grid or do a LOT of additional operations (?).
		- alternative: define N*M cells by N+1 * M+1 points.
		- perhaps a combination of both?
		  	-> that's more or less the same as 'flat mean' up to the further
			row/column pair
  - it would be generally useful to have an "interval" or "cell" mode: 
	the idea is that every input coordinate defines an interval (1d) or a cell
	(2d). To define the last cell, one needs to add one "mesh width" somehow.
	I just don't know where:
		- the artificial cell should be processed with the normal streams -
		  including limit updates, stacking etc.
		- the artificial cell needs to know when the end-of-stream occurs.
		  For 1d plots, that may be possible. For 2D plots, this information
		  requires a valid 'cols' key.
		- I suppose it would be best to patch @stream@coord.. at least for the
		  'cell' mode.
		- Idea:
		  	- the \pgfplots@coord@stream@coord implementation realizes the
			  cell-mode: after every 'cols' coordinate, a further one is
			  replicated. This needs the "last mesh width".
			  Furthermore, it needs to accumulate a row vector, the "last row".
			  This last row is need during stream@end to replicate the further
			  row:
			- the \pgfplots@coord@stream@end implementation has to realize the
			  last step of cell mode: the replication of a further row. It also
			  has to realize the implementation of 'interval' mode (replication
			  of last coordinate).
			  My idea is to simply use an applist for this row accumulation. The
			  format should be compatible with \pgfplots@coord@stream@foreach@NORMALIZED.
			  That doesn't produce problems, even when the end command is invoked within
			  a foreach@NORMALIZED loop - because the loop has already ended.




- I have a funny idea to replace the memory intensive and slow TeX based data
  structures: I could write coordinate streams into a file like LaTeX's .aux
  file - and re-read it. The file performs the coordinate loop automatically in
  such a case. Key question: what's more expensive: \input or the optimized
  macro append? There may be an even-point at which one should switch the low
  level data structure.
  - One could introduce some kind of in-macro caching: write to file every 100
	elements or so.
	This would be the applistX with the same L1 and L2 caches - but the main
	memory would be a file instead of a macro.
  - maybe it is sufficient to use concatenate up to N three-level-deep
	applistX, each with a fixed size? This should work as well. The global
	number of macros required for such an implementation would be 3*N. If each
	macro contains several thousand points, this would be better than nothing -
	and simpler than a tree. But it doesn't have good asymptotics, I agree.



+ pdf supports REAL lattice shadings! See pdf reference 1.7, section 4.6.3.
  It is possible to write the coordinates on a lattice and colors for each coordinate;
  resulting in a correctly interpolated shading. I suppose this uses a z buffer.
  The only problem: it requires binary integer input. The integers are then
  mapped linearly into the real space using the /Decode array.
  If I could somehow write binary data into pdf streams, this would work
  properly.
   + Notes to finish that thing:
	 	- the plot expression sampling could automatically respect the 'z buffer
		  emul' -> and clear the variable afterwards (optimization)
		+ finish low level interface
		+ write ps driver




- provide a public basic level API to pgfplotstable:
  	- access, iterate and read table elements
	- manipulate elements

+ binary input subroutines:
  	use a simply scaling for dimen registers. The scaling should be such it maps
	[-16384,16384] -> <range for N bytes>
	properly, i.e. it is just an integer division. The resulting integer can be
	encoded using the available linear map functionality.


+ is there a (small?) possibility to write an efficient z buffer? To order the
  drawing operations for mesh/surf plots?
  	-> Idea: for surface plots, it should be completely sufficient to start
	drawing at the correct edge; in the correct direction.
	Thus, the required operations to get a correct "z buffering" is either
		+ to reverse the sequence (i.e. to reverse rows and cols),
		+ to reverse the rows
		  	simple a posteriori impl: iterate through sequence, pushfront every
			row element. When row complete: pushback onto the final list.
		+ to reverse the cols	
		  	simpel a posteriori impl: iterate through sequence, pushback every
			row element. When row complete: pushfront onto final list.
	+ ok, I have implemented sorting and depth information.
	  	Ideas: 
			+ for scatter plots: simply sort coordinates,
			- for 3d bar plots (to be implemented): sort by (x,y,0) coordinates
			+ for (1d/2d) mesh plots: sort fragments (lines or rectangular
			  patches) according to the depth information of one corner,
			+ for any single-colored plot handler (lineto, curveto etc): to NOT
			  change the sequence.
			  -> perhaps I can return both, the sorted AND the unsorted sequence
			  if one has markers and single-colored plot handlers.
			+ don't use the enumeration pattern here; use '\let' to set the z
			  buffering technique (if possible).

+ provide better styles for 3D plots:
  	+ enlarge [xy] limits=false,
	+ view={45}{-30}

+ Ideas for 3D axes:
  	+ I could introduce '\addmesh' (or a 'mesh=true|false' option).
	  -> this activates R^2 -> R^3 visualisation.
	  -> \addplot is then always R^1 -> R^{2,3}
	  + only \addplot3 {<expr>} is different: it should default to (x,y,<expr>)
		using a mesh.
	+ mesh input:
	  	+ for plot expression: sample a matrix
		+ for coordinates, file, table: 
		  	+ describe how the linear sequence shall be mapped into a matrix
			+ requires the matrix' size and a flag 'ordering=rowwise|colwise'
			+ in principle, the matrix size is controlled by the samples key.
			  But since we are describing a mapping here, we should (maybe)
			  introduce a further key like |resulution={x}{y}| ...
		+ I need a |samples y| key anyway.
		+ visualization:
		  	+ case 'only marks': easy, just as before.
			+ all other cases:
			  	+ visualizations like surface and mesh are relatively simple:
				  we can iterate through the matrix (for example row-by-row)
				  and we ONLY need to access the CURRENT AND LAST ROW to 
				  draw the required things.
				-> Idea: provide an abstract datastructure which provides fast
				  access and efficient storage for the last visited row!
				  The best would be an array, but I should keep in mind that
				  arrays may be too inefficient with respect to TeX storage.
				+ I can implement 'flat shading' (piecewise constant). Idea:
				  	+ use rectangular elements
					+ query the colormap for one of the four corner points
					+ simply draw+fill the element with that color.
					+ framework: either the same as for scatter plots, or maybe
					  I can use the pgf basic- or system layer for the color
					  commands. This is potentially faster.

+ Notes for how to finish the 3D axes visualisation:
  	+ a 3D axis consist of several different parts (all of them are now more or
	  less ready).
	  They are:
	  	+ three axis vectors which determine the 2D projection.
			+ Input methods:
			  	+ |view| key (preferred)
				X explicit |x,y,z| vectors
				X |x,y,z| vectors given in the correct relative size.
				  -> simply scale them uniformly to get the desired width and
				  height
		+ A method to scale those axis vectors to get the desired dimensions.
		+ A decision for how to plot the axes:
			+ a complete box.
			+ only three surfaces visualized (the "back" of the axes)
		+ A decision which of the (available!) axis lines shall be used for
		   tick lines and tick labels.
		   Of course, this depends on the choice in (3.). 
		   Input methods:
		   	+ automatic placement. This is the preferred method.
			  this requires
			  	a) a decision which axis line gets the tick labels
				b) a decision whether tick labels are "right of" or whatever
				the chosen axis line.
			X user defined placement: the user EXPLICITLY provides the desired
			  axis.
			X The point (4b) above shall be modifyable by a user interface.
		+ An easily usable user interface to place axes descriptions like
		   labels and title.
		   Possible choices:
		   	+ Placement relative to axes vectors.
			+ Placement relative to a two-dimensional coordinate system,
			  relative to the VIEWPORT ("left of figure", "right of figure",
			  "above figure")
			+ Placement "parallel" to the axes which got tick labels
			  	+ "really" parallel? -> badly rotated text
				+ just "near" the respective axis line?

	- Some more implementation notes:
	  	+ If one of the 2D x,y,z vectors has length 0, the respective axes
		  should be hidden.
		+ a normal 2D axes should be considered to be an efficient special case
		  of a three dimensional axes - hide the special treatment as far as
		  possible.
		+ the routine which computes default tick positions needs
		  veclength*(max-min). Verify that.
		+ provide new keys:
		  	+ [xyz]ticklabel anchor=auto,paraxial,tikz
			+ [xyz]ticklabel dist=<dimen>
			+ with 'auto':
			  	+ non orthogonal axis => same as paraxial
				+ 3D => same as paraxial
				+ all other cases => same as tikz
			+ with 'paraxial':
			  	+ my new stuff (with the '*dist' keys as parameters)
			+ with 'tikz':
			  	+ as before: 'at='<tick position> and the anchor determines the
				  alignment.
			+ I still need anchors for 'paraxial'
		+ for axes labels:
		   Idea: use Tikz's  '\node[pos=0.5]' feature
		   + prepare two coordinates and a path (user configurable) which
			 connects them
			+ place the label on the path, for example using pos=0.5
			+ the path could be (depending on the tick label position which is
			  either LEFT or RIGHT) --  |-  -| or something like that.
		+ Ideas how to get those axes / surfaces which are on the back/front of
		  the 2d projection:
		  	+ I need the 3d (!) view direction. For 'view=', the 3d view
			  direction is directly available, for explicitly provided axis
			  vectors, it should be possible to compute it using cross products
			  and embedding in 3d (at least I hope so)
			+ now, given the 3d view direction and the three 3d axis vectors, I can
			  compute scalar products to check whether the view axis and the
			  axis vector point into the same direction. If I am not mistaken,
			  the following case distinctions hold:
			  	v * e_x > 0 => the surface attached at the lower end of e_x is
				FRONT, the surface attached at the upper end of e_x is BACK.
		  	  This should hold for e_y and e_z as well. Furthermore, the 3d axis
			  vectors are just unit vectors (if I suppose that only the view is
			  rotated)
			+ given the flags "FOREGROUND=[0|1]" for each axis line / axis
			  surface, I can also deduce
			  	+ which lines shall be drawn (or, in case of a complete box,
				  *when* they shall be drawn - as foreground or as background),
				+ which lines shall contain tick labels
				+ which lines shall contain axis labels

+ the FPU uninstall command can be assembled ONCE (globally). No need to do that
  multiple times.

+ What about something like '/pgfplots/table/x expr={<math expression>}' ?
  -> I could still use the lazy eval framework of pgfplotstable, i.e.
  	\thisrow{} commands, \pgfplotstablerow, \pgfplotstablecol etc.
	The \prevrow and \nextrow features won't be possible (?)

- improve support for multiple ordinates
- improve support for negative (reversed) axes
	- 'x dir =-1' -> scale automatically
	- x=-5.5cm, yticklabel pos=right, yticklabel style=left
	  could be a style (combined with x dir)
	- the anchor names are now strange - they are mirrored :-(
		\begin{tikzpicture}

		  \begin{axis}[
			title={Test},
			xlabel={Time [s]},
			ylabel={Segment},
			x=0.9cm, y=-0.9mm,
			%xlabel style={at={(0.5,1)}},
			%ylabel style={yshift=-6pt},
			%title style={at={(0.5,0)}},
			%xticklabel style={yshift=-6mm},
			%xticklabel pos=top,
			]

			\addplot plot coordinates {(0,30) (3,0) };
		  \end{axis}
		\end{tikzpicture}
	- furthermore tick scale labels should be shifted



+ improve plot expression
  	+ accuracy
	+ UI

- it would be useful if the clipping could be disabled for certain parts of the
  axis. Is that possible?
  	-> yes. 
	Idea: start clipping for every axis element separately! Shouldn't be
	much more expensive than a single marker path.
	- should work in the same way as before, there is no difference!
	- scopes should introduce no further problems
	- I could eliminate the nasty marker list

+ what about an optimized version of plot expression which does not need the
  brace hack (\x,{sin(\x r)}) ?

- allow math expressions for axis limits etc. Idea: try float parsing routine;
  if it fails: use math parser first.

+ plot expression for log plots would be more valueable, if it could sample
  points exponentially, i.e. linear between log(xmin) ... log(xmax):
  	x_i = exp( log(xmin) + i * ( log(xmax)-log(xmin) )/(N-1) )

- what about a feature like 'draw[xmin=...,xmax=...] fitline between points (a)
  (b)'?

- define a 'cycle list' style which simply inserts different colors into the
  predefined style (thus, markers are fixed, colors vary). One could also think
  about a complementary style.
  -> even better: I could provide up to three different lists which can be
  combined.
  Example: colorlist, markerlist, linespeclist
  -> iterate through all possible combinations!

- cycle list should be implemented using an array structure. That's faster.


+ create public key alias for '/pgfplots/domain' -> '/tikz/domain'

X the coordinate preparation routines should assign global registers. This would
  deal properly with grouped '\addplot' commands and it allows several
  optimizations in the coordinate processing (elimination of list allocations).

- document 'bar interval shift' and 'bar interval width'

+ document line styles with arrows

- think about quiver plots

- interpolate missing coordinates for stacked plots.

- think about a low-level contour plot interface in which PREPARED contours are
  provided as input. The contours as such could be computed with an external
  program (so far).

- the error bar implementation is relatively inefficient. Think about something like
  '/pgfplots/error bars/prepare drawing'
  which sets common style keys for every error bar

- think about using a combination of the visualization engine of pgf CVS and my
  prepared-list-structure. Maybe I can adjust the list format for the current
  plot type? I need
  	- scatter/line plots 2D
	- meta coords
	- quiver may need extra vectors
	- matrix plots may need twodimensional structure
	- error bars could be handled more consistently
	- ...
  -> implement a visualization class which provides methods
  	- prepare()
	- visualize()
	- serialize()
	- visualizestream()
	and provide protected pgfplots methods
	- axis->preprocesscoordinate (filters, logs)
	- visualizer->prepare()
	- axis->processcoordinate()
	- visualizer->serialize()
	- axis->postprocesscoordinate()
	The markers as they are implememted now don't really fit into this framework. 
	The clipping region is not really what I want here...
	Idea: enable/disable clipping separately for each drawing command!
  	

- provide 'only each nth coordinate' or so as style on top of 'x filter'.

+ 3D axes: my axis is "heavy weighted". 
  Possible improvements:
  	+ draw exactly 3 axis lines (unless one really wants the complete box).
	+ draw only one tick line per tick, in a direction which "looks well"
	  (one of the two possible directions).
	  this would also avoid double placing of tick labels in corners.
	+ attach tick labels generally at the end of tick lines. Provide a 
	  distance option configuring the distance.
	  -> my idea:
	  	+ for "normal" orthogonal axes (i.e. view={0,0}), the tick labels
		  are positioned directly at tick positions using proper anchors.
		+ for "non-standard" axes (skewed, rotated, 3D), tick labels are placed
		  at anchor 'center'; but the 'at' position it computed by pgfplots:
		  it is positioned parallel to the surfaces' 'b' axes at a predefined
		  distance.
		+ user interface: [xy]ticklabel pos in
		  {left,right,top,bottom,auto,paraxial:<distance>}
		  -> 'auto' implements the behavior above; all other choices are user
		  defined.
	+ automatically decide WHICH axis lines shall be drawn.
	+ see http://mathworld.wolfram.com/EulerAngles.html

+ implement simply style 'scatter classes'.
	+ sanity checking feature: try if 'pgfmathfloattofixed' results in a known
	  class!  -> but catch exceptions if the value is no number!

+ allow symbolic meta data

+ provide input options for 'meta' data
  	+ plot file
	+ plot table
	+ plot coordinates
	- document that stuff

- I could extend the clickable library such that a click into a TABLE
  opens a marker into one (or more) designated plots.

+ Optimization: normalize *internal* preprocessed stored point coordinate lists,
  for example as 'x1,y1,z1,x2,y2,z2,x3,y2,z3,' -> I have 100% control!
  Maybe it is even faster to re-use these lists for markers than to create a new
  one.

- I could compute maximum PGF logical coordinates which are then inserted just
  before qpointxy

+ optimize the new code by re-defining \pgfqpointxy for the case of scaled
  standard unit vectors.

X perhaps I can use pdf line annotations to improve clickable lib?
	-> no: there are right restrictions when using latex.

- there is a possibility to get that \label/\ref construction to work in
  conjunction with image externalization: I only need to write those commands
  into a separate AUX file and make sure they will remain ... even if the
  generating source has been externalized.
  The same could be done for javascript features; but that also requires bounding
  box control.


- asymmetric error bars

- Store the axis limits into the axis' node as saved macros. This would allow
  	- 'use [xy] limits of=<axis name>'
	- access to axis limits from other macros.
	-> provide a command
		\pgfplotslimits{current axis}{x}{min}
	  which expands to the 'xmin' limit.
	  PROBLEM: to WHICH limit: the untransformed one? The transformed one? The
	  logarithmized one?
	  -> I can't compute exp(xmin) in log plots!
	  - Ideas:
	  		- provide both, if possible. It is NOT possible for log axes.
			- use log-limits ( possibly combined with 'logxmin=' option ?)
			- The operation requires several operations because floats need to
			  be converted. Idea: do that only for NAMED AXES.
			  -> all user-interface macros must be expandable!
			- I don't want to spent time for number format conversions
			  unnecessarily here!
			- provide \pgfplotslimits and \pgfplotstransformedlimits
			  combined with simpler key-value interfaces
			- I could also provide access to the unit lengths (they are
			  available as macro anyway)
			- ALTERNATIVE: implement access to axis limits as a math function
			  which simply defines \pgfmathresult.
			-> that is probably the most efficient way to do it. I only need to 
			  register the new function(s) to PGF MATH.
			  	-> PGF 2.00: use \csname pgfmath@parsefunction@\pgfmath@parsedfunctionname\endcsname
				-> PGF > 2.00: use \pgfmathdeclarefunction
				Is it possible to provide 'string' arguments which are not
				parsed? No.
- I could provide public macros for the data transformations (and inverse
  transformations). This would also allow relatively simple access to axis
  limits.

	

+ I could optimize the number parser with '\csname ...#1\endcsname'
  constructions where '#1' is the currently identified character.
  If #1 in {0-9,e,E,+-} etc., I could save a lot of macro assignments and
  \ifx character comparisons.

+ Speaking about optimiziation: I always wanted to test \pgfmathln inside of the
  log code (combined with float support).

+ the 1000sep character should be placed for numbers >= 10000, not before. 

- provide predefined style for raised dots as 1000 seps.
  
+ improve scaled ticks: allow manual control over the automatic tick scaling.
	Idea: accept '[xy]scaled ticks=[false,true,auto,10^<k>,<real>]'
		+ true = auto: as it is now.
		+ false: as it is now.
		+ 10^k : accept an integer shift base 10. Should pose no impl. problem
		+ <real>: use float math and quotients

+ it would be interesting to get an high-level coordinate mapping
  	X : K -> \R
  X(k) \in \R is the x-coordinate.
  Idea: K can be any type of input, for example
  	- time,
	- date,
	- strings,
	- ...
  and K maps this transparently to numbers. Then: *all* input is given in K, and
  all output (tick labels) are given in K as well (requires X^{-1}).
  -> that's not difficult.

+ a scatter plot feature in which each mark gets its own set of options would be nice.
  More precisely, a general feature which sets keys according to the current value should be
  added -> this would also allow a (very early) visualisation of twodimensional functions.
  Ideas:
	 + linearly map data range to colormap as in matlab. Could use the result of
	   the scaling trafo; no need to work with float here (?)
	 + scope around each marker
	 + The colormap thing is generally useful and may be used in other contexts
	   as well. Ideas: 
	   		+ specification of colormap. An array of colors of size K? A color expression?
			+ providing color coordinates. Use the y coord? Or the z coord? Or
			  an expression of one of them? Maybe I still need high-level math
			  here?
			+ I guess the best is to use the same syntax as for pgfshadings.
			  Then, I will need to map linearly into a shading specification.
			  Technically, it is nothing but piecewise linear interpolation on 
			  a non-equidistant grid. To improve lookup speed, I could
			  normalize the input to an equidistant grid. The interpolation
			  procedure involves one lookup operation and one interpolation step
			  between two adjacent color specs (given as RGB).
			-> FIRST STEP: 
				+ define normalized format (RGB, equidistant etc.).
				+ provide lookup + interpolation routine.
				+ force normalized input. Auto-normalizations (conversions) are
				  a second step.
				+ Implement scatter plots based on this spec.
				+ provide a 'color data source' key which is one of
				  	1. 'xyz' (copy coordinate)
					2. f(T(x),T(y),T(z)) as expression in transformed range
					3. f(x,y,z) as expression in untransformed range (float
					  required)
					4. explicit color spec 'c'
				  the cases 3. and 4. need changes in the coordinate preparation
				  routines.
				  


+ styles are named very unintuitively. I should add something more convenient
  (for example like the 'legend style={}' command). Idea: use the *same* name
  as the options which are affected,
  'xlabel style'  'title style' etc. My current naming scheme used the name of
  the 'every style' which suffer from backwards compatibility with xkeyval...
  :-(   

- maybe it is possible to eliminate a lot of key macros to save string space?
  Those family macros can be optimized (sure ?).

- provide access to axis limits and data bounding box.
  It would be useful to get access to axis coordinates, for example in 'circle (XXX)'

+ axis equal option

+ consider 'plot image[xmin=,xmax=,ymin=,ymax=] {<graphics>};
  -> load external plot image!? Only useful for matlab, if matlab would allow 100% 
  control over bounding box. Unfortunately, it doesn't.

- allow extended <col name> arguments inside of create column

+ is it possible to create a *real* linked list? It should have the following
  features:
  1. O(1) push/pop operations
  2. O(N) copy()
  3. O(N) convert to macro list
  4. O(N) traversal/loop

+ introduce \label and \ref for legend entries?

+ optimize tikz-interface

+ optimize macro-append issue from O(N^2) time to O(N)

+ create a \pgfmathfloattosci method and use that for the numerics in table package

X re-implement 'dec sep align' of table package natively, not as high-level
  style.
+ It is not (easily) possible to replace single entries of tables with '-'.
  (for example: gradient columns)

+ create a \pgfmathfloattosci method and use that for the numerics in table package

- check whether the new floating point routines can be used to 
  REALLY setup a linear map DATA RANGE -> DISPLAY RANGE
  Technical thing: map the CLIPPED data range or the TOTAL data range? 
  What advantages/disadvantes appear?

+ [Tikz] document how to use internal registers can be used in libraries.

+ [Tikz] add an 'every plot mark' option and adjust 'mark options' accordingly

+ document the 'external' library of tikz (CVS only).

+ group 'All supported styles' section by content


+ allow arrow heads or other axis line styles
	+ styles for axis lines are missing
	+ for outer axis lines: introduce option 'separate axis line paths'
	   if one wants to use arrow heads

+ set default styles for non-boxed axis labels
	+ label positions for centered axis lines
	+ tick scale labels
	+ tick align versus label positions
	+ think about axis label placement. Possibilities:
	  	- on the same side as tick labels.
		  -> should be move away in normal direction
		  -> should avoid problems with tick scale labels
		- opposite of tick labels
- perhaps math style {grid=major, axis x line=middle, axis y line=center, tick
  align=outside}


+ the table package could use some sort of multicolumn feature which
  allows something like 'columns={A,B,A,B,A,B}' and distributes entries of input
  columns A and B equally to output columns.

+ TDS directory structure is not completely correct. Should be everything under
  directory 'pgfplots':
	$package = "pgfplots";
	&SYSTEM ("$MV README ext_scripts test doc/generic/$package/");
	&SYSTEM ("$MV generic tex/generic/$package/");
	&SYSTEM ("$MV context latex plain tex/");
  and context files should be in
  	tex/context/third/pgfplots/...
	doc/context/third/pgfplots/...
  (reference: mail conversation with Karl Berry)


+ automatic disabling of enlargelimits when axis lines are not drawn as a box

+ copy my personal' homepages short images to pgfplots website

+ interrupt single plots at discontinuities (for example tan(x))
  -> don't draw from +infty to -infty

- optimize plot expression

+ optimize tick generation code for speed

+ alias 'axis x line=middle' and 'axis x line=center'

+ an option which contains legend ENTRIES?

+ the non-boxed axis lines are placed at 'ZERO'. Maybe this zero level should
  get an anchor!? -> allows to place axis labels above it

+ default style for grid lines to: {thin, black!25} ?


X implement an axis as path-command

+ implement proper anchors 

+ provide simple options for useful bounding box truncations


+ Maybe I could perform a restore of the current bounding box at the END of an
  axis. Restore means: restore to the setting BEFORE the axis.

+ I could create a node which can be referenced and which has the axis' size 
  [ That touches another open problem, see below]

+ I could use the new 'local bounding box' option of PGF to restrict the
  bounding box to the axis' size

+ I also need some sort of number style for log-tick-labels.

+ move math mode shifts into \prettyprintnumber implementation.

+ allow the '-plot' commands.
  It would be a cool feature if '(FIRST_X,0)' could be inserted as move-to
  operation before every plot.
  -> one could make funny features with 'fill' in plot styles.

- make the legend code more general: allow
   \addformattedlegendentry{ \node{hallo} \nextcell \node{foo} \nextcell #1}
   where #1 is the auto-generated small plot-spec image. One could also provide
   '#2' as just the current plot spec OPTIONS.



+ document 'legend plot pos' option

+ there are some clipping paths in the tick-placement loop which can be
  replacement with simple \ifdim's. 
  I guess clipping is not the cheapest operation.


- remember unfiltered (non-logarithmized) input ticks with \listnew and provide
  them like '\tick' during ticklabel typesetting
 

+ improve tick placement (more) systematically

+ provide auto tick labels at 5*i if appropriate

+ implement the legend as tikz-matrix
  -> width computation works correctly (there is a bug with font scaling)

+ provide tick labels as a list like
  	axis[tick labels={A,B,1,4,5,$\frac 12$}]
	-> convert to \listnew, use listpopfront to access elements


+ provide options for log plot tick formatting:
  	10^0.703 vs fixed point format

+ I could provide a global coordinate transformation 

+ I could try to use the plot-stream framework of PGF directly instead of using
  the 'plot coordinates' command of tikz. 
  Advantage: would be faster. And the additional features can't be used anyway
  because of my own number parsing routines...

+ rename manual.pdf to pgfplots.pdf -> allows texdoc pgfplots


+ alignment: vertikal kann ich jetzt mit baseline. Kann ich horizontales
  alignment an (0,0) hinbekommen?

+ axis hide option ? macht das sinn?

+ legende anders formatierbar?
  	- ausserhalb des (und isoliert von dem) plots?
	+ horizontal?

+ grid lines
  	+ minor
	+ major
  -> einfach als verlaengerung der kleinen tick lines
 
- es gibt scheinbar in PDF viewern die moeglichkeit, fuer den Druck ein anderes
  dokument/dokumentteile zu verwenden als fuers Bildschirmbetrachten
  (draft-package bspw?).
  Kann man das nutzen, um sowohl farbige als auch S/W-plots zu generieren?
  -> pruefe draftcopy paket


+ koennte man den kram auch aus (grossen) tabellen rauslesen? Also sowas wie
  "plot X versus Y aus file Z"?
-> DEBUG!
  Ideen:
  	+ abstrakte datenstruktur als liste von spalten, eine spalte ist ne liste
	  von nummern
	+ einlesen: 
	  	+ zeilenweise, haengt an die jeweiligen spalten mit \listpushback
		  coordinaten dran
		+ read first line as header (optionally my $flags line for column
		  formatting advice)
		+ read just strings, no parsing
		- optimal: '\t' as separator. How can I teach TeX to use '\t' as
		  separator!?
	+ would allow
	+  	\addplot plot table[x=X,y=Z] {\table}
	  and
	+  	\typesettable[columns=...,format=sci,...,formatting options=...] {\table}
	+ implementation: simple run through column lists
	-> CONSISTENT data representation, powerful display options



+ man sollte \addplot mit '+[OPTIONEN]' starten koennen.

+ ich sollte das enlargelimits deaktivierbar machen! vllt. auch ne option 'tight'

+ automatisches tick-platzieren koennte verbessert werden
  	-> insbesondere fuer normale plots

+ fehlerbars waeren nett


+ baseline option, die die linke unter ecke als '(0,0)' koordinate annimmt.
  Wuerde generell sinn machen, oder?

+ ich haette sehr gerne ein Skript, dass zu jeder figure ein eps und/oder pdf
  macht, dass dann bitte schoen ordentlich includiert wird.
  -> see tikzexternal june 2008


+ passe bounding box und x/y-skalierung "sinnvoll" an.
  +	mache ne option "width=" die die GESAMTbreite angibt.
  + mache "height" option
  + belege width und height defaultmaessig sinnvoll
  + ueberlege ein sinnvolles gesamt-skalierungs-konzept.
	Das, was ich jetzt gebaut habe, mit 'x=SCALE' und/oder 'y=SCALE'
	ist nicht ausgereift und eher verwirrend. sowas macht man wohl besser mit
	pgf-skalierungen!
	+ 	Die 'x=' und 'y=' optionen sollten direkt in setxvec reingeschrieben werden,
		ohne schwachfug mit skalierung!
	+ 	wenn ich 'width=BLA' angebe, wird automatisch 'y=1cm' angenommen. Das
		ist unintuitiv; man erwartet eher, dass defaultheight im aspect ratio
		mitskaliert wird.
	+	Nur mit der 'x=' bzw. 'y=' option sollte es NACH AUSSEN moeglich sein,
		direkt einfluss auf die koordinaten zu nehmen.

+ entscheide automatisch, ob der abstand zwischen ticks an die skalierung
  angepasst werden sollte.

+ [xy]min = auto
  -> berechne die werte numerisch
  Ideen:
  + verzoegere das malen der Achse bis \end{axis}
  + in jedem \addplot:
    ich koennte irgendwie pruefen, ob ich 'plot coordinates' habe.
	Sobald ich diesen modus erkannt hab, kann ich koordinate fuer koordinate
	parsen und jeweils min/max bilden.
  + ich muesste dann noch den befehl in einem makro konserieren, sodass er
	 spaeter, nach dem verzoegerten achsen malen kommt.

  OFFEN: was passiert, wenn NICHT plot coordinates benutzt wird? Vllt. die
  'domain' variable abfragen?
  -> jedenfalls koennte ich mir da durchaus was ueberlegen!

+ [xy]tick = auto
  in abhaengigkeit von [xy]mode: zeige ticks von floor(xmin)...ceil(xmax)

+ mache styles:
  + every plot
  + every axis (?)

+ gebe eine liste von verfuegbaren linestyles an, durch die mit jedem
  plot-befehl durchgecykled werden kann

+ option, minor ticks ein/auszuschalten

+ option, die X/Y-Achsen anders zu formatieren. Moeglichkeiten:
  + Kasten drumrum
  + je eine Linie mit Pfeil am Ende
  + Achse nach rechts oder so

+ aendere die das \addplot makro derart, dass beliebige plot-moeglichkeiten
  folgen koennen
  \addplot[OPTIONS] plot coordinates {...};
  -> das \addplot ersetzt gewissermaßen das \draw