Mailing-List: contact dev-help@pdfbox.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@pdfbox.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Thu, 29 Mar 2012 08:36:05 +0200
From: Jeremias Maerki <dev@jeremias-maerki.ch>
To: dev@pdfbox.apache.org
Subject: Re: PDFBox Project for GSoC 2012
In-Reply-To: 
 <CAN7nmvQ5-HFT84-yKHWKTB_Qa42pJib3c8cUvCM3S3s=ypYjPg@mail.gmail.com>
References: 
 <CALmsGz2Ngjq8WV_UFBRYqN_SvTmzbtYKhvUHSuf8=yRwNXR8-w@mail.gmail.com>
 <CAN7nmvQ5-HFT84-yKHWKTB_Qa42pJib3c8cUvCM3S3s=ypYjPg@mail.gmail.com>
Message-Id: <20120329083604.3F7B.60BA733C@jeremias-maerki.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Tharaka,

Object Inspector: I'm not sure you need a tree for inspecting a single
object. The tree is useful when the PDF debugger is integrated as an
alternative view of a PDF. I'd expect to have a customized window (a
plug-in ;-) ) for each kind of object when inspecting it. A bitmap image
would display information about the size, the color space and profile,
effective resolution. Clicking on a word would display its font and
color. I guess it would be quite cool to have a button that says "jump
to object tree" so it would switch to the debugger view and focus on the
selected object. Imagine having viewer and debugger side-by-side in
separate views and the object that you click on in the debugger is
highlighted in the viewer. Wow. But I'm dreaming. ;-)

Unfortunately, JPF is off-limits for PDFBox if it is used for core
functionality because it's under the LGPL license. Only optional
components/plug-ins may depend on LGPL libraries. But I think the normal
JAR Service Provider mechanism would already be good enough as a plug-in
framework:
http://docs.oracle.com/javase/6/docs/technotes/guides/jar/jar.html#Service%=
20Provider
We use that extensively over in Apache XML Graphics land. I would
suggest to base the GUI on Java 6 where you have the service lookup
built in: http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.=
html

Swing with Nimbus generally sounds good to me.

OTOH, an RCP application would actually offer the whole pluggability
(even at runtime) and an Eclipse-like workbench which would be great for
such an application. But it would also mean practically re-writing both
the PDF viewer (although the PDF painting via Java2D should still be
usable) and debugger functionality.

Both Swing and RCP are non-trivial to learn. On the technical side I'd
probably favor RCP just a little bit, mostly because it's OSGi-based
(I'm biased there) even if the Eclipse world does ugly things to OSGi.
Furthermore, I know few good Swing applications but many good RCP
applications. Maybe that's an indicator. But I'd have to learn RCP
myself if I was to help out with this.

Optional Content Groups (since PDF 1.5) are groups of objects (think
"layer") that can be enabled and disabled. I think that's advanced
functionality that the mainstream doesn't really need. But I'm also not
sure what Medhi means with transparency layers.

On 29.03.2012 03:55:28 Tharaka Nayanajith Wijebandara wrote:
> Hi,
>=20
>=20
> Thanx mehdi, you have summarized all primary objective and we can continu=
e
> discussion based on it.
>=20
> For the GUI, I'm going to use Swing Framework and to modernize we can go
> for some available look and Feel such as nimbus. Is there any suggestion?
>=20
>=20
> I need some ideas about PDF object inspector and since it tool for
> developer all you can give some suggestions. In my opinion we can use swi=
ng
> tree for this. User can right click on object and click =91inspect=92 com=
mand
> in the menu, then it will show the object and it properties in the tree a=
nd
> highlight object margin in the PDF view.
>=20
>=20
> Plugin frame is another feature to consider. We can use and adapt some
> available plugin frame for PDFReader rather than going for new our own on=
e.
> As per my understand Java Plug-in Framework (http://jpf.sourceforge.net/)
> is good one we can use and it is XML based. Is there any apache framework
> for this? If I'm correct, maven project is based on plugin framework.
>=20
>=20
> Mehdi, I would like to add bookmark feature also in to primary objective
> list. It will allow user to view, add, edit and delete book marks. And al=
so
> I'm confused about what you mean by supporting optional content and
> transparency layers.
>=20
> On Mon, Mar 26, 2012 at 1:49 PM, mehdi houshmand <med1985@gmail.com> wrot=
e:
>=20
> > Hi Tharaka,
> >
> > Ok, well let's start with thinking about how this GUI is going to look.=
 In
> > its current form, it's looking a little dated, it might be worth using =
some
> > of the GUI frameworks out there to spruce it up a little and making it =
a
> > bit more modern. So if we get a list of TODOs (starting with Jeremias'
> > suggestions):
> >
> > - Investigate and design a proposal for upgrading the PDFReader GUI (i.=
e.
> > modernizing it)
> > - Implement a PDF object inspector to display PDF object properties whe=
n
> > objects are "clicked-on" in the viewer
> > - Implement a type-writer feature to add/remove text from a content str=
eam
> > from within the PDFViewer
> > - Design a plugin framework for the viewer
> >
> > Maybe those are a good list of primary objectives? We should think abou=
t
> > some secondary objectives, like possibly supporting Optional Content in=
 the
> > view (not sure if it already is) and better handling of transparency
> > layers?
> >
> > Just some thoughts, let's keep this discussions fluid for now, we haven=
't
> > actually got that long before we have to submit a proposal though.
> >
> > Mehdi
> >
> > On 22 March 2012 03:04, Tharaka Nayanajith Wijebandara <
> > tharaka.nw@gmail.com
> > > wrote:
> >
> > > Hi,
> > >
> > >
> > > Thanks everyone for your valuable ideas and comments.
> > >
> > >
> > > It seems most of you like to enhancing PDFReader project. Specially I
> > > prefer Jeremias' idea, develop application which allow user to access
> > > PDFBox features through the GUI and PDF viewer with integrated PDF
> > > Debugger. In my opinion it will be very much useful tool for users as
> > well
> > > as developers rather than just another PDF reader. So I would like to
> > > continue with this project. However, since there are several ways to
> > > enhance PDFReader, we have to define the scope of the project accordi=
ng
> > to
> > > priority in next few days.
> > >
> > >
> > > Additionally I want to mention another thing here. As my experience
> > current
> > > PDFReader is also not very much reliable and not working smoothly. I
> > still
> > > can't understand that whether it is problem of code of PDFReader or
> > PDFBox
> > > core. Anyway I think that it's better if we can consider also this in=
 the
> > > project, if it's not some issue in PDFBox core.
> > >
> > > On Wed, Mar 21, 2012 at 10:26 PM, mehdi houshmand <med1985@gmail.com>
> > > wrote:
> > >
> > > > Hi Tharaka,
> > > >
> > > > You have plenty of options here, the student application deadline i=
s on
> > > the
> > > > 6th April (see the calendar
> > > > http://www.google-melange.com/gsoc/events/google/gsoc2012), so you'=
ve
> > > got
> > > > plenty of time.
> > > >
> > > > Let me and/or the community know if you have any questions about th=
e
> > > > projects. If you have an idea of which project you'd prefer, maybe =
we
> > can
> > > > start drawing up some goals and a schedule and discuss with the
> > community
> > > > to get some feedback on which facets are a) interesting b) useful o=
r c)
> > > > both!
> > > >
> > > > Mehdi
> > > >
> > > > On 20 March 2012 15:58, Jeremias Maerki <dev@jeremias-maerki.ch>
> > wrote:
> > > >
> > > > > There are a number of HTML to XSL-FO converters. I've never check=
ed
> > how
> > > > > good the results are but ultimately a native HTML engine is likel=
y to
> > > > > produce better results especially since HTML was not really desig=
ned
> > > for
> > > > > print and has to be retrofitted in CSS3. But again, this is a lar=
ge
> > > > > project and, IMO, out of scope for PDFBox.
> > > > >
> > > > > http://html2fo.sourceforge.net/
> > > > > http://denature.sourceforge.net/
> > > > > ...and probably others...
> > > > >
> > > > > On 20.03.2012 13:02:33 Dexter Mishra wrote:
> > > > > > I vote for a PDS editor kind of stuff.
> > > > > > Another thing regarding the HTML to PDS, cant it be done with
> > XSL-FO
> > > > > > feature?
> > > > > > Thanks
> > > > > >
> > > > > > On Tue, Mar 20, 2012 at 3:03 PM, Maruan Sahyoun <
> > > > sahyoun@fileaffairs.de
> > > > > >wrote:
> > > > > >
> > > > > > >
> > > > > > > > <snip/>
> > > > > > > >
> > > > > > > >>
> > > > > > > >> Although I think that the current PDF Reader can be enhanc=
ed
> > in
> > > > many
> > > > > > > ways
> > > > > > > >> there are already so many Readers out there as well as PDF
> > > support
> > > > > > > within
> > > > > > > >> web browsers my personal opinion is that enhancing PDFBox =
core
> > > > > > > capabilities
> > > > > > > >> would be more beneficial.
> > > > > > > >>
> > > > > > > >> With kind regards
> > > > > > > >>
> > > > > > > >> Maruan Sahyoun
> > > > > > > >>
> > > > > > > >>
> > > > > > > > Check out Jeremias' suggestions of the viewer, it's less of=
 a
> > > > viewer
> > > > > and
> > > > > > > > more of a front-end for a lot of the tools PDFBox has to
> > offer, a
> > > > > PDFBox
> > > > > > > > GUI so to speak rather than a PDF viewer.
> > > > > > >
> > > > > > > I'd still look into enhancing PDFBox core as this will benefi=
t
> > most
> > > > > users.
> > > > > > > Looking at the bugs and issues most come from core capabiliti=
es.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Jeremias Maerki
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Thanks & Regards,
> > > Tharaka Wijebandara,
> > > Faculty of Information Technology,
> > > University of Moratuwa.
> > >
> >
>=20
>=20
>=20
> --=20
> Thanks & Regards,
> Tharaka Wijebandara,
> Faculty of Information Technology,
> University of Moratuwa.


Jeremias Maerki