Fri 30 Jun 2017 04:59:49 PM UTC, comment #9:
I consider this to be working properly with the latest Unifont release, for the reasons described below. I have tested this with Unifont 10.0.01, which was built on Debian 9 ("stretch"), released on 17 June 2017, using an updated version of FontForge. Unicode Standard version 10.0.0 was released three days after Debian 9. So this testing was done with a Unifont version that was built with very recent versions of Unicode, Debian, and FontForge.
Unicode Standard v. 10.0, section 2.1, Combining Characters, in the section on "Sequence of Base Characters and Diacritics", p. 56, states: "In the Unicode Standard, all combining characters are to be used in sequence following the base characters to which they apply." So in the text file, combining characters must appear after the character with which they combine. You can download that document (~12 MB) here:
http://www.unicode.org/versions/Unicode10.0.0/UnicodeStandard-10.0.pdf
So whatever input method editor (IME) you are using to enter characters might permit your typing combining characters before the character with which they combine, but the result must be stored in a file with the combining marks after the base character. If that is not happening, it is a bug in the IME, not in the font.
I tried the Unifont 10.0.01 build with the "xx́x" example that you gave and it rendered fine. So I decided to test it further with non-Latin vowels.
The U+03xx block contains the U+0301 glyph that you mentioned, as well as Greek letters, so Greek was a natural choice. I typed in something in Greek that would exercise U+0301 with some vowels: "Κύριε, ἐλέησον. Ἀμήν." ["Lord, have mercy. Amen."] That places U+0301 over three Greek vowels. I then examined the output file with the "od" program and found that the IME had changed combinations of vowel + U+0301 into one glyph containing vowel + tonos (acute accent): U+03CD, U+03AD, and U+03AE.
That was not going to let me check the interaction of U+0301 with those vowels, so I wrote a short program to hard-code the UTF-8 code points and store the result in a file. I have attached the resulting file as "kyrie.txt". The file begins with the three-byte UTF-8 signature, and then the Greek in quotes above follows. U+301 appears in UTF-8 as two bytes; in octal, they are "\314\201". You will see that sequence repeatedly in "kyrie.txt".
The resulting text appeared fine in: Debian's terminal window and LibreOffice Writer; Mac OS X El Capitan's TextEdit; Windows 7 Notepad and Word 2013. (I do not have access to a later version of Windows, so it will be difficult for me to support future Windows releases.) The only anomaly was because I ended "kyrie.txt" with just a line feed, not a carriage return/line feed pair, Notepad on Windows 7 printed the LF character. I can live with that. See the attached sample screen captures (I can only attach four files, so they are representative).
I also did not like the way the U+0301 accent was rendered as a vertical stroke in the Greek letters such as U+03CD, U+03AD, and U+03AE. I have touched up the entire U+03xx block, and am about to release that as Unifont 10.0.02.
I also checked the rendering of the "STARGATE" logo (also created by hand with a program so I knew that the byte ordering in the file complied with the Unicode Standard). It rendered correctly on Debian 9 in LibreOffice Writer when the selected font was Unifont--but not when the selected font was the default LibreOffice font, Liberation Serif!
The attached images show Unifont 10.0.02 (about to be released), but I did not touch hex2sfd so Unifont 10.0.01 would render the same (it did in the checks I made). I can only attach four files, so the attached files are a representative sample of the outcome.
In conclusion, as long as an editor/IME combination correctly stores Unicode combining characters after the base character as per the Unicode Standard, glyphs should appear properly with U+0301 on the systems that I tested. Therefore, I am closing this bug report.
(file #41085, file #41086, file #41087, file #41088)
|