Hi "1T3XT info" and sorry for the late answer! I just wanted you to know that I'm still on track, and the raw porting work is going on quite well, some 90% should be done by now.
The next steps would be: 1. some very basic design considerations This is especially the question: to which extent do I want to port the J2SE classes that are used by iText to PHP, and to which extent do I use PHPs language constructs or more specialized PHP classes instead. This is a question of maintainability, lean code, speed, API compatibility, consistency and ease of use for either users with PHP vs. iText skills. 2. settle down for an API. As it turned out, it's not even possible, neither would it be easy, to make the PHP port API-compatible with Java-iText. The most prominent obstacles are: (a) different semantics, (b) the complex of different data types + weak typing + no true overloading and (c) limitations of the PHP OOP implementation. a) Different semantics is not only '$this->write' instead of 'this.write', or 'PdfName::NEXTPAGE' instead of 'PdfName.NEXTPAGE'. It also means '$this->write' instead of just 'write', or 'self::MARKUP_UNDERLINE' instead of just 'MARKUP_UNDERLINE'. PHP always needs the class name or reference explicitely. b) The typing-related complex means we have to work around overloading. In many cases this is a really messy and ugly job (retrieve arguments, switch on count, check every single one for type and/or class in every combination, and then either manually throw exceptions or reroute to a private function). In some cases not even this is possible, because two Java datatypes both match a PHP datatype. So there are quite a few methods where I'd certainly like to reduce overloading, which on the other hand means: more API break c) In PHP, properties may not be initialized with an expression nor an object instance. When in Java we use PdfName::PAGE, in PHP we can only use new PdfName(PdfName::PAGE) or - with a trick - PdfName::$PAGE. The classname 'List' and the names of several constants are protected keywords in PHP. Casting between custom classes is one of the dirtiest spots of PHP5. "(PdfAnnotation)$annot" won't work. I need to provide a function "cast" in every single class I might want to cast to, and then I still have to use PdfAnnotation::cast($annot). Creating a new PdfAnnotation and merging the data in should be not better though. While there will certainly be other areas, where problems may arise, this should be more or less all problems that influence a possible API. I'm explaining this so much in details, so people don't complain afterwards about the API changes. 3. Make the code work This will be quite a lot of work, as with so many changes, we should probably test, debug and possibly optimize pretty much every single function iText offers. However, having the most basic functionality work would be enough to publish some kind of alpha release and to invite others to hunt the remaining bugs down with joint efforts. Do I have a timeline? Well, I'd love to move on to phase 3 as soon as possible. While April 2009 might sound realistic, the date could shift considerably into both directions. I just don't know yet. But there should be no doubt that there will be a beta or RC available by the end of this year. How about a Lite version of iText? Well, on one hand, I've made considerable progress with porting the full version. On the other hand, I don't really see which features should be stripped. If you said an (even) 'better', 'improved', 'more streamlined' and/or 'easier to use' version of iText, I'd be with you. If the PHP platform turns out to be not performant enough for one or the other feature, this might be a basis for an iText lite version, though. Another aspect: >From my POV, iText's development process seems to be less community driven than it could be. This might be because it is such a mature product or to keep the API frozen, because it has been adopted by so many companies and organizations. However, software redesigning without API restrictions (as Drupal does it once a year) may lead to considerable improvements without stripping functionality. In this case, the PHP experience might help open up the development model, because the PHP won't be API-compatible anyway, so API changes can be tested in PHP first and then you can decide whether you want to take over a certain feature taken to Java. I will keep you informed about the further progress! Best regards, Pancho 1T3XT info wrote: > > That's very good news! > And also: you're realistic, it won't be obvious. > Please keep us posted on your progress. > I'm thinking of making a "lite" version of iText. > It might be easier to port a light version that the full iText. > -- View this message in context: http://www.nabble.com/PHP-port-in-the-works-tp21609367p21927214.html Sent from the iText - General mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ iText-questions mailing list iText-questions@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.1t3xt.com/docs/book.php
