Re: [Devel] FT_Set_Hint_Flags problem

[Owen Taylor]

On Wed, 2003-05-07 at 04:09, David Turner wrote:
> Hi Owen,
> 
> Owen Taylor wrote:
> > I've attached the semi-public interfaces in Pango to the mail, as you'll
> > see, it's pretty high level and simple; no details of the OpenType
> > tables are exported other than the script/language/feature hierarchy.
> 
> Thanks a lot, I've attached a prototype header of what could become the
> API of the replacement OpenType Layout code. The documentation is included
> in the comments, as always. You'll notice that:
> 
>    - it's very similar to what you sent :-)
> 
>    - the caller must provide in-memory images of the various
>      OTL tables to the library.
> 
>    - it doesn't include something like "otl_ruleset_shape" since
>      I've not finalized a good "OTL_String" type for now.

Some notes learned from experience with pango_ruleset_shape():

 A) The normal progression is:

     1) Apply GSUB rules
     2) position the resulting glyphs according to their natural widths
     3) then apply GPOS rules.

    However, in some cases, it's necessary to do intervention between
    1) and 2). (The example we've run into is for the South Indian
    languages Tamil and Malayalam - see
    http://bugzilla.gnome.org/show_bug.cgi?id=111166
    for gory detail.)

    So, while it might nice to be able to do 1-3 in one step, it's also
    necessary to be able to apply multiple rulesets successively to the
    same string.
    
 B) It's needs to be possible to figure out what output glyphs
    correspond to what input glyphs. Of course, the mapping is
    N => M rather than 1 => 1.

    One way of representing this is to give to each output glyph
    the index of the first input glyph in the "cluster" to which
    it belongs. (GSUB rules never really reorder glyphs, they
    just do substitutions)

    E.g., if the substitution maps 4 glyphs to 4 glyphs as:
    AB=> A', C=>C', D=>D'E', that can be represented by 1,3,4,4.

    (This is basically how the log_clusters[] array in PangoGlyphString
    works.)
            
> My idea is the following:
> 
>    - port the original FreeType 1 / Pango code so that it implements
>      this new API. I expect doing this with a few tricks like macro
>      renaming, implementing "fake" FT_Stream to access the tables,
>      etc.. but nothing that really alters the code structure.
> 
>      the idea is that Werner's code works and should be used as a
>      reference implementation (including all necessary patches)
>
>    - once the reference is completed and working, rewrite the
>      implementation to use direct in-memory table parsing (after
>      validation) instead.

Sounds very reasonable. Full validation on initial load is certainly
something I support; trying to deal with failure and unpredictable
times in the shaping process could be nasty.


>  /************************************************************
>   *
>   * @function: otl_ruleset_set_feature
>   *
>   * @description:
>   *   sets all rules corresponding to a given feature tag
>   *   in a given ruleset
>   *
>   * @input:
>   *   ruleset     :: target handle.
>   *   feature_tag :: 4-byte feature tag
>   *
>   * @note:
>   *   this function does nothing is the feature is not listed
>   *   by the parent @OTL_Info. this allows you to use
>   *   @OTL_FEATURE_TAG_NONE when needed.
>   */
>   OTL_API( void )
>   otl_ruleset_set_feature( OTL_RuleSet  ruleset,
>                            OTL_Tag      feature_tag );
> 

One thing to note here is that the Pango API, copying what Werner
had in the FreeType API has:

 void pango_ot_ruleset_add_feature (PangoOTRuleset   *ruleset,
                                    PangoOTTableType  table_type,
                                    guint             feature_index,
                                    gulong            property_bit);


Note the "property_bit" parameter. This is because you want to apply
some features to only some characters -- an easy example is the 
init/medi/fini features for Arabic. Then, pango_ot_ruleset_shape()
'gulong *properties'. There probably are other ways to set this up,
but they all seem considerably less efficient.

Also - probably just an oversight - I don't see an equivalent to
FT_MAKE_TAG() in your header file. 

Regards,
                                            Owen