bugUnifont - Bugs: bug #51612, Problems with Myanmar

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #51612: Problems with Myanmar

Submitter:  David Corbett <dscorbett>
Submitted:  Sat 29 Jul 2017 03:52:51 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  unifoundry
Open/Closed:  Closed

Jump to the original submission

Tue 05 Jun 2018 10:23:08 PM UTC, comment #24: 

These glyphs have been added to Unifont 11.0.01.

Paul Hardy <unifoundry>
Group administrator
Fri 16 Feb 2018 12:51:13 AM UTC, comment #23: 

Here are the changes needed. The rest of the glyphs are the same as in my previous comments. With these changes, one more glyph, U+103B MYANMAR CONSONANT SIGN MEDIAL YA, should be removed from plane00-combining.txt.

102B:0F00108010800080008000800080008000800080008000800000000000000000
102C:0000000000000000000003E00410000800080008001001E00000000000000000
102D:0030004800480030000000000000000000000000000000000000000000000000
102E:0070008800A80088007000000000000000000000000000000000000000000000
102F:0000000000000000000002000200020002000200020002000200020002000380
1030:00000000000000000000050005000500050005000500050005000500050005C0
1033:007000A800D800A8007000000000000000000000000000000000000000000000
1034:0008001000200040000000000000000000000000000000000000000000000000
1035:0070008000B800C8007000000000000000000000000000000000000000000000
1036:0000000200050002000000000000000000000000000000000000000000000000
1037:0000000000000000000000000000000000000000000000000000001000280010
1038:0000000000000000000001000280010000000100028001000000000000000000
1039:0000000000000000000000000000000000000000000000000000002000700020
103A:000C001200100008000000000000000000000000000000000000000000000000
103B:0000000000000000000004000400040004000400040084008400840064001C00
103D:000000000000000000000000000000000000000000000000000800140022001C
103E:0000000000000000000000000000000000000000000000200020002000600000
1040:0000000000000000000003600410080808080808041003600000000000000000
1041:0000000000000000000003C00420001000100010042003C00000000000000000
1042:0000000000000000000000200020002000200020002000200020002008400780
1043:0000000000000000000003C00420001000100010042003C00100008000400020
1044:0000000000000000000003C00420080008000800042003C00080010002000400
1045:0000000000000000000007C00A200A10041000100010001000100010042003C0
1046:000001E002100400040004600480048004700410021001E00000000000000000
1047:0000000000000000000007800840002000200020004000800100020002000180
1048:0000000000000000000003C004200A1009100910052003000000000000000000
1049:0000000000000000000001E002100410047004800480046004000400021001E0
104A:0000000000000000000000800080008000800080008000800000000000000000
104B:0000000000000000000002400240024002400240024002400000000000000000
104C:0180024002000100000003C0042000100010042007C0040003E00020042003C0
104E:00000000000000000000007800840100010001000084007C0004000400040004
1056:0000000000000000000000600080004000200020084007800000000000000000
1057:0000000000000000000000300040002000100010092006C00000000000000000
1058:0000000000000000000000000000000000000000000000000030005000640038
1059:000000000000000000000000000000000000000000000000006000A000CA0074
105E:0000000000000000000000000000000000000000000000000010003800540030
105F:0000000000000000000000000000000000000000000000000010003000440038
1060:0000000000000000000000000000000000000000000000000010002000400078
1062:0000000000000000000003800080008000800080008000800000000000000000
1063:0000000000000000000003800440002000200020044007800400040004000400
1064:0000000000000000000007000100010001000100010001C00000000000000000
1067:0000000000000000000000800080008001800280028001000000000000000000
1068:0000010002800100000000800080008000800080008003800000000000000000
1069:0000000000000000000001800240004001800200024001800000000000000000
106A:0000000000000000000000800080008000800080028001000000000000000000
106B:0000000000000000000001000280008000800080008000800000000000000000
106C:0000000000000000000001000100010001000100014000800000000000000000
106D:0000000000000000000001800240020001800040024001800000000000000000
1072:0030004800400030000000000000000000000000000000000000000000000000
1074:0000004800480030000000000000000000000000000000000000000000000000
1082:0000000000000000000000000000000000000000000000000020004000480030
1083:00000000000000000000070001000100010001000100010001000100010001C0
1085:0070008800400088007000000000000000000000000000000000000000000000
1086:0020005000300010002000000000000000000000000000000000000000000000
1087:0000000000000000000000000000000000000100028001800080010000000000
1088:0000000000000000000001000280010000000100028001800080010000000000
1089:0000000000000000000000000000000000000100028001000000000000000000
108A:0000000000000000000002000540038000000200054003800000000000000000
108B:0000000000000000000000000000010002800100000000000000000000000000
108C:0000000000000000000000000000022005500220000000000000000000000000
108F:0000000000000000000001000280010000000100028003000200010000000000
1090:0000000000000000000003C00420042004200420042003C00000000000000000
1091:0000000000000000000003000500010001000100014001800000000000000000
1092:0000000000000000000005C00620002000400080010001000000000000000000
1093:0000000000000000008000800100010002000380044004400000000000000000
1094:000000000000000000800080018001800280028004A004C00000000000000000
1095:0000000000000000000000400040004007E00840084007800000000000000000
1096:0000000000000000000007800840084007E00040004000400000000000000000
1097:0000000000000000000007C00040008001000200040007C00000000000000000
1098:0000000000000000000004200420024003C00420042003C00000000000000000
1099:0000000000000000000003C00420042003C00240042004200000000000000000
109A:0000000000000000000001000280010000000000000000000000000000000000
109B:0000010002800180008001000000000000000000000000000000000000000000
109C:0000000000000000000003800540020000000380054002000000000000000000
109D:0000001C00220002000200020000000000000000000000000000000000000000
109E:00000100028001000000070001000100010001000100010001000100010001C0
A9E5:0070008800800070008800000000000000000000000000000000000000000000
A9E6:0000000000900120024004800000000000000000000000000000000000000000
A9F0:000003C00420081008100810081008100810081008100810042003C000000000
A9F1:000003C004200E1009100620000003C004200E10091006200040007000000000
A9F2:0000081008100810042003D0001003D00420080008000800042003C000000000
A9F3:000003E0041000100010061005E0040005E0061000100010041003E000000000
A9F4:000007C0082008000800086007A0002007A0086008000800082007C000000000
A9F5:000003C0042008100800080008000BC00C200810081008100420024000000000
A9F6:0000000002400420081008100810043003D00010001000100810042003C00000
A9F7:000000000780084010201C2012200C2000200020002000200020003800000000
A9F8:000003C00420080008000800040003C00420081008100810042003C000000000
AA70:000003E00410000003E004100000000000000000000000000000000000000000
AA7B:0000000000000000000000000000000000000100028003000200010000000000
AA7D:0000000000000000000000000000000007E00000000000000000000000000000

The single-cell non-combining glyphs have all been widened, generally by adding 4 blank columns to the left and right sides. Some of them I redrew to minimize the blank space; the sequence of U+102C and U+103A will be suboptimal but it is not as suboptimal as I’d thought.

The combining glyphs all got 8 blank columns on the left. All of the Myanmar glyphs in plane00-combining.txt should have an offset of -16.

The digits have ascenders and descenders as specified, and the dandas match.

David Corbett <dscorbett>
Sat 10 Feb 2018 07:04:41 PM UTC, comment #22: 

David,

There is the vertical alignment of the numerical digits, which I only learned about the second time I spoke with the Burmese monk.  I also would like to leave the Indic scripts double-width.  It simplifies combining characters.


Paul

Paul Hardy <unifoundry>
Group administrator
Mon 05 Feb 2018 12:55:36 PM UTC, comment #21: 

I have time, though I am not sure what still needs finishing.

David Corbett <dscorbett>
Mon 05 Feb 2018 05:57:18 AM UTC, comment #20: 

David,

Will you have time to finish Myanmar?

Thanks,


Paul Hardy

Paul Hardy <unifoundry>
Group administrator
Sun 10 Dec 2017 02:08:06 AM UTC, comment #19: 

David,

Thank you for your patience while I got caught up on other things.

I have posted a new bug report where I tried to capture my thoughts on Unifont philosophy in general:

https://savannah.gnu.org/bugs/index.php?52630

I would like to try to keep Unifont simple, bearing in mind its severe limitations as a plain TrueType font. (Actually, Roman Czyborra long ago lamented to me how much more complicated Unifont is now compared to what he originally created with .hex input files and BDF font output--I guess you can call it progress, but "progress" is a double-edged sword.) I welcome your comments on what I wrote, and hopefully an agreeable path forward can come out of it.

Thank you,


Paul Hardy

Paul Hardy <unifoundry>
Group administrator
Sun 15 Oct 2017 04:43:19 AM UTC, comment #18: 

David,

I need to review all the things you have submitted that are not incorporated, and I will not have time to give them a proper review until the end of November, with other things going on in my life right now. I would recommend you pause in submitting additional requests for other scripts until I have a chance to work through what is in the queue right now. I should be able to work through all that is currently outstanding in December.


Paul Hardy

Paul Hardy <unifoundry>
Group administrator
Sat 14 Oct 2017 10:16:11 PM UTC, comment #17: 

I don’t understand. Can you give an example Burmese string that would look wrong with the metrics I suggested? See comment #6 for why making all Myanmar glyphs double-width is not a good idea.

I think it is more important that a font be as functional and good-looking as possible than that it be easy to draw, on the premise that a product is used more times than it is created.

David Corbett <dscorbett>
Sat 14 Oct 2017 08:47:40 PM UTC, comment #16: 

David,

I have realized that with a double-width combining glyph like U+103C, the entire Myanmar block should probably just remain double-width. Otherwise, single-width glyphs will be off-center and spacing will be off with a double-width combining character.

I think it would be fine to leave the digits double width as they are now as well, leaving the entire script as double-width. Keeping that convention makes drawing the glyphs a lot easier. That is what I have followed for almost all of the Indic scripts/glyphs.


Paul Hardy

Paul Hardy <unifoundry>
Group administrator
Sun 08 Oct 2017 01:44:46 AM UTC, comment #15: 

David,

The only other thing to do might be adjusting the heights of the danda and double danda, if they need adjusting. They should be in the same vertical range as Burmese digits 0, 1, and 8, which is a lot shorter than the Devanagari equivalents.

The “ကြိမ်” combination you typed is the correct encoding of what goes after digits to indicate an ordinal number. The monk and I both know Sanskrit/Pali terms, so I was discussing this with him using what common vocabulary we have. He drew the mark at the end and told me that it was not a letter, but indicated there was no following vowel, like a virama in Sanskrit.

I tried rendering in Unicode what he wrote by hand on a piece of paper. (I would have scanned it, but do not have access to a scanner right now.) I didn't notice the asat code point in the Myanmar script. The way he wrote the asat sign, it was right-justified so it appeared to the right of the base letter and was more extended upwards. The Unicode Myanmar code chart did not have an asat that was similar to what the monk drew by hand (Unicode's sample glyph is more compact), so it did not jump out at me as I scanned the Myanmar range.


Paul Hardy

Paul Hardy <unifoundry>
Group administrator
Sat 07 Oct 2017 11:59:49 PM UTC, comment #14: 

Besides redrawing the digits, what is left to do?




(The following has no bearing on Unifont but I thought it was interesting.)

I am surprised to read that there is a word spelled “ကြမ္”: the final character, U+1039 MYANMAR SIGN VIRAMA, should never be word-final: it is an abstract subjoiner that affects the following consonant and has no visible form per se. The visible vowel-killer is U+103A MYANMAR SIGN ASAT.

The Burmese morpheme for “times” (as in “four times”) is apparently “ကြိမ်”. This is similar to “ကြမ္”; the differences are that the former has a vowel sign and that the former uses U+103A instead of U+1039. I can’t explain the vowel sign but I suspect that the correct spelling of this word uses U+103A and that the string you pasted into your latest comment is misencoded.

Where did you copy that string from? It is possible that your source was not in Unicode but Zawgyi, a popular pseudo-Unicode glyph-based encoding. Zawgyi uses U+1039 for the visible killer, which looks a bit like U+1034, and it encodes subjoined consonants with separate code points à la Tibetan.

David Corbett <dscorbett>
Sat 07 Oct 2017 04:58:41 PM UTC, comment #13: 

David,

I was able to stop by the Burmese Buddhist monastery and speak with the scholarly monk I met previously. In summary, I think the Burmese (Myanmar) digits can be single-width; it definitely sounds like combining marks are not used with digits--not even for ordinal numbers.

Ordinarily, when writing the words "first" through "twelfth", Burmese Buddhists use the Pali words. For "thirteenth" and higher, they use the Burmese words.

There is a way of writing ordinal numbers in Burmese, but this is done by writing the digits followed by the phrase "ကြမ္". The last symbol is a virama (U+1039), and should look sort of like the Burmese "o" (U+1034) but right-justified; it probably does not render correctly on this web page. So Burmese write:

၁ကြမ္ (1st)

၂ကြမ္ (2nd)

etc.

In a numbered list of items, numbers are followed by a single danda (U+104A). For example:

၁၊ (1:)

၂၊ (2:)

etc.

Here is something I did not realize about Burmese numbers: they are not all written with the bottom on the baseline, just as old style Arabic digits are not. I am going to use the terms "cap height" and "x-height", which concepts do not exist in Burmese but I think you will understand what I am trying to explain that way. The part of a glyph that is circular should extend from the baseline to the x-height. So should the single and double danda (U+104A and U+104B); U+104B is a full stop, as in Sanskrit. (Hope you don't mind my using Sanskrit terms like "danda", but that is what I know and I expect neither of us knows the Burmese terms.) These Burmese digits extend vertically from the baseline to the x-height: 0, 1, and 8. Burmese digit 6 extends from the baseline to the cap height; it is the only Burmese digit with that vertical range. The rest of Burmese digits (2, 3, 4, 5, 7, and 9) extend from the x-height down to the bottom row of a glyph (below the baseline). This might or might not render correctly in your browser: ၀၁၂၃၄၅၆၇၈၉.

Also, in a flexible Burmese font, the width of U+103C should change to match the width of the base letter, but of course that exceeds Unifont's abilities.


I had thought this would be a trivial matter and I could issue a minor Unifont release with finalized Khmer and Myanmar scripts this weekend, but obviously it will take longer in light of what I learned above. There is another free software package that I must work on over the next month or so, so I will plan the next Unifont release for the late November/December timeframe and work through the many bug reports you have currently filed for Unifont then.


Paul Hardy

Paul Hardy <unifoundry>
Group administrator
Fri 22 Sep 2017 06:47:51 AM UTC, comment #12: 

David,

I am about to go on travel, back on Monday. I might be able to return to the Burmese Buddhist monastery this weekend. If so, I will ask the monk I met to see if he can shed further light on combining diacritics with numeric digits now that I understand that they probably represent ordinal numbers.


Paul Hardy

Paul Hardy <unifoundry>
Group administrator
Wed 13 Sep 2017 03:54:46 AM UTC, comment #11: 

David,

I was able to reach the author of the Unicode document that you cited, Martin Hosken, through sil.org.

He does not speak Burmese, but he believes that diacritics can form with a single digit for ordinal numbers, as you hypothesized. He said that digits will not be used with stacked diacritics.

I will be driving near the Burmese monastery in the next couple of weeks, and will stop by there again and try to get clarification on this. It is a couple of hours from my home, and it is not often that I would be anywhere near there.

I am also going to try to create a Unifont 10.0.07 release as an intermediate step in addressing the bugs reports that you filed. I plan to do have that done on Sunday, October 1st. I need to create a release to test a couple of other things. It won't have nearly everything (for one thing, I will be on travel the weekend after next without a computer again), but I will include what I can. I will make every effort to wrap up the Myanmar and Khmer script changes for that release.

Thank you,


Paul Hardy

Paul Hardy <unifoundry>
Group administrator
Sun 10 Sep 2017 04:33:21 PM UTC, comment #10: 

Thanks for going to the monastery! Here is further background information and a possible follow-up question.

The source of the claim that digits take diacritics is http://www.unicode.org/notes/tn11/UTN11_4.pdf, which says “It is possible for a Myanmar syllable to have a number of diacritics surrounding a base consonant, independent vowel or digit. [...] The consonant position slot may hold much more than just a pure consonant. Digits, in certain circumstances, may take diacritics and so are included in the list.” It does not say what those circumstances are.

The Burmese Wikipedia uses diacritics on digits: https://my.wikipedia.org/w/index.php?search=insource%3A%2F%5B%E1%81%80-%E1%81%89%5D%5B%E1%80%AB-%E1%80%BE%5D%2F. U+1036 MYANMAR SIGN ANUSVARA on numbers is used as a degree sign. Digits also take vowel signs; my guess is it’s something like ordinal numbers or units of measurement.

The question that matters most is whether digits can take U+1031 MYANMAR VOWEL SIGN E or U+103C MYANMAR CONSONANT SIGN MEDIAL RA. Burmese diacritics on digits are attested, but without knowing why the monk you talked to says they aren’t, I think it is best to keep them 16 pixels wide. Maybe it is only used in informal shorthand, or it is obsolete, or he didn’t understand what you meant; or maybe Wikipedia is full of mistakes and should be ignored.




There is a good reason to remove the listed combining characters from plane00-combining.txt.

The term “combining” is polysemous. (Forgive me if the following is obvious.) Unicode and Unifont mean different things by it. In Unicode, it refers to a diacritic drawn in relation to a base without any advance width of its own or to a character, like a visarga, which is glyphically independent of any base but which orthographically is always used with a base, like a consonant. In Unifont, it refers to a glyph with no advance width that overlaps adjacent glyphs. These are related but distinct meanings. Therefore, I do not think it is worth while to try to keep General_Category=Spacing_Mark glyphs in plane00-combining.txt if they are not, glyphically speaking, combining characters.

So much for theory. Here’s why these specific glyphs should be removed. From left to right, a Myanmar grapheme cluster can consist of a pre-base vowel (U+1031), a medial ra (U+103C), a consonant (U+103F), a post-base vowel (U+102C), and a tone mark (U+1038). There just isn’t room for all that in 16 pixels. The only way to make it legible is to make the post-base glyphs spacing.




I drew some marks as 8 pixels wide, e.g. U+102D, so that the marks would be directly above the dotted circles in the dotted circle version of the font. If they are 16 pixels wide, the marks will be offset to the right. As long as it looks the same in the normal version of the font, though, widening them is okay.

I drew some spacing glyphs as 8 pixels wide because, were they 16 pixels wide, there would be too much blank space and they would look bad. They should not be widened. See comment #6.

David Corbett <dscorbett>
Sun 03 Sep 2017 04:08:35 AM UTC, comment #9: 

David,

I located the Burmese Buddhist monastery that I intended to visit today. The people there introduced me to a scholarly monk who has a Ph.D. in Religious Studies. He related some very interesting facts about Burmese writing. Here is a synopsis.

In general, he pointed out that Burmese writing evolved from Pali with the arrival of Buddhism. So Burmese writing shares many characteristics with Pali (and by extension Sanskrit and other Indic writing systems).

On numeric digits, he told me that no diacritics are used. If you find any document to the contrary and let me know about it, I can print it out and show it to him. He said the one unusual thing about Burmese numbers is that in the days before the British controlled Burma, Burmese might write one hundred and one, for example, as 100 1 (using Burmese digits of course, if I understood what he was explaining to me correctly). Once the British became established in Burma, the Burmese people changed to writing nubmers like the British, so one hundred and one would be written 101 in Burmese digits.

He also told me that there are no combinations of two or more vowels in Burmese. There are consonant combinations of two consonants and less frequently three consonants. In these ways it is similar to Sanskrit, Pali, etc.

He mentioned that as with other Indic scripts, Burmese used to be comprised of square-ish letters. Then about 200 years ago, King Bodaw, a king in the last dynasty of Burma, declared that writing should be circular like the sun and the moon. That is how modern Burmese got its curved letters. Here is a Wikipedia page about him, but it doesn't mention the change in Burmese script:

https://en.wikipedia.org/wiki/Bodawpaya

The monk told me that scholars still study the ancient writing, but everyday Burmese people are not able to read it.


I would like to keep all glyphs 16 pixels wide for uniformity across the Indic scripts unless some situation proves impossible. I still need time to look over the Indic scripts as a whole. Where you drew eight-pixel-wide combining characters, I would like to make them 16 pixels wide with an empty left half because that is how unibmp2hex is wired. I can do that for you. (I suppose I also need to modify unipng2hex to support the same round-trip conversions; it is just a matter of time.)

I would also like to leave all combining characters in plane00-combining.txt unless there is a very good reason to remove them. I'm not saying there isn't (I have already removed Miao code points from there after your input)--I just don't want to introduce too much unpredictability.

I should be able to get back to that monastery a few weekends from now when I have to travel that way again. I will try to spend time with you in adjusting Myanmar in light of what I learned today before then--except the rest of this weekend and next weekend I will not be able to spend time on it.

If you have other questions for this monk let me know and I can ask him when I am there again. I might also be able to put you in touch with him, but I would ask his permission to do that first.

Take care,


Paul

Paul Hardy <unifoundry>
Group administrator
Sat 02 Sep 2017 04:00:05 AM UTC, comment #8: 

David,

Thank you for your continued diligence in examining Unifont's glyphs.

I have some personal things I must attend to over the next couple of weekends, but I will go over everything from you that is still pending as soon as I can.

While on the road tomorrow afternoon, I am going to try to stop by the Burmese monastery as previously mentioned. If I cannot get there then, I should be able to get there the weekend of September 23rd.

All the best,


Paul Hardy

Paul Hardy <unifoundry>
Group administrator
Fri 18 Aug 2017 06:02:49 PM UTC, comment #7: 

David,

I am going on a road trip to see the eclipse and will not have my computer until Wednesday, so I probably will not be able to make further replies until then.

I have tried to keep up unihex2bmp and unibmp2hex so that they support round-trip conversion from .hex to .bmp and back to .hex.  hexdraw supports such round-trip conversion intrinsically. Andrew and I have not done that for the .png programs, mainly because all the Indic scripts that I added I drew in .bmp format and you are the first person to make the amount of changes to them that you have made.

I am certainly willing to modify the encoding in unibmp2hex as you request.

I will have to wait until my return home to look at this further.

All the best,


Paul Hardy

Paul Hardy <unifoundry>
Group administrator
Fri 18 Aug 2017 02:11:10 PM UTC, comment #6: 

An example of something that won’t look good if every glyph is wide is the combination of U+102C MYANMAR VOWEL SIGN AA and U+103A MYANMAR SIGN ASAT. The asat should be in the right cell, so it combines above the base consonant, and the aa should be in the left cell, so it nearly touches the preceding consonant; but the asat should be above the aa.

There are only two Myanmar glyphs (after my changes) which should be two cells wide yet have a blank right cell: U+1031 MYANMAR VOWEL SIGN E and U+1084 MYANMAR VOWEL SIGN SHAN E. Could you widen specifically those two in unibmp2hex instead of the entire Myanmar range?

David Corbett <dscorbett>
Thu 17 Aug 2017 09:36:18 PM UTC, comment #5: 

It won’t break anything, but it won’t look as good. I don’t understand why unibmp2hex is part of the pipeline: the glyphs already exist in hex format, so why convert them to BMP, add extra spacing, and convert them back to hex?

David Corbett <dscorbett>
Thu 17 Aug 2017 12:17:59 PM UTC, comment #4: 

David,

I will go over this thoroughly when I return next week.

On the diacritics with digits, there is a Burmese Buddhist monastery in the Los Angeles area. I might be able to get there sometime and find someone who would know the answer. I will let you know if I find anything out.

I would like to encode the hexadecimal strings for these glyphs so they are all 16 pixels wide, because unibmp2hex sets Indic scripts to be 16 pixels wide as a block. I can do that with a conversion of these hexadecimal codes to a .bmp file, then convert the .bmp file to a .hex file. If you think that will break anything, please let me know.

Thank you for all your time working on this.


Paul Hardy

Paul Hardy <unifoundry>
Group administrator
Tue 15 Aug 2017 10:45:37 PM UTC, comment #3: 

I redrew most of the Myanmar glyphs. For future reference, column 1 is for the previous cluster’s medial ya, columns 2–5 are for the two pre-base vowel signs, column 5 is for the medial ra, and columns 6–16 are for the base character. Most base characters are one circle (U+101D), which is 8 columns wide, or two circles (U+1011), which is 11 columns wide. Rows 6–12 are for the base character.

U+103B MYANMAR CONSONANT SIGN MEDIAL YA has an x-offset of -7. All the other combining characters’ x-offsets are their widths negated. (I mean “combining” in the Unifont sense, not the Unicode sense.)

U+1037 MYANMAR SIGN DOT BELOW, U+103D MYANMAR CONSONANT SIGN MEDIAL WA, and U+103E MYANMAR CONSONANT SIGN MEDIAL HA are placed so as to avoid any diacritic below being completely overlapped by any combination of descenders or other diacritics below. I didn’t even attempt to test the Mon and Shan medials for overlaps.

The descender of U+1014 MYANMAR LETTER NA is curtailed to look good with U+1037 and U+103E.

The bottom right corner of U+103C MYANMAR CONSONANT SIGN MEDIAL RA is diminished to look good with U+103B and U+103D.

U+1032 MYANMAR VOWEL SIGN AI is shifted left to avoid crossing U+102D MYANMAR VOWEL SIGN I.

It is alleged that Myanmar digits can take diacritics. I couldn’t discover which diacritics, so I made all the digits two cells wide to be safe. Before, a couple were one cell wide. This does not apply to the Shan or Tai Laing digits.

U+1029 MYANMAR LETTER O and U+102A MYANMAR LETTER AU would benefit from being over two cells wide.

U+102B MYANMAR VOWEL SIGN TALL AA and U+103B MYANMAR CONSONANT SIGN MEDIAL YA would benefit from being both spacing and combining. I mean that they should be two cells wide, where the first cell overlaps the preceding character and the second cell should be spacing. This feature would be useful for other Indic scripts too. Because Unifont does not support this, I shifted U+103A MYANMAR SIGN ASAT two columns right so it would combine properly with U+102B.

1000:00000000000000000000018C02520421042104210242000C0000000000000000
1001:0000000000000000000000780084000201F2010A008400780000000000000000
1002:0000000000000000000000780084010201020102008400480000000000000000
1003:00000000000000000000060C01420221042104210252018C0000000000000000
1004:0000000000000000000000780084010001000100008400780000000000000000
1005:0000000000000000000000780084014201420142008400780000000000000000
1006:00000000000000000000018C02520021002103A10252018C0000000000000000
1007:0000000000000000000000F001080214020A0200010800F00000000000000000
1008:0000000000000000000000710089014501450145008900790009000900050002
1009:0000000000000000000000E00110000800080008011001E001000101010100FE
100A:00000000000000000000018C02420021002100210252038C02000201020101FE
100B:0000000000000000000000780084010001000084007C000400F800800078000E
100C:00000000000000000000007800840100010001000084007C000400C4010400F8
100D:000000000000000000000078008400020002008400F80080007C000400040006
100E:0000000000000000000001880044008201020102008400780000000000000000
100F:0000000000000000000003760489045104510451028A00F80000000000000000
1010:00000000000000000000018C02520421042104210242018C0000000000000000
1011:00000000000000000000018C02520421042104210252018C0000000000000000
1012:0000000000000000000000F00108000800300008010800F00000000000000000
1013:000000000000000000000078008401020102017A008400780000000000000000
1014:00000000000000000000001C00200020001C00C2012200FC0020002000000000
1015:0000000000000000000000480084010201020102008400780000000000000000
1016:000000000000000000000058009401120112010A008400780000000000000000
1017:0000000000000000000000000084017A01020102008400780000000000000000
1018:00000000000000000000018C02520021002100210242018C0000000000000000
1019:000000000000000000000048008401020102017A008400780000000000000000
101A:00000000000000000000000C02420421042104210252018C0000000000000000
101B:0000000000000000000000F00108020403C40224011400F40004000400040007
101C:00000000000000000000018C02420421042104210212018C0000000000000000
101D:0000000000000000000000780084010201020102008400780000000000000000
101E:00000000000000000000018C02420021002100210252018C0000000000000000
101F:00000000000000000000000C02520421042104210242018C0000000000000000
1020:0000000000000000000000780084010001000084007C000400F8008000840078
1021:00000000000000000000019C0262004300850049024A018C0000000000000000
1022:00000000000000000000018C02520421042102210142060C0000000000000000
1023:00000000000000000000018C02520421042104210202000001DC022202240107
1024:000600090008000400020199026504250425042502450005000507E5080507F9
1025:0000000000000000000000F00108000400040004010801F001000100010400F8
1026:0070008800A800D80070000000F8010800040004010801F001000100010400F8
1027:0000000000000000000000780084017801000178008400780000000000000000
1028:0000000000000000007800840132014A010A0112010C01000102010200840078
1029:3FFE4001400140004000471C488240414041404148A3471D4001400140013FFE
102A:07C608290828080408000B36288948898889B889D89A6B6808080808080807F0
102B:70888808080808080808080800000000
102C:00000000007884020202047800000000
102D:30484830000000000000000000000000
102E:7088A888700000000000000000000000
102F:00000000002020202020202020202038
1030:0000000000505050505050505050505C
1031:0000000000000000000000003000400040007000500030000000000000000000
1032:0100008000400020000000000000000000000000000000000000000000000000
1033:70A8D8A8700000000000000000000000
1034:08102040000000000000000000000000
1035:7080B8C8700000000000000000000000
1036:00020502000000000000000000000000
1037:00000000000000000000000000102810
1038:00000000001028100010281000000000
1039:00000000000000000000000000207020
103A:0C121008000000000000000000000000
103B:00000000000101010101010109090502
103C:07FC0802080208000800080008000800080008000800080008000800080407F8
103D:0000000000000000000000000814221C
103E:00000000000000000000002020206000
103F:000000000000000000000124029200490049004902DA01240000000000000000
1040:0000000000000000000000D80104020202020202010400D80000000000000000
1041:0000000000000000000000F00108000400040004010800F00000000000000000
1042:0000000000000000001000100010001000100110011000E00000000000000000
1043:0000000000000000007000880008011000E00080004000200010000000000000
1044:0000000000000000007000880080004400380008001000200040000000000000
1045:0000000000000000003800540054002400040004004400380000000000000000
1046:000000000000000000380044004000480050004C004400380000000000000000
1047:0000000000000000003800440004000800100020002400180000000000000000
1048:000000000000000000000078008401420122012200A400600000000000000000
1049:000000000000000000380044004C005000480040004400380000000000000000
104A:00000000000808080808080800000000
104B:00000000002424242424242400000000
104C:18242010003C420101427C403E02423C
104D:000000180024002000100788084810281E28112808A807A800280628080807F0
104E:00000000001C22404040221E02020202
104F:001800240020001000080F6410942F1420142F1410940F140000000000000000
1050:0000000000000000000000780084010201320102008400480000000000000000
1051:0000000000000000000000480084010201320102008400780000000000000000
1052:0000000000000000000000060088010401020102008400780000000000000000
1053:0000000000000000000001860048008401020102008400780000000000000000
1054:00000000000000000000007800840142013E0100008400780000000000000000
1055:00000000000000000000007800840142013E01000092006C0000000000000000
1056:00000000000C10080404443800000000
1057:00000000000C10080404542800000000
1058:00000000000000000000000030506438
1059:00000000000000000000000060A0CA74
105A:0000000000000000000000780084010001000084007800200050001000200010
105B:0000000000000000000000E20112022A02160202011200F200120012000A0004
105C:00000000000000000000007800840132014A0132008400780000000000000000
105D:000000000000000000000048008401020102017A0086007A000200C2010200FC
105E:00000000000000000000000010385430
105F:00000000000000000000000010304438
1060:00000000000000000000000010204078
1061:0000000000000000000000780084010201E20112008A007A0002000A000A001A
1062:00000000003808080808080800000000
1063:00000000003844020202447840404040
1064:00000000007010101010101C00000000
1065:0000000000000000000000780084000200020002008400780000000000000000
1066:0000000000000000000000480084010201020102008400780000001000100030
1067:00000000000808081828281000000000
1068:00102810000808080808083800000000
1069:00000000001824041820241800000000
106A:00000000000808080808281000000000
106B:00000000001028080808080800000000
106C:00000000001010101010140800000000
106D:00000000001824201804241800000000
106E:0000000000000000000001B60249022902290249015200000000000000000000
106F:00000000000000000000000C02520421042104210242018C0000000800080018
1070:00000000000000000000060C01420221042104210252018C0000000800080018
1071:0000008801540088000000000000000000000000000000000000000000000000
1072:30484030000000000000000000000000
1073:0020005000880104000000000000000000000000000000000000000000000000
1074:00484830000000000000000000000000
1075:0000000000000000000000780084010201020082004401880000000000000000
1076:00000000000000000000013801440082000200FA008400780000000000000000
1077:0000000000000000000000780084010A010A008A004401800000000000000000
1078:00000000000000000000018C02520421042104210212018C0000000000000000
1079:00000000000000000000018C02520621052104A10292018C0000000000000000
107A:00000000000000000000018C0242042104210421023201AC0020002000200038
107B:00000000000000000000018C0252042304250429024A018C0000000000000000
107C:00000000000000000000018C02520020002001FC0252018C0000000000000000
107D:00000000000000000000060C015202200420042E0252018C0000000000000000
107E:00000000000000000000060C015202200420042E0252018C0000000800080018
107F:00000000000000000000006800A4012201220142008400780000000000000000
1080:00000000000000000000018C02420021002103A10252018C0000000000000000
1081:000000000000000000000078008401020102012200A4006000200020002000E0
1082:00000000000000000000000020404830
1083:0000000000701010101010101010101C
1084:0000000000000000000030004800400030004000480030000000000000000000
1085:70884088700000000000000000000000
1086:20503010200000000000000000000000
1087:00000000000000000010281808100000
1088:00000000001028100010281808100000
1089:00000000000000000010281000000000
108A:00000000002054380020543800000000
108B:00000000000000102810000000000000
108C:00000000000000225522000000000000
108D:000000000000000000000000000000000000000000000000000001FE00000000
108E:0000000000000000000000780084017A01020102008400780000000000000000
108F:00000000001028100010283020100000
1090:00000000003C42424242423C00000000
1091:00000000003050101010141800000000
1092:00000000005C62020408101000000000
1093:00000000080810102038444400000000
1094:000000000808181828284A4C00000000
1095:00000000000404047E84847800000000
1096:00000000007884847E04040400000000
1097:00000000007C04081020407C00000000
1098:00000000004242243C42423C00000000
1099:00000000003C42423C24424200000000
109A:00000000001028100000000000000000
109B:00102818081000000000000000000000
109C:00000000003854200038542000000000
109D:001C2202020200000000000000000000
109E:0010281000701010101010101010101C
109F:001800240020001000080F041084204420442044104400440044004400440038
A9E0:0000000000000000000000F801440082000200F2008C00780000000000000000
A9E1:00000000000000000000018C024203A1002100210252018C0000000000000000
A9E2:00000000000000000000018C024A0029002500230252018C0000000000000000
A9E3:00000000000000000000018C02D20120002001FC0252018C0000000000000000
A9E4:0000000000000000000000C60108021002100216012900C60000000000000000
A9E5:70888070880000000000000000000000
A9E6:00000912244800000000000000000000
A9E7:00000000000000000000018C02520421042102210122062C0020002000200038
A9E8:0000000000180020002001AC0232042104210421027201AC00200020002000E0
A9E9:00000000000000000000018C02520421042D04210242000C0000000000000000
A9EA:00000000000000000000018C02120421042D04210242018C0000000000000000
A9EB:00000000000000000000018C02520421042D04210212018C0000000000000000
A9EC:00000000000000000000000001020201022502510251018E0000000000000000
A9ED:00000000000000000000018C0252042105AD04210242018C0000000000000000
A9EE:00000000000000000000018C0252042105AD04210252018C0000000000000000
A9EF:0000000000000000000000380244028201CA00A2004400000000000000000000
A9F0:00182442424242424242424224180000
A9F1:003C629262182442724A320404070000
A9F2:00004242241A021A2440404024180000
A9F3:000000182442420C100C424224180000
A9F4:00000018244242300830424224180000
A9F5:00001824424040586442424242240000
A9F6:00002442424242261A02024224180000
A9F7:0000304884E494640404040404070000
A9F8:00000018244040201824424224180000
A9F9:000000000000000000000070008841044104410422881C700000000000000000
A9FA:00000000000000000000018C0242042105A104210212018C0000000000000000
A9FB:00000000000000000000018C02520421042D04210242018C0000000000000000
A9FC:00000000000000000000018C02520421042D04210252018C0000000000000000
A9FD:0000000000000000000000480084010201320102008400780000000000000000
A9FE:0000000000180020002001AC02320421042D04210252018C0000000000000000
AA60:00000000000000000000018C0252042304250429024A000C0000000000000000
AA61:00000000000000000000018C02520421042102210152060C0000000000000000
AA62:000000000000000000000118010401020102014201A401180000000000000000
AA63:00000000000000000000018C025204A104A104A10252060C0000000000000000
AA64:00000000000000000000000C02520421042104210252018C0000000000000000
AA65:00000000000000000000010C0212042104210421026201AC00200020002000E0
AA66:00000000000000000000018C0252042105A104210242018C0000000000000000
AA67:00000000000000000000018C0252042105A104210252018C0000000000000000
AA68:00000000000000000000018C0252042305A50429024A018C0000000000000000
AA69:00000000000000000000018C0252042105B904250252018C0000000000000000
AA6A:00000000000000000000018C02520421043904250252018C0000000000000000
AA6B:0000000000000000000000380244028201C200A2004400000000000000000000
AA6C:0000000000000000000000000102020102310249024901860000000000000000
AA6D:00000000000000000000000C005200A1006100210022002C00200020012000C0
AA6E:00000000000000000000018C02420621052104A10292018C0000000000000000
AA6F:00000000000000000000011801A4014201420142012401180000000000000000
AA70:003E41003E4100000000000000000000
AA71:00000000000000000000018C02520521052105210242000C0000000000000000
AA72:00000000000000000000004C00B2011101110711052A030C0000000000000000
AA73:00000000000000000000010C01820181014101210112010C0000000000000000
AA74:00300048004000200010040808C810A810A810A808C807880088038804C80330
AA75:0018002400200010000818C42524421442142214142460C40084038404E40318
AA76:000C001200100008000438E24512020A020A020A020A02320222326242B23C4C
AA77:000006000900080004000FF0109020502050205010500F5C0040004000400070
AA78:000000000000000C001208A02720102010401040274008C00000000000000000
AA79:0000000000000000000007800840102010201020082007A00020002000200038
AA7A:00000000002007C00800098C0A420C210C210C210A12099C08100810081007E0
AA7B:00000000000000000010283020100000
AA7C:00000000000001FE000000000000000000000000000000000000000000000000
AA7D:00000000000000007E00000000000000
AA7E:0000000000000000000000710089000501E501150089007900090009000D001A
AA7F:00000000000000000000011102A90045074504C502AD011500050005000D001A

102D:-8
102E:-8
1031:-16
1032:-16
1033:-8
1034:-8
1035:-8
1036:-8
1037:-8
1039:-8
103A:-8
103B:-7
103C:-16
103D:-8
103E:-8
1058:-8
1059:-8
105E:-8
105F:-8
1060:-8
1071:-16
1072:-8
1073:-16
1074:-8
1082:-8
1084:-16
1085:-8
1086:-8
108D:-16
109D:-8
A9E5:-8
AA7C:-16

Remove from plane00-combining.txt:

102B
102C
102F
1030
1038
1056
1057
1062
1063
1064
1067
1068
1069
106A
106B
106C
106D
1083
1087
1088
1089
108A
108B
108C
108F
109A
109B
109C
AA7B
AA7D

David Corbett <dscorbett>
Sun 13 Aug 2017 12:49:46 AM UTC, comment #2: 

David,

What you suggest is a good idea. Please go ahead.

I have looked over what I did and what you propose. I drew the bulk of the Myanmar glyphs almost 10 years ago and don't remember what my thinking was at the time, but it was incorrect for me to have glyphs such as U+1008 ascend all the way to the top line. I was probably still working out general spacing rules for the Indic scripts, which I subsequently worked out.

I was not aware that some post-base non-spacing Myanmar characters could themselves take combining characters.

If you could send me what you think should be in plane00-combining.txt for the Myanmar range when you are done, that would avoid errors on my part.

Thank you for pointing this out and suggesting such improvements.

Sincerely,


Paul Hardy

Paul Hardy <unifoundry>
Group administrator
Wed 09 Aug 2017 05:41:42 AM UTC, comment #1: 

David,

I plan to go over this and other Indic scripts during the weekend when I can spend some time reviewing your messages and commenting on them.

As for vertical spacing, in general I drew Indic glyphs with a base of four blank rows on the bottom and four blank rows on top. I also tried to leave a more or less consistent amount of space on the right and left of a base glyph for combining vowel marks. I realize that one size does not fit all; I figured that would let intermingled Indic scripts align with each other somewhat reasonably, and of course many need both ascenders and descenders.

Thanks,


Paul Hardy

Paul Hardy <unifoundry>
Group administrator
Sat 29 Jul 2017 03:52:51 AM UTC, original submission:  

Minor problems

U+1024 MYANMAR LETTER II is missing the right-hand part.

U+102E MYANMAR VOWEL SIGN II should have a curved line, as in U+1026 MYANMAR LETTER UU, not a dot.

U+104E MYANMAR SYMBOL AFOREMENTIONED is completely wrong.

U+108C MYANMAR SIGN SHAN COUNCIL TONE-3 is missing a pixel in the left dot.

U+109E MYANMAR SYMBOL SHAN ONE is unnecessarily wide.

U+A9E5 MYANMAR SIGN SHAN SAW is too low: it overlaps consonants.

U+AA7B MYANMAR SIGN PAO KAREN TONE should look like a reversed U+1087 MYANMAR SIGN SHAN TONE-2.

1024:000C00120010000838E445148214441400143E1440143FE40000000000000000
102E:01C0022002A0036001C000000000000000000000000000000000000000000000
104E:3844808080463A020202020200000000
108C:0000000000000000000000000000000000220055002200000000000000000000
109E:1028100038080808080808080E000000
A9E5:38444038440000000000000000000000
AA7B:000000000000000000000000000000000000000000000004000A000C00080004

Minor problems of broad scope

There are other problems with Myanmar, but I didn’t draw new glyphs for them because the problems affect the whole script, so I wanted feedback first.

The glyphs are generally inconsistent. For example, U+1002, U+1015, U+1017, and U+1051 all incorporate the same basic three-quarter-circle shape, but all their Unifont glyphs differ in how that shape is rendered. The circles of U+1011 are compressed, but not those of U+AA64. The dot of U+AA66 is bigger than that of U+A9EB. Et cetera.

Myanmar bases generally do not have ascenders, though they often have descenders. Unifont raises all glyphs with descenders such that they have ascenders instead. This is a pervasive pattern and can’t have been done by accident, but I don’t see the purpose. I think they should all be lowered.

The only purpose I can guess is to avoid overlapping diacritics below. This is not a great reason, though, since diacritics above are overlapped now. One way to mitigate the problem is to use the post-base forms of u. and u instead of the below-base forms.

102F:0000000000000000000000040004000400040004000400040004000400040007
1030:0000000000000000000000140014001400140014001400140014001400140017

These post-base forms avoid overlap but are only used with a few consonants compared to the below-base forms, so they might not be appropriate.

Major problem

There is not enough room for pre-base marks, and post-base marks can’t take their own non-spacing diacritics. A cluster that exemplifies both problems is ကော် kau. The e overlaps the left side of the ka.. The asat is over the ka. whereas it should be above the a. This will not be hard to fix but it requires changing nearly every Myanmar glyph.

Since the post-base non-spacing characters can take diacritics, Unifont should not treat them as combining characters. All Myanmar characters with general category Mc (except U+1031, U+103C, and U+1084) should be removed from plane00-combining.txt and should be 1 cell wide.

So that gc=Mc characters can take diacritics, the gc=Mn glyphs should be shifted horizontally to fit in 1 cell.

So that consonants still work with the newly shifted diacritics, all consonants should be shifted to the right side. They should still be 2 cells wide.

So that pre-base vowels are legible, the left 5 or 6 columns of each consonant glyph should be blank. This should not be difficult to effect as many consonant glyphs already have sufficient blank columns.

The glyphs in the kau example would become:

1000:00000000000000000000018C02520421042104210242000C0000000000000000
102C:00000000006090080808106000000000
1031:000000000000000000000000300040008000B000D00060000000000000000000
103A:18242018000000000000000000000000

with combining.txt entries:

1031:-16
103A:-8

If you think this is a good plan, I would be happy to provide glyphs. And no, I don’t expect this for the next release.

David Corbett <dscorbett>

 

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

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    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.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-06-05 unifoundry StatusIn Progress Fixed
    2018-06-05 unifoundry Open/ClosedOpen Closed
    2017-08-18 unifoundry StatusNone In Progress
        Assigned toNone unifoundry

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code