As I asked, so now must I summarize.  (and then draw unwarrented
conclusions)

Andreas Raab
===========
	Smalltalk native fonts mean that everything looks the
same across all platforms. TT Fonts may not be constant across platforms.
Recommends squeak native fonts, and limitations on even bit imaging of fonts
beyond a standard/accepable set.

	*** MMM  I'd like some more fonts please ***


Dan Ingalls
===========
	Standards are wonderful.  There's so many ways to implement them!  API is
most likely pretty straightforward, making sure "Plain" 32 is the same
bitmap on every platform is considerably more difficult.

	***MMM Uggghhhhhh-
			CAN SOMEONE PROVE OR DISPROVE THAT FOR ANY FONT f ON ANY
			PLATFORM p, the FORM g REPRESENTING A CHARACTER c WITH
			PROPERTIES SPECIFIED BY p IS
			CONSTANT?  If a Rose were a glyph is a rose(windows)
			 is a rose(mac) is a rose(bsd) ????

		I think to be safe, x-platform usage of TT requires that 1) you own the
rights to use the TT spec and 2) you own the rights to invoke a conversion
from TT to bitmap on the machine that's doing it.

Dave Smith (1)
==============
	Yup, Dave, we can do this. Questions on the table at present are;
		whassit cost in cycles ?
		whassa differential across platforms ?


	Reloading fonts on startup is interesting, significant subset of user
community shows signs of font-hording, defined as shoving every font they
ever encounter into their fontlibs.  Me, I've always liked the family
concepts, other than it covers a set of boring fonts and then lumps
everything I'm interested in under 'decorative'

Tim Rowledge
==============
 	Tim alludes to some of the mechanics that Dan and Andreas foreshadowed,
i.e.  'wot you lout ?  you thought that fonts wuz equivalent cross platform
?  or........   A given TT specification for a font will not neccessarily
consistantly yield an exactly equivalent form on all invocations on all
platforms.  And that is a nasty problem (neat crypto app if you think about
it tho)  I'd like to see proof that this is so, I figure proof of error by
exception should be easier than the options.

Tim, I'd be curious if you'd have any observations re: operational speed.
Say we solve this problem.  What about overall machine speed, now what we
have a more time consuming
"Please give me a char in this font at this size with these xplatform
fudges"

for every character we process, assuming that xplatform fudges exist.

Dave Smith (2)
	I responded to Dave directly, primarily indicating we'd be willing to give
up the code we use on Windows to handle this.  All 30 or so lines  :-)


SUMMARY
	1) Cross Platform Issues
		Folks, Microsoft Windows absolutely dominates the world.  If you had every
platform but Windows for a vertical market, end user intensive app, and a
competitor had a successful Windows version, you are tuna on rye. I first
used UNIX when you mailed a tape to NJ and got it, and I still know and love
it.  But if you have or want a mortgage you cannot ignore economics.
		Our official policy as a company is that we design for cross platform and
implement for Windows.  In many cases it costs little to support x-platform
stuff, and _when_ such is the case, only a fool would ignore the advantage.
Much of the time, xplatform leads to beneficial insight. When such is not
the case we write discardable code for windows.  But we also always view
cross platform compatibility for what it is.  The Windows market, and
everything else.

	I've made these two comments for a reason.  For the moment, the solution to
_all_ cross platform issues is;

		a) this works on all (reasonable) versions of Windows
		b) there is an automatable process to make this work on some other major
OS such as UNIX
		c) when a and b fail there's enough source for you to hack it onto
whatever oddity is your host os.

	Hence I respectfully file all xplatform font issues under
		A_) please say it aint so that C is not C is not C
		B) failing that, every platform for hisself until A is repaired, i.e.
we're at the old baseline + (delta+)

	2) Performance issues

Evidement, this is not simply a case of 'give me a 32 pt C in Cyrillic' and
a naive expectation that this will produce the same results across all
platforms.  My initial posting was borne of, 'gee I can certainly produce a
blizzard of Forms with char glyphs' but that assumed that the glyph I got
was the glyph I wanted.  Seems there is a consensus that this is not the
case.  So what does it mean for overall system overhead to say....

The glyph of any individual byte or double byte character in Squeak is
sourced from a call to GetCharacterGlyph(WORD potentialUnicodeNastiness)
that returns a Form of some aspect which is identical for all such
characters for that font from that manufacturer on all platforms?

Yeah, I know the last sentance sucked.. But it did cover the bases  :-)


Comments  ?????  We're more than willing to put up our font>bitmap stuff for
Windows, however it seems that TT acually means TrueType(sub)(on this
machine only). I'm not a TT kinda person, what I'm taking away here is
	"why bother, since fonts aren't consistant across platforms using TT"


Regards

Mark