On Wed, 27 Apr 2011, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 27 Apr 2011 09:57:30 +0200 (CEST) Vincent Torri <vto...@univ-evry.fr> > said: > >> On Tue, 26 Apr 2011, Carsten Haitzler (The Rasterman) wrote: >> >>> On Tue, 26 Apr 2011 09:54:53 +0200 (CEST) Vincent Torri >>> <vto...@univ-evry.fr> said: >>> >>>> >>>> >>>> On Tue, 26 Apr 2011, Enlightenment SVN wrote: >>>> >>>>> Log: >>>>> some readme fun >>>>> >>>>> >>>>> >>>>> Author: raster >>>>> Date: 2011-04-26 00:46:01 -0700 (Tue, 26 Apr 2011) >>>>> New Revision: 58922 >>>>> Trac: http://trac.enlightenment.org/e/changeset/58922 >>>>> >>>>> Modified: >>>>> trunk/evas_generic_loaders/README >>>>> >>>>> Modified: trunk/evas_generic_loaders/README >>>>> =================================================================== >>>>> --- trunk/evas_generic_loaders/README 2011-04-26 07:29:30 UTC (rev >>>>> 58921) +++ trunk/evas_generic_loaders/README 2011-04-26 07:46:01 >>>>> UTC (rev 58922) @@ -1,2 +1,27 @@ >>>>> Additional "generic" loaders for Evas that are stand-alone executables >>>>> -evas may run from its generic loader module >>>>> +evas may run from its generic loader module. >>>>> + >>>>> +Generic loaders currently provided: >>>>> + >>>>> + XCF (.xcf .xcf.gz) >>>>> + >>>>> +Wanted: >>>>> + >>>>> + RAW >>>>> + (libopenraw1 ??) >>>>> + PDF >>>>> + (use -key option to specific what page to get and load options for >>>>> size >>>>> + and use poppler and/or mupdf - look at epdf) >>>>> + PS >>>>> + (use -key option to specific what page to get and load options for >>>>> size >>>>> + and use ghostscript (libgs) to render etc.) >>>> >>>> what is the interest compared to eyesight/epdf/eps ? >>> >>> trivial thumbnailing. not intended for full ps/pdf control. also to avoid >>> the gpl issue in epdf. you could have a loader use evas itself and epdf >>> etc. if u wanted. it'd work. use buffer engine and render to memory. i'm >>> not that fussed really. >> >> I've looked a bit at the xcf code. Why are you doing a binary and not a >> lib ? (having an init, shutdown, head and data functions) > > 1. its the old xcf loader code from imlib2_loaders, so its inheriting fluff > 2. GPL. making it a lib makes it a GPL lib and anything linking to it becomes > GPL. making an executable avoids the GPL problem. thats WHY i mentioned PDF > and > PS - epdf has a GPL problem. i thought that with shm_open, we could avoid that problem, even with a lib. But it seems it's not the case. >> Also, maybe you could add a library that implment common code. I think >> about shm_alloc and shm_free, that are (almost) not related to the loader. >> (shm_alloc needs the name of the loader, and one would have to apss a >> pointer for the stored values like shm_fd, etc...) > > when/if time permits. right now there is just 1 binary there. when there are 2 > i might make the code common and compiled into both. there is little point for > a shared lib at this stage as the shared code is infinitesimal and any savings > in not duplicating it are lost in multiple separate pages for the code and > symbols and so on. :) not a shared lib. a static lib (a .la, which is not installed, and we link against it, like we do with sub parts of evas for example). Vincent ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
