There have been a number of requests for a development roadmap to track the progress of feature requests and bug fixes, so we have put together a roadmap showing the current state of our development plans.

There are certainly some items that we've forgot to add to the roadmap, and the existing items will undoubtedly be reordered as time goes by, but it's a start, and we'll update it over the next few weeks and see if it proves to be a useful resource for us and for you.

Excellent! One thing I'd like to add about the 7.x support for forms: please give us CSS properties to set the form features -- not all of us use XHTML.

Likewise, a few simple CSS properties to mimic the <META> tag support for XHTML would make a grand addition somewhere soon. =)

I've added a new item to the roadmap for 6.0 rev 5 to add a @prince-pdf CSS rule that could be used for PDF-specific properties, such as:

@prince-pdf {
    prince-pdf-title: "My PDF Document";
    prince-pdf-author: string(meta-author); /* named string taken from document */
}

It's still not clear what will be the best way to implement the form controls, and certainly it would be nice to have an extensible mechanism, as even HTML forms will be changing in the future (see the upcoming WebForms specification). New CSS properties might be the easiest way for now, but there are also binding technologies like XBL that can be used to attach behaviours onto elements.

Wonderful stuff - that's great guys, keep up the good work!

<><

There is no need for any hacks. Prince supports XML, so just use elements from the XHTML namespace. The entire document does not need to be XHTML:

<foo>
<input xmlns="http://www.w3.org/1999/xhtml" name="bar" type="text" />
</foo>

The same can be done with Web Forms 2.0 as well (which, indecentally, makes XForms redundant), but for now, just stick with the regular form inputs that Prince supports.

Yes, the question is how Prince should handle the XHTML form elements internally, as currently XHTML elements do not receive much special treatment at all, we just apply a default style sheet to style them appropriately. We may need to hardwire special case treatment for <input>, <select> etc. directly into Prince, but it would be nice if the appearance of the form controls could be customised more easily, for example by an external style sheet or something like that.

Hi,

In the roadmap, BiDi support for Hebrew and Arabic is mentioned, but I can't find anything about supporting complex script support.

Thai, various Indic scripts (Devanagari for Hindi, Malyalam, Tamil, Bengali, Tibetan, and so forth), Khmer, Lao, Burmese as well as Arabic need complex shaping (context-dependent reordering, ligature, joining, etc). If vowel marks are used (as for religeous/biblical text), Hebrew became complex as well. For some African languages and old English, even Latin is 'complex'.

I've just tested Prince on Linux with Thai and Hindi and it doesn't work properly

Supporting complex shaping is essential for Prince's acceptance in Thai, India and China (Chinese government requires that minority scripts be supported and Tibetan and Uguru need complex shaping).

On Linux, taking advantage of Pango would enable Prince to support those scripts. I'd like to hear about your thoughts/plans on complex script support.

Thanks !

In addition to Pango, you may consider ICU (International Component for Unicode) Layout Engine. Unlike Pango, it's not available on Linux by default so that you may need to link statically with it.

At the moment we are considering support for Arabic, Thai and Indic scripts, probably in that order. I'm not sure yet whether we can directly use Pango or ICU, but we will certainly be investigating both of those options.

Reviving this very very old thread, we have of course already added support for Unicode with complex scripts including Arabic and Hindi. We don't yet support form components, but in Prince 9 rev 2 we have added support for configuring PDF metadata from the command-line, and via a JavaScript interface.