On Sat, 2 Oct 1999, M. Uli Kusterer wrote:
> >Can't work: the same font could be used in different ways in different
> >contexts. Actually this is just about guaranteed to happen. For
> >example, if you add "Courier" to the "unicodeFonts" property to make
> >your stacks work right, all the examples in the MetaCard on-line would
> >turn to gibberish. Only thing worse than a "tag" hack is a global
> >property that seriously breaks backward compatibility ;-)
>
> Scott,
>
> this complicates things, of course. Maybe you could give fields a property
> "renderAsUnicode" of some sorts?
Can't work: this feature is most useful when applied to chunks of
text *within* a field. It also needs to be available for buttons and
other objects.
> Or you could support syntax like
>
> set the textFont of fld 4 to unicodeFont "Courier"
Yech.
> Using tags here is bad, since there's always bound to be a platform where a
> font exists that uses this tag in its name. Especially on the Mac, where
> all characters may be in a font name.
You should keep in mind that this is exactly how 16-bit fonts are
implemented in X11. You set the "fontName" to a set of fonts
separated by commas, one 16 bit and one or more are 8-bit (which font
is used for which chunk is determined by tags in the text, similar to
the way UTF-8 works). This group of fonts is called a "fontset". Of
course, anyone developing fonts for X11 knows not to put commas in
font names. My guess is this is true for font developers on the other
platforms too, but it'd be nice to have some sort of spec to prove it.
> If this is only needed under NT, you
> could of course resolve this to a tag there, but unicodeFont should simply
> be ignored on another platform. That is, for Linux
>
> set the textFont of fld 4 to unicodeFont "Courier"
> and
> set the textFont of fld 4 to "Courier"
>
> are the same, but under NT these might resolve to
> set the textFont of fld 4 to "Courier/u"
> and
> set the textFont of fld 4 to "Courier"
If the tag is going to be in the font, I don't see the point in adding
a spurious "unicodeFont" to the equation (I don't even know what part
of speech that is). And if the data has to be stored in a file and
maybe work cross platform (and I think it does), we're going to need
to filter (or maybe implement ;-) the tag on all the platforms anyway.
> instead. At least this would keep scripts compatible without endangering
> different platforms. Of course, if we need a way to determine a field's
> font including whether it uses Unicode we could only go by compares to
> unicodeFont "Courier" in this case.
Which means that you can't do comparisons directly in scripts. This
*is* a serious problem, both for simple UIs which would just display
and allow setting the font name directly, and for fancy ones that need
to deal with all properties in a consistent manner. Adding a new
property is bad enough, adding a new part of speech vastly increases
the amount of work required to build either type of UI. Any other
options?
Regards,
Scott
> Cheers,
> -- M. Uli Kusterer
>
> ------------------------------------------------------------
> http://www.weblayout.com/witness
> 'The Witnesses of TeachText are everywhere...'
>
> --- HELP SAVE HYPERCARD: ---
> Details at: http://www.hyperactivesw.com/SaveHC.html
> Sign: http://www.giguere.uqam.ca/petition/hcpetition.html
>
>
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
