How to convert number pairs into .grd file(w/o typing them all in)

Question

I want to be able to take a set of numbers (like coords from some shape), and use them to create a gradient file.
Example, I start w/file of:
x=0  , y=0 
x=1  , y=4 
x=2  , y=10
x=3  , y=18
x=4  , y=22
...50 lines elided...
x=75 , y=97
x=80 , y=98
x=84 , y=99
x=94 , y=100
where I would use the x as the x coord(duh), and 'y' as the 'height' of transparency
(or a brightness value that I'd combine with some desired color value to get an RGB value).
But in this simple case,
assume a a simple foregnd->backgrnd color (or any 2 color gradient @ 0 & 100), with only the transparency value needing
all the numbers ...)
(would be nice if I could just input a forumula...but.....)  barring that.. trying to figure out the .GRD
file format is proving to be a bit of a pain.
I notice lots of map-marker points like FE' (ala SVG FE function, ) values, references to doubles, etc...
but spending a bunch of time figuring out the file format seems like such a bother if it's already been done...
any scripts or tools to allow such conversions or am I stuck writing my own perl script...
(breaking it down w/vim wasn't too difficult subbing in <0> or <0000> for quads, etc...
going from that could see where numbers were wanted and convert those
to hex, <xx>;  At some point, given the 'FE' function I suspect I'll have to look up how floating point
is stored ... sigh.
See what I mean by a pain to write a script?)
Ideas/pointers?

Answer 1

   Odd, there was a response here by me, w/no content.   I don't remember posting 'nothing', rather than just delete it,  I thought I'd try to remember what I wrote at the time and see if it stays in the system this time.
Chris Cox wrote:
The gradient preset files are a sort of key/value pair system, but not really like XML (and are a heck of a lot faster to read and write than XML).
The file format is documented in the SDK, and has been for many years.
It's just a complex enough format that even most developers don't want to mess with it.
   Yes-- could see the key value pairs in the work I did.  that's were I found reference to a key with "FE"" in  it and thought it was related to the SVG function of the same name - as it is the gradient function in SVG, but you said above, that the FE key word in the binaries files had nothing to do with the gradient function that is in SVG by the same name (somehow I don't think you read what I was writing but sorta skimmed it.  My writing tends to alot more information in it than it appears (coincidentally, my posts tend to be longer than the average post), so it may not be that it contains more information than it _appears_, just more than the average post...and, as some may believe (not saying on the forum, but have encountered this on others)
   What is often true in writing about any topic is that, it is increasingly difficult to make my writing more concise while retaining precision -- especially if you are trying to be *clear*.  Too often, I find, that when I toss off quick notes, I'll lots of dumb looks <*huh?*? or responses (not responding to what I said) and I'll spend as much (usually more) clarifying or correcting misunderstandings, OR verifying that they were responding to or answering  was to something I actually 'said', rather than what it appeared (to me) that they were responding to.
   As for the bit about developers touching old code...that's common in almost every project...no one wants to touch something that is currently working, as even though they may be adding improvements or fixing a problem, it is certain they will change the code in a way that it doesn't behave precise as it did before (by definition, else why make changes?), and as a result, they may get complaints from some people who were using that code in some completely unexpected way which now breaks in the new code (even though the documented behavior may be unchanged).
   This is a major problem, since I have NEVER scene documentation that explains all the inter-relations and behaviors of a program, yet often, it is *expected* that people will use those undocumented interrelations to do anything other than the most basic functions.  Note -- by undocumented, I also include things that may be discerned via induction on the various pieces but are not  explicitly spelled out (thus open to 'reinterpretation' at some later point...).
   It seems, almost inherently, that they thorough documentation of code would be NOT just the code, but also design documents and notes -- which would not happen in almost any project (maybe a government funded security program), but would also be impractical as a an easy to use reference (I.e. that would need to be written as well).  As it is, some programs simply come with installation instructions and/or installation support.
   Anyway, hopefully, this answer will get posted and stay (don't know what happened to previous)...(failure in submission or bit-rot).
Astara