Hmm... looking back at the original post, I think the problem is that, 
while the error is caught, it's not properly handled, for two reasons:

1) The error messages don't say what the real problem is; the user
    might be able to deduce that a filename with non-ASCII chars is
    the problem, or he may not. Fixing the issue by relying on
    char replacement to spaces to trip a file-not-found error
    is... well, it's a hack. And the trip can fail because...

2) There may be a file in the same folder (or in whatever
    search paths exist) which already has the
    same name except it has a space instead of the extended char.
    The parser would then succeed and use that file, which could
    produce an erroneous rendering. This is a small possibility,
    I grant, but certainly not impossible. It's basically
    tantamount to POV-Ray thinking up what filename to use,
    when that should only be the user's decision.

fwiw, don't replace illegal filename chars -- just fail right at that 
point altogether (and with a "filename contains unsupported chars" message).

Ray



Thorsten Froehlich wrote:
> Ray Gardener wrote:
>> 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"
> 
> Actually, that line is not he problem, but the fix. POV-Ray is perfectly 
> capable of parsing UTF-8, but the remaining file handling code cannot 
> always deal with UTF-8 strings, and on non-recent-Unix systems it is not 
> even supposed to. As inspecting the code for UTF-8 would have been 
> overkill for 3.6, the design decision was to disable it, which is why 
> the line you quoted above enforces an ASCII string.
> 
> Either way, it is not a bug and the design is not going to be changed 
> for 3.6 either.
> 
>     Thorsten, POV-Team

Post a reply to this message