In article <4388d42c$1@news.povray.org>, tho### [at] trfde says...
> Patrick Elliott wrote:
>   > How can it be, given that it doesn't allow access to all unicode
> > characters? It by definition can't, since true unicode requires a 
> > 'section' code, followed by a 'character' code, of *always* two bytes. 
> > UTF8 treats only specific characters as a 'section' code, so part of the 
> > unicode set if unavailable. Unless I am completely missing something... 
> 
> There is no such thing as a "section code" in Unicode. Unicode defines one 
> continuous set of character codes. UTF8 is an encoding of Unicode, providing 
> access to all Unicode character codes. You definition is clearly wrong; I 
> suspect you are confusing Unicode with "code pages" from long forgotten DOS 
> and early Windos times.
> 
No, I am not confusing them, I just don't know the right term, so guessed 
at one. But to be clear, what would this $2039 be in UTF8? Would it be a 
space and a 0, or the 0/00 symbol? If the later, then Ok, sorry for the 
confusion. If that is the case, then we need to fix the editor so it 
correctly supports the characters.

> > But I have seen people complain before about how they can't use some 
> > character with POV-Ray and the reason always given is that UTF8 doesn't 
> > support them. If I am wrong, then why does this problem crop up all the 
> > time?
> 
> Because* people do not realise that most editors, including those included 
> with POV-Ray for Windows and POV-Ray for Macintosh do *not* save text files 
> in UTF8 but ISO-8859-1 and MacRoman respectively.  As such, entering any 
> character outside the ASCII range and setting "charset" to "utf8" causes 
> POV-Ray to try to interpret those an UTF8 sequences, which they are not. 
> This of course yields all kinds of strange errors, with POV-Ray rejecting 
> characters many times, or replacing them with blanks after issuing a warning 
> (it depends).
>
Sounds like there are serious bugs in the support.. Maybe a binary field 
type would be useful, like the html # numbers? It seems quite ridiculous 
to support it, but have that support be effectively broken.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message