UTF-8 editor
------------

The POV-Team seems to say you need to be sure to write UTF-8
files, because POV cannot read UTF-16 files.

I know of one such program: Vim. Yes, it's a Vi clone, so you
might not like the way it works. But you don't need to do much
work there, and gvim has a graphical interface. Open the file
with it, type
	:set fileencoding=utf-8
and then
	:wq
to write it and quit the editor.

Vim 6.0 is still in beta (for only a few more days) and is
available from Vim FTP mirrors in the unreleased/pc directory.
Take the gvim60ax.exe file.

-- 
Adrien Beau - adr### [at] freefr - http://adrien.beau.free.fr
 Mes propos n'engagent que moi et en aucun cas mes employeurs

Post a reply to this message

> > When using UDF8 character mapping (with unicode formatting of the
> > .pov-file, using notepad), the parser cannot parse the document
> > successfully, rendering only garbage.
>
> Are you sure the text output is really UTF8?  Does it work if you use the
> raw character code with "\uXXXX" (where XXXX is the hexadecimal character
> code) instead of encoding the characters in UTF8 directly?
>
> ____________________________________________________
> Thorsten Froehlich, Duisburg, Germany
> e-mail: tho### [at] trfde
>
> Visit POV-Ray on the web: http://mac.povray.org

At last - a useable hint! I tried the raw character code with "\uXXXX" and a
little help from Character Map, and it worked! I must admit that I still have
very limited knowledge of UTF8 coding, but I have noticed the 'unicode'
markings in Character Map. I could never have guessed the \u-part by myself.

Thank you very much for this information. You have been very helpful.

Best Regards

Nils Olav Kilen, nok### [at] post8teledk.

Post a reply to this message

In article <3BAF9E54.A52F66DD@post8.tele.dk> , Nils Olav Kilen 
<nok### [at] post8teledk>  wrote:

> At last - a useable hint! I tried the raw character code with "\uXXXX" and a
> little help from Character Map, and it worked! I must admit that I still have
> very limited knowledge of UTF8 coding, but I have noticed the 'unicode'
> markings in Character Map. I could never have guessed the \u-part by myself.

Hmm, while it is good that this works (so at least the TrueType rendering
works), I am still worried because of the UTF-8 problem.  If notepad indeed
claims it writes UTF-8, could you ZIP a (small) sample file with lots of
non-ASCII characters and post it in beta-test.binaries, please?  It would
help to find out what is wrong if the file is UTF-8.

    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 Tue, 25 Sep 2001 10:28:55 -0400, Thorsten Froehlich wrote:
>In article <3BAF9E54.A52F66DD@post8.tele.dk> , Nils Olav Kilen 
><nok### [at] post8teledk>  wrote:
>
>> At last - a useable hint! I tried the raw character code with "\uXXXX" and a
>> little help from Character Map, and it worked! I must admit that I still have
>> very limited knowledge of UTF8 coding, but I have noticed the 'unicode'
>> markings in Character Map. I could never have guessed the \u-part by myself.
>
>Hmm, while it is good that this works (so at least the TrueType rendering
>works), I am still worried because of the UTF-8 problem.  If notepad indeed
>claims it writes UTF-8, could you ZIP a (small) sample file with lots of
>non-ASCII characters and post it in beta-test.binaries, please?  It would
>help to find out what is wrong if the file is UTF-8.

It is UTF-8, but it starts with EF BB BF, the UTF-8 encoding of the FFFE 
endianness indicator (as written on an Intel machine, obviously.  A Motorola
machine would use EF BF BE)  We could easily interpret the presence of those
three bytes as an implicit UTF-8 charmap, and infer the endianness of the
other UTF-8 characters in the file at the same time.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end 
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

Post a reply to this message

In article <slr### [at] fwicom> , ron### [at] povrayorg (Ron
Parker) wrote:

> It is UTF-8, but it starts with EF BB BF, the UTF-8 encoding of the FFFE
> endianness indicator (as written on an Intel machine, obviously.  A Motorola
> machine would use EF BF BE)  We could easily interpret the presence of those
> three bytes as an implicit UTF-8 charmap, and infer the endianness of the
> other UTF-8 characters in the file at the same time.

Ah, of course, if it is a whole UTF-8 file.  I will fix it in the next few
weeks.


    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

Ron Parker wrote:

> It is UTF-8, but it starts with EF BB BF, the UTF-8 encoding of the FFFE
> endianness indicator (as written on an Intel machine, obviously.  A Motorola
> machine would use EF BF BE)

Actually, UTF-8 is byte-order independent. So the UTF-8 BOM will always be EF BB
BF.


> We could easily interpret the presence of those
> three bytes as an implicit UTF-8 charmap, and infer the endianness of the
> other UTF-8 characters in the file at the same time.

http://www.unicode.org/unicode/faq/utf_bom.html

I had just run into this on some Java related issues.
Basically, the BOM is a special use of a standard "ZERO WIDTH NON-BREAKING SPACE"
character. Sometimes it might be treated as a BOM (or UTF-8 flag) and stripped out,
but it doesn't have to be. At the begining of a file it's probably a good idea,
though.



--
Jon A. Cruz
http://www.geocities.com/joncruz/action.html

Post a reply to this message