The complex scripts (CS) patch is now committed to trunk at revision 1293736 [1].
[1] http://svn.apache.org/viewvc?view=revision&revision=1293736 The functionality added by this patch is enabled by default. If you do not need complex script support or do not need the benefit of OpenType Advanced Typographic Tables (e.g., advanced kerning, ligatures, etc) in non-complex scripts, then you can disable these features by one of three mechanisms: (1) add <complex-scripts>false</complex-scripts> to your fop.xconf file (as a child of the <fop/> element), or (2) specify -nocs option as a command line option when invoking FOP, or (3) invoke setComplexScriptFeaturesEnabled(false) on the FOUserAgent instance you use programmatically; If you do not disable complex script features and you use non-complex scripts, there is a small processing and memory penalty which would not be incurred otherwise. Furthermore, for large fonts with many OpenType Advanced Typographic Tables, such as Arial Unicode MS, you may notice a significant processing penalty at font load time. At present, the complex script features support only PDF, AT (XML), and IF output formats. Support for other formats is expected to be added over time, depending on user needs. In particular, support for PS, PCL, AFP, RTF, Java2D, and image output formats is not yet implemented. Other limitations apply to CS features as well, including: - only OpenType advanced typographic tables supported - only certain complex scripts are supported in this initial patch, specifically Arabic, Hebrew, Devanagari, and preliminary (largely untested) support for Gujarati and Gurmukhi - only certain OpenType CS fonts have been tested, see [2] for the current list; [2] http://skynav.trac.cvsdude.com/fop/wiki/SupportedFonts I will be migrating (to the Apache FOP documentation and wiki) and enhancing the (limited) documentation I originally provided at [3]. So stay tuned for updates. [3] http://skynav.trac.cvsdude.com/fop/wiki/ComplexScripts Finally, to give you advance warning, you will notice when you run this new FOP the first time that your font cache will be rebuilt. This is because the serialized font cache data has changed, and thus the old version of the cache won't load. If you switch back and forth between this new work and the pre-CS trunk, then the older form of the font cache will be rebuilt. I have noticed that rebuilding the font cache often takes quite a bit of VM space, and, as a consequence, you might run out of memory if you run FOP the first time on a large FO file in combination with rebuilding the font cache. One way to deal with this is to first run FOP on a small, input file that has the side effect of rebuilding the font cache. Subsequent invocations will not have a problem since they won't rebuild the cache a second time. Regards, Glenn
