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
|
This file is designed to keep track of various problem fixes and new
features being worked on for the current PLplot CVS MAIN HEAD version and
who is taking responsibility for following up on each item.
The items are divided into Essential and "Would be nice" (i.e., release
critical versus not) with each of those categories further classified into
minor or major effort required.
N.B. at the end we have an additional section on problems/issues associated
with the new unicode-aware fonts.
Essential, major effort required.
********************************
Essential, minor effort required.
********************************
* PLplot documentation of python, java, etc., interfaces. Alan
"Would be nice", major effort required.
***************************************
* Fix bad-looking surface contours for plsurf. The problem goes away if the
plP_fill call is commented out in the normal series of alternating calls to
plP_fill and plline3 that are used to generate the surface and the surface
contours. So I conclude there is some inconsistency between the edge of
the triangles as defined for the surface contours plotted by plline3
and the edge of the triangles being filled. Low resolution devices have
worse problems than high resolution devices. Surface contours look bad
for png, better (but still not acceptable for publication) for psc, better
still for xwin, and I could not find any problems at all for tk.
* Move from DSSL based docbook stylesheets to XSL. Rafael, as soon as
the XSL results look as good (pdf currently a problem) as the DSSL results.
* Maurice's idea of plsopt and plsdopt so that our API doesn't keep
proliferating. Example, instead of plenv0 do:
plsopt("plenv_advance", "0");
plenv(...)
* -the tk drivers ignore plconfig.tcl if it is in the user directory ~/tcl
and a tclIndex file is generated. "auto_path" is correctly initialized to
~/tcl, pwd/tcl, etc, but plconfig is not executed. Reported by Joao. Status?
* Maurice plans to finish his changes to implement handling strings as
strings in the metafile format.
* Geoffrey plans to at least evaluate remaining fidelity problems caused
by our 16-bit integer approach.
* Put in index limits for the plot3d API's so they can handle
non-rectangular x,y regions. This has already been done for plsurf and
needs to be extended to plot3d.
* Put in variation of "defined" callback function with user-defined data
for plshade and plshades. Rafael?
* Put in "defined" callback function with user-defined data for plcont,
plot3d, and plsurf. This will supersede the non-rectangular x,y regions
change already done for plsurf and planned for plot3d, but this programming
is harder than those previous or planned changes so it will probably take
longer. Rafael?
"Would be nice", minor effort required.
***************************************
* 2003-09-20: The generated info files should have their root name changed
from plplotdoc (plplotdoc.info, etc.) to plplot$version like the rest of the
generated files (plplot-5.2.1.cvs.20030915.dvi, etc.) Note this change would
require that packagers' scripts that execute install-info would need a
change to use the versioned name, but this should be straightforward to do
both for RedHat and Debian packages.
* 2003-09-20: References are not there in info bibliography section (chapter
14). According to Rafael this problem is caused by docbook2x not currently
supporting the <bibliomixed> and <bibliomset> tags so we will have to wait
for that to get sorted out.
* plplot_general list 2003-08-26: Arjen Markus <arjen.markus@wldelft.nl> "I
have found that with the X Window driver the values returned by plgspa()
are/can be too small by a factor of approximately 1.4." This should be
followed up by an attempt to confirm the bug, and if it is there, fix it.
* Error messages for when the extended search fails in tclAPI.c. This is
required when running in tcl-only mode with no plframe or stack trace.
* As part of extended search try the install location. We know exactly
where that is relative to our font data, and we know exactly where the font
data are installed so we know the absolute path to our tcl install location.
Then, the only way such an extended search would fail is if the packagers
messed with our tcl install location.
* Use some well-recognized pdf verification tool (similar in spirit to the
w3c verification tests for web sites) to be sure our results conform to the
published pdf standards. Currently there is no idea whether such a pdf
verification tool exists, but acroread is buggy on Linux so that is not good
enough as a verification tool.
Collection of problems/issues with new unicode-aware fonts as of 2005-03-21.
All these are in the would-be-nice category with some/all taking major effort
to resolve.
****************************************************************************
I. Font problems associated with plfreetype.c which is called by gd.c which
implements the png, gif, or jpeg devices. (These issues were discovered
using -dev png).
* The default -drvopt smooth=1 option does not work (lots of cmap0 index
errors) if there is any user change to cmap0. This problem is triggered
if you attempt to run example 2 with -dev png. Andrew Roach thinks he
knows a small redesign that will fix it.
* There are still problems with vertical alignment of symbols for
plfreetype.c. See results from
examples/c/x06c -dev png -o test.png
where on line 100 the characters move up or down depending on whether they
have an ascender, descender or neither. There are similar problems for
example 7.
N.B. This is only a problem for plpoin (example 6) and plsym (example 7),
but not a problem for plmtex. So there is probably some issue with the way
plhrsh (called by plpoin and plsym) sets up the call to the code in
plfreetype.c that is not present for plmtex.
* The above problem may be related to the xform setting in plhrsh (plsym.c)
which is a kludge. if you define TEST_FOR_MISSING_GLYPHS,
it quits working (all the symbols are twisted by 90 deg).
* -drvopt 24bit problems. If this option is turned on (and only in this
case), Example 9 and 22 second and subsequent pages have rectangular
viewports with no box or tick marks. Furthermore, with Example 19 the
second and 3rd pages turn black. If you use -bg FFFFFF, you can see the
problem is a cmap0 one, somehow 24bit turns the default red colour into
black which doesn't show against the normal black background, but which
does show against a white background as with -bg FFFFFF.
* text clipping does not work (see example 9). There is a clipping method
in libgd, but the preferred solution (since it will apply to every device
driver that uses plfreetype.c) is to use the libfreetype clipping
method which Andrew Ross found in the freetype documentation.
* We need to build in fontconfig support into plfreetype.c for truetype
fonts. This well-known library by Keith Packard is available for both
Linux and windows and should allow truetype font selection by name rather
than by filename, and font substitution on both Linux and windows if the
requested named font is not available.
II. Font problems associated with ps.c and either -dev psc or -dev ps.
* The overall size of the text is systematically smaller than for Hershey or
TrueType fonts.
III. Other font problems/issues.
* We should enable additional device drivers for unicode. In particular,
our two most heavily used interactive device drivers, xwin and tk, should
give some outstanding looking results once they are unicode-enabled.
I nominate Maurice to make this happen.... :-)
|