Target

This document briefly describes the current organization of the development process.

Versioning

The version numbering is designed on a simple sequential model. No special numbering will be used to indicate the status of each version, this will be announced elsewhere. The current status of version 1 is obsolete. The current status of version 2 is stable. Once the library has seen sufficient testing, we will make a release candidate. After sufficient testing in the user community with this version, the version will be announced as a stable version (or a subsequent version, if bugfixes are required, possibly resulting in multiple release candidates before an acceptable stable version is achieved). Any bugfixes that are required after the release version is announced will be incremented in minor number and announced as bugfixes to the release.

Extensions

Because of enhanced extensibility in version 2, we are not planning to fork the code when 2 becomes stable. Instead we plan to add enhancements to version 2 via the extension mechanism. The code will be forked only when further enhancements will require changes to the codebase that would threaten the library's stability.

Current development effort is directed toward an "effects" extension and a "packer" extension.

Target

The functionality target for the 2.x release of phppdflib follows.

General Functionality

The goal of phppdflib is to create a php class that allows a programmer to easily integrate PDF formatted output into php scripts.

The library is designed with a "no limitations" theory. All limitations to the capibility of the library are vested in the php programming language or the limits of the PDF format. Furthermore, version 2 will not do bounds checking to ensure limits are maintained. Thus version 2 is capable of creating PDF files that exceed the implementation limits of the PDF format and are thus invalid. For the moment, staying within the limits of the PDF standard are the responsibility of the calling application.

Methods

The following methods are planned to go into version 2.x. This is our primary method for determining when we have reached release status for the library. Italic text indicates improvments over version 1.

• draw_text() will support the following:
  • The 14 standard PDF fonts
  • Fill, stroke, or both painting modes
  • All point sizes
  • Rotate font to any angle
• A function will exist to return the width of strings drawn in a particular font at a particular point size
• draw_rectangle(), draw_line(), draw_circle() supporting:
  • Colors
  • Line weights
  • Fill, stroke, or both painting modes
• new_page() supporting symbolic codes for common page sizes as well as an absolute representation to allow any page size to be created
• zlib compression
• jfif_embed()
• png_embed()
• Function to return the size of an embedded image in PDF units
• image_place()
• A system of default values for specifying page sizes, text parameters and any other parameters that may be reused (to avoid the need for parameters arrays each time an object is painted)
• An error reporting system that allows a client script to accurately detect and sanely react to errors
• A set of template functions that allow a user to generate layout templates, and then paint information to the page, formatted by those templates
  • template->create()
  • template->place()
  • template->size()
  • template->text()
  • template->field()
  • template->paragraph()
  • template->rectangle()
  • template->line()
  • template->circle()
  • template->image()

Note that the Template interface obsoletes both the band interface and the column interface. These methods have been removed from the library.