Re: Linking against libjpeg ?


Subject: Re: Linking against libjpeg ?
From: Thomas Fletcher (thomasf@qnx.com)
Date: Wed Apr 18 2001 - 07:54:58 CDT


On Wed, 18 Apr 2001, Hubert Figuiere wrote:

> Thomas Fletcher écrit:
>
> > Where do we draw the line on what we load? I hate this
> > incremental "add this lib, add this lib, add this lib" since
> > we just get bigger and bigger and bigger. Having one
> > guaranteed format for import (png) and then using system
> > services (translators on BeOS, imaging library on QNX etc)
> > would be my recommendation. I know that we already have
> > BMP support finangled in there (the defacto windows standard,
> > what can I say about it) but it doesn't please me.
>
> BTW I'd like push for JPEG internal support. Why ? Just because I can't
> imagine manipulating JPEG photographies in PNG and store them as such.
> Having JPEG import within XP code is IMHO not a bad thing. BeOS as libjpeg
> built-in. Gnome build already links against LibJPEG (haven't cheked for
> GTK). So what is the problem ? Is it difficult for QNX ?
> So I'll have to make it a platform switch.
>
> On the otherside, I'm OK to make platform specific importers. For example,
> for the Mac port, I planned to do a QT Graphics importer. That would have
> brought dozen of picture format for free.

Hub,

  I don't mean to single you out on this. I personally don't
mind having JPEG as a native support for AbiWord, it isn't
difficult for QNX at all. My intention was to be that proding
voice that makes someone think twice about adding another
library dependancy for AbiWord. If we do this, I want libjpeg
to be in CVS so that one checkout gets us all that we need.
Again the other thing to consider, as someone (dom I think)
mentioned is that perhaps going the ImageMagic route with a
common API that then uses these same libs would be more worthwhile
(and also reduce our internal code bloat).
 
> > If I had a thing to say about it, I would say make it a
> > loadable module (and consequently make loadable modules
> > work properly) but don't force it to be present.
>
> Oh yes. I vote for this one, even if it costs me more time for the MacOS
> port. Dom provided some infrastructures. What are we waiting for this ?

We are waiting for someone to take a compelling first stab at
making these plugins a reality. Things that need to be considered
are:
- How do we identify where a plugin lives in the filesystem
- Do we support multiple locations?
- Do we scan continuously or load just once at startup?
- What plugins do we support and do they have a common API?
        - Importers/Exporters (yes on the API)
        - Image modules (no not currently)
        - Spelling modules (potentially with the new class)
- Will C++ name mangling kill us?
 
> > AbiWord ... 3M and growing fast
>
> I actually waste more than 30 Min each time I rebuild completely Abiword.
> And linking on my poor Linux laptop is over several minutes... in debug
> mode.

Yup ... and each library we add costs more both in time and
in space.

Thomas ... embedded developer cutting costs everyday!
-------------------------------------------------------------
Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Neutrino Development Group
(613)-591-0931 http://www.qnx.com/~thomasf



This archive was generated by hypermail 2b25 : Wed Apr 18 2001 - 07:55:25 CDT