Analysis of the code in pov_util.cpp indicates heavy reliance on 8-bit 
C-string functions when processing filenames, which would need 
nontrivial recoding to support non-ASCII filenames.

The core problem is that filenames/pathspecs are considered strings, 
when they should be promoted to their own datatype of which the string 
aspect is an implementation and/or interface detail. Code that does

   char* filename = Parse_C_string(true); // true indicates "is filename"

would become

   file_id* filename = Parse_FileID();


It's much friendler to implement file_id types in C++ (e.g., boost has a 
type which makes it easy to express multipart paths using a '/' op 
overload), so if POV 4.x is using C++, could do it there. A file_id type 
also makes it easier to encapsulate policies for path separators, drive 
letters, extensions, legal filenames and filename characters, language 
support, etc.

Ray




Torsten Werner wrote:
> please have a look at <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507915>:
> 
> PoV-Ray can not use filenames allowed by the standard Debian encoding, UTF-8. As
> an example I tried to include a file, which creates a mountain, called

> itself works, (povray accepts it as an input file) it is not possible to have
> it included:
> 
>   0:00:00 Parsing

> Possible Parse Error: Non-ASCII character has been replaced by space character.

> Possible Parse Error: Non-ASCII character has been replaced by space character.

> Possible Parse Error: Could not find file 'monta  a.pov'

> File Context (5 lines):
> #include "colors.inc"
> #include "camaras.inc.pov"

> Parse Error: Cannot open include file monta  a.pov.

> Parse Warning: Check that the file is in a directory specifed with a +L switch
>  or 'Library_Path=' .INI item. Standard include files are in the include
>  directory or folder. Please read your documentation carefully.
> 
> 
>

Post a reply to this message