-
1. Re: How to convert number pairs into .grd file(w/o typing them all in)
Chris Cox Sep 12, 2011 3:20 PM (in response to Astara_)The Gradient preset format is binary, and not easy to decipher.
No, it has nothing to do with SVG.
No, I don't know of any tools that can do what you describe with Photoshop gradient presets.
-
2. Re: How to convert number pairs into .grd file(w/o typing them all in)
Astara_ Sep 12, 2011 3:35 PM (in response to Chris Cox)In CS5, it looks more like XML without the <> and the values encoded in binary. I don't remember if it was in .grd, or another
file value, but they looked like datatypes with type information had been curried out from mem into a file. It wasn't
real complex.
The FE function was one I just remembered the name of in SVG...It's for specifying gradient values in SVG, that it would
be included in a gradient file wouldn't be a great surprise.
Simply being told it's not possible isn't exactly the type of helpful answer I was looking for...*sigh*...
Oh...you're an employee...er, of course I'd never look inside file types to try to do anything compatible with Adobe's stuff..
uh uh!...Geez! does it take a lawsuit like MS went through to make you open up your formats for 3rd party tool compat?
I'd think Adobe would be better than that...
-
3. Re: How to convert number pairs into .grd file(w/o typing them all in)
Chris Cox Sep 12, 2011 3:57 PM (in response to Astara_)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.
-
4. Re: How to convert number pairs into .grd file(w/o typing them all in)
Astara_ Nov 14, 2011 11:47 AM (in response to Chris Cox)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



