Of course Peter, I was being a little tongue in cheek. But, let's not forget
that performance and size issues are always nickel and dime problems. Add a
little thing there and you slow down by 1%. Big deal, right? Well, if 15
things like that are added by different people all thinking it is no big
deal, you start to really notice. For example, when we are working on boot
times for Office apps, the performance team agonizes over hundredths of
seconds. Adding a single large (e.g. 30MB font) to Windows can significantly
increase the Windows start up time (maybe several seconds), especially if
any application included in the start up sequence tries to enumerate all
fonts, as many do (mainly because it is convenient and they are ignorant of
the perf hit). This alone is an unacceptable increase for many people.
Then there are all the other groups that want default install. For example,
does everyone want a full set of database drivers and access methods
installed by default? No, but for developers of database tools it sure would
be great if they were all there on all machines, and they didn't have to
ship the full set with their client software just in case the client machine
does not have them, including forcing a system reboot during install. You
see where this is headed - every special interest has an angle - you can't
accommodate all of them., and you have to triage the requests to accommodate
the ones who make the best cases. (In the bad old days, floppy disk space
was at a premium so we couldn't even ship the pan-Euro fonts with retail
versions of Win95 as an optional install due to the increase in
cost-of-goods-sold. Thank goodness for CDs, and now DVD)
Same thing with disk space - 50MB for complete international support is
still a lot. And is the case for this really as strong as say, the data
access argument? Keep in mind that people who seriously use a particular
language will already have that language support on their machine. You are
concerned mainly with people who for some reason a) understand and b) want
to use a language, yet c) for some reason do not have the support on their
system. This is a pretty specific group of people - a small minority of real
users (who tend to buy preconfigured localized versions), but maybe a
majority of readers of the Unicode list.
It is mainly a configuration issue then - how do we make sure that anyone
who wants this support can get it easily or automatically? One possible
solution is that it is installed by default, but for the short-medium term,
a solution more palatable to the rest of the users is required. In Win2000,
that solution is to make the support an easy control panel setting away, so
that's a big improvement over language packs hidden on the CD (NT4), or not
available at all (Win95 floppies)
Anyway, you and I agree on this - I am just trying to inject a little sense
of the competing pressures that govern the actual decisions for the benefit
of the list. Sometimes things are the way they are due to oversight, but
usually they are considered decisions resulting from tradeoffs of many
competing priorities that may not be apparent to the casual observer.
Cheers,
Chris Pratley
Lead Program Manager
Microsoft Office
P.S. Office2000 does ship UniScribe.
-----Original Message-----
From: peter_constable@sil.org [mailto:peter_constable@sil.org]
Sent: December 7, 1999 12:09 PM
To: Unicode List
Subject: Re: Support for Multilingual Documents
Chris:
PC>> Certainly disk space is a non-issue.
CP>Wish it were so.
Here's the original context to which I was responding:
AP>>>I'm aware of these nice multilingual features in these
products. Thanks for pointing them out again, though.
AP>>>However, if you are authoring web pages for a general
audience, then IE and NN are the standards you have to support.
My point is: just because you, the page author, can view the
character does not mean that arbitrary users can view it. Users
on most standard installs of Windows, Mac, or UNIX do not get
the character sets and fonts by default and most won't
understand why that little black square is being presented in
place of various (sometimes common) characters.
AP>>>IOW: I'd argue in favor of more Unicode and cross-script
support built into the operating systems. I would be happier
if, for example, the retail Windows 2000 included the full
install of all of the scripts and associated fonts by default.
My understanding is that this won't happen...
What was being considered was just what it takes so that a
person developing web content can have confidence that their
non-Roman documents will render correctly on others' machines.
CP>Multilingual bits of Win2000 are huge when all the IMEs,
dictionaries, and fonts are installed - in the 200MB range...
I agree that this is huge, and that 200MB would be an issue.
But not all of this is needed just to attain the goal described
above. IMEs and dictionaries aren't required to ensure that if
I create a web page with Hindi or Amharic that it will display
with *some measure of predictability* on other's machines. All
that is required is a minimum of one (large) font and some
shaping engine that can provide at least default rendering for
any script supported in Unicode.
Such a font is already being provided with Office and IE, and I
believe you'd like to provide the shaping (Uniscribe is
beginning to do that, and is included in IE5; I expect you're
planning to ship Uniscribe with the next version of Office). In
other words, this goal is in line with something that your
product group at MS and at least one other product group have
already decided you should do. We know that a Unicode 2 font
takes ~25MB; I'm guessing that a font for all of Unicode 3
isn't that much bigger (I have one that's only 18MB); let's
suppose that by Unicode 4 fonts and shaping engine take up
~50MB. That's rather less than 200MB. I wouldn't have thought
users would be concerned about 25MB today, 50MB in a couple of
years. From what I've seen, I looks to me that you've reached
that conclusion yourself.
Peter
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:56 EDT