Closed Veerjee closed 8 months ago
Yes, this is true. And I'm afraid it's not something we can easily fix - the Duployan font is quite different to everything else. There is a plan to produce a more simple Duployan font, but until then you can merge with an earlier version.
How is it different? Looks like any other font. The GPOS table issue exists even with the older version of the font when merging. Also please don't close an issue without giving a chance to reply.
On Fri, Feb 2, 2024 at 11:04 AM Simon Cozens @.***> wrote:
Yes, this is true. And I'm afraid it's not something we can easily fix - the Duployan font is quite different to everything else. There is a plan to produce a more simple Duployan font, but until then you can merge with an earlier version.
— Reply to this email directly, view it on GitHub https://github.com/notofonts/balinese/issues/38#issuecomment-1924508687, or unsubscribe https://github.com/notifications/unsubscribe-auth/A4VES5SOVFTSICBSKQJQNJDYRU2FLAVCNFSM6AAAAABCXEDMUGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRUGUYDQNRYG4 . You are receiving this because you authored the thread.Message ID: @.***>
There's not enough information to act on your issue. Please tell me:
Any information would allow me to debug this.
Pyftmerge ./NotoSans-Regular.ttf ./NotoMusic-Regular.ttf ...
WARNING: Dropped cmap subtable from font '15': format 0, platformID 1, platEncID 0 Traceback (most recent call last): File "C:\Users\guruwazeer\AppData\Local\Programs\Python\Python311\Lib\site-packages\fontTools\ttLib\tables\otBase.py", line 403, in getData items[i] = packUShort(item.pos - pos) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "C:\Users\guruwazeer\AppData\Local\Programs\Python\Python311\Lib\site-packages\fontTools\ttLib\tables\otBase.py", line 793, in packUShort return struct.pack(">H", value) ^^^^^^^^^^^^^^^^^^^^^^^^ struct.error: 'H' format requires 0 <= number <= 65535
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "
I can generate the merge font if I use the iolder version of NotoSansDuployan-Regular.ttf
Looks like pyftmerge doesn't know how to resolve overflows. Did you try installing the uharfbuzz
Python module? This helps fontTools to pack the tables more efficiently.
How do I add uharfbuzz Python module?
pip install uharfbuzz.
(But this is no longer about a bug in a Noto font; potentially there's a bug in fontTools, but you may be able to work around it.)
I have installed the uharfbuzz Python module. However, the problem of merging the latest version of NotoSansDuployan-Regular.ttf persists.
Upon building the font with the same set of fonts as before, a merged.ttf is now generated within seconds instead of the previous versions which took 5+ minutes to generate. This is excellent work. Thank you, Simon!
Also file size is slightly smaller. File size saving are mostly coming from GPOS and some from GSUB tables.
Defect Report
Title
Font
NotoSansDuployan-Regular.ttf
Where the font came from, and when
From the Noto fonts repo https://notofonts.github.io/
Font Version
Latest posted on the repo
OS name and version
NA -- Windows 11
Application name and version
merger script
Issue
The merger script will not merge this font with anyother Noto font unless you remove/ignore the GPOS table.