bugFree UCS Outline Fonts - Bugs: bug #59699, Lam and alef presentation forms...

 
 

bug #59699: Lam and alef presentation forms should not ligate

Submitted by:  David Corbett <dscorbett>
Submitted on:  Wed 16 Dec 2020 01:35:50 AM UTC  
 
Category:  individual character(s) Severity:  3 - Normal
Item Group:  character substitution issue Status:  Fix posted
Privacy:  Public Assigned to:  Steve White <Stevan_White>
Open/Closed:  Open Release:  development

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Tue 12 Jan 2021 11:56:14 PM UTC, comment #6: 

I hope the post I just made fixes the problem.
The method was as I described: I made s separate set of auxiliary forms just for alif and lam, and formed ligatures only on these.
Attached find a test page... I have my doubts that I have tested everything adequately.

(file #50713)

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Tue 12 Jan 2021 12:12:33 PM UTC, comment #5: 

As I had feared, in fact the lookups are executed in the order
'frac' 'ccmp' 'locl' 'isol' 'fina' 'medi' 'init' 'rlig' 'dlig'
regardless of thir order in the lookup tables.

Since I'm using the presentation form characters for the glyphs for positional forms, the problem is, that the distinction between an original character from the main Arabic range, and one from the presentation ranges is lost after the positional lookups.  That means, there is no way to distinguish them for a following ligature lookup.

One approach would be to to chunk the use of the presentation forms altogether for positonal glyphs.  I'm not inclied to do that, because it would be a lot of work, and because it would necessitate hundreds of duplicate auxiliary glyphs.

Maybe just alif and lam.  Have special glyphs for just their positional forms, which can then later be used in ligature lookups.

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Fri 18 Dec 2020 04:36:49 PM UTC, comment #4: 

That’s the most explicit thing I can find in the standard.

I don’t think it’s quite accurate to say that those paragraphs are about something deprecated. U+206C itself is deprecated, of course, but the fact that the default behavior is not to modify the shapes Arabic presentation forms is not deprecated: earlier in that section, the standard says “if contextual forms for Arabic characters are desired, then the nominal characters should be used, not the presentation forms with the shaping selectors.”

David Corbett <dscorbett>
Wed 16 Dec 2020 02:43:07 PM UTC, comment #3: 

Ah.  I was looking in Ch. 9.

While I accept the behaviour of the font is wrong...

Are any of these paragraphs refer to something that isn't deprecated?

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Wed 16 Dec 2020 02:20:54 PM UTC, comment #2: 

https://www.unicode.org/versions/Unicode13.0.0/ch23.pdf#page=17 says:

> The character shaping selector format characters are used in conjunction with Arabic presentation forms. During the presentation process, certain letterforms may be joined together in cursive connection or ligatures. The shaping selector codes indicate that the character shape determination (glyph selection) process used to achieve this presentation effect is to be either activated or inhibited. The shaping selector codes do not nest.
>
> From the point of encountering a U+206C INHIBIT ARABIC FORM SHAPING format character up to a subsequent U+206D ACTIVATE ARABIC FORM SHAPING (if any), the character shaping determination process should be inhibited. If the backing store contains Arabic presentation forms (for example, U+FE80..U+FEFC), then these forms should be presented without shape modification. This state (inhibited) is the default state in the absence of any character shaping selector or a higher-level protocol.


That means that, by default, the shapes of Arabic presentation forms are meant to stay static.

David Corbett <dscorbett>
Wed 16 Dec 2020 12:57:37 PM UTC, comment #1: 

Hi David,

Could you please cite a passage from the standard to support your claim?  I just looked, and nothing pops out as quite the prohibition as you state it.

I accept this as a bug.  The cause seems pretty clear -- because I placed the fina medi init lookups before the rlig lookup.  It shouldn't be too hard to fix, provided the order can be switched.  (I only question it because the order of Indic lookups is fixed.)

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Wed 16 Dec 2020 01:35:50 AM UTC, original submission:  

Arabic presentation forms represent specific glyphs that are immune to contextual shaping. When a lam presentation form (e.g. U+FEDF ARABIC LETTER LAM INITIAL FORM) precedes an alef presentation form (e.g. U+FE8E ARABIC LETTER ALEF FINAL FORM), they should not be ligated. (A lam–alef ligature using presentation forms requires a character like U+FEFB ARABIC LIGATURE LAM WITH ALEF ISOLATED FORM.) This affects FreeMono and FreeSerif, both regular and bold.

David Corbett <dscorbett>

 

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

Attach Files:
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by Stevan_White (Posted a comment)
  • -email is unavailable- added by dscorbett (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-01-12 Stevan_White Attached File- => Added arabic-presentation.html, #50713
        StatusProceeding => Fix posted
    2020-12-16 Stevan_White StatusNone => Proceeding
        Assigned toNone => Stevan_White

    Back to the top


    Powered by Savane 3.7