In article <3f21a2a3$1@news.povray.org>, wol### [at] hot-mailcom says...
> > void main () {

> >     call functional_code()
> >   else
> >     call crash_windows();
> > }
> 
> I love your .sig. Is it the source code for "Windows for quantic computers"?
> :-D
> 
Actually my opinion is that MS already has secret deals in place to 
install a few special quantum circuits into existing chips that only work 
with the Windows OS. Thus this code is already hidden in there some 
place. ;)

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

In article <3f21a958$1@news.povray.org>, tho### [at] trfde says...
> I am still undecided whether I should recommend some sleep or you are on
> drugs.  There is neither head nor tail to what you are writing.  I don't
> even know how to respond to this in a meaningful way!?! :-(
> 

Ok.. Then let me try again...

I could make a file with the same name as flyer_2000 is talking about on 
my windows machine. It would look different in a DOS window, since 
Windows doesn't use the OEM terminal font in most programs, even for 
dealing with filenames. However, the file system would have absolutely no 
problem with it and 'in windows' it would have the proper accented 
character. This does not make it a unicode name. I am not sure what the 
technical name for a character set that has exactly 255 characters is, 
but it isn't exactly ASCII and it also isn't Unicode.

So I am unclear about exactly 'which' OS you seem to think would have a 
problem here? Windows will accept the name, I am fairly sure Unix based 
systems would, maybe Mac 'might' have a problem, but the only 'real' 
issue is the font used to display the names, which differs between a DOS 
window and Windows, but 'should' be the same under most GUI environments.

If you still don't believe me, then consider that these sorts of 
characters have also been used in text documents since before Windows 3.1 
and on 9x systems you have to install Unicode support separately, because 
it is not a native part of the OS. If such file names and characters can 
only happen with Unicode, then how they heck do you explain them existing 
before Unicode was available?

So again. Exactly 'which' OS are you saying is not capable of using this 
particular set of files? You are the one that assumed he was talking 
about unicode and brought that into the discussion, but such a name is 
not unicode.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Ok.. I just ran a quick search. The character set is called ISO_8859_1, 
or at least some equivalent in it. This is what a file name like "Suba 

'exactly' like that when viewed in DOS, because the font used there is 
Terminal and Windows used Courier everywhere. This quirk also means that 
other OSs may also show such names using the wrong characters, but again, 
this is not unicode, and it certainly doesn't mean that a file name is 
limited to ISO/ASCII.

Now if there is some OS out there that won't support this and 'that' is 
the issue, then sorry for attempting to say anything.

BTW: I got the ISO_8859_1 thing from searching Google for: 'ascii 
character set 0-255'. There seems to be a bit of confusion here though, 
since while it clearly states that ISO_8859_1 supports 256 characters, 
half the sites insist on calling it ASCII, which you insist only uses 
128. This sort of thing gives me a bloody headache.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

In article <MPG.198c7761600bdbbf989844@news.povray.org> , Patrick Elliott 
<sha### [at] hotmailcom>  wrote:

> So I am unclear about exactly 'which' OS you seem to think would have a
> problem here?

Really, you are simply missing the point, which is

>>>
It has nothing to do with Unicode.  It has to do with the filesystem and how
it is accessed.  there is no portable way to access files with Unicode names
because you cannot pass Unicode strings.  That is all.
<<<

The ISO 8859-1, also known as Latin-1 character set is simply a superset of
ASCII, that is ASCII specifies characters 0 to 127 and Latin-1 specifies
characters 0 to 255 with characters with the code 0 to 127 being identical
to ASCII.  It provides many characters used in European languages.

Further, Unicode supports all ISO 8859-1 characters with exactly the same
encoding plus another million or so characters.  UTF-8, as support by
POV-Ray is just a transfer encoding of Unicode characters with a few special
properties, one being that characters 0 to 127 are identical to ASCII.

Windows, like by far most operating systems you will find today, initially
did not support Unicode simply because Unicode was only defined in 1991.
Instead, systems use other tricks that essentially assign the codes 128 to
255 (more does not fit into a single bytes) different characters depending
on the language the operating system is set to use.

However, this all has absolutely nothing to do with POV-Ray not being able
to support Unicode filenames.  The fact that you can enter them somewhere in
some operating system says absolutely nothing.  Explaining this in the level
of detail and with all the background for you to understand it is simply not
possible in a news message.  So, I suggest you just accept the fact that
what you are looking for isn't possible to do in a portable manner for the
time being.  This may change in a few years, but has absolutely nothing to
do with POV-Ray.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <MPG.198c7a70fd0396d989845@news.povray.org> , Patrick Elliott 
<sha### [at] hotmailcom>  wrote:

> Ok.. I just ran a quick search. The character set is called ISO_8859_1,
> or at least some equivalent in it. This is what a file name like "Suba

> 'exactly' like that when viewed in DOS, because the font used there is
> Terminal and Windows used Courier everywhere. This quirk also means that
> other OSs may also show such names using the wrong characters, but again,
> this is not unicode, and it certainly doesn't mean that a file name is
> limited to ISO/ASCII.

No, they don't "show the wrong characters".  They show exactly the right
characters, but you miss the fact that not the whole world uses Latin
characters and a few European special versions of them.  The non-ASCII
characters simply have different "meanings" when using a different operating
system language.  There is no right or wrong, all are right as the same
character code will have a different "meaning" depending on the language
being used, which cannot be encoded in the characters.  That is why Unicode
allows many, many more character codes and even composition of characters to
complex "symbols" used in some languages.

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

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

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

In article <MPG.198dcefec22b76a9989846@news.povray.org> , Patrick Elliott 
<sha### [at] hotmailcom>  wrote:

> 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. :(

No, you still got it all upside down.  Probably I didn't make clear enough
that there is a huge different between what you as a user see and what a
program will "see" (not really, but I can't explain it better without going
into endless details).  So POV-Ray cannot *access* files with non-ASCII
names in a portable manner.  It has absolutely nothing to do with you giving
files names with non-ASCII characters.  It has nothing to do with one
particular operating system.  It has to do with how to universally access
files.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Sun, 27 Jul 2003 11:59:30 -0700, Patrick Elliott <sha### [at] hotmailcom>
wrote:
> Actually, I do know about the much more complex issue of true unicode. 

There isn't even such a thing like "true" unicode.
http://www.unicode.org/faq/utf_bom.html#14

ABX

Post a reply to this message

In article <l4t9ivcinr4ejp55k9cjiopnh1odfjbgqe@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

>> Actually, I do know about the much more complex issue of true unicode.
>
> There isn't even such a thing like "true" unicode.
> http://www.unicode.org/faq/utf_bom.html#14

Well, it really depends on how you define "true" in this context ;-)  It
should also be noted that POV-Ray internally only handles strings in UCS-2
without surrogates.  The reasons for this "limitation" are even more complex
than why files are only supported with ASCII characters, but it does have
certain effects...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3f2441f9$1@news.povray.org>, tho### [at] trfde says...
> In article <MPG.198dcefec22b76a9989846@news.povray.org> , Patrick Elliott 
> <sha### [at] hotmailcom>  wrote:
> 
> > 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. :(
> 
> No, you still got it all upside down.  Probably I didn't make clear enough
> that there is a huge different between what you as a user see and what a
> program will "see" (not really, but I can't explain it better without going
> into endless details).

Sigh.. Well I have run into something like this with file names from a 
unix system that I tried to unpack to a Windows machine. The fact that 
this particular program included make files and headers that where 
'supposed' to let it compile under windows didn't change the fact that 
most programs like WinZip are apparently not smart enough to know the 
limitations of the system they run on and offer to let you rename the 
damn things. I can imagine a similar situation for files in POV, so... :( 
Oh well... :p

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message