Details
-
Type: New Feature
-
Status: Done/Fixed
-
Priority: Major
-
Resolution: Fixed/Completed
-
Affects Version/s: None
-
Fix Version/s: 1.5
-
Component/s: None
-
Labels:None
Description
Background
=========
One of our users has created a prototype for generating a PDF with printable address labels for a selected set of contacts. This is modeled as a search result "task" (similar to Export or Print). The prototype demonstrates the value of this functionality and can be referenced for ideas about impelmentation. However, in order to keep our project copyright intact, we SHOULD NOT COPY any of the code from the prototype.
You can download the prototype (and read a summary of code revisions) here:
http://wiki.civicrm.org/confluence/display/CRM/CiviCRM+Plugins - "Task to Print PDF Labels" section
Also note that the prototype implementation is in "alpha" state - and has a number of open issues and bugs.
We will use the same open-source library as the prototype - fpdf.org - and incorporate it in our distro (make sure to grab latest stable version).
Implementation
============
UI flow and output can follow prototype with the following changes and enhancements...
1. Replace hard-coded label data contents (in prototype Core/Report/Pdf.php) with the following (configurable)
content:
$display_name
.. plus...
2. Add a "Confirm task..." step to the flow (as we do with "Assign Tag to Contacts..."). This form will have two element:
- A drop-down of available Avery Label codes (sourced from $_Avery_Labels in fpdf.php) - so user can pick which label they are using. This replaces the hard-coded Avery label var ('L7163') currently passed in Pdf.php.
- A drop-down of available location_type titles - so user can determine which location is used on the labels. Default for this drop-down is "Primary Location" (which means use the is_primary location for all contacts). However, user could pick "Home" or any other configured location_type.
3. Review the information about charsets and encoding here:
http://fpdf.org/en/tutorial/tuto7.htm
... and determine what is needed to handle (hopefully) UTF-8 encoded data (we want to avoid the utf8-decode hack in the prototype as this will cause problems with non-US names.