On Fri, 2006-12-01 at 01:26 +0000, Roger James wrote: > The path returned from osgDB::findDataFile( osgimg->getFileName() is > ./Textures/RM_big_tree1.rgb > > This is relative the the current working directory of the current process > and is correct.
I think the code is trying to make a document relative URL from that (denormalized) result. > > The statement is a very simplistic creation of an absolute URL from the > > results of findDataFile(). It is saying that the leading '/' is the base > > URI. Since the supporting code doesn't normalize on this, there should > > be a check for a pre-existing leading '/' at the very least. > > > > You may be right here, but I suspect that the author of the code put the > leading slash in to stop the subsequent call to daeURI::validate from > converting the path component to an absolute path. Heh, by making it a absolute path to a non-existent file instead? That's broken. > So the function will either return the path supplied (relative of absolute) > or an absolute path to the file rooted in one of the search paths. So we need some path algebra that can convert one path to another path. In this case the ultimate goal seems to be to create a document relative path. As you say the input is either CWD relative or absolute. > > > #ifdef WIN32 > > > daeURI uri( _strlwr( (char *)imgstr.c_str() ) ); > > > #else > > > daeURI uri( imgstr.c_str() ); > > > #endif > > > > For Windows this completes file to URL normalization by making it > > lowercase. This could be a source of problems because the path portion > > of a URL is case sensitive, so this should be a transient operation and > > not persisted in the output (ie it must be case preserving). > > > > This is the code that I inserted to try and get round problems with the DAE > functuon daeURI::makeRelativeTo performing case sensitive comparisons on > platforms where the path is case insensitive. I don't think that matters because URI path are always case-sensitive. The goal of this function is to write a URI so it must be case preserving. > If I remove the code that adds the leading slash then after the call to > daeURI::validate the path is > > C:/Temp/colladatest/models/zach/textures/rm_big_tree1.rgba Is this correct? > And after the call to makeRelativeTo it is > > ../../../../../C:/Temp/colladatest/models/zach/textures/rm_big_tree1.rgba > > Which is even more broken. This implies to me that there is a bug in daeURI::makeRelativeTo() that needs to be reported to that sourceforge project. > Unless anyone else wants to have a go at it I will attempt code up a version > that gets round the problem of makeRelativeTo doing a case sensitive > comparison on a platform that does not have case sensitive paths, but it > will be a couple of days before I can get to this. Well this is a feature of URI that makeRelativeTo() is doing right. It's often painfully true that higher level tools (like even Apache, see http://httpd.apache.org/docs/2.0/urlmapping.html and http://httpd.apache.org/docs/2.0/mod/mod_speling.html) have to do a proper job remapping URI to filesystems. This is a bit harder on Windows because it's not also case-sensitive. > I cannot see anything in the standards about the lexical comparison of path > components in a file scheme URI, so I assume it must be platform sensitive. It's not, rather it's scheme based. See http://www.apps.ietf.org/rfc/rfc3986.html#sec-6.2.2.1 and http://www.apps.ietf.org/rfc/rfc3986.html#sec-6.2.3 . See http://www.apps.ietf.org/rfc/rfc1738.html#sec-3.10 , the specification for the file scheme. It doesn't make the exception that the path is case-insensitive. Regards, Marcus _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
