Re: Re: PEAR inclusion request: php_jh_pdf

le 10/04/02 19:24, Johann Hanne à jonny@xiroi.de a écrit : > bjoern@baer.main.de: >> Is it similar to http://pc4p.sourceforge.net/ ? > After having a look at it: Yes, it is. So it looks like Alexander and me > have developed two similar things. This was not my intention. However, > now there ARE two projects and probably only one will make it into PEAR. > Of course I like my approach more, but that's only because it has exactly > the API I want, which is no wonder as I designed it. I think we'll have to > see which API the other people prefer and the more popular project should > go into PEAR. This is the 'survival of the fittest' game and I won't be > angry if Alexander's project will make it. Well, according to me, both your classes do not handle the same purpose or at least, they don't do it the same way. For that reason, and also because there are for instance more than just one HTML_Form class in PEAR, I think both should go into PEAR. The main difference I see is that PC4P looks like a very good helper class, which can handle all the process of creating a simple PDF document while yours is more open to custom-made extensions (correct me if I'm wrong) and allow flexibility for complex layouts. Based on this difference, it should be easier to find a name for your class.. > bmansion@mamasam.com: >> I have looked at PC4P but it does not handle PDI (PDF Import) functions of >> PDFLib which is an absolute need for a PDF wrapper class. PC4P seems also a >> bit closed in terms of architecture, it handles the PDF from its creation >> (even before the pdf_open call). It is quite difficult to plug your own >> methods in PC4P. This is why I would prefer your approach which is closer to >> what I would need and also seems more open. > I do not have immediate plans to implement a PDI wrapper class. But as you > wrote it's no problem to use the PDI functions while still using my PDF That's fine. Alexander is also implementing a PDI wrapper as he said in his last mail. > classes. I'll probably add something to handle the document-level stuff > (PDF_open(), PDF_new_page, etc.), but I'll always try to keep its use > optional. This would be handy, but according to me, it reduces the flexibility of the API when it becomes compulsory. I mean that you should be able to set any PDF parameter using the PDF_set_parameter function. >> You might want to change the name of your class for a better and simplier >> one, have a deeper look at PC4P, include PDI functionalities, have a look at >> HTML_Table for table handling ;) You might also want to create an PDF_Common >> class which would handle attributes for tables, cells, rows, colors, fonts, >> size, alignment ... the way you want. This could be based on HTML >> specifications ? > I know that the name "php_jh_pdf" is ugly, i've only chosen it because I'm > too lazy to think of a better one and using my initials is the best > way to avoid name clashes. If you have some idea, let me know! > I have plans to abstract the table (and maybe other) definitions in some way. > Maybe HTML, maybe XML, I'm not currently aware of a good solution. Any > suggestions? XML would be great (for a start ;-) In conclusion, +1 to integrate both projects into PEAR, and finally have a PDF directory with some content in it. I really missed such classes when working on one PDF related project recently. Bertrand Mansion Mamasam