Wed 12 Jul 2017 11:30:47 AM UTC, comment #16:
Fixed in Unifont 10.0.05 release.
Paul Hardy
|
Sun 09 Jul 2017 10:03:53 PM UTC, comment #15:
I will remove all of these from plane00-combining.txt in the next release.
Paul Hardy
|
Sun 09 Jul 2017 04:49:10 AM UTC, comment #14:
I will leave this bug report open.
Paul Hardy
|
Sat 08 Jul 2017 11:43:50 PM UTC, comment #13:
There are still some glyphs in nonprinting hex files handled as combining characters.
|
Sat 08 Jul 2017 04:03:02 PM UTC, comment #12:
I believe that this is now in an acceptable state in the Unifont 10.0.04 release, just uploaded.
Paul Hardy
|
Sat 08 Jul 2017 12:43:49 PM UTC, comment #11:
That all sounds good. Thanks!
|
Sat 08 Jul 2017 04:03:53 AM UTC, comment #10:
David,
This is what I have changed additionally:
U+2D7F: moved to unifont-base.hex as a "+" subscript combining character.
U+011A3A: made a single-width combining character.
U+011A47: made the same as U+011A34 (virama) and moved to plane01.hex.
U+011A99: made a "+" subscript combining character, as Soyombo does not have a virama (halant) mark.
U+011D45: made the same as U+011D44 (halant) as a combining character.
Although semantically the virama will make sense for the subjoiner code points where their scripts use a virama (halant), syntactically a virama would only occur naturally at the end of a word. I am hoping the virama will cause less confusion than a "+" sign for readers who are not Unicode experts. I'll see what happens.
The other glyphs (Duployan, Japanese ruby, etc.) will keep their original glyphs. Unifont will print them, but not as combining characters.
Paul
|
Fri 07 Jul 2017 01:59:15 PM UTC, comment #9:
A glyph I have seen other fonts use to indicate an unsupported conjunct in a script that uses a subjoiner instead of a virama is a small subscript plus sign.
|
Fri 07 Jul 2017 05:23:04 AM UTC, comment #8:
Here's an idea. For Indic scripts, instead of the Unicode dashed box glyph I could use the virama/halant symbol in a script to indicate a subjoiner. They are used to signal the formation of a consonant conjunction in Sanskrit and derivative scripts. The virama is used to indicate that an inherent vowel does not follow the consonant. Then if something is printed it still will not look elegant the way a font with consonant conjunctions would, but it would be less jarring for someone to see a virama instead of a dashed box. Semantically it would also carry the correct meaning.
Soyombo does not have such a glyph, so I could use the Sanskrit / Devanagari virama (U+094D) as the consonant subjoiner glyph. It would be treated as a combining character.
That is probably the last change I will have time to make on this if I am to create a release this weekend.
Paul
|
Thu 06 Jul 2017 04:59:01 PM UTC, comment #7:
For U+06DD through U+2011 I agree.
According to The Unicode Standard 10.0, ch. 5, p. 255, “The other notable set of exceptional format characters is the interlinear annotation characters: U+FFF9 INTERLINEAR ANNOTATION ANCHOR through U+FFFB INTERLINEAR ANNOTATION TERMINATOR. These annotation characters should have a visible glyph display for fallback rendering, because if they are simply not displayed, there is too much potential to misread the resulting displayed text.” For the same reason, all the subjoiners and so on should also have visible fallback glyphs, but since this is just a question of what file they go in it doesn’t really matter.
|
Thu 06 Jul 2017 06:34:24 AM UTC, comment #6:
David,
By the way, I saw how the Brahmi Number Joiner was supposed to behave by reading this document:
http://unicode.org/L2/L2011/11357r-brahmi-num-joiner.pdf
Paul
|
Thu 06 Jul 2017 06:33:16 AM UTC, comment #5:
David,
Here is what I propose doing. Mind you, the so-called non-printing glyphs are included in the default Unifont build anyways, so at some level this is just a philosophical discussion.
06DD ARABIC END OF AYAH - remove the dashed box and move to unifont-base.hex
070F SYRIAC ABBREVIATION MARK - leave as is and move to unifont-base.hex, based upon what Wikipedia says at https://en.wikipedia.org/wiki/Syriac_Abbreviation_Mark
0F0C TIBETAN MARK DELIMITER TSHEG BSTAR - make the same glyph as U+0F0B, the TSHEG delimiter that allows line breaks, and move the glyph to unifont-base.hex
2011 NON-BREAKING HYPHEN - make the same glyph as U+002D, the ordinary hyphen, and move it to unifont-base.hex
These are for Japanese "ruby" (annotation) text, and are internal markers that do not appear on the screen or in print, so I would leave them as they are:
FFF9 INTERLINEAR ANNOTATION ANCHOR
FFFA INTERLINEAR ANNOTATION SEPARATOR
FFFB INTERLINEAR ANNOTATION TERMINATOR
Any subjoiner-type glyphs in Indic-type scripts are usually indicators that a conjunction should be used, often without an intervening vowel, so I would leave them as they are. They are not visibly rendered, but the text will only appear correct in a more capable font than Unifont:
11A47 ZANABAZAR SQUARE SUBJOINER
11A99 SOYOMBO SUBJOINER
11D45 MASARAM GONDI VIRAMA
This is a special case that I can handle with a horizontal line placed across two glyphs like a double diacritic, with the glyph placed in plane01.hex; I do not think I will have time to do more than that if I am to create a release this weekend:
1107F BRAHMI NUMBER JOINER
The Unifont Standard 10.0 states that these are not visibly rendered, so I would leave these as they are; they are for special text processing with TrueType fonts more capable than Unifont:
2D7F TIFINAGH CONSONANT JOINER
1BC9D DUPLOYAN THICK LETTER SELECTOR
1BCA0 SHORTHAND FORMAT LETTER OVERLAP
1BCA1 SHORTHAND FORMAT CONTINUING OVERLAP
1BCA2 SHORTHAND FORMAT DOWN STEP
1BCA3 SHORTHAND FORMAT UP STEP
Paul
|
Thu 06 Jul 2017 01:28:33 AM UTC, comment #4:
06DD ARABIC END OF AYAH
070F SYRIAC ABBREVIATION MARK
0F0C TIBETAN MARK DELIMITER TSHEG BSTAR
2011 NON-BREAKING HYPHEN
2D7F TIFINAGH CONSONANT JOINER
FFF9 INTERLINEAR ANNOTATION ANCHOR
FFFA INTERLINEAR ANNOTATION SEPARATOR
FFFB INTERLINEAR ANNOTATION TERMINATOR
1107F BRAHMI NUMBER JOINER
11A47 ZANABAZAR SQUARE SUBJOINER
11A99 SOYOMBO SUBJOINER
11D45 MASARAM GONDI VIRAMA
1BC9D DUPLOYAN THICK LETTER SELECTOR
1BCA0 SHORTHAND FORMAT LETTER OVERLAP
1BCA1 SHORTHAND FORMAT CONTINUING OVERLAP
1BCA2 SHORTHAND FORMAT DOWN STEP
1BCA3 SHORTHAND FORMAT UP STEP
|
Wed 05 Jul 2017 01:41:42 PM UTC, comment #3:
David,
I retitled the bug in a way that reflects the path I suggested.
I do not know that I will have time to address what is or is not in the nonprinting hex files for Plane 0 and Plane 1 before the next release, but any code points that are listed in those files have been removed from the combining.txt files.
Is it possible for you to provide a list of glyphs you think should always be printed, but which are listed in one of the nonprinting hex files?
Thank you,
Paul Hardy
|
Tue 04 Jul 2017 12:58:14 AM UTC, comment #2:
I am not sure what you mean by non-printing. None of those three code points is a Default_Ignorable_Code_Point. Neither does any match the UTS #18 regex [:^print:]. Furthermore, some of the characters in nonprinting.hex are meant to have visible glyphs.
What I did was to find every line matching :AAAA.*5555$ (to find dotted squares) and check the resulting non-default-ignorable combining characters in Unifont. I skipped default-ignorable characters like U+17B4 because some renderers ignore them; but then again some don’t, so I agree with all you wrote, pending a clarification of “non-printing”.
|
Mon 03 Jul 2017 08:20:52 PM UTC, comment #1:
Those code points are all classified in the Unicode Standard as non-printing. Theoretically I could implement what you suggest for U+2D7F. That character seems intended for intelligent fonts to select ligature glyphs of two consonants, so classifying it as non-printing is appropriate.
I would prefer to apply a consistent policy across as much of Unifont as possible though, and I think it is possible.
Unifont's font/plane00 and font/plane01 directories contain separate Unifont hex files for non-printing characters, so they are already separated out and can be omitted from the compiled font if someone so desires.
However, in the current release the following Plane 0 non-printing characters are also in the file of Plane 0 combining characters: U+034F (COMBINING GRAPHEME JOINER in the Combining Diacritical Marks block -- with a note that it does not actually combine graphemes!); U+17B4 and U+17B5 (Khmer Inherent Vowel signs); U+180B, U+180C, and U+180D (Mongolian variation selectors); and U+FE00..U+FE0F (the "Variation Selectors" block).
In Plane 1, none of the non-printing characters are listed in the file for Plane 1 combining characters.
I would like to apply a consistent policy of not handling a non-printing character as a combining character. That would prevent the glyph from being superimposed on adjacent glyphs if the font is compiled to include non-printing characters (which it is by default).
Then a text editor that is smart enough to know what to do when it encounters a non-printing character can perform the expected action, but a text editor that doesn't know any better will display the character so its presence will be known. Also, this would allow a user to selectively view hidden characters if a text editor allows that.
font/Makefile always includes the non-printing characters in the Unifont Upper font. I need to introduce a way of selectively disabling that inclusion, just as I did for Plane 0.
Following this approach, I would like to retitle this bug to "Don't Treat Non-printing Characters as Combining Characters". Then I would remove the code points that I mentioned above from the Plane 0 combining characters file for the next Unifont release.
Any thoughts?
|
Mon 03 Jul 2017 02:21:25 AM UTC, original submission:
U+2D7F TIFINAGH CONSONANT JOINER, U+1107F BRAHMI NUMBER JOINER, and U+1BC9D DUPLOYAN THICK LETTER SELECTOR are combining characters whose Unifont glyphs have dotted squares. These glyphs obscure the previous two cells, making the text illegible. They should either be designed as combining glyphs or not be combining.
For U+2D7F, I suggest removing the dotted square, lowering the six dots so that they do not overlap Tifinagh letters’ bases, and making the glyph one cell wide so that it only combines with the previous character instead of the previous two. Even better would be if it were two cells wide but had an advance width of one cell, so that half of the dots were under the previous character and half under the next.
For the others, I suggest keeping the existing glyphs and making them spacing.
|