As far as I am concerned this is Uwe's decision to make.  I would be happy
to see you guys have direct CVS access to maintain this extension and make
whatever changes you deem necessary.  Uwe?

Many of the things you mention are things people have been asking for, and
if it can't be implemented without a few backward compatibility issues, so
be it.  As long as we document this fact and you guys keep an eye on the
mailing lists and the bug database and steer people who might be hit by
the incompatibility in the right direction then everything is cool.

-Rasmus

On Wed, 24 Jan 2001, Rainer Schaaf wrote:
> Hello,
>
> 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
> *stringparam,
>  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
> again.
>
> 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
> this.
>
> 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
>
> --
> 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]
>
>


-- 
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