corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <j...@apache.org>
Subject Re: libxml2 and iconv question, do we really need iconv ?
Date Mon, 23 Mar 2015 14:45:02 GMT
On 23 March 2015 at 15:08, Peter Kelly <pmkelly@apache.org> wrote:

> > On 23 Mar 2015, at 7:13 pm, Franz de Copenhague <
> franzdecopenhague@outlook.com> wrote:
> >
> > dfwebserver  will need iconv or similar functionality to reduce the
> image resources resolution in documents to improve download performance in
> the client editor.
>
> iconv deals with character set conversion, not images; SDL_image does that.
>
But do we really need character set conversation ?

DocFormat does not use it directly, it is only linked to libxml2.

If I were to redo getImageDimension() we could remove SDL_image and SDL ?


>
> Currently we have SDL_image treated as a platform-dependent library, since
> we’re only using it for one purpose, which is to get the width and height
> of an image, and that is handled by the system-supplied ImageIO framework
> on OS X/iOS (I suspect there’s something similar on Windows as well). For
> image resizing, if that’s the only extra thing we need to do with images,
> we could probably implement both an SDL_image and ImageIO version of that
> as well. If we’re going to be doing more extensive image manipulation, I
> think it would be better to rely on one library (that is, use SDL_image on
> Apple platforms as well as others).
>
> Note of course that dfwebserver could have dependencies on SDL or another
> library (e.g. ImageMagick - either linked against it or calling out to
> separate processes). Library functionality used only by dfwebserver doesn’t
> necessarily have to be depended on by DocFormats itself.
>
+1

rgds
jan i

>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message