Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
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 ? Vincent > + > +Possible fun ones: > + > + MPG/AVI/OGV/MOV/MKV/WMV etc. > +(use gstreamer and/or libxine or libvlc and snap one frame from the > + middle somewhere) > + PPT/PPTX > +(beats me how u can render a page from these without a whole > + office impl - but worth a try? libopenoffice/libllibreoffice if > + it ever happens?) > > > -- > 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-svn mailing list > enlightenment-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn > > -- 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Tue, Apr 26, 2011 at 9:54 AM, Vincent Torri wrote: > 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 ? Complete integration with evas cache and preload infrastructure. Should be easier to maintain it. -- Cedric BAIL -- 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Tue, 26 Apr 2011, Cedric BAIL wrote: On Tue, Apr 26, 2011 at 9:54 AM, Vincent Torri wrote: 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 ? Complete integration with evas cache and preload infrastructure. Should be easier to maintain it. so there is no interest to develop eyesight anymore 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Tue, 26 Apr 2011 09:54:53 +0200 (CEST) Vincent Torri 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/README2011-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. > Vincent > > > + > > +Possible fun ones: > > + > > + MPG/AVI/OGV/MOV/MKV/WMV etc. > > +(use gstreamer and/or libxine or libvlc and snap one frame from the > > + middle somewhere) > > + PPT/PPTX > > +(beats me how u can render a page from these without a whole > > + office impl - but worth a try? libopenoffice/libllibreoffice if > > + it ever happens?) > > > > > > -- > > 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-svn mailing list > > enlightenment-...@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn > > > > > > -- > 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 > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Tue, 26 Apr 2011 09:58:36 +0200 Cedric BAIL said: > On Tue, Apr 26, 2011 at 9:54 AM, Vincent Torri wrote: > > 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 ? > > Complete integration with evas cache and preload infrastructure. > Should be easier to maintain it. actually the generic loader right now is single stage - no preload vs data. its all load at once, so this means that it's going to be useless for async preload until i change some of it. i just got it working, so give me a breather. :) i got the first external loader working. :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Tue, Apr 26, 2011 at 10:02 AM, Vincent Torri wrote: > On Tue, 26 Apr 2011, Cedric BAIL wrote: >> On Tue, Apr 26, 2011 at 9:54 AM, Vincent Torri >> wrote: >>> >>> 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 ? >> >> Complete integration with evas cache and preload infrastructure. >> Should be easier to maintain it. > > so there is no interest to develop eyesight anymore I may be wrong, but it would not be possible to expose all the chapter, link, page, and other contextual information that a pdf/ps do have. That why we still need eyesight (it would also provide the binary that would load the pdf/ps stuff). It's a source of simplification in my opinion, not a replacement. -- Cedric BAIL -- 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Tue, 26 Apr 2011 10:20:53 +0200 Cedric BAIL said: > On Tue, Apr 26, 2011 at 10:02 AM, Vincent Torri wrote: > > On Tue, 26 Apr 2011, Cedric BAIL wrote: > >> On Tue, Apr 26, 2011 at 9:54 AM, Vincent Torri > >> wrote: > >>> > >>> 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 ? > >> > >> Complete integration with evas cache and preload infrastructure. > >> Should be easier to maintain it. > > > > so there is no interest to develop eyesight anymore > > I may be wrong, but it would not be possible to expose all the > chapter, link, page, and other contextual information that a pdf/ps do > have. That why we still need eyesight (it would also provide the > binary that would load the pdf/ps stuff). It's a source of > simplification in my opinion, not a replacement. correct. the generic loader mechanism is not a replacement. it's a "i want to just load page x in the pdf and i am uninterested in yet another library and an api to deal with as i need none of those features for just rendering a THUMBNAIL of the pdf". for example. for doing a real pdf viewer u need all the info. bu no means meant to kill off or replace epdf and friends. BUT... people need the ability to load a pdf as an image, and not make their generic "i display images" app gpl because of it. they lose functionality (chapters, links, references and other things) but gain simplistic functionality. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Tue, 26 Apr 2011, Carsten Haitzler (The Rasterman) wrote: > On Tue, 26 Apr 2011 09:54:53 +0200 (CEST) Vincent Torri > 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/README2011-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) 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...) Vincent > >> Vincent >> >>> + >>> +Possible fun ones: >>> + >>> + MPG/AVI/OGV/MOV/MKV/WMV etc. >>> +(use gstreamer and/or libxine or libvlc and snap one frame from the >>> + middle somewhere) >>> + PPT/PPTX >>> +(beats me how u can render a page from these without a whole >>> + office impl - but worth a try? libopenoffice/libllibreoffice if >>> + it ever happens?) >>> >>> >>> -- >>> 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-svn mailing list >>> enlightenment-...@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn >>> >>> >> >> -- >> 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 >> > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > -- 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Wed, 27 Apr 2011 09:57:30 +0200 (CEST) Vincent Torri said: > On Tue, 26 Apr 2011, Carsten Haitzler (The Rasterman) wrote: > > > On Tue, 26 Apr 2011 09:54:53 +0200 (CEST) Vincent Torri > > 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. > 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. :) > Vincent > > > > >> Vincent > >> > >>> + > >>> +Possible fun ones: > >>> + > >>> + MPG/AVI/OGV/MOV/MKV/WMV etc. > >>> +(use gstreamer and/or libxine or libvlc and snap one frame from the > >>> + middle somewhere) > >>> + PPT/PPTX > >>> +(beats me how u can render a page from these without a whole > >>> + office impl - but worth a try? libopenoffice/libllibreoffice if > >>> + it ever happens?) > >>> > >>> > >>> -- > >>> 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-svn mailing list > >>> enlightenment-...@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn > >>> > >>> > >> > >> -- > >> 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 > >> > > > > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > > > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- WhatsUp Gold - Download Free Network Management Software The most intuitive, compreh
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Wed, 27 Apr 2011, Carsten Haitzler (The Rasterman) wrote: > On Wed, 27 Apr 2011 09:57:30 +0200 (CEST) Vincent Torri > said: > >> On Tue, 26 Apr 2011, Carsten Haitzler (The Rasterman) wrote: >> >>> On Tue, 26 Apr 2011 09:54:53 +0200 (CEST) Vincent Torri >>> 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Wed, 27 Apr 2011 11:17:07 +0200 (CEST) Vincent Torri said: > > > On Wed, 27 Apr 2011, Carsten Haitzler (The Rasterman) wrote: > > > On Wed, 27 Apr 2011 09:57:30 +0200 (CEST) Vincent Torri > > said: > > > >> On Tue, 26 Apr 2011, Carsten Haitzler (The Rasterman) wrote: > >> > >>> On Tue, 26 Apr 2011 09:54:53 +0200 (CEST) Vincent Torri > >>> 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/README2011-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. no. if you link, then both the code and data for the GPL stuff shares the memory space of the rest of the lib (evas) and thus also the app using evas. thus.. GPL leaks through. as a separate process that dumps dumb data into a temporary file (that it mmaps - be it a shm "file" or a real one) or a pipe/stream, then they share no memory space with the app. > >> 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). can do - that.. once it becomes useful to do it. ie.. when there is > 1 binary :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Wed, 2011-04-27 at 19:49 +0900, Carsten Haitzler wrote: > no. if you link, then both the code and data for the GPL stuff shares the > memory space of the rest of the lib (evas) and thus also the app using evas. > thus.. GPL leaks through. as a separate process that dumps dumb data into a > temporary file (that it mmaps - be it a shm "file" or a real one) or a > pipe/stream, then they share no memory space with the app. I hate GPL (for libs). -- Tom. -- 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Wed, 27 Apr 2011 13:50:39 +0300 Tom Hacohen said: > On Wed, 2011-04-27 at 19:49 +0900, Carsten Haitzler wrote: > > no. if you link, then both the code and data for the GPL stuff shares the > > memory space of the rest of the lib (evas) and thus also the app using evas. > > thus.. GPL leaks through. as a separate process that dumps dumb data into a > > temporary file (that it mmaps - be it a shm "file" or a real one) or a > > pipe/stream, then they share no memory space with the app. > > I hate GPL (for libs). that's why the generic loader mechanism executes a binary. yet its not efficient. yes its kind of hacky - its the only solution to 1. thing to do the decoding is GPL and u dont want a license leak into an app and 2. thing that decodes may leak memory and/or crash, so you need to isolate it into its own process so it can crash that sometimes without bringing your main app down with it. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Wed, 27 Apr 2011, Carsten Haitzler (The Rasterman) wrote: > On Wed, 27 Apr 2011 11:17:07 +0200 (CEST) Vincent Torri > said: > >> >> >> On Wed, 27 Apr 2011, Carsten Haitzler (The Rasterman) wrote: >> >>> On Wed, 27 Apr 2011 09:57:30 +0200 (CEST) Vincent Torri >>> said: >>> On Tue, 26 Apr 2011, Carsten Haitzler (The Rasterman) wrote: > On Tue, 26 Apr 2011 09:54:53 +0200 (CEST) Vincent Torri > 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/README2011-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. > > no. if you link, then both the code and data for the GPL stuff shares the > memory space of the rest of the lib (evas) and thus also the app using evas. > thus.. GPL leaks through. as a separate process that dumps dumb data into a > temporary file (that it mmaps - be it a shm "file" or a real one) or a > pipe/stream, then they share no memory space with the app. ok 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). > > can do - that.. once it becomes useful to do it. ie.. when there is > 1 > binary :) pdf, dvi, ps djvu. 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Wed, 27 Apr 2011 20:00:31 +0900 Carsten Haitzler (The Rasterman) wrote: > On Wed, 27 Apr 2011 13:50:39 +0300 Tom Hacohen > said: > > > On Wed, 2011-04-27 at 19:49 +0900, Carsten Haitzler wrote: > > > no. if you link, then both the code and data for the GPL stuff > > > shares the memory space of the rest of the lib (evas) and thus > > > also the app using evas. thus.. GPL leaks through. as a separate > > > process that dumps dumb data into a temporary file (that it mmaps > > > - be it a shm "file" or a real one) or a pipe/stream, then they > > > share no memory space with the app. > > > > I hate GPL (for libs). > > that's why the generic loader mechanism executes a binary. yet its not > efficient. yes its kind of hacky - its the only solution to > > 1. thing to do the decoding is GPL and u dont want a license leak > into an app and I'm finding it ironic that a license allegedly all about preserving freedom, tends to take away the freedom to link. > 2. thing that decodes may leak memory and/or crash, so you need to > isolate it into its own process so it can crash that sometimes > without bringing your main app down with it. That's a good reason though. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Wed, Apr 27, 2011 at 2:00 PM, Carsten Haitzler wrote: > 1. thing to do the decoding is GPL and u dont want a license leak into an > app > and > Yes, that's what I hate. > 2. thing that decodes may leak memory and/or crash, so you need to isolate > it > into its own process so it can crash that sometimes without bringing your > main > app down with it. > This was my argument when I talked about implementing efm outside of e itself. Given this rationale we should split a lot more than we currently do, and evas itself is probably not the best place to start at :) But yeah, reason #1 is good enough and that's why I hate GPL (for libs), forcing us to do such awful things just to avoid evilness. -- Tom. -- 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Thu, 28 Apr 2011 06:39:01 +1000 David Seikel said: > On Wed, 27 Apr 2011 20:00:31 +0900 Carsten Haitzler (The Rasterman) > wrote: > > > On Wed, 27 Apr 2011 13:50:39 +0300 Tom Hacohen > > said: > > > > > On Wed, 2011-04-27 at 19:49 +0900, Carsten Haitzler wrote: > > > > no. if you link, then both the code and data for the GPL stuff > > > > shares the memory space of the rest of the lib (evas) and thus > > > > also the app using evas. thus.. GPL leaks through. as a separate > > > > process that dumps dumb data into a temporary file (that it mmaps > > > > - be it a shm "file" or a real one) or a pipe/stream, then they > > > > share no memory space with the app. > > > > > > I hate GPL (for libs). > > > > that's why the generic loader mechanism executes a binary. yet its not > > efficient. yes its kind of hacky - its the only solution to > > > > 1. thing to do the decoding is GPL and u dont want a license leak > > into an app and > > I'm finding it ironic that a license allegedly all about preserving > freedom, tends to take away the freedom to link. it's the WAY gpl defined what is a derivate that is a problem. an app that someone decided to license under BSD, or make closed that just uses a public api provided and encouraged to be used (like evas) should not (imho) be forced into an unwanted licensing decision for their app or software. that's their decision. but if indirectly some deep down component of this lib causes their app to HAVE to become GPL, then that's not preserving freedom. that's "freedom in our way only". i'm not going to make evas do that. a generic loader that can just blindly execute some binary that happens to have the right name avoids that problem entirely. we've separated out the license problem. that specific loader binary and all its derivative works become GPL. but that's as far as that goes. > > 2. thing that decodes may leak memory and/or crash, so you need to > > isolate it into its own process so it can crash that sometimes > > without bringing your main app down with it. > > That's a good reason though. both are good reasons. without #1 we will NOT be getting a RAW loader, not XCF loader, nor PDF, and so on. we can now have them, but at a performance price. these are not common enough to be an issue, so it doesn't much matter :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Wed, 27 Apr 2011 14:06:59 +0200 (CEST) Vincent Torri said: > > can do - that.. once it becomes useful to do it. ie.. when there is > 1 > > binary :) > > pdf, dvi, ps djvu. once someone starts another blob of src for another binary loader.. it can be put into common shared code. it doesn't actually have to be a lib.a - it can just be the same c file included in both src lists. simpler :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Fri, 29 Apr 2011, Carsten Haitzler (The Rasterman) wrote: > On Wed, 27 Apr 2011 14:06:59 +0200 (CEST) Vincent Torri > said: > >>> can do - that.. once it becomes useful to do it. ie.. when there is > 1 >>> binary :) >> >> pdf, dvi, ps djvu. > > once someone starts another blob of src for another binary loader.. it can be > put into common shared code. it doesn't actually have to be a lib.a - it can > just be the same c file included in both src lists. simpler :) why doing simple things ? :p You're right :) 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Fri, 29 Apr 2011 08:02:12 +0200 (CEST) Vincent Torri said: > > > On Fri, 29 Apr 2011, Carsten Haitzler (The Rasterman) wrote: > > > On Wed, 27 Apr 2011 14:06:59 +0200 (CEST) Vincent Torri > > said: > > > >>> can do - that.. once it becomes useful to do it. ie.. when there is > 1 > >>> binary :) > >> > >> pdf, dvi, ps djvu. > > > > once someone starts another blob of src for another binary loader.. it can > > be put into common shared code. it doesn't actually have to be a lib.a - it > > can just be the same c file included in both src lists. simpler :) > > why doing simple things ? :p You're right :) because... je ne suis pas francais! :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Fri, 29 Apr 2011, Carsten Haitzler (The Rasterman) wrote: > On Wed, 27 Apr 2011 14:06:59 +0200 (CEST) Vincent Torri > said: > >>> can do - that.. once it becomes useful to do it. ie.. when there is > 1 >>> binary :) >> >> pdf, dvi, ps djvu. > > once someone starts another blob of src for another binary loader.. it can be > put into common shared code. it doesn't actually have to be a lib.a - it can > just be the same c file included in both src lists. simpler :) I'm still wondering aboutefficiency : for example, for pdf rendering, shouldn't the use of a pdf generic loader be slower than wht i can achieve in eyesight ? 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Fri, 29 Apr 2011 11:58:43 +0200 (CEST) Vincent Torri said: > > > On Fri, 29 Apr 2011, Carsten Haitzler (The Rasterman) wrote: > > > On Wed, 27 Apr 2011 14:06:59 +0200 (CEST) Vincent Torri > > said: > > > >>> can do - that.. once it becomes useful to do it. ie.. when there is > 1 > >>> binary :) > >> > >> pdf, dvi, ps djvu. > > > > once someone starts another blob of src for another binary loader.. it can > > be put into common shared code. it doesn't actually have to be a lib.a - it > > can just be the same c file included in both src lists. simpler :) > > I'm still wondering aboutefficiency : for example, for pdf rendering, > shouldn't the use of a pdf generic loader be slower than wht i can achieve > in eyesight ? rendering-wise, no, but the fact that it has to execute a whole new process will slow it down, not to mention that if you want to access > 1 page, ot needs to keep opening and re-parsing the file to find the page you want. it's not meant for efficiency. it's meant to not force gpl on people who simply want to load an image (that happens to be a pdf). this makes ethumb instantly able to thumbnail pdf's for example. as i said - sure. not efficient, but works. not for the purpose of making a pdf viewer or embedding pdf docs in an app where u want content inspection and control. just for dumb "load me page x" from pdf. or ps. or xfc.gz, ro for our always crashing svg loader... -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Fri, Apr 29, 2011 at 11:58:43AM +0200, Vincent Torri wrote: > I'm still wondering aboutefficiency : for example, for pdf rendering, > shouldn't the use of a pdf generic loader be slower than wht i can achieve > in eyesight ? Only if you fork once per page or something like that. Give it a minimal input processing like Ghostscript's X11 target and the overhead is going to mostly vanish. E.g. "open", "render $page $resolution" "close" should be good enough for most purposes. Joerg -- 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Fri, 29 Apr 2011 17:26:23 +0200 Joerg Sonnenberger said: > On Fri, Apr 29, 2011 at 11:58:43AM +0200, Vincent Torri wrote: > > I'm still wondering aboutefficiency : for example, for pdf rendering, > > shouldn't the use of a pdf generic loader be slower than wht i can achieve > > in eyesight ? > > Only if you fork once per page or something like that. Give it a minimal > input processing like Ghostscript's X11 target and the overhead is going > to mostly vanish. E.g. "open", "render $page $resolution" "close" should > be good enough for most purposes. the generic loader does fork once.. actually it forks AND execs TWICE per load (once for header, once for body). -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Sat, 30 Apr 2011, Carsten Haitzler (The Rasterman) wrote: > On Fri, 29 Apr 2011 17:26:23 +0200 Joerg Sonnenberger > > said: > >> On Fri, Apr 29, 2011 at 11:58:43AM +0200, Vincent Torri wrote: >>> I'm still wondering aboutefficiency : for example, for pdf rendering, >>> shouldn't the use of a pdf generic loader be slower than wht i can achieve >>> in eyesight ? >> >> Only if you fork once per page or something like that. Give it a minimal >> input processing like Ghostscript's X11 target and the overhead is going >> to mostly vanish. E.g. "open", "render $page $resolution" "close" should >> be good enough for most purposes. > > the generic loader does fork once.. actually it forks AND execs TWICE per load > (once for header, once for body). if one has to parse the file for each display of a page, then it's definitely not the way to use for a document viewer. It can indeed be good for thumbnailing, like an icon on the desktop or in a file viewer. 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders
On Sat, 30 Apr 2011 08:09:05 +0200 (CEST) Vincent Torri said: > > > On Sat, 30 Apr 2011, Carsten Haitzler (The Rasterman) wrote: > > > On Fri, 29 Apr 2011 17:26:23 +0200 Joerg Sonnenberger > > said: > > > >> On Fri, Apr 29, 2011 at 11:58:43AM +0200, Vincent Torri wrote: > >>> I'm still wondering aboutefficiency : for example, for pdf rendering, > >>> shouldn't the use of a pdf generic loader be slower than wht i can achieve > >>> in eyesight ? > >> > >> Only if you fork once per page or something like that. Give it a minimal > >> input processing like Ghostscript's X11 target and the overhead is going > >> to mostly vanish. E.g. "open", "render $page $resolution" "close" should > >> be good enough for most purposes. > > > > the generic loader does fork once.. actually it forks AND execs TWICE per > > load (once for header, once for body). > > if one has to parse the file for each display of a page, then it's > definitely not the way to use for a document viewer. It can indeed be good > for thumbnailing, like an icon on the desktop or in a file viewer. thats exactly what i keep saying. it's NOT meant to replace epdf/eyesight etc. etc. - it's a quick way to do a preview app (eg in efm), thumbnails and n image viewer than can also manage to look at pdf's etc. as a added bonus, but it's not optimal. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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
Re: [E-devel] E SVN: raster trunk/evas_generic_loaders/src/bin/pdf
On Fri, 13 May 2011, Enlightenment SVN wrote:
> Log:
> fix pdf loader to
>
> 1. handle load options for dpi and load size
> 2. handle pdf crop region properly
> 3. handle landscape oriented pdf's properly and render right.
>
>
>
> Author: raster
> Date: 2011-05-13 00:45:22 -0700 (Fri, 13 May 2011)
> New Revision: 59362
> Trac: http://trac.enlightenment.org/e/changeset/59362
>
> Modified:
> trunk/evas_generic_loaders/src/bin/pdf/main.cpp
>
> Modified: trunk/evas_generic_loaders/src/bin/pdf/main.cpp
> ===
> --- trunk/evas_generic_loaders/src/bin/pdf/main.cpp 2011-05-13 06:10:13 UTC
> (rev 59361)
> +++ trunk/evas_generic_loaders/src/bin/pdf/main.cpp 2011-05-13 07:45:22 UTC
> (rev 59362)
> @@ -31,15 +31,18 @@
> SplashOutputDev *output_dev;
>
> ::Page *page;
> -int width = 0;
> -int height = 0;
> -void *data;
> +int width = 0, height = 0;
> +int crop_width = 0, crop_height = 0;
> +void *data = NULL;
> +double dpi = -1.0;
>
> static int shm_fd = -1;
> static int shm_size = 0;
> static void *shm_addr = NULL;
> static char shmfile[1024] = "";
>
> +#define DEF_DPI 72.0
> +
> static void
> shm_alloc(int dsize)
> {
> @@ -93,10 +96,12 @@
>shm_fd = -1;
> }
>
> -Eina_Bool poppler_init(const char *file, int page_nbr, double dpi, int
> size_w, int size_h)
> +Eina_Bool poppler_init(const char *file, int page_nbr, int size_w, int
> size_h)
> {
>Object obj;
>SplashColor white;
> + double w, h, cw, ch;
> + int rot;
>
>if (!file || !*file)
> return EINA_FALSE;
> @@ -131,42 +136,49 @@
>if (!page || !page->isOk())
> goto del_pdfdoc;
>
> - width = page->getMediaWidth();
> - height = page->getMediaHeight();
> -
> + w = page->getMediaWidth();
> + h = page->getMediaHeight();
> + cw = page->getCropWidth();
> + ch = page->getCropHeight();
> + rot = page->getRotate();
> + if (cw > w) cw = w;
> + if (ch > h) ch = h;
> + if ((rot == 90) || (rot == 270))
> + {
> +double t;
> +// swap width & height
> +t = w; w = h; h = t;
> +// swap crop width & height
> +t = cw; cw = ch; ch = t;
> + }
> +
>if ((size_w > 0) || (size_h > 0))
> {
> -/* FIXME: tell poller to render at the new width and height
> -unsigned int w2 = width, h2 = height;
> -if (size_w > 0)
> +double w2 = cw, h2 = ch;
> +
> +w2 = size_w;
> +h2 = (size_w * ch) / cw;
> +if (h2 > size_h)
> {
> - w2 = size_w;
> - h2 = (size_w * h) / w;
> - if ((size_h > 0) && (h2 > size_h))
> - {
> - unsigned int w3;
> - h2 = size_h;
> - w3 = (size_h * w) / h;
> - if (w3 > w2)
> - w2 = w3;
> - }
> - }
> -else if (size_h > 0)
> - {
> h2 = size_h;
> - w2 = (size_h * w) / h;
> + w2 = (size_h * cw) / ch;
> }
> -width = w2;
> -height = h2;
> - */
> +D("x %3.3fx%3.3f\n", w2, h2);
> +if (w2 > h2) dpi = (w2 * DEF_DPI) / cw;
> +else dpi = (h2 * DEF_DPI) / ch;
> }
> - else if (dpi > 0.0)
> +
> + if (dpi > 0.0)
> {
> -/* FIXME: tell poppler to render at this size
> -width = (width * dpi) / 72.0;
> -height = (height * dpi) / 72.0;
> - */
> +cw = (cw * dpi) / DEF_DPI;
> +ch = (ch * dpi) / DEF_DPI;
> +w = (w * dpi) / DEF_DPI;
> +h = (h * dpi) / DEF_DPI;
> }
> + width = w;
> + height = h;
> + crop_width = cw;
> + crop_height = ch;
>
>return EINA_TRUE;
>
> @@ -185,11 +197,13 @@
>delete globalParams;
> }
>
> -void poppler_load_image(double dpi, int size_w, int size_h)
> +void poppler_load_image(int size_w, int size_h)
> {
>SplashOutputDev *output_dev;
>SplashColor white;
>SplashColorPtr color_ptr;
> + DATA32 *src, *dst;
> + int y;
>
>white[0] = 255;
>white[1] = 255;
> @@ -202,19 +216,25 @@
>
>output_dev->startDoc(pdfdoc->getXRef());
>
> - if (dpi <= 0.0) dpi = 72.0;
> + if (dpi <= 0.0) dpi = DEF_DPI;
>
> - page->display(output_dev,
> - dpi, dpi, 0,
> - false, false, false,
> - pdfdoc->getCatalog());
> + page->displaySlice(output_dev, dpi, dpi,
> + 0, false, false,
> + 0, 0, width, height,
> + false, pdfdoc->getCatalog());
would it be possible to know whether or not one has to crop ? ::display()
is faster than ::displaySlice() (and we would just do a memcpy below, and
not a loop).
Vincent
>color_ptr = output_dev->getBitmap()->getDataPtr();
>
> - shm_alloc(width * height * sizeof(DATA32));
> - if (!shm_addr)
> - goto del_outpput_dev;
> + shm_alloc(crop_width * crop_height
