|
|
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
|
|