PDF use cases

This has the potential to be a great feature set. In many community organizations, for whatever reason, there's a large set of people who need to be included in the community who are not able to participate on-line. Paper is a great technology for including these users. To allow them to experience the "life" of the site, and the life of the community that the site represents, I think that some way to select a pile of nodes (like through a view, or a taxonomy query, or through a module like simpleNews) is needed. So the sequence would look something like:

1. Select a pile of nodes somehow (see above)
2. Choose some level of detail in which to represent the nodes (either titles, teasers, full)
3. Apply some default theming or styling functions, allowing others to plug in their own fairly easily (realizing that needs will vary considerably about this)
4. Generate a PDF based on the styled node collection
5. Either display the PDF, or plop it in some directory, or attach it to a node and tag it with a particular taxonomy term.

I'm thinking of the case where an organization might want to periodically generate a newsletter / update for its offline members. Potentially it could generate several newsletters, or even generate individually customized newsletters, which a staff person could print and mail (or hand out) to the offline members.

Hope this helps you see some of the potential for this kind of module.

I want to generate a list of events listed in a table.
This table should be downloadable as PDF File.
So that every member has an offline version and also members without internet could get a great looking one for their use.
I need the same functionality for a telephone list, too

What I personally don't need is a way to download a single node.

About theming:

1. I think it is necessary to be able to theme everything. Beginning with the header and ending with the footer :)
2. PDF output of views should be themeable individually - I should be able to create a special theme for every view or maybe even for every content type.
   One Idea could be to extend the tcpdf class and add a new method: SetThemeFunctions() which accepts an array of different theme functions for footer, body, head and a general one. If one of this function was not specified it should use the default one.

What I like is, that tcpdf has a html interpreter, but which does not work perfectly.
What I really dislike with tcpdf is that it has no proper error handling every single and stupid error ends with a die()
I created for the a feature request at sourceforge: http://sourceforge.net/tracker/index.php?func=detail&aid=1652731&group_i...

Tobias Maier - http://www.tobiasmaier.info/
--
Switch to Firefox!
Steig auf den Firefox um!
mozilla.com

'Publication' or 'Journal' output of the PDF module, that would be a good facilation of such module and add Drupal yet one more advantage over other CFS's..

There is an open source project from Canada Open Journal Systems (OJS) does exactly that -only that
http://pkp.sfu.ca/?q=ojs
example site
http://ijoc.org/ojs/index.php/ijoc

i think similar 'publication or journal' content type can be achieved with conjunction of the book module and the taxonomy -as volumes- and with an calendar view output of mothly or weekly or other publication durations..
the challange is the PDF output in a single document in multiple pages.. a publication structured document in volumes -that is a single PDF file in this case..

just a PDF module usage thought. (I am not a coder to make coding contribution unfortunalely)

I use drupal for a corporate intranet site storing all types of corporate data including: policies, procedures, processes, memos, documents of all types. We use the PDFView module to output pdfs of nodes when we need to send it to someone who, for whatever reason, doesn't have access to the main site. Because we are an outsourced IT support organization we frequently have to post our process/policy/procedure docs to the mother company site b/c the intranets have no connection to each other.

For the most part the module meets our needs as is, but ideally should be more customizable through the user interface. Currently, as admin, I have to do all the customizations in the theme by overriding the function.

Features we'd like to see for our use case are:
1. custom output per content type
2. UI settings for header, footer, margins, logo, & cover page (per content type)
3. the ability to designate a role that could change #2 but not #1. Ideally this would extend to the OG group manager level so that group managers could change their format for their content only.

Until I got this module working, I was using "Print Friendly Pages" and instructing users to output to the freeware CutePDF (with gsview) pdf printer utility and was researching customizing that module to offer the option of sending that output to tcpdf.

It seems to me that there is a great deal of commonality in uses between the two modules-- it might make sense to combine resources and develop jointly.

I'm still learning to program drupal, but am eager to volunteer my services on this project.

wow--- wikipublisher is very cool. I'd not seen that one before. And yes, having that functionality would be awesome. I'll have to keep that solution in mind for sites that require nicely formatted output.

I need to be able to:

1. select which parts of node to convert to pdf (don't show nav, logon etc.)
2. use existing node security for viewing the pdf
3. be able to control the mapping of html elements and classes to particular pdf rendering (Paragraph text is block, 10 pica height; H3 is inline, italic)

I had to do something similar for some custom built form generation software that needed view only pdf versions of forms and used the following approach:

1. Start with xhtml for web browser + xml document articulating exceptions for the particular document
2. transform with xslt to xsl-fo
3. apply apache fop to get to PDF (or jfor for rtf)

Ignoring the tools used which are probably not appropriate for a Drupal module,
the problem with html to pdf is that the developer will want to determine exactly how each html element maps to pdf rendering. This can end up involving a whole new intermediary language. I started off with Doug Tidwell's XSLT at http://www.ibm.com/developerworks/library/x-xslfo2app/ for the trasformation and allowed for a per document type override of all html elements to xsl-fo mappings.

Its vaguely outlined at:

http://www.johnbarclay.com/programming/plus_flowchart.pdf and

http://www.johnbarclay.com/programming/plus_documentation.pdf

But who wants to develop an intermediary language for mapping html to xsl-fo or whatever document preceeds the pdf document in the transformation process.

When print css came along I ended up repeating the info in print css as in the configuration xml files. ( though I could have generated the print css from the config xml I suppose.)

An solution could use print css as the xhtml to pdf configuration language. The print css file could be the same print css page used by the browser in printing or a second print css file used only to convert to pdf. Aside from print css being something people are used to working with the display:none rule could be used to hide unwanted parts of a page from pdfs and fullfilling my 1 and 3 use cases.

I'd be willing to help on this module. I've been working with Drupal for 6 months or so and php for a couple of years.

My PDF requirement is to convert a collection of in-house paper forms into a digital format, so that once filled out over HTML, a final PDF version becomes available (not unlike the on-line IRS tax forms approach).

In that usage case, it seems to me that Sam's "glue" might be something like http://www.ros.co.nz/pdf/ -- though honestly, it might not handle the positioning of HTML elements (the print page to PDF approach) in the way this group requires, or at least, not without tweaking.

Given my forms requirement, I'm curious about your thoughts on the following approach: write a module to hook into certain content types and provide additional fields requesting X and Y coordinates for that content type's form elements on the final PDF document. Such a module would ideally be CCK-field aware. This user-collected positioning data would then fed to the "glue" above.

Thoughts?

In case anyone has gotten here and not see, PDFView now informs users it is unsupported and directs people to http://drupal.org/project/print, Printer Friendly Pages.

Nothing seems to support Views.

I want to be able to upload PDF documents and have drupal nodes index them directly, e.g. as book pages. It should load within the content area or targeted block just like any other node. You could certainly do this sort of thing using frames (yuk), but drupal seems to eschew frames. If drupal nodes supported , drupal could open a new window with a reference to the PDF file in htdocs, though that content would not be managed by drupal.

- Mike
Computational Intelligence