Re: Corrupted Fonts

On 2005-09-21 09:21:42 -0400, Daiya Mitchell <daiyaNOSPAM@xxxxxxxxxxxxxxxx> said:

No one has a definitive statement, because we don't know what causes the
problem. Not everyone sees it, not even everyone on Tiger.  A number of
people maintaining multiple computers on Tiger have not seen it.  It is
clearly due to some sort of interaction with the OS, because it never came
up on Panther, but I have no idea whether the problem is with MS or with
Apple, and I have no idea whether anyone at the MacBU has tracked it down
either.  Problems that *don't'* strike everyone are the hardest to track
down.



Daiya,

Thanks again for your helpful contributions here.

May I say that I'm not much of a programmer.  But I know enough to know
that Word puts up a dialog that says <font x> is corrupt.  that means
it has a check to see if font x is corrupt.  look at the bloody routine
that does that check and figure out why that check might be DEAD WRONG
on a Tiger system.  If the genius microsoft programmers can't figure it
out, then build in an "ignore this font" option, and only list fonts
that it thinks are not corrupt and ignore the bloody rest.  Not too
hard.


Hi Loren,

I don't know much about programming either, but the way I see it:

The root of the problem is not the check that comes back as corrupt, nor
even the corrupt cache, but whatever process corrupts the cache so that it
reports a wrong answer.  It's that process that needs to be tracked down,
and that's about interaction with the OS, and happens *before* ever the
check is made, I'm guessing.

Again, the check does not come back wrong on all Tiger systems, only some,
which is what makes me think the problem is not in the process of checking,
but somewhere else.

A workaround for this, as you say, would be to build in an "ignore this
font" option. Since the way Word deals with fonts is so complicated, I'm
guessing that would involve some deep structural changes that are beyond the
scope of an update. Many people asked if they could turn off "optimizing
font menu", which would prevent the corrupt font messages.  I'm thinking
that's coded in Word at a pretty low level, since it's part of the startup
routine.

Daiya 

Daiya,

Thanks again for the thoughtful response. But I'm guessing it's mostly nonsense. (No offence to you personally, as I do believe you either don't know any better or have been told by whoever you talk to at MS that Office is "very complicated" and that it interacts with OS X in an arcane and totally unaccessable technical way and so forth, basically transforming the corporate politics between apple and ms into a problem of programming.)

First, I don't think there's anything that really corrupts the font cache, because no other application nor the operating system has any problems. The cache just gets corrupted as far as word is concerned. And yes, something must happen for that, but something that Office should be able to gracefully handle. Putting up an endless series of dialogs for each so-called corrupt font is no way to handle it.

Now then, if you have the patience and the time to sit though 100 dialogs and press ok for each (which I have done and which takes about 20 mins on my system), word works just fine once it finally starts up. So in effect it is already ignoring the so-called corrupt fonts.

Coding the dialog box is most certainly NOT at a "low level". It would be a matter of changing the logic (to use AppleScript) from:

set corrupt_check to check_corruption(this_font)
if corrupt_check is true then
 display dialog (name of this_font) is corrupt with button {"OK"}
else
copy this_font to optimized_menu_list
end if

to:

set corrupt_check to check_corruption(this_font)
if corrupt_check is false then copy this_font to optimized_menu_list

Now as to the way word deals with fonts being so "complicated" that this would involve "deep structural changes" and so forth, that's nonsense too. No matter how "low level" this mysterious "way" is, at some point a program keeps a list. Lists, also known as arrays, are low level programming objects, and even the most low level assembly language has some way of dealing with lists. It's a matter of NOT ADDING items (in this case fonts thought to be corrupt) to this list/array during the check sequence without unnecessary user intervention.

Now thankfully, Office is not written in assembly language. It is, I'm guessing, written in C+, but at least some common high level language. Which means the source code has identifiable and commented (sub)routines, and one that deals with checking for corrupt fonts. That code has to be fixed, probably with a few lines. (Since the fonts aren't actually corrupt, word just thinks they are. I mean duplicate fonts for chrissake?? come on, again it's a matter of not adding a dupliate to the list of good fonts But I'm just restating the point here.)

Anyway, once fixed in the high-level source code, the source is recompiled. Any change to the source code, from the most superficial change to the most major, requires a total recompile, as it does with all coding environments. There's nothing so deep that it is beyond anyone familiar with the source code. The line of argument you're pushing is just a kind of obfuscation that tech geeks like to push on every day computer users: make it seem so technical that a fix is either impossible or will cost you hundreds of dollars an hour in consulting fees.

Believe me, it's not. It's just bad programming combined with lazy programmers, shielded by an army of apologists and a wall of corporate silence.


--
----------------------------
Loren
pls reply in this thread. 

.