Re: [PHP-DEV] Proposal for updating the PDF-extension

[Boian Bonev]

hi,

> >There are probably other points which need to be discussed like
> >what a function should return if it fails. Many php functions return
> >false but pdflib's api requires to return -1.
>
> Again, we should be consistant within PHP the language.
> ie. if function fails -> RETURN_FALSE.
>
> IMO.

+1

also you can manage extension global errno and handle errors, provide for
example pdf_str_error(void) or something.

most people need not check all possible cases. on the other side it should
be possible and not only possible but easy.

b.


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposal for updating the PDF-extension

[Rasmus Lerdorf]

> I agree. PHP doesn't need to map the C API's one-to-one but implement PHP
> functions in the PHP spirit and in a consistent way. That consistent way is
> returning false.
> We've talked about this numerous times. When we implement an extension
> module for a C library we don't even necessarily need to map the functions
> one-to-one to PHP but think of what API would be the most useful for PHP
> programmers allowing them flexibility but staying with it's short
> development time advantage.

In the case of the current pdflib extension, it is very close to a 1:1
mapping already with a few missing things.  The error handling needs to
stay PHP consistent, but I don't really mind if we end up with a 1:1
mapping in this case.  That shouldn't exclude some higher level functions
at some point, but if a complete 1:1 mapping makes life easier for you
guys and it means a well-maintained and well-documented pdflib extension
for PHP then I am all for it.

-Rasmus


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposal for updating the PDF-extension

[Andi Gutmans]

At 05:43 PM 1/24/2001 +0200, Jani Taskinen wrote:
>On Wed, 24 Jan 2001, Uwe Steinmann wrote:
>
> >On Wed, Jan 24, 2001 at 03:07:09PM +0100, Cynic wrote:
> >> confuse folks. and the consensus (at least I got it it's agreed
> >> on) is pdf_add_local_link-like names.
> >>From the php point of view there should be underscores but
> >the pdflib api doesn't use them except for the one after the 'pdf'.
> >The question is, shall we enforce the php naming or allow the
> >pdflib naming.
>
>This API is used in PHP -> use the PHP naming. If we start making
>exceptions we end up having a mess in our hands.. :)
>
> >There are probably other points which need to be discussed like
> >what a function should return if it fails. Many php functions return
> >false but pdflib's api requires to return -1.
>
>Again, we should be consistant within PHP the language.
>ie. if function fails -> RETURN_FALSE.
>
>IMO.

I agree. PHP doesn't need to map the C API's one-to-one but implement PHP 
functions in the PHP spirit and in a consistent way. That consistent way is 
returning false.
We've talked about this numerous times. When we implement an extension 
module for a C library we don't even necessarily need to map the functions 
one-to-one to PHP but think of what API would be the most useful for PHP 
programmers allowing them flexibility but staying with it's short 
development time advantage.

Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposal for updating the PDF-extension

[Rainer Schaaf]

Jani Taskinen wrote:

> On Wed, 24 Jan 2001, Uwe Steinmann wrote:
>
> >On Wed, Jan 24, 2001 at 03:07:09PM +0100, Cynic wrote:
> >> confuse folks. and the consensus (at least I got it it's agreed
> >> on) is pdf_add_local_link-like names.
> >>From the php point of view there should be underscores but
> >the pdflib api doesn't use them except for the one after the 'pdf'.
> >The question is, shall we enforce the php naming or allow the
> >pdflib naming.
>
> This API is used in PHP -> use the PHP naming. If we start making
> exceptions we end up having a mess in our hands.. :)
>

This is the same problem for us. We have to support eight (number is
still growing) PDFlib language bindings including documentation and
samples, on differnent plattforms. So it is very essential for us to have
a consistent API and documentation. We cannot afford to duplicate the
whole PDFlib-Manual for each language binding, and therefore strive to
supply a single unified reference Manual for all languages. The benefit
for the developer is that allwas has access to the latest and
comprehensive PDFlib documentation. The maintainers not neccesarly have
to duplicate the manual into the PHP documentation. Even another little
detail, if somebody changes from i.e. ASP to php they can simply reuse
the pdflib-code :-)

>
> >There are probably other points which need to be discussed like
> >what a function should return if it fails. Many php functions return
> >false but pdflib's api requires to return -1.
>
> Again, we should be consistant within PHP the language.
> ie. if function fails -> RETURN_FALSE.
>

After some discussion with Thomas, we are convinced to do it the php way.
The extension will take care to convert the PDFlib error convention to
PHP conventions. In addition PDFlib exceptions are mapped to php_error().

>
> IMO.
>
> --Jani

Rainer + Thomas ([EMAIL PROTECTED])
--
Rainer Schaaf   [EMAIL PROTECTED]http://www.pdflib.com
___PDFlib - a library for generating PDF on the fly



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposal for updating the PDF-extension

[Rasmus Lerdorf]

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 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list

Re: [PHP-DEV] Proposal for updating the PDF-extension

[Jani Taskinen]

On Wed, 24 Jan 2001, Uwe Steinmann wrote:

>On Wed, Jan 24, 2001 at 03:07:09PM +0100, Cynic wrote:
>> confuse folks. and the consensus (at least I got it it's agreed
>> on) is pdf_add_local_link-like names.
>>From the php point of view there should be underscores but
>the pdflib api doesn't use them except for the one after the 'pdf'.
>The question is, shall we enforce the php naming or allow the
>pdflib naming.

This API is used in PHP -> use the PHP naming. If we start making
exceptions we end up having a mess in our hands.. :)

>There are probably other points which need to be discussed like
>what a function should return if it fails. Many php functions return
>false but pdflib's api requires to return -1.

Again, we should be consistant within PHP the language.
ie. if function fails -> RETURN_FALSE.

IMO.

--Jani



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposal for updating the PDF-extension

[Cynic]

+1 for PHP way on both questions. The language should be consistent.
I think one of the goals - a major one - of PHP (or any other 
programming language, for that matter) should be:

provide a single, consistent interface to many different areas 
of programmer's life. In other words, I think consistency is 
what distinguishes a programming language from a pile of libs 
quickly hacked together into something resembling Crude Puppy 
rather than anything else.

At 17:16 24.1. 2001, Uwe Steinmann wrote the following:
-- 
>On Wed, Jan 24, 2001 at 03:07:09PM +0100, Cynic wrote:
>> maybe they should be pdf_find_font, pdf_add_local_link etc?
>> that would be more consistent with the func-naming convention, 
>> I guess, but I'm in no position to decide this.
>> but I definitely think that it should be either underscore 
>> everywhere, or just between the ext. prefix and the rest of 
>> the name (i. e. pdf_findfont, pdf_injectasmanywordasyouseefit), 
>> or whatever, but it should be consistent. that is, don't 
>> mix pdf_open_file with pdf_add_locallink, because that only 
>> confuse folks. and the consensus (at least I got it it's agreed
>> on) is pdf_add_local_link-like names.
> From the php point of view there should be underscores but
>the pdflib api doesn't use them except for the one after the 'pdf'.
>The question is, shall we enforce the php naming or allow the
>pdflib naming.
>
>There are probably other points which need to be discussed like
>what a function should return if it fails. Many php functions return
>false but pdflib's api requires to return -1.
>
>  Uwe
>-- 
>  [EMAIL PROTECTED]
>  Tel: +2331 987 4528Fax: +2331 987 375
--end of quote-- 




Cynic:

A member of a group of ancient Greek philosophers who taught
that virtue constitutes happiness and that self control is
the essential part of virtue.

[EMAIL PROTECTED]



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposal for updating the PDF-extension

[Uwe Steinmann]

On Wed, Jan 24, 2001 at 03:07:09PM +0100, Cynic wrote:
> maybe they should be pdf_find_font, pdf_add_local_link etc?
> that would be more consistent with the func-naming convention, 
> I guess, but I'm in no position to decide this.
> but I definitely think that it should be either underscore 
> everywhere, or just between the ext. prefix and the rest of 
> the name (i. e. pdf_findfont, pdf_injectasmanywordasyouseefit), 
> or whatever, but it should be consistent. that is, don't 
> mix pdf_open_file with pdf_add_locallink, because that only 
> confuse folks. and the consensus (at least I got it it's agreed
> on) is pdf_add_local_link-like names.
>From the php point of view there should be underscores but
the pdflib api doesn't use them except for the one after the 'pdf'.
The question is, shall we enforce the php naming or allow the
pdflib naming.

There are probably other points which need to be discussed like
what a function should return if it fails. Many php functions return
false but pdflib's api requires to return -1.

  Uwe
-- 
  [EMAIL PROTECTED]
  Tel: +2331 987 4528Fax: +2331 987 375

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposal for updating the PDF-extension

[Cynic]

maybe they should be pdf_find_font, pdf_add_local_link etc?
that would be more consistent with the func-naming convention, 
I guess, but I'm in no position to decide this.
but I definitely think that it should be either underscore 
everywhere, or just between the ext. prefix and the rest of 
the name (i. e. pdf_findfont, pdf_injectasmanywordasyouseefit), 
or whatever, but it should be consistent. that is, don't 
mix pdf_open_file with pdf_add_locallink, because that only 
confuse folks. and the consensus (at least I got it it's agreed
on) is pdf_add_local_link-like names.

At 14:26 24.1. 2001, Rainer Schaaf wrote the following:
-- 
>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 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]
--end of quote-- 




Cynic:

A member of a group of ancient Greek philosophers who taught
that virtue constitutes happiness and that self control is
the essential part of virtue.

[EMAIL PROTECTED]



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]