From mboxrd@z Thu Jan  1 00:00:00 1970
Mime-Version: 1.0 (Apple Message framework v753)
In-Reply-To: <c85458b08f9e262e911c1bfbfc8e0067@proxima.alt.za>
References: <c85458b08f9e262e911c1bfbfc8e0067@proxima.alt.za>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <56DCAD47-EB6C-4C1B-B11B-CDA0DF7829E0@mac.com>
Content-Transfer-Encoding: 7bit
From: Pietro Gagliardi <pietro10@mac.com>
Subject: Re: [9fans] Re: Building GCC
Date: Fri, 25 Jan 2008 09:07:15 -0500
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Topicbox-Message-UUID: 386be7a2-ead3-11e9-9d60-3106f5b1d025

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@proxima.alt.za 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
>