In article <3f22d546@news.povray.org>, tho### [at] trfde says...
> Really, what you say based on observation may fit the limited observations
> you have made, but your conclusions are all wrong because you simply don't
> know what really happens.
> 
>     Thorsten

Actually, I do know about the much more complex issue of true unicode. 
All I am saying is that in general principal the extended ASCII may not 
be the same from one machine to another, but that does not preclude those 
names existing in some form (if not the expected one) on any machine, at 
least that I have used. I.e. Files with characters beyond the 0-127 range 
'should' be readable, even if the characters don't match what the 
original author intended. They are still in the range of characters that 
the file system actually uses. Thus unicode or not, it is a null issue, 
unless the system you are trying to put it on is some insane OS that only 
lets you use 0-127. If I end up with a .pov file on my machine I don't 
bloody care if the character set that was 'originally' used was in some 
bloody Chinese sub-dialect, I just want to use the file without having 
the rename it first. Now I admit that most of my experience has been with 
Mac, Windows, OS/2 and DOS, so there may be cases where this 'is' an 
issue. I am just not aware from my own experience of any case where it 
would be, unless you are talking about something like an 8088 running 
CPM, then you have a valid point. lol

I however have trouble imagining any modern systems actually suffering 
from this issue so severely that the result is not a mere flipping around 
or replacement of a few letters that would give the file a funny looking 
name. But, you say it is a problem, so I'll shut up now. :(

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message