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

Reply via email to