scamper problem

goran.krampe at bluefish.se goran.krampe at bluefish.se
Fri Mar 4 08:46:44 UTC 2005


Hi John!

John M McIntosh <johnmci at smalltalkconsulting.com> wrote:
> Gee how timely, I was working on Tk4/Sophie this morning and coding up  
> a FileURL for a font file.
> 
> say
> FileUrl absoluteFromText: 'file:///Library/Fonts/Corsiva.ttf'.
> 
> But the problem is on the mac when I ask for the pathForFile
> I get back
> 
> ':Library:Fonts:Corsiva.ttf'

Just tried in my 3.8 and given Andreas fix back in October (I think) it
looks good. I threw in a MacHFSPlusFileDirectory to see it (I am on
Linux) though, but it looks good to me.
 
> The leading ':' implies under HFS+ to use the current working directory  
> and of course we don't get the file open.
> In this case the path should be:
> 'Library:Fonts:Corsiva.ttf''

Good. :)

> Now if I say
> FileUrl absoluteFromText: 'file:Library/Fonts/Corsiva.ttf'.
> which gets me a non-absolute file URL object, then I'll get the HFS+  
> correct, but that's wrong...

Oh yes, that is wrong. Now you are relying on a bit of "smartness" in
FileUrl>>privateInitializeFromText: which, if there aren't two slashes
after "file:" - meaning it can't possibly be a correct FileUrl - then it
tries to handle *everything* after "file:" as the path.

And since the current logic for detecting "absoluteness" checks for a
leading "/" (which given my coding and reliance on RFC1738 (and the
presumption that all FileUrls *are* absolute) is a trick, because in a
correctly formed FileUrl there is always a slash after <host>, becuase
it is the separator) it will think that the path is not absolute.

But again, that is just code I threw in to be able to "decently handle
malformed file URLs".
 
regards, Göran



More information about the Squeak-dev mailing list