[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IDL 5.4. Neato. NOT.
In article <djboccip-6E662E.07013329102000@news2.mco.bellsouth.net>,
"Dennis J. Boccippio" <djboccip@bellsouth.net> wrote:
> Posting from home so as to forego the possibility that _our_ ODIN vendor
> will lose my post. In partial response to Joseph's issue (4) below:
>
> Q: Will 5.4's non-support of LZW (specifically, WRITE_GIF) balk at _any_
> routine named 'WRITE_GIF'? It strikes me that we, in theory, should be
> able to replace the built-in WRITE_GIF with our own code which, e.g.,
> calls WRITE_PNG, and then spawns a Unix process which converts the PNG
> to GIF using 3rd party tools, or an Applescript that calls
> GraphicConverter to do the same (I'm pretty sure GC is scriptable).
> Sorry, Windows folks, no idea how this would be done on that platform...
>
> Anyway, if this were possible, it'd be a one-time fix (for the write
> routines at least, although presumably the same could be done for
> reading) rather than a huge amount of code retooling...
>
> - Dennis Boccippio
>
> ( PS - can confirm that Mac GC is scriptable... I note the following
> entry in its AppleScript Dictionary:
>
> save reference [in alias] as [list of types, including GIF] makeCopy
> boolean
>
> On Un*x, the 'convert' command comes along with a package that I've
> forgotten - ImageMagick, or libppm, or something...)
That sounds like a good plan, and another reason we would be staying
with 5.3 for a while --- to test the new and old "WRITE_GIF" and
"READ_GIF" side by side for a while to see how close to indetical
results one could get before then trying to test the new one with 5.4.
I notice that the Mac OS QuickTime viewer no longer exports as GIF,
so I wonder how AppleScript is able to do so....
In any case, I'm certain there are ways to work around this, but in
the real world, any such implementation takes people's time, which means
money. In this case, money that Kodak will not be getting. Seems
shortsighted as a business decision to me --- but once again, we don't
have enough, er, insight into the process to know what Unisys demanded.