https://issues.apache.org/bugzilla/show_bug.cgi?id=32789
Glenn Adams <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW --- Comment #19 from Glenn Adams <[email protected]> 2010-04-30 03:21:13 EDT --- basically, the patch will do the following (in summary): * enhance org.apache.fop.fonts.truetype.TTFFile in order to read the OpenType GSUB and GPOS tables, creating new org.apache.fop.fonts.GlyphTable instances which are added to MultiByteFont instances; * enhance org.apache.fop.fonts.apps.TTFReader in order to write out XML representation of this new data into the FOP metrics file; * enhance org.apache.fop.fonts.FontReader to read the new GSUB/GPOS data stored in the FOP metrics file; * enhance the knuth elements generation in org.apache.fop.layoutmgr.inline.TextLayoutManager, specifically, #processWord, in order to perform substitution processing, which, if the current font supports substitution, causes the font to invoke substitution processing using the new metrics; this substitution process is a multi-stage process starting with a mapping from a sequence of character codes to a sequence of glyph indices, followed by one or more mappings from sequence of glyph indices to sequences of glyph indices, and finally mapping back to a sequence of character codes denoting the final mapped glyphs to be used; * similarly, if font supports these new metrics, then perform glyph positioning process to produce sequence of [dx,dy] adjustments to apply, the application of which follows a somewhat updated logic to handle both X and Y advancements on a per-resultant-glyph (= per output character) basis; implement bidi algorithm specified in XSL-FO 1.1 Section 5.8 "Unicode Bidi Processing", which essentially involves resolving the final inline-progression-direction for each glyph or inline area child of an inline area and each inline child of a line area; * enhance area generation process to make use of inline-progress-direction produced by bidi processing in order to reorder areas to satisfy unicode bidi semantics (both explicit and implied); initially, i am testing against the set of Arabic fonts shipped with Windows 7; but I expect to work with a few other fonts that have GSUB/GPOS tables as well; i am actually doing this work on MacOSX 10.6, so at some point I would hope to add support for the TrueType GX tables known as 'mort' and 'morx' which perform similar processes; note that these processes (substitution/positioning/etc) allow support for a number of complex scripts, not just arabic script; e.g., the indic scripts, southeast asian, mongolian, tibetan scripts, etc, and also advanced typographic effects on latin, greek, cyrillic, etc., and east asian scripts (e.g., JISX4051) are supported by these processes as well; nevertheless, in order to make use of specific sub-tables of GSUB/GPOS, it is necessary to make use of script specific processing; therefore, I have implemented a mechanism to make use of script information, either supplied by the XSL-FO script property or, by default, scanning the characters to determine their dominant script; I have started by implementing this general mechanism and also specific Arabic and Default script processors; it will then be straightforward to add other script specific support; i don't have a fixed schedule, but I have most of the GSUB code working and tested; i am wrapping up the bidi algorithm work now, and when that is complete to submit a patch for potential incorporation into the trunk; i am hoping to have that patch done within the next 2 to 4 weeks time; as a teaser, i will add an attachment containing several files, one showing an FOP metrics file with the new data (see the <script-extras/> element); the others show the GlyphSubstitutionTable and ArabicScriptProcessor classes, which are not functionally complete, but are sufficiently complete to perform basic Arabic glyphs substitution (but not yet ligature processing); regarding how it will be used, you will need to: * possess or have access to a font in the form of a TTF file that contains GSUB/GPOS metrics; if it is to be used with Arabic, then it must should contain the GSUB lookup tables for the following features, e.g., 'isol', 'init', 'medi', 'fina', and 'liga'; * create the FOP font metrics file for it by using the org.apache.fop.fonts.apps.TTFReader application; update your FOP configuration file as needed to refer to the new font and metrics; reference the font as usual using XSL-FO properties; * where necessary, add explicit use of <fo:bidi-override/> in order to override the default Unicode bidi logic; e.g., to override implicit directionality or to create embedding levels; you can also make use of the explicit Unicode bidi control characters, LRO RLO LRE RLE and PDF, but it is better to use explicit markup with <fo:bidi-override/>; * where necessary, to force or prevent joining behavior when the default would not join or would join, then you can use the ZWJ and ZWNJ Unicode controls, however, forced joining must be supported by the font to have an effect; while force non-joining doesn't depend on the font (though if font did not support joining of two characters in the first place then ZWNJ would have no visible effect); regards, glenn p.s. I have an ICLA on file with the apache office; (In reply to comment #18) > (In reply to comment #17) > > FYI, I am preparing a candidate patch that will add direct support for > > Arabic > > (and other complex scripts). This primarily involves making use of the > > advanced > > typographic tables present in TrueType and OpenType fonts (e.g., 'mort', > > 'morx', 'GSUB' and 'GPOS' tables). Initial support will focus on use of the > > GSUB table. This patch will not have any external dependencies, i.e., it > > does > > not make use of ICU4J. > > > > Regards, > > Glenn Adams > > > Glenn, > Can you please provide more information on this as to when & how will this > update be available? > > Regards, > Sachin Sharma. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
