bugFree UCS Outline Fonts - Bugs: bug #44466, Kienning dialect: Double overline...


bug #44466: Kienning dialect: Double overline position issue

Submitted by:  Hsing-yen He <hammerandsickle>
Submitted on:  Sat 07 Mar 2015 12:36:19 PM UTC  
Category:  individual character(s) Severity:  3 - Normal
Item Group:  letter positioning poor 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 18 Aug 2015 12:03:52 PM UTC, comment #18:

I see the effect in Firefox, with HTML

a&#x0304;&#x0304;&#x0324; e&#x0324;&#x0304;&#x0304; o&#x0324;&#x0304;&#x0304;

and CSS

body { font-variant-caps: small-caps; }

The macrons are overlayed to produce a single macron, as if the mark-to-mark placement lookup were inactive.

I don't see how anything amiss in the font. Yet that lookup is one of the last in the GPOS table, and is enabled for every script, every language. But even then...why would a replacement change the script or language? It shouldn't.

Beats me. Looks like not a FreeFont bug.

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Sun 16 Aug 2015 06:36:33 PM UTC, comment #17:


I found a̤, e̤, o̤ with two macrons doesn't work when I turned small capital on, tested in this page.

Hsing-yen He <hammerandsickle>
Sun 03 May 2015 06:32:03 AM UTC, comment #16:

OK good. Finally!

Let me explain about the pre-composing.

I saw quickly that your original test HTML file had the letters precomposed with macron. That is one issue, and I don' know why the makers of that product would do that.

But I fixed the HTML file, and foud that this did not fix the problem. The rendering was still done as though the letters were pre-composed. That is, before applying the mark placement rules as defined in the font, some layer of software had already pre-composed the letters.

Again, either I really don't understand somehting in the standards, or someody has decided to "help out" by pre-composing certain sequences of letters. Either way, it's disturbing.


Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Sun 03 May 2015 02:58:42 AM UTC, comment #15:


I have made a test with a HTML from file #33819, all these sequences looks well.

(I will explain that MediaWiki is used for building a wiki based website, not for font shaping, but this software can precomposed some of composes certainly after you submit them.)

Hsing-yen He <hammerandsickle>
Sat 02 May 2015 12:57:05 PM UTC, comment #14:

Either I am unaware of some standard that says these characters should be automatically precomposed, or there is a bug in the font shaping software. I don't have time to research it at this time.

Anyway, I just posted a work-around in the font.

Please give it a try!

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Tue 28 Apr 2015 12:30:57 PM UTC, comment #13:

Hi Steve,

I heard that Wikimedia software can automatically normalize some characters, and I am sure that MediaWiki can do it certainly, so I have converted all these sequenses to numeric character references by BabelMap.

Hsing-yen He <hammerandsickle>
Tue 28 Apr 2015 10:01:19 AM UTC, comment #12:


I already noticed that in your test the letters were precomposed with macrons. But it's worse than that.

Something in the font rendering software is also precomposing them. So if you deliberately write
the first two characters get precomposed to a-macron. As I said, this is a mystery to me. I don't see anything in the font that requests that replacement. So why is it happening?

And in this case it's conceptually wrong: This is not an 'a-macron' with a macron over it. It's an 'a' with a double macron over it.

Of course I can fix this by putting further positioning anchors over all the letters with macrons in all 12 font faces. But it's so annoying. Maybe I'll just forcibly decompose all precomposed letters (but that seems equally evil).

Anyway I'm on it.

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Tue 28 Apr 2015 06:32:15 AM UTC, comment #11:

Hi Steve,

I have made a test again, found some of them still positioned incorrect.

Some servers' application may will convert some of composes into precomposeed characters when you submit them (especially MediaWiki), such as <0041 0304> → <0100>, so I add more sequences into here.

(file #33819)

Hsing-yen He <hammerandsickle>
Mon 27 Apr 2015 10:41:27 AM UTC, comment #10:

Hi Steve,

(file #33809)

Hsing-yen He <hammerandsickle>
Sun 26 Apr 2015 08:08:08 AM UTC, comment #9:

Hi Hsing-yen,

I just looked at the macron (U+0304) in Serif and Sans normal faces. They both already have the positioning anchors that would make repeated occurances stack properly.

Could you please test this?

For completeness, I would still like to have a reference to some documentation indicating this is the correct solution.

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Sun 26 Apr 2015 02:19:13 AM UTC, comment #8:

Hi Steve,

I asked again and I got the answer that Times New Roman, Calibri, Georgia, Gentium Plus, Gentium Basic, Verdana can implementing it. Then I have made a test from here, found only Arial, SIL fonts, TNR have this convention. BTW I feel so mystical that FreeSans and FreeSerif have already implemented in small capital style.

Hsing-yen He <hammerandsickle>
Sat 25 Apr 2015 10:38:23 PM UTC, comment #7:

Hi Hsing-yen,

This is technically quite possible.

I would like to see some corroboration of this encoding.

I still think the way this mark is used is like a single symbol with a single function, as opposed to two different marks whose functions are combined. The right answer should then be a new code point.

However, at some point, these things become a matter of convention. If there is an existing covention, we can follow that.

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Sat 25 Apr 2015 04:03:36 PM UTC, comment #6:

I asked again for the encoding, then I received the correct sequence is: <0304, 0304>

Hsing-yen He <hammerandsickle>
Sat 25 Apr 2015 03:59:59 PM UTC, comment #5:

Hi Steve,

I heard one people have wrote a proposal to the Unicode Consortium, but recieved a recommend to use two macrons, so I think it is clear that this mark should using U+0304 for two times.

Hsing-yen He <hammerandsickle>
Sun 08 Mar 2015 07:34:05 AM UTC, comment #4:

Hi Hsing-yen,

It is clear that Kienning uses a double-line mark over letters.

It is not clear that U+033F is a good choice of Unicode character for that purpose. The description in the standard does not sound at all right.

It is not clear that a good Unicode character exists for this purpose. (As I said it might be possible to stack macrons, but in this case, the mark is conceptually a single entity added to a character.)

I think a new, special, mark character is needed here. I think you should consider writing a proposal to the Unicode Consortium.

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Sun 08 Mar 2015 02:44:44 AM UTC, comment #3:

Hi Steve,

I referred the Kienning Colloquial Romanized Alphabet (Gṳ̿ing-nǎing Lô̤-mǎ-cī), is Romanization system adopted by Western Missionaries to compile the Kienning dialect (modern day Jian'ou City) of the Northern Min language in the Fujian Province of China. The double line is stand for tone 4 in this Romanization system. In the block "Combining Diacritical Marks" only U+033F can be suitable for this usage.


Sand the sample again from comment #1:

Hsing-yen He <hammerandsickle>
Sat 07 Mar 2015 06:17:59 PM UTC, comment #2:


1) I have doubts about the character being used here: You seem to be using U+033F 'combining double overline' as an accent mark. However the Unicode Standard v. 7.0.0 Ch 7.9 under "Combining Diacritical Marks: U+0300–U+036F", says:

"The characters U+0332 combining low line, U+0333 combining double low line, U+0305 combining overline, and U+033F combining double overline are intended to connect on the left and right. Thus, when used in combination, they could have the effect of continuous lines above or below a sequence of characters.
However, because of their interaction with other combining marks and other layout considerations such as intercharacter spacing, their use for underlining or overlining of text is discouraged in favor of using styled text."

Now, I never really understood how this combining overline was supposed to be used in any case, but the remark "intended to connect" sound as if these were never meant as tone marks.

2) But what would be a better diacritic? I haven't found it. There's the possibility of a macron stacked on another.

3) Please provide a standards document indicating the correct Unicode letter for this purpose in Kienning.

4) It may be that the Unicode Consortium should be made aware of this.


Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Sat 07 Mar 2015 04:58:24 PM UTC, comment #1:

Oh~sorry, I want to give you a tip, you need to copy the URL to access.

Hsing-yen He <hammerandsickle>
Sat 07 Mar 2015 12:36:19 PM UTC, original submission:

Hi Steve,

I found the Kienning Colloquial Romanized letter i̿ have a problem when I use FreeFont. In this case the dot should be disappeared, but in FreeFont, this dot still exist when with double overline. Please fix it.

You can found a image as an example from this page, this image is scanned from the Kienning dialect translation of Gospel of Matthew, New Testament. Click the image can get cleaner version:

Hsing-yen He <hammerandsickle>


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

Attach Files:

Attached Files
file #33819:  Tests.zip added by hammerandsickle (182KiB - application/zip)
file #33809:  Tests.zip added by hammerandsickle (28KiB - application/zip)


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 hammerandsickle (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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-05-02 Stevan_White StatusNeed info => Fix posted
    2015-04-28 hammerandsickle Attached File- => Added Tests.zip, #33819
    2015-04-27 hammerandsickle Attached File- => Added Tests.zip, #33809
    2015-03-07 Stevan_White Categoryoverall font problem => individual character(s)
        Item Groupglyph(s) incorrect => letter positioning poor
        StatusNone => Need info
        Assigned toNone => Stevan_White

    Back to the top

    Powered by Savane 3.3