On Sun, Jan 21, 2007 at 10:41:29PM +0100, Georg Baum wrote:

> Enrico Forestieri wrote:

> > I had a look at the code and come to the conclusion that the FileName
> > class with its toFilesystemEncoding method is not of help here. This
> > is because we have to also deal with non-absolute paths and some
> > arguments may also be in utf8.
> 
> Why non-absolute paths?

There's a comment in converter.C about the fact that some converters can
only output files to the current directory, so makeRelPath is used with
first and second arguments as utf8 encoded paths. Whereas the
first argument can be easily converted to the file system encoding (it's
a FileName), the second one is the path encoded as an utf8 string.

> In the past we were moving to absolute paths
> wherever possible in order to get rid of the Path class that is simply too
> confusing to use.

Really? I find it quite clever ;-)

> And why would some arguments be in utf8? AFAIK commandline arguments should
> always be in the current locale.

I am talking about the parameters that are added to the command line to
be executed. Due to lack of time, I was not able to ascertain how they
are stored in the Converter class. AFAIK they could be in utf8 encoding.

> > IMO we should have functions for directly converting from utf8 to the
> > file system encoding and vice versa. I would like to hear opinions about
> > this issue and, for discussion, attach here a patch solving these
> > problems.
> 
> As I already wrote to Abdel last week the fact that all our filename related
> code does still use std::string and not docstring is only of temporary
> nature. I did not convert it yet because that would mean a lot of
> conversions e.g. in some bibtex related code that cannot be converted to
> docstring easily.

Oh, that's it. I was wondering why you chose to go through those double
conversions...

> Therefore I don't think that we should convert from/to utf8 directly. If a
> function
> 
> std::string const to_filesystem8bit(docstring const & s);
> 
> is needed, then add it, but instead of direct conversion from/to utf8 I
> would rather change all filename related code to docstring. I can do that
> if you want, but not too soon (the next week will be busy).

Yes, I thought about implementing to_filesystem8bit, but then realized that
I would have not used it by alone but always in conjunction with from_utf8.
Introducing to_filesystem8bit, only converter.C and the two python scripts
should be changed. I'll try to do it.
BTW, I never use anything but ascii paths ;-)

-- 
Enrico

Reply via email to