We could store the raw data in binary files and have C programs
access the data with a standard interface.
/* in libc */
enum { Achar, Aimage };
typedef struct Atom {
int type;
union {
char c;
Image *i;
};
} Atom;
void amamkechar(Atom *a, char c)
{
a->type = Achar;
a->c = c;
}
void amakeimage(Atom *a, Image *i)
{
a->type = Aimage;
a->i = i;
}
/* in libdraw */
void drawatom(Image *d, Atom *a, Point loc, Image *textcolor, Point
textcolorpt, char *font)
{
if (a->type == Atext) {
char c[2];
c[0] = a->c;
c[1] = '\0';
string(d, loc, textcolor, textcolorpt, font, c);
} else
}
However, this severely complicates the Unix/Plan 9 philosophy of
pipes, and only allows for character-at-a-time reads. We could add an
ability to read a string of characters up to EOF or an image to make
it (a tiny bit) simpler.
On Jan 25, 2008, at 6:21 AM, [EMAIL PROTECTED] wrote:
Treating image as character (with unusual width and height) means
indefinite number of potential characters and if a machine (not
human)
does not able to differentiate between "text characters" and "image
characters" it renders character sets unusable.
Sure, but the idea is that the actual description of the image lies in
a different layer (no, I don't have any idea how these will be linked)
and only a descriptive placeholder will appear at the relevant
coordinates (recall that I'm advocating a two-dimensional
representation to replace the current linear simplification).
But your point is certainly relevant. And I'm only tossing ideas
around, no deep theories involved.
++L
