Re: [Devel] RE: [Freetype] Pango or Freetype and some other questions!!

[Owen Taylor]

The right place to report problems with the OpenType code in
Pango is in bugzilla.gnome.org. 

Unfortunately, I only occasionally have time to work on this code,
and by the time I get another chance to work on the code, I'll
probably forget that a mail was sent here.

Thanks,
                                        Owen

On Tue, 2004-06-29 at 09:29, 786 wrote:
> //sorry for duplicate message.
> 
> Hi, 
> 
> I came across a small problem in working of the Chaining Contextual
> Substitution.
> 
> A little overview into the specification; during text processing, a lookup
> is applied to each glyph in the string before moving to the next lookup. A
> lookup say L1 is finished for a glyph after the client locates the target
> glyph satisfying the backtrack and/or lookahead context and performs a
> substitution and moves onto the next glyph in the sequence. Now the problem;
> Well in the way how it is done in freetype, the substitution output say X is
> actually copied on to the ANOTHER output array (out).  It is only after the
> same lookup is tried on the remaining input (in) string that the
> substitution output X is copied back on to the in string. 
> 
> As a result, during the time the lookup L1 is being applied on the remaining
> input string, it is in a way 'blind' to the substitution that it (itself)
> had earlier done. And in this way the chaining part of the 'chaining context
> subst table' is choked.
> 
> So here is the solution for ccsf3; same can be done for ccsf1 and ccsf2.
> In static TT_Error  Lookup_ChainContextSubst3  Instead of....
> 
> if ( bgc > in->pos || in->pos + igc + lgc > in->length )
>         return TTO_Err_Not_Covered;
>       if ( bgc )
>       {
>          curr_pos = 0;
>          s_in     = &in->string[curr_pos];
>          bc       = ccsf3->BacktrackCoverage;
> 
>       for ( i = bgc, j = in->pos - 1; i > 0; i--, j-- )
>       {
>         while ( CHECK_Property( gdef, s_in[j], flags, &property ) )
>         {
>            AND SO ON....
> 
> Only for the backtrack context, the out array should be used. That is...
> 
>              HERE
> if ( bgc > out->pos || in->pos + igc + lgc > in->length )
>         return TTO_Err_Not_Covered;
>       if ( bgc )
>       {
>           curr_pos = 0;
>           /*Earlier */ 
>           /* s_in     = &in->string[curr_pos]; */
>           /*Now */
>           s_in     = &out->string[curr_pos];
>           bc       = ccsf3->BacktrackCoverage;
> 
>                             HERE
>       for ( i = bgc, j = out->pos - 1; i > 0; i--, j-- )
>       {
>         while ( CHECK_Property( gdef, s_in[j], flags, &property ) )
>         {
>            AND SO ON....
> 
> Aamir
> 
> 
> 
> -----Original Message-----
> From: 786 
> Sent: Thursday, June 03, 2004 3:05 PM
> To: 'Owen Taylor'; 'address@hidden'
> Subject: [Freetype] Pango or Freetype and some other questions!!
> 
> 
> /duplicate. Note in previous it was not 'offline' but *offlist*
> 
> Hello,
> 
> Long long time ago there was this conversation....(read below if you have
> time).
> 
> Well I had a small question in mind. But first consider this Mr Lemberg said
> that "not aware of any parts of the substitution specification that the
> PANGO CODE (or that matter the opentype code), doesn't implement" (Note the
> capital PANGO)
> 
> " What about the new GSUB lookup type 8?  AFAIK, this is specifically
> for Urdu.  Have you added it to to PANGO?" (Note the capital PANGO)
> 
> Well what I don't understand is why are we calling it Pango code? Shouldn't
> it be freetype's code (ftxgsub.c in freetype package)? Pango uses this code
> after some initial 'script specific processing' when it actually applies the
> rules on 'tagged' input string. So this does not make it pango code. As a
> result when we talk about adding GSUB type 8 don't we actually mean in
> ftxgsub.c.
> 
> >> Have you added it to to PANGO?" 
> So shouldn't it be the freetype guys who should be thinking about adding it?
> And if it does have to be added then it's right in the OT code in pango
> where other types are implemented. 
> 
> Another question: Say for the moment 'All the GSUB tables has been
> implemented' is there a any list of which features have so far been
> implemented. Is calt implemented? I have pango-1.2.5 & Freetype-current,
> this does not?
> 
> 
> And finally Pango-1.2.5 does not implement calt, that's no problem..it can
> easily be added and tested in gedit. Calt uses the LookupType 6: Chaining
> Contextual Substitution in ftxgsub.c. But there seem to be some problem; the
> calt rules listed in the font do not seem to apply at some instances. Now
> this could either be the problem with my gedit/linux or with the lookuptype
> 6's implementation. Can Freetype's team allow me to please discuss this
> problem with them offlIST?
> 
> Thanks
> 
> Aamir
> 
> 
> -----Original Message-----
> From: Owen Taylor [mailto:address@hidden 
> Sent: Tuesday, October 07, 2003 1:57 AM
> To: address@hidden
> Cc: address@hidden
> Subject: Re: [Freetype] Add more claws to FreeType.
> 
> On Sun, 2003-10-05 at 04:54, Werner LEMBERG wrote:
> > > I'm not aware of any parts of the substitution specification that
> > > the Pango code (or that matter the opentype code), doesn't
> > > implement.  For positioning, cursive attachments of vertical text is
> > > not implemented, but even for Mongolian that probably isn't big
> > > deal.
> > 
> > What about the new GSUB lookup type 8?  AFAIK, this is specifically
> > for Urdu.  Have you added it to to Pango?
> 
> No, I wasn't aware of that.. it didn't come up in any fonts I've
> tested widh. It doesn't look that complicated to implement, if
> someone was interested.
> 
> Regards,
>                                       Owen
> 
> 
> _______________________________________________
> Freetype mailing list
> address@hidden
> http://www.freetype.org/mailman/listinfo/freetype
> 
> _______________________________________________
> Devel mailing list
> address@hidden
> http://www.freetype.org/mailman/listinfo/devel

signature.asc
Description: This is a digitally signed message part