Thanks to Chinh for these cogent explanations. I wholly agree that it
would be a good idea to ditch MacRoman text encoding in favor of
ISO-8859-1. I have that option in my text editor (as well as the
option to save files with Unix line endings) and it is very useful.
I would like to have a response to the broader issue raised in my
message. It is not acceptable to produce, e.g., graphs in Stata that
must be edited by some kludge downstream to contain UTF-8 characters
that are not available in the ISO-8859-1 charset (such as the Greek
alphabet, mathematical symbols, etc.) We need UTF-8 (broadly,
Unicode) handling to make graphs fully presentation-quality. We can
get around this for tables as routines like Ben Jann's -estout- can
write TeX, including the TeX codes for all desired characters (sorry,
you MS Word devotees have some manual work to do). But for graphics,
UTF-8/Unicode support is really necessary.
Kit Baum, Boston College Economics
http://ideas.repec.org/e/pba1.html
An Introduction to Modern Econometrics Using Stata:
http://www.stata-press.com/books/imeus.html
On Dec 14, 2006, at 2:33 AM, statalist-digest wrote:
> Apple has a new font API in later versions of Mac OS X that we may
> be able to
> use to get a list of available fixed-width fonts. But that could
> mean dropping
> support for earlier versions of Mac OS X so this method may have to
> be saved
> for a future release. Either way, we'll look into it.
>
> <character mappings deleted>
>
>>> is Windows-specific. These are not the correct mappings for
>> Mac OS X.
>
> We're probably going to make Stata for Macintosh use the ISOLatin1
> text
> encoding in the future rather than the default Mac Roman text
> encoding to get
> some consistency across all the platforms we support (Windows and
> Unix both
> use ISOLatin1). We can't do it now because this will screw up
> datasets saved
> on the Mac that contain 8-bit ASCII characters when read back into
> the Mac."
