On Wednesday, 27 May 1998, at 13:41:20 (-0400),
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> but to gain transparency out of all these formats all must be native.
I agree. But to gain transparency alone, you just need one.
> Go fix gimp's script-fu to save png's and I woudl ahve used png for the
> onyl fnlib font around right now. So that font is in TIFF format, thsu
> u need native tiff loading. E's current theme uses PNG's due to the
> open standard, good libpng support etc. thus u need native png support.
> native jpeg supprt is a matter of sheer sanity. you will get, if you
> use the latest imagemagick, about a factor of 20-50 times faster jpeg
> loading useing libjpeg. Now dont' tell me nto to require it. I'm sick
> to death of lame idiots saying "E's slow.. it sux" when they use the
> most obfusicated loading methods becuase they simply are too lazy to
> install a library that is a one-line command for most Linxu systems and
> isn't much trouble with other unicies.
If people expect blazing speed when using IM or NetPBM, they're crazy.
But if, for example, I don't use GIF's in my theme and don't have
libgif, why should E/Imlib not work without it?
> This way you now have a choice - you can use XPM, PNG, GIF or TIFF
> files for transparent parts, and all these formats plus BMP and JPEG
> aswell - all natively, for "flat" images.
I agree that E/Imlib should offer support for all those libraries. My
only point is that it should be compileable without them, with the
general caveats about speed.
> We aren't... nto form Imlib. It will still soldier on.. but E will
> require the full compliement.. thus you will need to go back to zero
> and re-compile imlib and everything else using it to link to all the
> libs.
Well that's different. As long as Imlib can be compiled without one
or more of the libs, I'm happy. (I don't believe it can be at this
point, but I haven't tried since Imlib 1.1.) I'm just saying that
one should be able to use Imlib without E, so Imlib should not be
bound by E's requirements.
> Imlib still will enable and disbale native loaders if the libs are
> found. that will not change, but E will stolidly refuse to compile
> aunless u have all the libs. It doesn't matter what Eterm does or
> doesn't do. Thus to get E running you will need to go get all the libs
> - recompile Imlib, recompile all apps linkign to imlib to link to all
> the new libs tand then compile E. Fnlib and E require native
> transparency. The brain-dead method used by windows and libXpm of
> having "just one format" is stupid to the extreme. I let people chose
> their format as a matter of convenience.
I don't disagree for a moment. It's certainly not forward-thinking
to put off the inevitable, but shouldn't that be the user's right?
I personally think that XTerm's scrollbar blows chunks, but I will
continue to code (and patch, if necessary) Eterm to support it.
To paraphrase Voltaire, I may think they're a complete idiot for doing
it another way, but I'll defend to the death their right to do it.
Michael
--
"Ivanova is always right. I will listen to Ivanova. I will not
ignore Ivanova's recommendations. Ivanova is God...and if this
ever happens again, Ivanova will personally rip your lungs out."
-- Claudia Christian (Lt. Cmdr Susan Ivanova), Babylon Five
=======================================================================
Michael Jennings http://www.tcserv.com/ <[EMAIL PROTECTED]>
Associate Tech Services Analyst I, Vencor IS http://www.vencor.com/
-
To unsubscribe from this list send mail to: [EMAIL PROTECTED]
with the message contents: unsubscribe e-develop
