World: r3wp

That sounds like a good idea to me too, so when a new distro comes 
along which locates fonts in a different location, then at least 
you can do something about it without having to wait for rebol to 
be updated. It will also require less code in rebol compared to a 
full automatic font finder.

no possibility of moving to the HTML5 Web Open Font Format? - then 
just use the same fonts in all OS?

I have a technical re-distribution question relative to the R2/forward 
code-base.


I might be forced to use an older version of R2 but need to include 
"some" of the functions within r2/forward mezz files.   


since I don't want to have to include many files in this project, 
I would like to simply include the few functions directly within 
my own "reusable" stuff module which is already part of that project...


is it ok for me to include, as a comment within my own lib, the headers 
found in the source files I would pick specific functions from?

license is bsd is it not? or apache or similar for r2/forward

for 2.7.8, I have submitted this to rambo http://www.rebol.net/cgi-bin/rambo.r?id=-4776&

R2/Forward is MIT. Use it as you will. Actually, that use is part 
of the reason for its existence. If you run into any compatibility 
problems with older versions of R2 please mention them here. I eventually 
plan to make R2/Forward work on versions as far back as 2.5.0.

If you like you can attribute what you use, but MIT was specificly 
chosen so that wouldn't be required.

Graham, the id in your link is negative(!), and gives this:
	ERROR: Ticket not found. Go back and check your input.

Before a RAMBO ticket is reviewed and accepted it has a negative 
ID. If it doesn't work now, it must have been reviewed. Don't know 
the current ID.

http://www.rebol.net/cgi-bin/rambo.r?id=4400&

As Gab says, the username has to be double url encoded for this to 
work

Can anyone think of any side effects from adding a 'dehex to the 
protocol rules ?

Yeah. The problem is that it dehexes too soon, not that it doesn't 
dehex soon enough.

Eh?

Just posted a ticket about this for R3 (by request). This shows the 
problem:
>> http://user%40rebol.com:[blah-:-www-:-rebol-:-com]/
== http://[user-:-rebol-:-com]:[blah-:-www-:-rebol-:-com]/
; should be http://user%40rebol.com:[blah-:-www-:-rebol-:-com]/

>> decode-url http://rebol%2540rebol.com:[password-:-www-:-rebol-:-com]

== [scheme: 'http pass: "password" user: "rebol%40rebol.com" host: 
"www.rebol.co
m"]

The scheme handler should have to do a dehex in some cases, but isn't 
because the dehex is being done in DECODE-URL first, when it shouldn't 
be.

decode-url should not dehex

Right. And once I figure out how to make it not do so in R3 (based 
on Gabriele's code) then I will port that to R2.

Perhaps DECODE-URL should dehex the split-out parts, but after it 
splits them out. And since it doesn't fully decode the path section, 
it shouldn't dehex it - and probably not dehex the rest, just for 
consistency. If the reconstructed url doesn't rehex the parts then 
it shouldn't dehex them in the first place.

If you feed a url to a function, the only thing you really need to 
dehex is the username and password... nothing else

It depends on what you mean by "you": "you" the user, "you" the writer 
of DECODE-URL, or "you" the writer of the schemes.

the latter two euwes

Well, DECODE-URL should probably not dehex the username and password 
unless the (unknown to me) code that reassembles the url! can be 
changed to rehex them. As it should, but I don't know which code 
to fix. The scheme, host and path should not be dehexed in any case.

Probably don't dehex anything in decode-url ...leave it to the schemes

true... since a scheme can potentially not even represent anything 
network related.

The problem is that while the scheme might not represent anything 
network-related, the standard for URI syntax is independent of network 
issues. And that standard is pretty strict about hex encoding, regardless 
of the scheme's internal rules. So schemes need to be hex-encoding-aware 
for their specs, whether they are network-related or not.

parse-url should not dehex .. we can fix the rest in the schemes

brian, true.  my error... I'm deep in calculus... my brain is a bit 
mushy ;-)


IIRC the RFC has an BNF-style breakdown, so there should be no surprise 
as to where hexing can and should be interpreted.

I did a fully compliant RFC URL parser which works better than the 
internal one... maybe I should look at it for more details...

My only concern is that I don't know where is the code that reassembles 
the url! from the results of DECODE-URL. So I don't know how to fix 
any issues in it.

the code is in the sdk

Which file? What is the function named?

Why do you think it is reassembled?

IIRC its all in a context.

All urls are deconstructed into an object

Right. But the problem I am trying to fix is this:
>> http://user%40rebol.com:[blah-:-www-:-rebol-:-com]/
== http://[user-:-rebol-:-com]:[blah-:-www-:-rebol-:-com]/

Somewhere in the middle of that process, DECODE-URL is called. What 
is called after that to reassemble the result into a url! value?

The dehex in that process is the one that we need to get rid of.

I suspect we don't have the source to that...

look in the URL-parser context within the prot-utils.r file.

that is where the url decoding occurs.

There's no 'dehex there

but I remember having the same issue a while back and traced it to 
the actual datatype always handling the hex values.

I don't think it matters

yes, Max ..

just using the to-url created the same headaches... IIRC

Brian's issue is not a problem

That is exactly where it matters. That is the whole problem.

We can fix it without worrying about that part

That part is the only part that needs fixing.