On 02 Oct 1999 13:52:01 +0200, Lars Gullik Bj°nnes wrote:
>"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:
>
>| > Are we going to use this?
>| >
>| > - if (!isalnum(name[i]) && name[i] != '.')
>| > + if (!isalnum(name[i]) && name[i] != '.'
>| > + && name[i] != '-' && name[i] != '+' name[i] != '=' )
>
>One question though, why can't we use the functions from ctype.h to
>determin if this is a good char or not?
>
>We requiere for all chars c that
> - isspace(c) == false
> - iscntrl(c) == false
> - isascii(c) == true
>
>Does isgraph include control chars?
>
>I know that there are some chars in addition to this that is not
>allowed on certain filesystems. ('/' on unix)
>
>I to me &= 0x7f does not really show that we want to move from 8bit to
>7bit...especially when this is done by just removing the 8th bit.
Comments must be more explicit here.
>F.eks. in latin1 -> a would be a good translation, same with ->
>'a' (better -> "ae")
I was always in favour of using the standard macros. The problem
discussed with Shigeru Miyata and the reason for his radical cut-off #8
solution IIRC was the problem with DBCS (double-byte characters) and
other uncommon PC encodings (a list of wierd encodings to be supported
by XFree 4.0 is part of the japanese XTT-Server, which adds some
support already). We should not try to make the porting to asian and
other languages more difficult as it already is. So this one will work,
an explicit per-character solution won't, at least least not without
rewrite.
>This would not be a problem if this was only used internally in LyX
>(in the tmp dir), but it is not. This is vislible to users when they
>export.
>
>Should we perhaps don't do the translation when exporting?
>
>I agree with Asger, efficiency in this func is not important at all.
>Clear and obvious code is.
That's true, but I don't think a per char substitution with double or
triple byte codes would be clear. This is not your problem now, I
know...
Greets,
Arnd
