I'm a new employee at PDFlib GmbH. Our company decided to improve and
support the PHP-extension for PDFlib as soon as possible. Therefore I
contacted Uwe Steinman the maintainer of this extension. He suggested to

discuss with the list, where to put the changes I'm doing. Uwe offered
to bring the changes into CVS, after clarifying where they should go.

We would be happy if the next maintainance release of PHP will contain
the stuff, but of course I don't know your plans regarding this.

Why changing the current extension? If PDFlib GmbH wants to support the
PHP-extension, we need that the complete API is supported by the
extension. This has the advantage that the original PDFlib API-Reference

will be valid for PHP users too.

This is what I prepared (on the basis of the current extension from the
cvs, pdf.c V1.65). So I'm in the process of coding all these things.
Most of the work is already done, but I'm still testing wheter
everything is working as expected. One goal was to make the new
extension compatible to the existing one. The details are below.

New PDFlib API for php4:

New functions (available in PDFlib, but not yet in PHP):

        PHP_FE(pdf_new, NULL)           /* new function */
        PHP_FE(pdf_delete, NULL)        /* new function */
        PHP_FE(pdf_open_file, NULL)     /* new function */
        PHP_FE(pdf_get_buffer, NULL)    /* new function */
        PHP_FE(pdf_findfont, NULL)      /* new function */
        PHP_FE(pdf_setfont, NULL)       /* new function */
        PHP_FE(pdf_setpolydash, NULL)   /* new function: not yet
finished */
        PHP_FE(pdf_concat, NULL)        /* new function */
        PHP_FE(pdf_open_CCITT, NULL)    /* new function */
        PHP_FE(pdf_open_image, NULL)    /* new function */
        PHP_FE(pdf_attach_file, NULL)   /* new function */
        PHP_FE(pdf_add_note, NULL)      /* new function */
        PHP_FE(pdf_attach_file, NULL)   /* new function */
        PHP_FE(pdf_add_note, NULL)      /* new function */
        PHP_FE(pdf_add_locallink, NULL) /* new function */
        PHP_FE(pdf_add_launchlink, NULL)/* new function */

these functions got some more (optional) parameters.

        PHP_FE(pdf_open_image_file, NULL)  /* new parameters: [char
 int intparam] */
        PHP_FE(pdf_stringwidth, NULL)   /* new parameters: [int font,
float size
] */

The function pdf_add_outline was renamed to pdf_add_bookmark and
PHP_FALIAS(pdf_add_outline, pdf_add_bookmark, NULL) will map it to the
old name.

Possible incompatible changes in the PHP-PDFlib API:

We removed the PHP-Resource-handling of PDFlib Resources in the
wrapper-code on most places. This was neccesary to return the documented

returnvalues. The proper resourcehandling is done by PDFlib internaly so

it seems to be unnecceary that the PHP-extension tries to do the work

PDF_open_image() PDF_open_CCITT() and PDF_open_image_file() now return
an Integer, so the returnvalue is no longer handeld as a PHP-resource.
Functions like PDF_get_value(=, PDF_close_image(), PDF_place_image(),
pdf_get_image_width(), pdf_get_image_height() are changed to reflect

PDF_add_bookmark() now returns an Integer.

Some new features available now:

PDF_new() + PDF_open_file replaces PDF_open() and PDF_delete() allows to

cleanup the whole PDFlib-stuff.

=> now you may create many different PDF_files with one PDF-Object.
=> PDF_set_parameter($p, "compatibility", ...) now works

PDF_get_buffer() now works this allows the users to generate  PDF-Files
in memory with full control over the generated PDF-File.

+ all the missing functions of the PDFlib 3.x API (see above).

All your input is welcome.


Rainer Schaaf       [EMAIL PROTECTED]        http://www.pdflib.com
_______PDFlib - a library for generating PDF on the fly________

PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to