Re: [9fans] Re: Building GCC
- From: pietro10@xxxxxxx (Pietro Gagliardi)
- Date: Fri, 25 Jan 2008 14:09:21 GMT
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, lucio@xxxxxxxxxxxxxx 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
.
- Follow-Ups:
- References:
- Re: [9fans] Re: Building GCC
- From: lucio
- Re: [9fans] Re: Building GCC
- Prev by Date: [9fans] OT: layout models
- Next by Date: Re: [9fans] Re: Building GCC
- Previous by thread: Re: [9fans] Re: Building GCC
- Next by thread: Re: [9fans] Higher level document rendering and editing (Was: Building GCC)
- Index(es):
Relevant Pages
|
Loading