Closed ryanlo713 closed 1 year ago
PUA characters don’t work properly in many applications, including Chrome, although they do work in Firefox. I suspect it is a bug in Chrome’s script itemizer.
A similar issue was reported last year. In e9084d1e885b6773c062b727137f60c50bbba7e7, I replaced some PUA characters with an alternative non-PUA solution, but I left the rest in the PUA because they are not actually attested in Duployan. I only use them to test the font; it doesn’t matter if they don’t work outside my tests, and when I eventually release the font, I’ll remove them.
Thank you for your reply.
I tested the font in Inkscape.
I observed abnormal spacing between Duployan glyphs, compared to the numbers above with normal spacing:
I also tested the PUA characters in passing, and their parts showed up fine (but with abnormal spacing yet); but for U+EC10, the fallback font was used against expectation.
original text
𛱁 𛰂𛱁 𛱘 𛱑 𛱘𛰙 𛰆𛱜𛰙
Is there abnormal spacing in Inkscape for a very short input, e.g. just “𛰙𛱁” as the entire text content?
The font does not support U+EC10. Did you mean to use U+EC19 instead?
Yes, there is abnormal spacing in Inkscape:
Yes, it is my typo; for U+EC19 U+1BC58 U+1BC19, the glyph is shown normally in Inkscape:
I found that some glyphs of PUA characters could not be replaced in Inscape:
Left-justified; no kerning setting; ending with CR+LF for each line; substitution failed.
Text:
U+EC02 U+1BC58 U+EC1A
U+EC02 U+1BC51 U+EC1A
U+EC02 U+1BC19 U+EC1A
Expected glyphs (previewed in FontCreator)
The extra space is a bug in Inkscape. It seems to be ignoring glyphs’ negative advances. This font’s width system uses shims with positive and negative advance widths. If negative advances are ignored, the overall advance is larger than intended. For example, the string ⟨𛰙⟩ has shims for +4180 on the left, −3870 on the left, and +120 on the right. The left shims are supposed to resolve to +310, but Inkscape uses +4180.
The problem with <U+EC02, U+1BC58, U+EC1A> and <U+EC02, U+1BC51, U+EC1A> is another bug in Inkscape. Whenever a glyph’s cursive entry point is farther to the right than its cursive exit point, Inkscape seems to swap the points’ x coordinates. A clearer example is <U+1BC03, U+1BC05, U+1BC02>, which should look like this: but which Inkscape renders thus:
I’ve pushed a new version to duployan-test that removes the extra left-side space in Inkscape. There is still extra space on the right side.
text
𛰙𛱁̄𛰙𛱁̱ 𛰙𛱁́𛰙𛱁̀ 𛰙𛱁̌𛰙𛱁̂ 𛰙𛱁̆𛰙𛱁̯ 𛰙𛱁̇𛰙𛱁̣ 𛰙𛱁̈𛰙𛱁̤ 𛰙𛱁̱́𛰃 𛰙𛱁̱̌𛰃 𛰙𛱁̯̈𛰃 𛰙𛱁̱̆𛰃 𛰙𛱁̱̌𛰃 𛰙𛱁̯̈𛰃
𛰂𛱘 𛰂𛱘 𛰂𛱘 𛰂𛱘 𛰂𛱘𛰙 𛰂𛱘𛰚 𛰂𛱘𛰛 𛰂𛱘𛰜 𛱘𛰂𛱘 𛱘 𛱘 𛱘
Chrome (107.0.5304.107):
Inkscape 1.2 (dc2aedaf03, 2022-05-15):
XeLaTeX:
There is a minor bug in Chrome and a major bug in Inkscape, but I don’t think any of these problems is caused by a bug in this font. Is there anything left to do here?
Hi David,
First of all, thank you for your work. I have found multiple of your projects extremely useful in my research and learning.
I was curious about the implementation details, so I tried to render the corresponding characters in Chrome based on the contents of the test folder in the repository, while I obtained the font file through another repository of yours and opened it in FontCreator to call specific glyphs.
During this time I found that combinations with PUA characters cannot be automatically replaced in the browser; some examples provided below:
Thanks for your time!