xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 32789] [PATCH] Arabic Shaping not Supported by FOP
Date Fri, 30 Apr 2010 07:21:21 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=32789

Glenn Adams <glenn@skynav.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |NEW

--- Comment #19 from Glenn Adams <glenn@skynav.com> 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.

Mime
View raw message