Goals

[knownasilya]

What does this do, or what will it do? Is this project still alive?

[achambers]

@mysterlune I am going to be needing pdfjs functionality soon. This addon seems to be in its's infancy and has not been committed to for 3 months.

I'd much prefer we combine efforts rather than have two separate addons with the same intentions.

What are your plans here? Are you planning on actually maintaining this repo?

If I start contributing to it extensively, will you be around to review and merge PR's?

/cc @knownasilya

[mysterlune]

Yes. I'm very much in favor of collaborating on this. I have not had a lot of time to focus on this in the last few months, though prior to that my research into using PDFJS with Ember was primarily exploratory.

I've experimented using PDFJS to render a pdf into an Ember ListView (and have faced some challenges keeping my skunkworks project up-to-date as that project has undergone heavy development). I would be interested in your thoughts on ways that we could optimize the rendering of pdfs (whether in a list or a "paged" orientation) into Ember views or components. ListView seemed like a great starting point, though the goals of that project seem a bit thin for supporting something like a pdf.

I am very interested in making something useful here.

Basically my goals for this project are to:

• supply a template/component that uses the src for a pdf resource
• render the pdf (lazy-optional) into a list of pages (canvases)
• provide interactivity for highlighting the "hidden" text
• as a bonus, I'd like to be able to have active links in a pdf remain active (whether linking to an external resource or a section within the same document (which will probably be harder than it initially sounds))

My organization's instructor/student client application provides rich interactivity for documents currently (highlighting, inline and bubble comments, capturing audio feedback, decorating with human and machine feedback on submitted works). It's pretty amazing stuff, and rather specialized in terms of features. It's in no way a simple "reader" application.

I'd like to hear what you are working on, and what you think this addon could benefit from.

[knownasilya]

Go components all the way, views are "going away" for 2.0.

[mysterlune]

(nods)

[mysterlune]

In this addon project, there is a set of components that all should be implemented in a way that allows for flexible UI composition. For example (though this is not a complete list, but what I have in mind for a start), in addition to the pdf-document component, also a pdf-pagination, pdf-find (or pdf-search?) and pdf-print-download components. Basically, the set of features PDFJS's own viewer implements, but built as Ember components that tie together with the EventBus injected as a dependency for messaging events to all participating pdf-* components.

In this way, a consumer of this addon could put the pagination component anywhere in the layout -- since we'll use dependency injection to share the EventBus with the document component. A search box (pdf-find [or -search?] could be placed by the pagination in a footer -- or in the header, side panel, or the top of a thumbnail list view…).

An admirable example of this kind of component addon is https://github.com/bustlelabs/ember-mobiledoc-editor. This one is for Mobiledoc Kit what ember-pdfjs should be in the end for PDFJS. The component structure allows you to compose a layout in a very flexible way. The trick the project solves elegantly is inter-component messaging. This is done in the ember-mobiledoc-editor project by ensuring that participating components (the toolbar or layout cards) are passed the editor object as an argument.

The addition of the EventBus object to the PDFJS library adds pub/sub/event-management feature. the EventBus was implemented to provide centralized messaging across the PDFJS viewer and libraries.

It does feel that PDFJS is the primary source of interactivity with the pdf object, which makes the role of Ember much more about "how do we lay out toolbars, side panels, thumbnail scroll views, etc" than it does about "how do we compose rich components to use within a PDFJS viewer context. Prior versions of ember-pdfjs seemed to try to lift the DOM and pdf management out of PDFJS and into Ember-land in a way that was off direction.

You will see in the latest version (v0.4.0) that I've update the ember-pdfjs addon to support the later version(s) of PDFJS including the EventBus, and have all but ripped out the old way of rendering individual pages for the document (component-within-component style rendering) which forced us to do suboptimal list handling in order to manage the DOM outside of PDFJS.

The Ember part really should be about layout, routing, adaptation to the service backend, dependency injection. As much as possible, I believe PDFJS's UI libs should do the lifting for in-document elements (like anchors, highlight, possibly annotations?)

I think there is discussion to be had about where Ember components vs PDFJS-managed DOM objects fit.

[mysterlune]

@collegeimprovements, @DarrenDrumm, I'd like to know if you have any comment as to whether this project's goals are in alignment with your project.

Please leave your comments here, or file an issue. I'd be happy to work with you to ensure the goals of this project encompass yours.