Re: [poppler] Example travis configuration file for poppler

[jose.ali...@gmail.com]

Hi,

On Mon, Feb 12, 2018 at 6:57 PM, Albert Astals Cid  wrote:

> El dilluns, 12 de febrer de 2018, a les 16:03:35 CET, Jeroen Ooms va
> escriure:
> > We have been working on a .travis configuration file to automatically
> > test poppler feature branches on various linux and osx configurations.
> > Perhaps this may be interesting to other poppler users as well.
> >
> > The example ".travis.yml" file can be copied from:
> > https://github.com/jeroen/poppler/blob/travis/.travis.yml (example
> > results: https://travis-ci.org/jeroen/poppler). Github users can
> > active the CI up by adding the .travis.yml file to the root of the
> > poppler source directory, and then login to travis.com and activate
> > the switch for the poppler source repository.
>
> I don't think promoting a non free platform on the official poppler
> repository
> makes sense.
>
> I'm running travis on my non official poppler mirror
> https://travis-ci.org/tsdgeos/poppler_mirror
> as you obviously know since you're using my packages.
>
> I'll see if i adopt your mac parts.
>
> Is there other ways of automatically test with travis using free
infrastructure?



> >
> > If there is sufficient interest, we can explore additional travis
> > targets for other platforms, compilers, sanitizers, etc. Large
> > projects like libcurl [1] and gdal [2] extensively use travis in the
> > development process. It may be useful to use this for the official
> > https://github.com/freedesktop/poppler repository.
>
> WHAT THE FUCK IS THAT REPOSITORY? Who is pushing there? I'll ask the
> freedesktop people.
>
> This is just a mirror of cgit.freedesktop.org


Greetings

José

This is not our repository, our repository is
> http://cgit.freedesktop.org/poppler/poppler
>
> Cheers,
>   Albert
>
> >
> > [1] https://travis-ci.org/curl/curl
> > [2] https://travis-ci.org/OSGeo/gdal
> > ___
> > poppler mailing list
> > poppler@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/poppler
>
>
>
>
> ___
> poppler mailing list
> poppler@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/poppler
>
___
poppler mailing list
poppler@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] Poppler 0.60.0 released

[jose.ali...@gmail.com]

This is a python3 versus python2 compability thing. If you make sure the
script runs with python2 it should work. I don't know what's better. to fix
the script to run in either version of python or just make explicit
dependency on python2.


Greetings

José


On Tue, Oct 3, 2017 at 11:47 AM, Andreas Radke 
wrote:

> Building with GTK-Dok enabled fails here:
>
> -[ 41%] Built target poppler-glib-demo
> Scanning dependencies of target glib-docs
> [ 41%] Generating glib-docs-build.stamp
> Traceback (most recent call last):
>   File "/build/poppler/src/poppler-0.60.0/make-glib-api-docs", line 66,
> in 
> gtkdoc.generate(not args.skip_html)
>   File "/build/poppler/src/poppler-0.60.0/gtkdoc.py", line 144, in
> generate
> self._run_gtkdoc_mkdb()
>   File "/build/poppler/src/poppler-0.60.0/gtkdoc.py", line 360, in
> _run_gtkdoc_mkdb
> self._run_command(args, cwd=self.output_dir)
>   File "/build/poppler/src/poppler-0.60.0/gtkdoc.py", line 198, in
> _run_command
> sys.stdout.write(stdout.encode("utf-8"))
> TypeError: write() argument must be str, not bytes
> make[2]: *** [glib/reference/CMakeFiles/glib-docs.dir/build.make:61:
> glib/reference/glib-docs-build.stamp] Error 1
> make[1]: *** [CMakeFiles/Makefile2:794: 
> glib/reference/CMakeFiles/glib-docs.dir/all]
> Error 2
> make: *** [Makefile:141: all] Error 2
>
>
> Any idea what's wrong with the argument?
>
>
> -Andy
> Arch Linux
>
> ___
> poppler mailing list
> poppler@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/poppler
>
>
___
poppler mailing list
poppler@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] XMP support

[jose.ali...@gmail.com]

Hi,

On Mon, Sep 25, 2017 at 8:01 PM, Albert Astals Cid  wrote:

> We have "very basic" XMP metadata support, i.e. we "can read it" in
> Catalog::readMetadata and pdfinfo -meta dumps it
>
> But that's it.
>
> The ISO spec says that "the metadata stream shall be taken as authoritative
> [given some conditions]" and we're not obeying that in say pdfinfo.
>
> I guess we should at least support the dc: and xmp: entries that are
> similar
> to the catalog info document, e.g. dc:title dc:creator xmp:CreateDate
>
>
Question is where to do this:
>  * in pdfinfo
>  * in poppler core
>
> For the basic stuff, I would do something like...

doc->getTitle()

If there is no xmp, then get the title from the catalog, else, get the
title from xmp. And I would do that in core,
as we need to use the same code in pdfinfo, evince, okular, etc. And
reading xmp would add us only a dep on
a small library like libxml or so.

Regards



> In pdfinfo is easier since we don't have to build lots of classes around
> it,
> but that means that for example I would have to do the same code in Okular
> which is not particularly great.
>
> Opinions?
>
> Cheers,
>   Albert
> ___
> poppler mailing list
> poppler@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/poppler
>
___
poppler mailing list
poppler@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] Access to Poppler internal C++ API by GDAL

[jose.ali...@gmail.com]

On Sun, Sep 10, 2017 at 10:57 AM, Even Rouault <even.roua...@spatialys.com>
wrote:

> On dimanche 10 septembre 2017 10:50:42 CEST jose.ali...@gmail.com wrote:
>
> > Hi,
>
> > the internal c++ API is not intended for use by external applications,
> only
>
> > by frontends. So, if you want a stable API, you should be using either of
>
> > the frontends. There is a cpp frontend that should be fare more stable.
>
>
>
> Jose,
>
>
>
> I'm aware of the cpp frontend, but unless I miss something, it is mostly
> about rendering or text search. GDAL needs go far beyond rendering as I
> explained.
>
>
>
sure, but the internal c++ api is not going to be stable... If the cpp is
missing parts of what you pointed out, then add patches to it with api that
you expect to be stable. I mean, add API that is general enough to be used
by others to the cpp frontend and then you can take some of your code
outside of your app into the cpp frontend. Or use the qt4 or qt5 frontend,
even if you are not going to render anything.


Kind regards



> Even
>
>
>
> >
>
> > Regards
>
> >
>
> >
>
> > On Sun, Sep 10, 2017 at 10:41 AM, Even Rouault <
> even.roua...@spatialys.com>
>
> >
>
> > wrote:
>
> > > Hi,
>
> > >
>
> > >
>
> > >
>
> > > I'm one of the developper of the GDAL library (http://gdal.org) that
>
> > > reads various raster & vector formats, mostly geospatial, including PDF
>
> > > and
>
> > > its georeferencing extensions (either expressed wtih Adobe Supplement
> to
>
> > > ISO 32000 or with Open Geospatial Consortium Best Practice:
>
> > >
>
> > > https://portal.opengeospatial.org/files/?artifact_id=40537 )
>
> > >
>
> > >
>
> > >
>
> > > Currently we use the Poppler internal C++ API and regularly must adjust
>
> > > for changes in it. Recently we had to do adjustments to accomodate for
>
> > > Poppler 0.58 changes. Supporting multiple Poppler versions begin to
> make
>
> > > our code ugly. So I and packagers from Linux distribution are
> wondering if
>
> > > there would be a way to access a more stable C++ API
>
> > >
>
> > >
>
> > >
>
> > > Besides rendering as image, we need really low-level access to PDF
>
> > > objects, to be able to parse georeferencing objects, retrieve layers,
> turn
>
> > > on/off OCG, or even access streams to decode drawing instructions so
> as to
>
> > > build vector objects
>
> > >
>
> > >
>
> > >
>
> > > I've tried to summarize below our current use of Poppler C++ API. I
>
> > > probably missed a few calls, but you should get the overall picture:
>
> > >
>
> > > - Object class: getType(), getTypeName(), getBool(), getInt(),
> getReal(),
>
> > > getString(), getName(), getStream(), getArray()
>
> > >
>
> > > - Dict class: lookupNF(), lookup(), getLength(), getKey()
>
> > >
>
> > > - Array class: getLength(), getNF(), get()
>
> > >
>
> > > - Stream class: getDict(), reset(), getChar(), fillGooString()
>
> > >
>
> > > - Catalog class: getPage(), getPageRef(), readMetadata()
>
> > >
>
> > > - GooString: getCString(), getLength()
>
> > >
>
> > > - Ref class: access to num and gen
>
> > >
>
> > > - PDFDoc class: isOk(), displayPageSlice(), getCatalog(),
>
> > > getOptContentConfig(), getNumPages(), getDocInfo(), getErrorCode(), str
>
> > > private member(accessed through a ugly "#define private public" before
>
> > > including poppler! we need to access it to be able to delete it with
> our
>
> > > heap since we allocated a stream object provided to PDFDoc()
> constructor.
>
> > > this is to avoid potential problems on Windows with cross-heap issues)
>
> > >
>
> > > - Page class: isOk(), pageObj private member (accessed through a ugly
>
> > > "#define private public" before including poppler!), getMediaBox()
>
> > >
>
> > > - OCGs class: isOk(), getOCGs()
>
> > >
>
> > > - GooList class: getLength(), get()
>
> > >
>
> > > - OptionalContentGroup class: setState()
>
> > >
>
> > > - SplashBitmap class: getBitmap(), getWidth(), getHeigh(),
> getDataPtr(),
>
> > > getAlphaPtr(), getAlphaRowSize(), getRowSize()
>
> > &g

Re: [poppler] Access to Poppler internal C++ API by GDAL

[jose.ali...@gmail.com]

Hi,
the internal c++ API is not intended for use by external applications, only
by frontends. So, if you want a stable API, you should be using either of
the frontends. There is a cpp frontend that should be fare more stable.

Regards


On Sun, Sep 10, 2017 at 10:41 AM, Even Rouault 
wrote:

> Hi,
>
>
>
> I'm one of the developper of the GDAL library (http://gdal.org) that
> reads various raster & vector formats, mostly geospatial, including PDF and
> its georeferencing extensions (either expressed wtih Adobe Supplement to
> ISO 32000 or with Open Geospatial Consortium Best Practice:
>
> https://portal.opengeospatial.org/files/?artifact_id=40537 )
>
>
>
> Currently we use the Poppler internal C++ API and regularly must adjust
> for changes in it. Recently we had to do adjustments to accomodate for
> Poppler 0.58 changes. Supporting multiple Poppler versions begin to make
> our code ugly. So I and packagers from Linux distribution are wondering if
> there would be a way to access a more stable C++ API
>
>
>
> Besides rendering as image, we need really low-level access to PDF
> objects, to be able to parse georeferencing objects, retrieve layers, turn
> on/off OCG, or even access streams to decode drawing instructions so as to
> build vector objects
>
>
>
> I've tried to summarize below our current use of Poppler C++ API. I
> probably missed a few calls, but you should get the overall picture:
>
> - Object class: getType(), getTypeName(), getBool(), getInt(), getReal(),
> getString(), getName(), getStream(), getArray()
>
> - Dict class: lookupNF(), lookup(), getLength(), getKey()
>
> - Array class: getLength(), getNF(), get()
>
> - Stream class: getDict(), reset(), getChar(), fillGooString()
>
> - Catalog class: getPage(), getPageRef(), readMetadata()
>
> - GooString: getCString(), getLength()
>
> - Ref class: access to num and gen
>
> - PDFDoc class: isOk(), displayPageSlice(), getCatalog(),
> getOptContentConfig(), getNumPages(), getDocInfo(), getErrorCode(), str
> private member(accessed through a ugly "#define private public" before
> including poppler! we need to access it to be able to delete it with our
> heap since we allocated a stream object provided to PDFDoc() constructor.
> this is to avoid potential problems on Windows with cross-heap issues)
>
> - Page class: isOk(), pageObj private member (accessed through a ugly
> "#define private public" before including poppler!), getMediaBox()
>
> - OCGs class: isOk(), getOCGs()
>
> - GooList class: getLength(), get()
>
> - OptionalContentGroup class: setState()
>
> - SplashBitmap class: getBitmap(), getWidth(), getHeigh(), getDataPtr(),
> getAlphaPtr(), getAlphaRowSize(), getRowSize()
>
> - SplashOutputDev class: we subclass this class and override all/most
> virtual methods to be able to turn on/off rendering of various elements as
> we offer options to render selectively vector, raster and/or text elements
> (so basically just a conditional test to decide whether to return as a
> no-op or call the base implementation)
>
> - BaseStream class: we subclass this class to use GDAL own I/O abstraction
> layer (which beyond regular files can read in .zip files, in-memory files,
> files available through HTTP, etc...). So we implement copy(),
> makeSubStream(), getPos(), getStart(), setPos(), moveStart(), getKind(),
> getFileName(), getChar(), makeSubStream(), lookChar(), reset(),
> unfilteredReset(), close(), hasGetChars(), getChars()
>
> - GlobalParams class: setPrintCommands()
>
> - setErrorCallback() function
>
>
>
> If you want to glance at the code, the most relevant files are:
>
> https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/pdf/pdfobject.cpp
>
> https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/pdf/pdfio.cpp
>
> https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/pdf/pdfdataset.cpp
>
>
>
> I'm not clear if that would be feasible for Poppler to provide a more
> stable API for our use. At least, this makes you aware of external users of
> this API.
>
>
>
> Best regards,
>
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>
> ___
> poppler mailing list
> poppler@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/poppler
>
>
___
poppler mailing list
poppler@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] Do we need to remove the internal DCT and JPX decoders

[jose.ali...@gmail.com]

On Wed, May 17, 2017 at 6:13 PM, Albert Astals Cid <aa...@kde.org> wrote:

> El dimarts, 16 de maig de 2017, a les 19:40:31 CEST, jose.ali...@gmail.com
> va
> escriure:
> > Hey List,
> >
> > very recently, Thalos(CISCO) has encountered some overflows that could
> > potentially lead to security risks. One of this is in the DCT decoder and
> > the other in the JPX decoder. The question is what to do? Do we fix these
> > overflows or just remove the decoders from poppler since they are not
> being
> > mantained. One of the problems is that Ubuntu is compiled by default to
> use
> > the JPX decoder while most distributions do include libjpeg support.
> >
> > The bugs as I understand are still private, so if any of the developers
> of
> > poppler wants to see the reports, please contact me directly (off list)
> and
> > I will send it to you together with a minimal pdf sample.
>
> Right now we "almost silently" fall back to the unsupported code, yes we
> put a
> warning at the very end of the configure/cmake process but i guess hardly
> anyone reads those.
>
> My suggestion would be change the configure/cmake process so it behaves
> like
> this (process explained for libjpeg but same would apply for libopenjpeg)
>
>  * You have libjpeg -> all is good
>  * You don't have it, configure fails
> * Unless you pass one of these two options
>  * --dct-decoder=unmaintained
>  * --dct-decoder=none
>
> Which would give you either the unmaintained decoder or none at all.
>
> At least this way we can totally pass the blame for distros for using
> either
> the unmaintained or the none flags.
>
> I am suggesting this instead of removing it because for some controlled
> reasons it may be actually better to be able to use the unmaintained
> decoders
> than nothing (e.g. you're running pdftotext inside a virtual machine,
> doesn't
> matter if you get "rooted" inside the virtual machine).
>
> I like this idea. I have only one concern about how to manage the
"security" bugs that will  have here (like the two from CISCO). Do we
simply reply that these are unmantained and that if any distribution is
using this code, it's up to them to fix it and provide patches?


Cheers

José



> Cheers,
>   Albert
>
> >
> >
> > Kind regards
> >
> > José
>
>
> ___
> poppler mailing list
> poppler@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/poppler
>
___
poppler mailing list
poppler@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/poppler

[poppler] Support for XMP metadata in poppler?

[jose.ali...@gmail.com]

Hey List,

sorry if this has been discussed, but afaik, poppler does not read the XMP
metadata when trying to find the title, or creation dates, etc. It's that
corret. If so, is there is any reason why we don't have such suppport
(other than nobody submitted a patch?) ... I tried to search in the list
and the web but only found an old email saying that someone has submitted a
patch to the list while ago (2007 or so)... So I am wondering about this.

Is the solution to read the metadata with another library? or shoud we add
some logic in poppler to do this?


Greetings

José
___
poppler mailing list
poppler@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] hyperlinks not clickable

[jose.ali...@gmail.com]

Hi again,


On Thu, Feb 23, 2017 at 8:19 PM, Petr Vanek <p...@linuks.cz> wrote:

> On Thu, Feb 23, 2017 at 7:33 PM, jose.ali...@gmail.com
> <jose.ali...@gmail.com> wrote:
> > Hi Petr,
> >
> > Please submit a bug in GNOME's bugzilla product:evince. Although I think
> > it's very unlikely to be implemented (not enough devs working on
> evince
> > atm)
> >
> Hi José,
>
> actually i did before and I will try again but debian bugtracker
> didn't like me today, see below or perhaps something went wrong on my
> side, Anyways, will retry :)
>
> Your message didn't have a Package: line at the very first line of the
> mail body (part of the pseudo-header), or didn't have a Package: line
> at all. Unfortunatly, this means that your message has been ignored
> completely.
>
> Without this information we are unable to categorise or otherwise deal
> with your problem report. Please _resubmit_ your report to
> sub...@bugs.debian.org and tell us which package the
> report is for. For help, check out
> http://www.debian.org/Bugs/Reporting.
>
reporting a bug in debian will get you nowhere. You should use
https://bugzilla.gnome.org



>
> > from: Albert Astals Cid
> > What do you mean it doesn't allow you to enter any bug?
>
> Hi Albert,
>
> I made an account today but there wasn't poppler category on
> bugs.freedesktop.org (there were other categories), i tried to
> force-feed it via
>

In bugs.freedesktop.org you need to use the Product:poppler


> https://bugs.documentfoundation.org/enter_bug.cgi?product=poppler but
> it said "Sorry, either the product poppler does not exist or you
> aren't authorized to enter a bug into it. "
>
This also will get you nowhere with poppler

Cheers,

José



>
>
> cheers
>
> Petr
>
___
poppler mailing list
poppler@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] hyperlinks not clickable

[jose.ali...@gmail.com]

Hi Petr,

Please submit a bug in GNOME's bugzilla product:evince. Although I think
it's very unlikely to be implemented (not enough devs working on evince
atm)

Kind regards

José


On Thu, Feb 23, 2017 at 1:57 PM, Petr Vanek  wrote:

> Thank you Alexander.
>
> I do not have access to create this as a "real Annotation" as it is in a
> context of 3D modeling software. I did this probably about ten years ago
> and actoread simply worked ever since day one. When observing more and more
> people moving to Linux within business office deployment and with the
> constant explaining why they need acroread i realized that it would be nice
> not to depend on Adobe abandon-ware (linux client receives no more
> updates), so this pushed me to file a report.
>
> Any chance to do auto-link in poppler? What would be the harm? Is it
> against the specs? Would it be computationally expensive?
>
>
> On Thu, Feb 23, 2017 at 3:45 PM, Alexander Grahn  wrote:
>
>> On Thu, Feb 23, 2017 at 02:56:32PM +0100, Petr Vanek wrote:
>> >For whatever reason, Evince doesn't make links clickable in my own
>> created
>> >documents, see example here: http://www.penguin.cz/~vanous/out.pdf - the
>> >numbers in circles have hyperlinks underneath (you can actually select
>> them
>> >as a text with a mouse). The links are small and several  of them, to
>> fill
>> >the circle. This was created many moons ago by writing an extension to
>> some
>> >3D modeling software and works perfectly in Acroread. Any idea why
>> poppler
>> >ignores these links?
>>
>> These are not real links (PDF Annotations with subtype /Link) but
>> ordinary text in the content stream of the page.
>>
>> Acroread has a built-in "auto-link" feature that creates links from text
>> that
>> looks like an URL.
>>
>
>
> ___
> poppler mailing list
> poppler@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/poppler
>
>
___
poppler mailing list
poppler@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] Rethinking poppler releases

[jose.ali...@gmail.com]

Hey Albert, if you think it wont be much more burden for you at making the
releases, then please go for it. Having more releases make for easier
synchronization with KDE and GNOME schedules. Other than that, we could
also try to put a schedule every x months that is sync with KDE and GNOME
(and other desktops if necessary) so features needed for okular and evince
can be pushed sooner than later.


Greetings


José


On Wed, Sep 24, 2014 at 4:38 PM, Albert Astals Cid aa...@kde.org wrote:

 El Dimecres, 24 de setembre de 2014, a les 02:15:49, Maciej Mrozowski va
 escriure:
  On Wednesday 24 of September 2014 00:51:06 Albert Astals Cid wrote:
  | Hi all, we released 0.26.0 five months ago. And we have no schedule for
  | 0.28.0 (or i can't find no email discussing it).
  |
  | This is something that has been happening repeateadly, we forget when
  | the
  | next feature release or we need to delay it because we only release it
  | every so often and we *really* need a feature in.
  |
  | I'd like to propose a change from having bugfix releases every month
 and
  | feature releases every ~6 months to just having a release every month.
  |
  | In that release we would introduce both bugfixes and features.
  |
  | We have been *very* good in the past with not introducing regressions
  | thanks to running the regression suite, so i think this is a good thing
  | since it makes it easier for our features to reach the users earlier
  | (e.g. i have a feature in poppler-qt that need to be released to make
  | okular faster).
  |
  | The downside is that some distros won't like it, but honestly those
  | distros
  | already don't update some of the minor releases because we do changes
 to
  | our internal APIs so one can't fix distros.
  |
  | Given the manpower we have at the moment (i.e. very low) i think a
 monthly
  | release (or maybe every two months) that contains both bugfixes and
  | features is the best for us.
  |
  | Comments?
  |
  | Cheers,
  |
  |   Albert
 
  Sorry for maybe missing something obvious, but how about just releasing
 when
  you feel there's something warranting the release instead of sort of
  forcing yourself to do release cycles?

 Timed releases are the best for us, solves us from the issue of thinking
 do
 we have enough to release?, yes we do because it's time.

 Cheers,
   Albert

 
  While a little bit orthogonal, this could also involve choosing different
  versioning method[1]. Patch releases whenever important enough fixes are
  delivered (so that distros don't have to backport them from git).
 Introduce
  major releases for important changes, minor releases for maybe less
  important, but preferably API backward compatible changes. important
 is
  differently defined by different parties. For distros it could mean
  anything that breaks API or considerably enhances functionality.
 Poppler
  is somewhat known for changing internal (XPdf?) API more than once so -
  following distros' important definition - that could mean numerous
 major
  releases if that API is considered public API, but hey..
 
  1. http://en.wikipedia.org/wiki/Software_versioning#Change_significance
 
  regards
  MM
  ___
  poppler mailing list
  poppler@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/poppler

 ___
 poppler mailing list
 poppler@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/poppler

___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] xpdf 3.04 is out

[jose.ali...@gmail.com]

but if implementations are similar? do we prefer ours because of copyright?
or do we want to give some priority to the original xpdf so it will be
easier to merge in the future?

about difficulty, I realized it was more difficult that I thought at the
begining, so it changed my mind. I still want to merge things that would be
useful for us (soc project), but that would be my effort and not part of
soc.

Greetings


On Thu, Jun 5, 2014 at 3:24 AM, Carlos Garcia Campos carlo...@gnome.org
wrote:

 jose.ali...@gmail.com jose.ali...@gmail.com writes:

  Mmmm.. by looking at the new Form and AcroForm classes, there is a
 lot
  of functionality already implemented by poppler that does not come from
  Xpdf. What should we do in this case to do the merge?

 That parts are the most difficult ones, we need to check the changes
 carefully and see if we prefer our implementation or the xpdf one, and
 merge any other fixes present in our implementation. So, I'm not sure
 that's a good task for GSoC project.

 
 
  On Wed, Jun 4, 2014 at 5:50 PM, Albert Astals Cid aa...@kde.org wrote:
 
  El Dimecres, 4 de juny de 2014, a les 20:20:17, Carlos Garcia Campos va
  escriure:
   Albert Astals Cid aa...@kde.org writes:
Has anyone done any preliminary diff between 3.03 and 3.04?
  
   I dind't even know it :-P
  
How hard is it going to merge?
  
   I guess like usual, some parts trivial and some others quite
 difficult.
  
I'm ultra *behind* on reviewing/regtesting existing patches so i
 don't
think i'll be able to do this for a while, but is something that
defenitely needs doing.
  
   I'll try to find to time to work on this. Maybe we can setup a repo
 like
   last time with the diff, and start merging individual changes to a
   branch. Once a chunk of the diff is merged in the xpdf-304 branch it's
   removed from the diff in the repo until the diff is empty :-)
 
  Looks good, do you think you can set that up?
 
  Cheers,
Albert
 
  
Cheers,
   
  Albert
   
___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler
 
  ___
  poppler mailing list
  poppler@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/poppler
 
 
  ___
  poppler mailing list
  poppler@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/poppler

 --
 Carlos Garcia Campos
 PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462

___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] xpdf 3.04 is out

[jose.ali...@gmail.com]

We are working with Anuj with Forms for his SoC internship. I think we can
take care of starting merging form bits that will be useful for us.

Cheers



On Wed, Jun 4, 2014 at 2:20 PM, Carlos Garcia Campos carlo...@gnome.org
wrote:

 Albert Astals Cid aa...@kde.org writes:

  Has anyone done any preliminary diff between 3.03 and 3.04?

 I dind't even know it :-P

  How hard is it going to merge?

 I guess like usual, some parts trivial and some others quite difficult.

  I'm ultra *behind* on reviewing/regtesting existing patches so i don't
 think
  i'll be able to do this for a while, but is something that defenitely
 needs
  doing.

 I'll try to find to time to work on this. Maybe we can setup a repo like
 last time with the diff, and start merging individual changes to a
 branch. Once a chunk of the diff is merged in the xpdf-304 branch it's
 removed from the diff in the repo until the diff is empty :-)

  Cheers,
Albert
  ___
  poppler mailing list
  poppler@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/poppler

 --
 Carlos Garcia Campos
 PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462

 ___
 poppler mailing list
 poppler@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/poppler


___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] xpdf 3.04 is out

[jose.ali...@gmail.com]

Mmmm.. by looking at the new Form and AcroForm classes, there is a lot
of functionality already implemented by poppler that does not come from
Xpdf. What should we do in this case to do the merge?



On Wed, Jun 4, 2014 at 5:50 PM, Albert Astals Cid aa...@kde.org wrote:

 El Dimecres, 4 de juny de 2014, a les 20:20:17, Carlos Garcia Campos va
 escriure:
  Albert Astals Cid aa...@kde.org writes:
   Has anyone done any preliminary diff between 3.03 and 3.04?
 
  I dind't even know it :-P
 
   How hard is it going to merge?
 
  I guess like usual, some parts trivial and some others quite difficult.
 
   I'm ultra *behind* on reviewing/regtesting existing patches so i don't
   think i'll be able to do this for a while, but is something that
   defenitely needs doing.
 
  I'll try to find to time to work on this. Maybe we can setup a repo like
  last time with the diff, and start merging individual changes to a
  branch. Once a chunk of the diff is merged in the xpdf-304 branch it's
  removed from the diff in the repo until the diff is empty :-)

 Looks good, do you think you can set that up?

 Cheers,
   Albert

 
   Cheers,
  
 Albert
  
   ___
   poppler mailing list
   poppler@lists.freedesktop.org
   http://lists.freedesktop.org/mailman/listinfo/poppler

 ___
 poppler mailing list
 poppler@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/poppler


___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] White space on font size change

[jose.ali...@gmail.com]

Hi Kostis,

If you want to fix a bug... the first thing is to check in newer versions.
Please try to reproduce the bug either with the latest 0.22.x release or
building directly from git. If you still can reproduce the problem, please
file a bug in http://bugs.freedesktop.org

Greetings

José



On Sat, Apr 27, 2013 at 1:42 AM, Kostis Leledakis kole...@gmail.com wrote:

 Hi all,
 Try to use pdftohtml on the attached file...
 I explain in the file what exactly the problem is.

 I use version 0.18.4 on ubuntu...
 I don't know if the problem has solved on newer versions..
 If not, i am a developer too, so i will try to fix it.

 I will appreciate any help (of where exactly to look-for font changes and
 the calculations of positioning) from more experienced members.

 P.S: I checked some bugs for similar problems, but my English  are not so
 good
 to understand if it was exactly the bug i found... Sorry if i repeat an
 existing bug

 Thank you
 Kostis

 ___
 poppler mailing list
 poppler@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/poppler


___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] Missing fonts on DefaultAppareance of Form fields

[jose.ali...@gmail.com]

I havan't have many more comments on this patch. Albert, could you please
comment when have the time? Thanks




On Mon, Feb 18, 2013 at 11:29 AM, jose.ali...@gmail.com 
jose.ali...@gmail.com wrote:

 Hi list,

 There are some PDF's out there (I don't know how common they are, but at
 least the IRS tax form of 2008 used to have this) that specify fonts like
 /Helv or /HeBo in their DA streams without specifying the corresponding
 font in the resources. You will find a proof-of-concept patch, where I
 refactor the code we use to force ZapDingbats to  render any of the
 standard 14 fonts given by the short refs. So the first question is, Do we
 want a feature like this? If so, reviews to make this mergable are most
 than welcome.


 Greetings

 José


___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

[poppler] Missing fonts on DefaultAppareance of Form fields

[jose.ali...@gmail.com]

Hi list,

There are some PDF's out there (I don't know how common they are, but at
least the IRS tax form of 2008 used to have this) that specify fonts like
/Helv or /HeBo in their DA streams without specifying the corresponding
font in the resources. You will find a proof-of-concept patch, where I
refactor the code we use to force ZapDingbats to  render any of the
standard 14 fonts given by the short refs. So the first question is, Do we
want a feature like this? If so, reviews to make this mergable are most
than welcome.


Greetings

José


0001-Create-dummy-fonts-for-missing-fonts-in-the-DA-of-an.patch
Description: Binary data
___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] Missing fonts on DefaultAppareance of Form fields

[jose.ali...@gmail.com]

Leonard,

thanks for your answer, please look at [1] for an example of such file (the
IRS form of 2008). In there, I can't find the Helvetica Bold font in the
resources, but the DA streams all contain the /HeBo when specifying the
font. About forcing to Dingbats, poppler only forces Dingbats to render the
checkboxes and the radio buttons even on pdf files that don't have Dingats
in their resources (that's my understanding of the code, maybe I am
mistaken). It just happened that I could re-use the code to force adding
resources of missing fonts.



Greets

José







[1] http://bugzilla-attachments.gnome.org/attachment.cgi?id=124437


On Mon, Feb 18, 2013 at 2:25 PM, Leonard Rosenthol lrose...@adobe.comwrote:

 Jose – that's strange, those names aren't special and need to have
 associated resources.

 However, they are fairly standard…so if you must map, then map correctly
 (not just to Dingbats for all).

 Leonard

 From: jose.ali...@gmail.com jose.ali...@gmail.com
 Date: Monday, February 18, 2013 5:29 AM
 To: poppler@lists.freedesktop.org poppler@lists.freedesktop.org
 Subject: [poppler] Missing fonts on DefaultAppareance of Form fields

 Hi list,

 There are some PDF's out there (I don't know how common they are, but at
 least the IRS tax form of 2008 used to have this) that specify fonts like
 /Helv or /HeBo in their DA streams without specifying the corresponding
 font in the resources. You will find a proof-of-concept patch, where I
 refactor the code we use to force ZapDingbats to  render any of the
 standard 14 fonts given by the short refs. So the first question is, Do we
 want a feature like this? If so, reviews to make this mergable are most
 than welcome.


 Greetings

 José


___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] Help with first time compiling

[jose.ali...@gmail.com]

Hey Ronald,


On Sat, Jan 5, 2013 at 10:02 PM, Ronald Bradford
ronald.bradf...@gmail.comwrote:

 Hi List,

 I am a user of pdftotext and pdfimages on Ubuntu 12.04 and I noticed the
 repo distro version was 0.18.
 Seeing you are at 0.24 I thought I should check it out for any
 improvements.
 My goal is only to use the utils, but I assume I need to compile the full
 codebase.

 I am getting the following configure warnings and would like some
 assistance.

 checking for CAIRO... no
 ./configure: line 2: test: too many arguments
 checking for gtkdoc-check... no
 checking for gtkdoc-rebase... no
 checking for gtkdoc-mkpdf... no
 checking whether to build gtk-doc documentation... no
 checking for POPPLER_QT4... no
 ./configure: line 22517: syntax error near unexpected token `iconv'
 ./configure: line 22517: `  AC_LIB_LINKFLAGS_BODY(iconv)'

 I'm guessing (not being a configure guru, these two errors should not be.)

 It is easier if you just do apt-get build-dep poppler, which will install
all the dependencies you need to build poppler

Greets




 If I need cairo (which is a heavy package), what specific packages are the
 minimum needed, e.. just libcairo2-dev?
 Any help on also getting a clean configure past the later error to run
 make would be appreciated.


 My steps to reproduce are :

 git clone git://git.freedesktop.org/git/poppler/poppler
 cd poppler
 sudo apt-get install automake libtool libfontconfig1-dev libjpeg-dev
 ./autogen.sh



 Thanks

 Ronald

 ___
 poppler mailing list
 poppler@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/poppler


___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

[poppler] [PATCH] glib frontend: Compute text only the first time you render a page

[jose.ali...@gmail.com]

Hey list,

currently the glib frontend will recalculate the TextPage of a Page each
time we call poppler_page_render. The following patch fixes that.


Greetings

José


0001-glib-Ensure-text-is-only-computed-on-first-render.patch
Description: Binary data
___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] Retrieve all objects from a PDF file

[jose.ali...@gmail.com]

Hi

On Mon, Oct 31, 2011 at 3:12 PM, Josh Richardson j...@chegg.com wrote:
 What kinds of objects are you interested in?  I have a version of
 pdftohtml which I believe is not yet merged into the master repo that
 extracts images and fonts.

I am interested in sample code to get all fonts!

Greetings


 --josh

 On 10/31/11 9:16 AM, Nedim Srndic nedim...@gmail.com wrote:

Dear list,

I am using the Poppler library (in the src/poppler folder, no bindings,
version 7 from the Ubuntu 10.10 repos) and would like to retrieve all
objects from a PDF file. Currently, I am running a loop on XRef and
getting all the non-null objects from it, but it doesn't seem to
retrieve objects from object streams. What solution would you propose
for this problem?

Thanks,
Nedim Srndic

___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler


 ___
 poppler mailing list
 poppler@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/poppler

___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] libpdfjs

[jose.ali...@gmail.com]

Hi,

On Wed, Oct 12, 2011 at 10:26 AM, Albert Astals Cid aa...@kde.org wrote:
 A Dimecres, 12 d'octubre de 2011, Nedim Srndic vàreu escriure:
 Dear list,

 Poppler's Catalog class has a getJS() method that returns JavaScript
 scripts from the PDF document.
 http://www.google.com/codesearch#F0okAQSJLc0/poppler/Catalog.hq=javascript%
 20package:popplertype=csl=187

 It currently only scans the Name tree for JavaScript scripts, but they
 can also be found in many other places in a PDF document. It is not so
 straightforward to find this in the PDF reference. I had to, though, so
 I wrote a very compact C++ library called libpdfjs that looks for
 JavaScript strings in those locations where the PDF reference says they
 might be found (except for attachments, need to implement that). The
 library home page is here:
 https://sourceforge.net/p/libpdfjs/home/Home/

 Do you (Poppler developers) plan to support something like this in the
 future? If you do, then maybe the libpdfjs functionality can be moved to
 Poppler and libpdfjs obsoleted.


 As far as I know there is noone working on it. We will gladfully accept your
 patches though.
I have some wip patches in my branch that add this functionality to
poppler. I'll take a look into your lib but as Albert says, if you
feel like providing a patch for poppler, that would be great.

José


 Albert



 Greetings,
 Nedim Srndic

 ___
 poppler mailing list
 poppler@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/poppler
 ___
 poppler mailing list
 poppler@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/poppler

___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] Drawing styledForm Widgets

[jose.ali...@gmail.com]

Hi,

On Tue, Oct 11, 2011 at 9:20 AM, Carlos Garcia Campos
carlo...@gnome.org wrote:
 Excerpts from Albert Astals Cid's message of mar oct 11 14:07:07 +0200 2011:

 No, I think he means drawing current forms with the same style as the
 widgets, using the current theme, but using real widgets for the
 interactivity with the user.
yeah, the idea is to use real widgets, but to get the rendering or the
style from poppler so the widgets
can render the text exactly as poppler would do.  In Gtk3, one way of
doing this is to get the constructed AP stream and then use that to
construct a CSS style that would be apply to the GtkEntry
corresponding to that form field, the other way of doing it is to try
to hook up the rendering into poppler, but let the widget use its
machinery for everything else (not sure if that's really possible in
gtk, but nevertheless)

 I don't know how it's done in okular, but
 in Evince, we only use a real widget when the user clicks on a form,
 and it's destroyed when the form is edited. This way we don't need to
 keep widgets in the view all the time if they are not used. For some
 forms like check and radio buttons we don't even use real
 widgets. This way if you draw a choice widget exactly the same a
 GtkComboBox would be, when you click on the form to edit it, ideally you
 wouldn't even notice there wasn't a real widget.

Yeah, the main point is that when you are editing the form, you don't
notice there is this widget there...
specially annoying is the fact that the text style changes when you
hide the form.


Greetings,

José
___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] Drawing styledForm Widgets

[jose.ali...@gmail.com]

On Tue, Oct 11, 2011 at 9:53 AM, Albert Astals Cid aa...@kde.org wrote:
 A Dimarts, 11 d'octubre de 2011, Carlos Garcia Campos vàreu escriure:
 Excerpts from Albert Astals Cid's message of mar oct 11 14:07:07 +0200 2011:
  A Dilluns, 10 d'octubre de 2011, jose.ali...@gmail.com vàreu escriure:
   Hi list,
  
   there is idea, why not adding some support to draw style form
   widgets
   to poppler. I know that poppler is already doing that when
   rendering,
   but the idea would be to have a method that given a form widget,
   either renders the contents of the widget for you with the correct
   style, or some sort of struct with all the style information of the
   corresponding constructed AP stream, so the frontends can use this
   information to mimic poppler's rendering to render the widgets
   themselves. In order for the first option to work, this rendering
   should not depend on reparsing otherwise it would too slow
   (Basically,
   I consider that we could construct the AP stream and then using this
   stream with some Gfx magic it should be possible to render the
   widgets
   value without reparsing and thus being fast enough to put this
   method
   in a widget-rendering callback)
 
  As I understand what you want is apps no longer embedding real
  widgets on top of the forms but the apps drawing the forms themselves
  based on info given by poppler?
 
  I am not sure this is going to be easy to do, since using real widgets
  gives you lots of functionality for free (e.g: copy/paste,
  keyboard/mouse handling, etc) and if we do what you say I understand we
  have to stop using real widgets and do all this stuff in the final
  app which will be lots of work. Of course that does not mean that we
  could still provide the option to have it and not make it mandatory.
 
  Or did I totally misunderstand what you meant?

 No, I think he means drawing current forms with the same style as the
 widgets, using the current theme, but using real widgets for the
 interactivity with the user. I don't know how it's done in okular, but
 in Evince, we only use a real widget when the user clicks on a form,
 and it's destroyed when the form is edited. This way we don't need to
 keep widgets in the view all the time if they are not used. For some
 forms like check and radio buttons we don't even use real
 widgets. This way if you draw a choice widget exactly the same a
 GtkComboBox would be, when you click on the form to edit it, ideally you
 wouldn't even notice there wasn't a real widget.

 Ah, so instead of trying to render the real widgets like poppler renders the
 forms you mean trying to make poppler render like the top level application-
 widget is rendered.

Nop the idea is to takes poppler's rendering of the form field as it
is right now, and try to hook up this into the widgets rendering
painting method, or, to get the style from the field and apply this
style to the widget so you won't notice the difference between
poppler's rendering and the widget's rendering.

 This probably makes more sense but i am not still sure how easy/feasible
 that is.

 Albert


 José, is that the idea?

  Albert
 
   Greetings
  
   José
   ___
   poppler mailing list
   poppler@lists.freedesktop.org
   http://lists.freedesktop.org/mailman/listinfo/poppler

 --
 Carlos Garcia Campos
 PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462
 ___
 poppler mailing list
 poppler@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/poppler

___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

[poppler] Drawing styledForm Widgets

[jose.ali...@gmail.com]

Hi list,

there is idea, why not adding some support to draw style form widgets
to poppler. I know that poppler is already doing that when rendering,
but the idea would be to have a method that given a form widget,
either renders the contents of the widget for you with the correct
style, or some sort of struct with all the style information of the
corresponding constructed AP stream, so the frontends can use this
information to mimic poppler's rendering to render the widgets
themselves. In order for the first option to work, this rendering
should not depend on reparsing otherwise it would too slow (Basically,
I consider that we could construct the AP stream and then using this
stream with some Gfx magic it should be possible to render the widgets
value without reparsing and thus being fast enough to put this method
in a widget-rendering callback)



Greetings

José
___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] [PATCH] Selection improvements

[jose.ali...@gmail.com]

Hi,

On Fri, Oct 7, 2011 at 7:28 AM, Andreas Becker atayoo...@googlemail.com wrote:
 Not sure if you are sending and old patch again or you are a new person
 doing
 the same mistake, but we have discussed this a few times, starting a new
 word
 when the font changes is wrong.

 As an example of why it is wrong your patch changes the output of
 pdftotext in
 http://wooster.hut.fi/kurssit/s88211/s88211MatlabProject.pdf
 from
 uses a channel model described in [4]
 to
 uses a channel model described in [4 ]

 I am a new person.
I guess I am one of the old persons ;)

 If only the space after [4 is a problem, I can fix it using the variable
 spaceAfter (TextOutputDev.cc).

 Another possibility is to store a GfxFont* array in TextWord, so that every
 letter has its own font.
 I tested this and it works fine, but the rest of poppler still acts as if
 one word had only one font. A word would have
 a main font and letters with individual fonts. It is not a very clean
 solution, but probably better
 than starting new words.

Yeah, the problem is that this still could have some (potentially)
other issues as the codepath used to draw the page is so different
from the codepath used to draw the selection, and thus why I didn't
want to change the behaviour that much as you are proposing now. Then
I went to see how Okular handle selections but then I got sidetracker
(as always)
Greets



 ___
 poppler mailing list
 poppler@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/poppler


___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] Direct Poppler access without frontend allowed?

[jose.ali...@gmail.com]

Hi,

On Thu, May 12, 2011 at 12:36 AM, Andreas Butti andreasbu...@gmail.com wrote:
 Ok, I can provide my code, but I need some help to complete integrate with
 Poppler.

 What I did now:
 I have two PDFs, one for background and one for the foreground, like two
 slides on a overhead projector, the second slide is on top of the first
 slide. Sometimes there are two pages, 1 foreground and one background,
 sometimes there is only one PDF.
 Not all source PDFs are used always, and sometimes PDF Pages are used twice.


 My code does the following:

 Extract the contents stream of the pages
 Append the stream from one page to the other page

 update all references, e.g. images and fonts, because /F1 in one document is
 may not the same font than /F1 in the other document

 Write outlines to the document (they have to be created by the application,
 because if there are pages inserted / deleted, I cannot use the original
 outlines)
 Write metadata (Creator, Autor, Creationdate etc.)
There is a patch to poppler-glib bindings to add write/edit  metadata
in bugzilla. The patch is not ready yet, but help with that would be
appreciated I think.

 Writeout the document to a file

 Create new XREF table
 compress the contents of the pages with GZ

 My application is mostly written in C++, but I use GTK (no discussion about
 this combination;-)).

 So I first used the GLib frontend, but there I had problems with searching,
 and I cannot access the underlying poppler objects.
So I guess it makes sense to use the glib frontend as you are using
GTK. If there are things that the glib frontend does not support, then
you should feel free to file bugs and attach patches to implement the
api you are missing. Normally, you need to divide your patches in two
parts, first, a core part if the functionality you want to add is not
already present in the core poppler, and two the glib part that gives
you access to this functionality from the glib frontend.



 The Question is now which frontend I should use.


 In my opinion, the best solution is may to create a new frontend, e.g. a
 PDF-editing frontend?

 Because then it's possible to change some behaviour, and add other things,
 like:

 Edit text within PDF documents (not add, add is no problem with merging)
 Delete objects from a PDF (e.g. select a rectangle and delete all objects
 within this rectangle)
 Copy objects

as I pointed above, the best thing is to submit bugs/attach patches to
poppler-core/ and poppler-glib to make this happen. As Albert pointed
out, you don't really need a new frontend, but instead to add some API
to the poppler-glib one. For instance, the poppler-glib frontend
already supports adding annotations, and as I mentioned, there is a
patch to support editing the metadata.

Greetings,

José


 Currently there is no easy to use application which support these 3
 operations for Linux.

 If poppler would have such a frontend I'll may append this functionality to
 Xournal++ (in the future, not now).


 What do you think about this?




 Andreas

 Am 11.05.2011 21:43, schrieb Albert Astals Cid:

 A Wednesday, May 11, 2011, Andreas Butti va escriure:

 Hello everybody

 Hi

 I'm working on a new Xournal version (Xournal++, not yet present on a
 webpage, only in the SVN).

 I used Poppler to display PDF and also for PDF export, to implement the
 PDF export (merging two PDFs together) I access Poppler without any
 frontend.

 I'm working on Ubuntu, which contain all necessary headers, but other
 distributions don't.

 Now there is a discussion if it's allowed to access Poppler without
 frontend, or not.

 I thought it should be allowed, because on the poppler Wiki are also two
 projects listed which access poppler without frontent,

 But now I need a clear answer if it's allowed or not, and if not if
 there is another way for me to implement this without breaking any rules.

 It is not encouraged since we reserve the right to change the API (and do
 so)
 at any release (minor versions included) while our API in the frontends is
 much more stable.

 If you tell us what you are missing from the public frontend API we might
 add
 it, or you might even contribute the code you have that uses the internal
 API
 so we add it to our frontend ;-)

 Albert

 Thank you for the answer.


 Andreas

 ___
 poppler mailing list
 poppler@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/poppler

 ___
 poppler mailing list
 poppler@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/poppler

 ___
 poppler mailing list
 poppler@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/poppler


___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] Direct Poppler access without frontend allowed?

[jose.ali...@gmail.com]

Hi,

the following is non-authoritative (I am not a poppler-maintainer), so
some things may be wrong;

On Thu, May 12, 2011 at 12:57 PM, Andreas Butti andreasbu...@gmail.com wrote:
 OK, I read both mails.

 There is a patch to poppler-glib bindings to add write/edit  metadata
 in bugzilla. The patch is not ready yet, but help with that would be
 appreciated I think.
 I don't now what not ready means, but so I can use this patch an may
 get it complete working if it's not already complete working.

not ready means that it was reviewed by Carlos (who is the
poppler-glib maintainer) but the author has not found the time yet to
address the comments. AFAIK, the patch works. Here is the
link [1]

 I'll write now the additional defintions which I would create for the
 GLib API. (I know, the implementation is in background)

 // creates a new empty poppler document
 PopplerDocument * poppler_document_new_empty();

 // append a page to the poppler document (The page will be copied),
 return the new created page
 PopplerPage * poppler_document_add_page(PopplerDocument * doc,
 PopplerPage * page);

 // append the page src on top of page, src will be copied, return
 the new created page
 PopplerPage * poppler_document_add_page_on_top(PopplerDocument * doc,
 PopplerPage * src, PopplerPage * page);

 and methods to add bookmarks, something like
 ... poppler_document_add_outline(PopplerDocument * doc, const char *
 name, int level, ... action ...);

 would this be OK for you?


 How does it work with the maintenance of the code, I have to create a
 bugreport (featurerequest) and attach a patch, and then? Does somebody
 testing it?
You can either (but NOT both) attach your patches in bugzilla or send
them to the list. From what I have seen, in general patches get well
tested by Albert, who runs a regression test for each patch. Of
course, the kind of changes you are proposing won't have any
regressions as it will be code only used by you at the first time.

 Do I have to write unittest or something like this? (are there reviews,
 or what's the criteria for the path to get into the poppler library?)
I believe the core part gets reviewed by any of the poppler
maintainers, the glib parts gets reviewed by Carlos. I don't know
about the unittests, but usually if you add API to the poppler glib,
then you also need to add a demo of the use of the api in the
poppler-glib-demo program.


 If there are bugs (within the implementation) does the poppler team
 matain the code or is this in my responsibility because I may currently
 the only one who is using this API?
I don't know.



 Andreas

Hope this helps, and it's not so wrong ;)


[1] https://bugs.freedesktop.org/show_bug.cgi?id=36653
___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] [Patch] Parse Additional Actions for Widget Annots.

[jose.ali...@gmail.com]

yeah, I clicked too quickly the send button, the patch has a lot of
typos... but I also realized that I have to work more on the whole
infrastructure before submitting more patches... I Will be glad to
hear about this new class

Greets

Jose

On Thu, Mar 31, 2011 at 3:00 PM, Carlos Garcia Campos
carlo...@gnome.org wrote:
 Excerpts from jose.ali...@gmail.com's message of jue mar 31 14:19:24 +0200 
 2011:
 Hi,

 now patch 1 contains the memleak fix.

 pushed to both master and poppler-0.16 branches. Thanks!

 and patch2 is the updated patch
 addressing review comments.

 Great, I still have a couple of comments about the patch, but Pino had
 an idea to add a new class to handle additional actions in a more
 generic way. Pino?


 Greets

 José


 From 967cb1ef4acba2b517eb97cace9fab770388bb58 Mon Sep 17 00:00:00 2001
 From: =?UTF-8?q?Jos=C3=A9=20Aliste?= jali...@src.gnome.org
 Date: Tue, 29 Mar 2011 04:27:15 -0400
 Subject: [PATCH 2/2] Parse additionActions dictionary for Widget annots.

 ---
  poppler/Annot.cc |   71 
 ++---
  poppler/Annot.h  |   29 +
  2 files changed, 84 insertions(+), 16 deletions(-)

 diff --git a/poppler/Annot.cc b/poppler/Annot.cc
 index 7d1136c..dbf1778 100644
 --- a/poppler/Annot.cc
 +++ b/poppler/Annot.cc
 @@ -1350,6 +1350,45 @@ void Annot::draw(Gfx *gfx, GBool printing) {
    obj.free();
  }

 +// Parse Actions in AdditionalActionss dictionary that are common to Screen 
 and Widget annots
 +void Annot::parseAdditionalActionss (LinkAction **additionActions, Object 
 *addActionDict, GooString *baseURI)

 Actionss?

    if (action)
      delete action;
 -
 -  if (additionActions)
 -    delete additionActions;
 -
 +
 +  for (int i = 0; i  EventsNumber; i++)
 +     delete additionActions[i];
 +

 Wrong indentation here.

    if (parent)
      delete parent;
  }
 @@ -2758,10 +2797,19 @@ void AnnotWidget::initialize(XRef *xrefA, Catalog 
 *catalog, Dict *dict) {
    }
    obj1.free();

 Thanks!
 --
 Carlos Garcia Campos
 PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462

___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] [Patch] Parse Additional Actions for Widget Annots.

[jose.ali...@gmail.com]

Hi,

now patch 1 contains the memleak fix. and patch2 is the updated patch
addressing review comments.


Greets

José


On Thu, Mar 31, 2011 at 6:57 AM, Carlos Garcia Campos
carlo...@gnome.org wrote:
 Excerpts from jose.ali...@gmail.com's message of mié mar 30 20:50:44 +0200 
 2011:
 Carlos, thanks for the review.

 Here is an updated patch. I finally decided to have only one enum for
 TriggerEvents, so we can have methods
 AnnotScreen::getAdditionAction(AnnotTriggerEvent event)
 and AnnotWidget::getAdditionAction(AnnotTriggerEvent event)
 of giving eventFocusOut or eventFocusIn to a screen Annotation will
 just give you a NULL.

 I changed to use a stack allocated pointer of LinkActions. If you feel
 there is a better data struct for this, let me know.


 From e1576c8d6be31721ffeab52c4aa936eef1195d19 Mon Sep 17 00:00:00 2001
 From: =?UTF-8?q?Jos=C3=A9=20Aliste?= jali...@src.gnome.org
 Date: Tue, 29 Mar 2011 04:27:15 -0400
 Subject: [PATCH] Parse additionActions dictionary for Widget annots.

 ---
  poppler/Annot.cc |  102 
 +-
  poppler/Annot.h  |   31 +---
  2 files changed, 118 insertions(+), 15 deletions(-)

 diff --git a/poppler/Annot.cc b/poppler/Annot.cc
 index 1f77c71..faab471 100644
 --- a/poppler/Annot.cc
 +++ b/poppler/Annot.cc
 @@ -1350,6 +1350,72 @@ void Annot::draw(Gfx *gfx, GBool printing) {
    obj.free();
  }

 +// Parse Actions in AdditionActions dictionary that are common to Screen 
 and Widget annots
 +void Annot::parseAdditionActions (LinkAction **additionActions, Object 
 *addActionDict, GooString *baseURI)
 +{
 +    Object obj2;
 +
 +    if (addActionDict-dictLookup(E, obj2)-isDict())
 +      additionActions[eventCursorEnter] = LinkAction::parseAction (obj2, 
 baseURI);
 +    obj2.free();
 +
 +    if (addActionDict-dictLookup(X, obj2)-isDict())
 +      additionActions[eventCursorExit] = LinkAction::parseAction (obj2, 
 baseURI);
 +    obj2.free();
 +
 +    if (addActionDict-dictLookup(D, obj2)-isDict())
 +      additionActions[eventMouseDown] = LinkAction::parseAction (obj2, 
 baseURI);
 +    obj2.free();
 +
 +    if (addActionDict-dictLookup(U, obj2)-isDict())
 +      additionActions[eventMouseUp] = LinkAction::parseAction (obj2, 
 baseURI);
 +    obj2.free();
 +
 +    if (addActionDict-dictLookup(PO, obj2)-isDict())
 +      additionActions[eventPageOpen] = LinkAction::parseAction (obj2, 
 baseURI);
 +    obj2.free();
 +
 +    if (addActionDict-dictLookup(PC, obj2)-isDict())
 +      additionActions[eventPageClose] = LinkAction::parseAction (obj2, 
 baseURI);
 +    obj2.free();
 +
 +    if (addActionDict-dictLookup(PV, obj2)-isDict())
 +      additionActions[eventPageVisible] = LinkAction::parseAction (obj2, 
 baseURI);
 +    obj2.free();
 +
 +    if (addActionDict-dictLookup(PI, obj2)-isDict())
 +      additionActions[eventPageInvisible] = LinkAction::parseAction (obj2, 
 baseURI);
 +    obj2.free();
 +
 +  }
 +
 +// Delete additionActions that are common to Screen and Widget annots
 +void Annot::deleteAdditionActions(LinkAction **additionActions) {

 You don't need this. See below

 +  if (additionActions[eventCursorEnter])
 +     delete additionActions[eventCursorEnter];
 +
 +  if (additionActions[eventCursorExit])
 +    delete additionActions[eventCursorExit];
 +
 +  if (additionActions[eventMouseDown])
 +    delete additionActions[eventMouseDown];
 +
 +  if (additionActions[eventMouseUp])
 +    delete additionActions[eventMouseUp];
 +
 +  if (additionActions[eventPageOpen])
 +    delete additionActions[eventPageOpen];
 +
 +  if (additionActions[eventPageClose])
 +    delete additionActions[eventPageClose];
 +
 +  if (additionActions[eventPageVisible])
 +    delete additionActions[eventPageVisible];
 +
 +  if (additionActions[eventPageInvisible])
 +    delete additionActions[eventPageInvisible];
 +}
 +
  //
  // AnnotPopup
  //
 @@ -2715,12 +2781,16 @@ AnnotWidget::~AnnotWidget() {

    if (action)
      delete action;
 -
 -  if (additionActions)
 -    delete additionActions;
 -
 +
 +  Annot::deleteAdditionActions(additionActions);
 +  if (additionActions[eventFocusIn])
 +    delete additionActions[eventFocusIn];
 +  if (additionActions[eventFocusOut])
 +    delete additionActions[eventFocusOut];
 +

 delete is null-safe so here you only need a for loop

 for (int i = 0; i  EventsNumber; i++)
  delete additionActions[i];

    if (parent)
      delete parent;
 +
  }

 Remove this new line please.

  void AnnotWidget::initialize(XRef *xrefA, Catalog *catalog, Dict *dict) {
 @@ -2758,10 +2828,20 @@ void AnnotWidget::initialize(XRef *xrefA, Catalog 
 *catalog, Dict *dict) {
    }
    obj1.free();

 +  memset (additionActions, 0, EventsNumber);
 +
    if(dict-lookup(AA, obj1)-isDict()) {
 -    additionActions = NULL;
 -  } else {
 -    additionActions = NULL;
 +    Object obj2;
 

Re: [poppler] [Patch] Parse Additional Actions for Widget Annots.

[jose.ali...@gmail.com]

Carlos, thanks for the review.

Here is an updated patch. I finally decided to have only one enum for
TriggerEvents, so we can have methods
AnnotScreen::getAdditionAction(AnnotTriggerEvent event)
and AnnotWidget::getAdditionAction(AnnotTriggerEvent event)
of giving eventFocusOut or eventFocusIn to a screen Annotation will
just give you a NULL.

I changed to use a stack allocated pointer of LinkActions. If you feel
there is a better data struct for this, let me know.

On Tue, Mar 29, 2011 at 1:31 PM, Carlos Garcia Campos
carlo...@gnome.org wrote:
 Excerpts from jose.ali...@gmail.com's message of mar mar 29 10:35:08 +0200 
 2011:
 Hi,

 Here is a patch to parse the additional actions dict that is present
 in Widget Annots. This is one of the first patches we will need to get
 javascript support as many of the javascript in the pdfs are encoded
 in JavascriptActions that are associated to the AditionalActions
 dictionary. All comments welcome, specially about the way I am saving
 the AditionalActions as an Array of Pointers to LinkActions.


 Greetings,


 José

 From deb6fa54b20858d1aff74f87262b6ddc7b303335 Mon Sep 17 00:00:00 2001
 From: =?UTF-8?q?Jos=C3=A9=20Aliste?= jali...@src.gnome.org
 Date: Tue, 29 Mar 2011 04:27:15 -0400
 Subject: [PATCH] Parse additionActions dictionary for Widget annots.

 ---
  poppler/Annot.cc |   45 -
  poppler/Annot.h  |   19 +--
  2 files changed, 61 insertions(+), 3 deletions(-)

 Additional actions are not specific to Widget annotations, Screen
 annotation also have an AA entry, only Fo and Bl (focus-in, focus-out)
 events are specific to widget annots.

 diff --git a/poppler/Annot.cc b/poppler/Annot.cc
 index 1f77c71..2996be9 100644
 --- a/poppler/Annot.cc
 +++ b/poppler/Annot.cc
 @@ -2759,7 +2759,50 @@ void AnnotWidget::initialize(XRef *xrefA, Catalog 
 *catalog, Dict *dict) {
    obj1.free();

    if(dict-lookup(AA, obj1)-isDict()) {
 -    additionActions = NULL;
 +    Dict *addActionDict = obj1.getDict();
 +    Object obj2;
 +    additionActions = (LinkAction **) gmallocn ((NumberOfEvents), 
 sizeof(LinkAction *));

 We know the array size at compile time so we can use a stack allocated
 array instead.

 +    for (int i = 0; i  NumberOfEvents; i++) {
 +      additionActions[i] = NULL;
 +    }

 Use memset instead.

 +    for (int i = 0; i  addActionDict-getLength(); i++) {
 +      GooString key(addActionDict-getKey(i));
 +      int triggerEvent = -1;
 +
 +      if (key.cmp(E)) {
 +        triggerEvent = eventCursorEnter;
 +      } else if (key.cmp(X)) {
 +        triggerEvent = eventCursorExit;
 +      } else if (key.cmp(D)) {
 +        triggerEvent = eventMouseDown;
 +      } else if (key.cmp(U)) {
 +        triggerEvent = eventMouseUp;
 +      } else if (key.cmp(Fo)) {
 +        triggerEvent = eventFocusIn;
 +      } else if (key.cmp(Bl)) {
 +        triggerEvent = eventFocusOut;
 +      } else if (key.cmp(PO)) {
 +        triggerEvent = eventPageOpen;
 +      } else if (key.cmp(PC)) {
 +        triggerEvent = eventPageClose;
 +      } else if (key.cmp(PV)) {
 +        triggerEvent = eventPageVisible;
 +      } else if (key.cmp(PI)) {
 +        triggerEvent = eventPageInvisible;
 +      }

 We don't usually do this in poppler, instead of iterate the whole
 dictionary comparing every entry we check the entries we are
 interested in.

 if (additionalActions.dictLookup(E, obj1)-isDict())
  additionActions[eventCursorEnter] = LinkAction::parseAction (obj1, 
 catalog-getBaseURI());
 obj1.free();

 if (additionalActions.dictLookup(X, obj1)-isDict())
  additionActions[eventCursorExit] = LinkAction::parseAction (obj1, 
 catalog-getBaseURI());
 obj1.free();

 ..


 something like that.

 +      if (triggerEvent  0) {
 +        Object obj3;
 +
 +        addActionDict-getVal(i,obj3);
 +     additionActions[triggerEvent] = LinkAction::parseAction (obj3,  
 catalog-getBaseURI());
 +     obj3.free();
 +      }
 +
 +    }
 +
    } else {
      additionActions = NULL;
    }

 The actions should be freed (deleted) in the destructor.

 diff --git a/poppler/Annot.h b/poppler/Annot.h
 index 93f82bf..4f522d7 100644
 --- a/poppler/Annot.h
 +++ b/poppler/Annot.h
 @@ -453,6 +453,21 @@ public:
      type3D              // 3D             25
    };

 +  enum AnnotTriggerEvent {
 +    eventCursorEnter,        // E
 +    eventCursorExit, // X
 +    eventMouseDown,  // D
 +    eventMouseUp,    // U
 +    eventFocusIn,    // Fo
 +    eventFocusOut,   // Bl
 +    eventPageOpen,   // PO
 +    eventPageClose,  // PC
 +    eventPageVisible,        // PV
 +    eventPageInvisible,      // PI
 +    NumberOfEvents
 +  };
 +
 +
    Annot(XRef *xrefA, PDFRectangle *rectA, Catalog *catalog);
    Annot(XRef *xrefA, Dict *dict, Catalog *catalog);
    Annot(XRef *xrefA, Dict *dict, Catalog *catalog, Object *obj);
 @@ -1147,7 +1162,7 @@ public:
    AnnotWidgetHighlightMode getMode() { return mode; }
    AnnotAppearanceCharacs *getAppearCharacs() { 

[poppler] [Patch] Parse Additional Actions for Widget Annots.

[jose.ali...@gmail.com]

Hi,

Here is a patch to parse the additional actions dict that is present
in Widget Annots. This is one of the first patches we will need to get
javascript support as many of the javascript in the pdfs are encoded
in JavascriptActions that are associated to the AditionalActions
dictionary. All comments welcome, specially about the way I am saving
the AditionalActions as an Array of Pointers to LinkActions.


Greetings,


José
From deb6fa54b20858d1aff74f87262b6ddc7b303335 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Aliste?= jali...@src.gnome.org
Date: Tue, 29 Mar 2011 04:27:15 -0400
Subject: [PATCH] Parse additionActions dictionary for Widget annots.

---
 poppler/Annot.cc |   45 -
 poppler/Annot.h  |   19 +--
 2 files changed, 61 insertions(+), 3 deletions(-)

diff --git a/poppler/Annot.cc b/poppler/Annot.cc
index 1f77c71..2996be9 100644
--- a/poppler/Annot.cc
+++ b/poppler/Annot.cc
@@ -2759,7 +2759,50 @@ void AnnotWidget::initialize(XRef *xrefA, Catalog *catalog, Dict *dict) {
   obj1.free();
 
   if(dict-lookup(AA, obj1)-isDict()) {
-additionActions = NULL;
+Dict *addActionDict = obj1.getDict();
+Object obj2;
+additionActions = (LinkAction **) gmallocn ((NumberOfEvents), sizeof(LinkAction *));
+
+for (int i = 0; i  NumberOfEvents; i++) {
+  additionActions[i] = NULL;
+}
+
+for (int i = 0; i  addActionDict-getLength(); i++) {
+  GooString key(addActionDict-getKey(i));
+  int triggerEvent = -1;
+
+  if (key.cmp(E)) {
+triggerEvent = eventCursorEnter;
+  } else if (key.cmp(X)) {
+triggerEvent = eventCursorExit;
+  } else if (key.cmp(D)) {
+triggerEvent = eventMouseDown;
+  } else if (key.cmp(U)) {
+triggerEvent = eventMouseUp;
+  } else if (key.cmp(Fo)) {
+triggerEvent = eventFocusIn;
+  } else if (key.cmp(Bl)) {
+triggerEvent = eventFocusOut;
+  } else if (key.cmp(PO)) {
+triggerEvent = eventPageOpen;
+  } else if (key.cmp(PC)) {
+triggerEvent = eventPageClose;
+  } else if (key.cmp(PV)) {
+triggerEvent = eventPageVisible;
+  } else if (key.cmp(PI)) {
+triggerEvent = eventPageInvisible;
+  }
+
+  if (triggerEvent  0) {
+Object obj3;
+
+addActionDict-getVal(i,obj3);
+	additionActions[triggerEvent] = LinkAction::parseAction (obj3,  catalog-getBaseURI());
+	obj3.free();
+  }
+
+}
+
   } else {
 additionActions = NULL;
   }
diff --git a/poppler/Annot.h b/poppler/Annot.h
index 93f82bf..4f522d7 100644
--- a/poppler/Annot.h
+++ b/poppler/Annot.h
@@ -453,6 +453,21 @@ public:
 type3D  // 3D 25
   };
 
+  enum AnnotTriggerEvent {
+eventCursorEnter,	// E
+eventCursorExit,	// X
+eventMouseDown,	// D
+eventMouseUp,	// U
+eventFocusIn,	// Fo
+eventFocusOut,	// Bl
+eventPageOpen,	// PO
+eventPageClose,	// PC
+eventPageVisible,	// PV
+eventPageInvisible,	// PI
+NumberOfEvents
+  };
+
+
   Annot(XRef *xrefA, PDFRectangle *rectA, Catalog *catalog);
   Annot(XRef *xrefA, Dict *dict, Catalog *catalog);
   Annot(XRef *xrefA, Dict *dict, Catalog *catalog, Object *obj);
@@ -1147,7 +1162,7 @@ public:
   AnnotWidgetHighlightMode getMode() { return mode; }
   AnnotAppearanceCharacs *getAppearCharacs() { return appearCharacs; }
   LinkAction *getAction() { return action; }
-  Dict *getAdditionActions() { return additionActions; }
+  LinkAction **getAdditionActions() { return additionActions; }
   Dict *getParent() { return parent; }
 
 private:
@@ -1170,7 +1185,7 @@ private:
   AnnotWidgetHighlightMode mode;  // H  (Default I)
   AnnotAppearanceCharacs *appearCharacs;  // MK
   LinkAction *action; // A
-  Dict *additionActions;  // AA
+  LinkAction **additionActions;   // AA
   // inherited  from Annot
   // AnnotBorderBS border;// BS
   Dict *parent;   // Parent
-- 
1.7.3.5

___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

[poppler] [Patch] glib-frontend: add PopplerActionJavaScript object

[jose.ali...@gmail.com]

Hi,

the following patch add a wrapper for JavascriptActions to the glib
bindings. Comments and review welcome.


Greets

José
From f4b0e8d9f038e3ef4033e2c9af45bb48adf0c224 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Aliste?= jali...@src.gnome.org
Date: Tue, 29 Mar 2011 04:56:37 -0400
Subject: [PATCH] glib: add PopplerActionJavaScript wrapper.

---
 glib/poppler-action.cc |   22 ++
 glib/poppler-action.h  |   14 +-
 2 files changed, 35 insertions(+), 1 deletions(-)

diff --git a/glib/poppler-action.cc b/glib/poppler-action.cc
index ca88ca4..8b95543 100644
--- a/glib/poppler-action.cc
+++ b/glib/poppler-action.cc
@@ -140,6 +140,10 @@ poppler_action_free (PopplerAction *action)
 			g_list_free (action-ocg_state.state_list);
 		}
 		break;
+case POPPLER_ACTION_JAVASCRIPT:
+		if (action-javascript.script)
+			g_free (action-javascript.script);
+		break;
 	default:
 		break;
 	}
@@ -514,6 +518,20 @@ build_movie (PopplerDocument *document,
 }
 
 static void
+build_javascript (PopplerAction *action,
+		  LinkJavaScript *link)
+{
+	action-javascript.script = NULL;
+	if (link) {
+		GooString *script;
+
+		script = link-getScript();
+		if (script)
+			action-javascript.script =  g_strdup (script-getCString ());
+	}
+}
+
+static void
 build_rendition (PopplerAction *action,
 		 LinkRendition *link)
 {
@@ -650,6 +668,10 @@ _poppler_action_new (PopplerDocument *document,
 		action-type = POPPLER_ACTION_OCG_STATE;
 		build_ocg_state (document, action, dynamic_castLinkOCGState* (link));
 		break;
+	case actionJavaScript:
+		action-type = POPPLER_ACTION_JAVASCRIPT;
+		build_javascript (action, dynamic_castLinkJavaScript* (link));
+		break;
 	case actionUnknown:
 	default:
 		action-type = POPPLER_ACTION_UNKNOWN;
diff --git a/glib/poppler-action.h b/glib/poppler-action.h
index 6bb87ba..b3df50b 100644
--- a/glib/poppler-action.h
+++ b/glib/poppler-action.h
@@ -36,6 +36,7 @@ G_BEGIN_DECLS
  * @POPPLER_ACTION_MOVIE: play movies. Since 0.14
  * @POPPLER_ACTION_RENDITION: play multimedia content. Since 0.14
  * @POPPLER_ACTION_OCG_STATE: state of layer. Since 0.14
+ * @POPPLER_ACTION_JAVASCRIPT: Javascript. Since 0.18
  *
  * Action types
  */
@@ -50,7 +51,8 @@ typedef enum
 	POPPLER_ACTION_NAMED,		/* named action*/
 	POPPLER_ACTION_MOVIE,		/* movie action */
 	POPPLER_ACTION_RENDITION,   /* rendition action */
-	POPPLER_ACTION_OCG_STATE/* Set-OCG-State action */
+	POPPLER_ACTION_OCG_STATE,   /* Set-OCG-State action */
+	POPPLER_ACTION_JAVASCRIPT	/* Javascript action */
 } PopplerActionType;
 
 /**
@@ -145,6 +147,7 @@ typedef struct _PopplerActionNamed  PopplerActionNamed;
 typedef struct _PopplerActionMovie  PopplerActionMovie;
 typedef struct _PopplerActionRendition  PopplerActionRendition;
 typedef struct _PopplerActionOCGState   PopplerActionOCGState;
+typedef struct _PopplerActionJavaScript PopplerActionJavaScript;
 
 /**
  * PopplerDest:
@@ -265,6 +268,14 @@ struct _PopplerActionOCGState
 	GList*state_list;
 };
 
+struct _PopplerActionJavaScript
+{
+	PopplerActionType  type;
+	gchar 		  *title;
+
+	gchar		  *script;
+};
+
 /**
  * PopplerAction:
  *
@@ -282,6 +293,7 @@ union _PopplerAction
 	PopplerActionMovie movie;
 	PopplerActionRendition rendition;
 	PopplerActionOCGState ocg_state;
+	PopplerActionJavaScript javascript;
 };
 
 #define POPPLER_TYPE_ACTION (poppler_action_get_type ())
-- 
1.7.3.5

___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] [Patch] Parse Additional Actions for Widget Annots.

[jose.ali...@gmail.com]

Hi,

On Tue, Mar 29, 2011 at 9:24 AM, Leonard Rosenthol lrose...@adobe.com wrote:
 Why to LinkActions when they can be to ANY type of action?

Maybe I missunderstood the poppler core, but it seems to me that
LinkAction is the the base clase for any action in poppler core,
that's why I use LinkAction.

 And are you creating a new JavaScriptAction class to handle the details of JS 
 processing??

There is already a LinkActionJavascript action which stores the
javascript of the action as a GooString, so we need to use that (see
my other patch, were I add the glib wrapper for this).
More precisely, details of JS processing will be dealt by bindings
(and/or viewers), not by  poppler core, but according to the my
understanding of the PDF spec. Exposing these additional Actions makes
sense even for viewer that don't want to support javascript.


Greetings

José


 -Original Message-
 From: poppler-bounces+leonardr=adobe@lists.freedesktop.org 
 [mailto:poppler-bounces+leonardr=adobe@lists.freedesktop.org] On Behalf 
 Of jose.ali...@gmail.com
 Sent: Tuesday, March 29, 2011 1:35 AM
 To: poppler@lists.freedesktop.org
 Subject: [poppler] [Patch] Parse Additional Actions for Widget Annots.

 Hi,

 Here is a patch to parse the additional actions dict that is present in 
 Widget Annots. This is one of the first patches we will need to get 
 javascript support as many of the javascript in the pdfs are encoded in 
 JavascriptActions that are associated to the AditionalActions dictionary. All 
 comments welcome, specially about the way I am saving the AditionalActions as 
 an Array of Pointers to LinkActions.


 Greetings,


 José

___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] Plans to get Javascript support in Poppler.

[jose.ali...@gmail.com]

Hi,

On Wed, Mar 23, 2011 at 11:20 PM, Leonard Rosenthol lrose...@adobe.com wrote:
 Another API-related question you need to consider is how to handle trigger 
 events (ISO 32000-1:2008, 12.6.3).  Is it a push or pull model? What 
 parameters get passed in/out?


Could you explain what do you mean? I am not sure I understand the
questions... I haven't thought much about events yet, but the general
idea I have , at least from the point of view of Evince,  is that if
you have two objects, a FormField, which is the Javascript Object, and
a FormFieldWidget, which is a real widget in Gtk+. Then, in the
implementation, the FormFieldWidget will forward the signals/events he
receives (like focus-in,focus-out, keystrokes, etc.) to the FormField
object. Then the magic of Seed comes in, which translates the Gtk+
signals/Events into Javascript Events, so when you have AA
dictionaries, you just register the code inside each of the entries as
listener of the right Event on the formfield js object. I have no idea
how the JScore in Qt works, but I imagine that the idea there is not
that different...

Anyway, we are just starting to plan and implement the basic stuff we
need before implementing the bridget between poppler and js, which
will of course take us a long time :)

 I would also suggest that you consider supporting JS in Forms before other 
 types, since that is (by a LARGE MARGIN) the most commonly found JavaScript.  
  There are lots of documents on the net that you can use to test.

Of course, Javascript forms have  the highest priority, since many of
the forms out-there are useless without Javascript support.

Greets

José


 Leonard

___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

[poppler] Plans to get Javascript support in Poppler.

[jose.ali...@gmail.com]

Hi list,

So we are discussing how we can join efforts to start adding poppler
support for Javascript in poppler.  With Carlos and Pino, we got some
agreements that I want to share with you so you can add comments/
regards/ questions/ etc. These are by no mean sealed plans, I only try
to account for a summary of the discussion we had yesterday in IRC.
The basic plan is:

1. To start a plain core js API in C++ that will use poppler core
API and will follow as close as possible the PDF JS API [1]
2. Each frontend, glib and qt, can then decide how they will bind
these API to their frontends.

Notes:
a) Of course, will coding 1, we will need to add functionality to core
poppler that is not there yet, like for instance, support for
Javascript Actions.
b) the plain core js api in 1 should be probably very easy, as it
should wrap more or less directly from the core poppler, but we choose
this way so the code can be shared by Okular and Evince.
c) Just for completness, I give more details about the glib frontend,
in which I plan to hack: Our idea in 2) is to wrap  the plain core
js api into a GObject API, and then use the automatic
GObject-Javascript glue that (will be) is provided to us by Seed using
gobject-introspection (BTW, in this case the Javascript engine comes
from Webkit).

That's more or less it. Comments/questions/rants/patches welcome.

Greets

José


@Carlos, Pino, if I forget something (or I got something wrong),
please add it here.
___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler

Re: [poppler] Patch for embedding videos in to the pdf

[jose.ali...@gmail.com]

On Tue, Mar 1, 2011 at 5:37 PM, Albert Astals Cid aa...@kde.org wrote:
 A Dimarts, 1 de març de 2011, srinivas adicherla va escriure:
 Hi

          I found some way using gstreamer to get the image from some frame.
 But I need to test it. How can I put gstreamer includes and libs. I tried
 some hack in Makefile but that doesn't work.
 Please tell me some method so that I can test my code.

 I don't think adding a dependency on gstreamer for poppler is something that
 make sense.
As Albert says, putting a dependency of poppler in gstreamer is too
much. You just should allow to put screen annotations
without any appareance. It's up to the viewer (AND NOT poppler) to
have some dependency in some Video platform to use the first frame(or
whatever specified by the pdf) as an appeareance for the screen
annotation where there is no appareance).

Greets

José


 Albert
 ___
 poppler mailing list
 poppler@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/poppler

___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler