bugm17n - Bugs: bug #44697, Mark2mark attachment ambiguous to...

 
 

bug #44697: Mark2mark attachment ambiguous to libotf client

Submitter:  Richard Wordingham <richardw>
Submitted:  Thu 02 Apr 2015 08:09:11 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 04 Apr 2015 05:41:05 PM UTC, comment #2: 

I've implemented an upwards-compatible solution and offer it for consideration.  Unfortunately, the application needs some modifications to benefit from the changes.  I attach:

1) Changes to otf.h.  Most of the change is documentation of the change.  The only code change is an additional member of field f in the type OTF_Glyph.  This does not change the storage size.

2) Changes to otfdrive.c.  I've grouped the options in a single struct rather than pass a multitude of flags and supporting data.

3) Changes to an application to use the cure.  The file changed is ftfont.c from Version 24.4.1 of Emacs.

(file #33535, file #33536, file #33537)

Richard Wordingham <richardw>
Thu 02 Apr 2015 09:05:25 PM UTC, comment #1: 

I think I can see a cleaner mechanism.  At user command, (prefixed to the 'features' argument, e.g. between a leading TAB and semicolon), the positioning and glyph code of mark2 glyph can be stored via a pointer in a new submember f15 of type OTF_Glyph parallel to f6.  (Strictly, it would be a new type, say OTF_Glyph2, but a pointer to OTF_Glyph2 can be used interchangeably with a pointer to OTF_Glyph.)  This preserves binary compatibility, and existing buggy systems can continue as before.

The data pointed to would be on the heap, but a simple protocol can be set up for its deallocation.  For example, the first active f15 member could be constrained to point to the start of this memory.

If this is used in the function passed to m17n-flt as drive_otf(), the glyph can be saved in the m17n-flt glyph structure, for the m17n structures allow users to effectively add private fields to the glyph type. This would be appropriate if GPOS lookups were made feature by feature, rather than in their numerical order.  The Latin and Arabic OpenType specifications still call for ordering by feature, rather than by numerical order.

Is this the right way forward?

Richard Wordingham <richardw>
Thu 02 Apr 2015 08:09:11 AM UTC, original submission:  

Although libotf correctly works out which mark a mark is attached to, this information is not passed to the caller of any member of the OTF_drive_gpos*() family of interface functions.

Normally this is not a problem - interacting marks tend to be sorted out into runs of the same kind.  In these cases, the mark attached to is the preceding mark, and the Emacs code in function ftfont_drive_otf() in ftfont.c makes this assumption.

However, this does not work in some unusual but natural strings, such as Northern Thai ᨻᩦ᩠᩵ᩋᩬ᩶ᨦ 'relatives', where the sequence of marks is SIGN II (above), TONE-1 (above), <SAKOT, NA> (below), OA BELOW (below), TONE-2 (above).  TONE-2 attaches to TONE-1, but the client assumes it is attached to OA BELOW and mispositions it.

An upwards compatible solution would be for the client to signal that it will accept complete information and receive it through a supplementary fake glyph, just as multiple lookup type 1 and type 2 positionings are combined using the 'accumulate' option.  I note that the Emacs client currently fails to implement this part of the interface.  The glyph code of the glyph attached to would be sufficient information - OpenType offers no mechanism to choose between preceding glyphs with the same glyph code.

Making the font reorder the combining marks is not a solution.  Moroever, it is the font that decides whether <SAKOT, X> is a combining mark or a non-spacing mark for several characters X, so m17n cannot perform the desirable reordering.

Richard Wordingham <richardw>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #33535:  otf.h added by richardw (36KiB - text/x-chdr)
file #33536:  ftfont.dif added by richardw (3KiB - video/dv)
file #33537:  otfdrive.dif added by richardw (16KiB - video/dv)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by richardw (Submitted the item)
  • -email is unavailable- added by richardw
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-04-04 richardw Attached File- Added otf.h, #33535
        Attached File- Added ftfont.dif, #33536
        Attached File- Added otfdrive.dif, #33537
    2015-04-02 richardw Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code