Re: image support (was Re: Core-dump during startup on AIX-4.3.2)


Subject: Re: image support (was Re: Core-dump during startup on AIX-4.3.2)
From: Paul Rohr (paul@abisource.com)
Date: Fri Mar 03 2000 - 12:29:53 CST


At 08:07 AM 3/3/00 GMT, Caolan McNamara wrote:
>For what it is worth Microsoft Word converts all gifs that are
>imported into it to
>png files and works with that instead. This is the reason that wv
>exports png files from word documents. I don't know if they have any
>license driven reason behind it though.

That's a relief. Does anyone know how WordPerfect stores its raster images?
If they avoid storing GIFs, too, we may be all set.

>I would be concerned though to see abi rip the
>code out of all the libraries and rewrite its own interface and set of
>import entities. I suspect that it increases the amount of maintaining
>that is required. Using an existing library gets you your bug fixes to
>the original code fixed for you for free, adding in the code to my
>mind will cause a spiraling amount of work just to remain up to date
>with the originals. Maybe I over estimate the problem.

I totally agree. I didn't mean to suggest that we rip code *out* of
libjpeg, etc. Gack! Forking like that would be shooting ourselves in the
foot. The only reason to touch that code is if we have to do something to
get it to build.

The only AbiWord-specific APIs I'm talking about are a lightweight set of
wrapper classes that give us a common API for converting arbitrary image
formats to PNG.

There'd be two kinds of implementations for these classes, both of which
should be very lightweight:

  - a thin XP layer which drives, say libjpeg to do the job, or
  - a thin platform-specific layer which makes OS-specific calls

Each platform can decide which mix of converter implementations is
appropriate, and adjust their makefiles according. As far as the rest of
AbiWord is concerned, we just call a converter factory to get an instance of
some converter class and use that abstract interface to perform the
conversion.

This is the "switching mechanism" I've been referring to, and as Justin
says, it's just not that hard. All we need to do is decide on the APIs and
the rest is easy.

Anybody want to take a whack at this?

Paul



This archive was generated by hypermail 2b25 : Fri Mar 03 2000 - 12:24:26 CST