Some Iosevka variants broken #694
Comments
|
An especially severe problem have these two fonts: After (any, even manual) patching, the patched result can not even be opened with I even tried the newest release v11.2.0. This has nothing to do with the ligature removal (opposed to what I wrote above). Note the error message in the bottom:
(*) Opened programatically via Python. It opens in interactive |
|
I'm also facing same issue. I patch Iosevka 11.2.3 and want to keep built in ligature on Iosevka . Successfully patched with some error warning like this. "Internal error: Internal Error: Attempt to output 66740 into a 16-bit field. It will be truncated and the file may not be useful."
And after install it on Linux Ubuntu, and try in VS Code text editor, the patched font didn't work properly. It not show ligature. But if i use unpatched Iosevka font, it work properly. |
|
Hmm, at this point
|
|
Well, it has nothing to do with our patching. While I can open
|
|
WHAT THE F***! It does save correctly if we supply an empty flag tuple (instead of no flags): #!/usr/bin/env python
import fontforge
font = fontforge.open('src/unpatched-fonts/Iosevka/Regular/iosevka-term-regular.ttf')
font.generate('iosevka_blah.ttf', flags=tuple())😭 |
/* Legacy screw ups mean that opentype & apple bits don't mean what */
/* I want them to. Python users should not see that, but fix it up */
/* here */
if ( (iflags&0x80) && (iflags&0x10) ) /* Both */
iflags &= ~0x10;
else if ( (iflags&0x80) && !(iflags&0x10)) /* Just opentype */
iflags &= ~0x80;
else if ( !(iflags&0x80) && (iflags&0x10)) /* Just apple */
/* This one's set already */;
else
iflags |= 0x90;
[...]
fm_flag_apple = 0x10,
fm_flag_opentype = 0x80,If we set "apple" and "opentype" -> |
|
If we set no flags by setting an empty tuple the correction will happen and we in fact set That will later be translated here: old_sfnt_flags = 0;
switch ( fmflags&(fm_flag_apple|fm_flag_opentype) ) {
case fm_flag_opentype:
old_sfnt_flags |= ttf_flag_applemode|ttf_flag_otmode;
break;
case fm_flag_apple|fm_flag_opentype:
/* Neither */;
break;
case fm_flag_apple:
old_sfnt_flags |= ttf_flag_applemode;
break;
case 0x00:
old_sfnt_flags |= ttf_flag_otmode;
break;
default:
break;
}If we set "apple" and "opentype" -> If we set no flags by ... just not mentioning, we use int old_sfnt_flags = ttf_flag_otmode; |
|
Interactive mode (default) works, because it uses
It fails with the same error if |
[why] For some reason fontforge is unable to pack all the lookup tables of Iosevka back into the generated font, although they fit obviously in the source font. The lookup tables will become garbled and fontforge says something like: Attempt to output 67666 into a 16-bit field. It will be truncated and the file may not be useful. As this also happens if we do nothing, just open and generate the font without touching, there is not much we can do. [how] The only thing we can do is reduce the number of lookup tables that are in the font file. This is somewhat brute, but at least we end up with a usable font, albeit with a little bit less features. Unfortunately the SS (Style Set) tables are not enough, but the CV (Character Variants) suffice. So all CV lookups are riped out. Fixes: #694 Signed-off-by: Fini Jastrow <[email protected]>
[why]
Sometimes, especially when generating fonts with a lot ligatures,
fontforge can not create the font file correctly. A typical error
message looks like this:
Attempt to output 68142 into a 16-bit field.
It will be truncated and the file may not be useful.
This will already happen when the font is opened and generated without
any change. But the generated font must contain the lookups of course.
[how]
When the lookup tables are written we need to check if the indices can
be represented by 16 bit values. Big tables will often be longer.
In the file first is comes the lookups table that points to all lookups.
Then follow the lookups themselves.
When a lookup would violate the 16 bit boundary we need a different and
longer (!) entry in the lookups table, so all lookups will be shifted.
For this reason the function
tottfgpos.c:g___FigureExtensionSubTables()
does this calculation recursively. Increasing the size of the lookups
table step by step for each lookup, and then checking the previous
lookups again (because they shifted).
Unfortunately the check if the 16 bit boundary would be violated does
not take the grown lookups table into account. Under some circumstances
this means that a lookup, that fittet just-so before is now shifted
because of the bigger lookups table and will then be too far away (i.e.
index > 16 bit).
In the calculation the `len` (size increase) of the lookups table needs
to be included.
[note]
In the `fontforge/tottfgsub.c`:
g___FigureExtensionSubTables()
3179: if ( sub->subtable_offset+offset>65535 )
3218: sub->subtable_offset += len;
and later:
dumpg___info()
3410: efile=g___FigureExtensionSubTables(all,offset,is_gpos);
3423: putshort(g___,offset+sub->subtable_offset);
On line 3179 is decided if a figure-extension has to be used, from the
original offsets sum.
One offset is then changed on line 3218.
On line 3423 we push out the changed offset sum as 16 bits, but did not
check if the changed (3218) offset values would fit.
There is this comment nearby in the code
/* Offset to lookup data which is in the temp file */
/* we keep adjusting offset so it reflects the distance between */
/* here and the place where the temp file will start, and then */
/* we need to skip l->offset bytes in the temp file */
/* If it's a big GPOS/SUB table we may also need some extension */
/* pointers, but FigureExtension will adjust for that */
[note]
This fix has been triggered by
ryanoasis/nerd-fonts#694
Reported-by: Gulajava Ministudio <GulajavaMinistudio>
Reported-by: Rui Ming (Max) Xiong <xsrvmy>
Signed-off-by: Fini Jastrow <[email protected]>
[why]
Sometimes, especially when generating fonts with a lot ligatures,
fontforge can not create the font file correctly. A typical error
message looks like this:
Attempt to output 68142 into a 16-bit field.
It will be truncated and the file may not be useful.
This will already happen when the font is opened and generated without
any change. But the generated font must contain the lookups of course.
[how]
When the lookup tables are written we need to check if the indices can
be represented by 16 bit values. Big tables will often be longer.
In the file first is comes the lookups table that points to all lookups.
Then follow the lookups themselves.
When a lookup would violate the 16 bit boundary we need a different and
longer (!) entry in the lookups table, so all lookups will be shifted.
For this reason the function
tottfgpos.c:g___FigureExtensionSubTables()
does this calculation recursively. Increasing the size of the lookups
table step by step for each lookup, and then checking the previous
lookups again (because they shifted).
Unfortunately the check if the 16 bit boundary would be violated does
not take the grown lookups table into account. Under some circumstances
this means that a lookup, that fittet just-so before is now shifted
because of the bigger lookups table and will then be too far away (i.e.
index > 16 bit).
In the calculation the `len` (size increase) of the lookups table needs
to be included.
[note]
In the `fontforge/tottfgsub.c`:
g___FigureExtensionSubTables()
3179: if ( sub->subtable_offset+offset>65535 )
3218: sub->subtable_offset += len;
and later:
dumpg___info()
3410: efile=g___FigureExtensionSubTables(all,offset,is_gpos);
3423: putshort(g___,offset+sub->subtable_offset);
On line 3179 is decided if a figure-extension has to be used, from the
original offsets sum.
One offset is then changed on line 3218.
On line 3423 we push out the changed offset sum as 16 bits, but did not
check if the changed (3218) offset values would fit.
There is this comment nearby in the code
/* Offset to lookup data which is in the temp file */
/* we keep adjusting offset so it reflects the distance between */
/* here and the place where the temp file will start, and then */
/* we need to skip l->offset bytes in the temp file */
/* If it's a big GPOS/SUB table we may also need some extension */
/* pointers, but FigureExtension will adjust for that */
[note]
This fix has been triggered by
ryanoasis/nerd-fonts#694
Reported-by: Gulajava Ministudio <GulajavaMinistudio>
Reported-by: Rui Ming (Max) Xiong <xsrvmy>
Signed-off-by: Fini Jastrow <[email protected]>
[why]
Sometimes, especially when generating fonts with a lot ligatures,
fontforge can not create the font file correctly. A typical error
message looks like this:
Attempt to output 68142 into a 16-bit field.
It will be truncated and the file may not be useful.
This will already happen when the font is opened and generated without
any change. But the generated font must contain the lookups of course.
[how]
When the lookup tables are written we need to check if the indices can
be represented by 16 bit values. Big tables will often be longer.
In the file first is comes the lookups table that points to all lookups.
Then follow the lookups themselves.
When a lookup would violate the 16 bit boundary we need a different and
longer (!) entry in the lookups table, so all lookups will be shifted.
For this reason the function
tottfgpos.c:g___FigureExtensionSubTables()
does this calculation recursively. Increasing the size of the lookups
table step by step for each lookup, and then checking the previous
lookups again (because they shifted).
Unfortunately the check if the 16 bit boundary would be violated does
not take the grown lookups table into account. Under some circumstances
this means that a lookup, that fittet just-so before is now shifted
because of the bigger lookups table and will then be too far away (i.e.
index > 16 bit).
In the calculation the `len` (size increase) of the lookups table needs
to be included.
[note]
In the `fontforge/tottfgsub.c`:
g___FigureExtensionSubTables()
3179: if ( sub->subtable_offset+offset>65535 )
3218: sub->subtable_offset += len;
and later:
dumpg___info()
3410: efile=g___FigureExtensionSubTables(all,offset,is_gpos);
3423: putshort(g___,offset+sub->subtable_offset);
On line 3179 is decided if a figure-extension has to be used, from the
original offsets sum.
One offset is then changed on line 3218.
On line 3423 we push out the changed offset sum as 16 bits, but did not
check if the changed (3218) offset values would fit.
There is this comment nearby in the code
/* Offset to lookup data which is in the temp file */
/* we keep adjusting offset so it reflects the distance between */
/* here and the place where the temp file will start, and then */
/* we need to skip l->offset bytes in the temp file */
/* If it's a big GPOS/SUB table we may also need some extension */
/* pointers, but FigureExtension will adjust for that */
[note]
This fix has been triggered by
ryanoasis/nerd-fonts#694
Reported-by: Gulajava Ministudio <GulajavaMinistudio>
Reported-by: Rui Ming (Max) Xiong <xsrvmy>
Signed-off-by: Fini Jastrow <[email protected]>
|
Fixed via #884 |
|
This issue has been automatically locked since there has not been any recent activity (i.e. last half year) after it was closed. It helps our maintainers focus on the active issues. If you have found a problem that seems similar, please open a new issue, complete the issue template with all the details necessary to reproduce, and mention this issue as reference. |
🗹 Requirements
🎯 Subject of the issue
The patched Iosevka Mono fonts are more or less broken
Some Iosevka Mono fonts can not be opened at all (or it takes more than some minutes), while most other open with error messages of this kind:
I believe fontforge tries to fix the fonts that do not open for extended times like this:
I guess the problem is the ligature removal with the
src/unpatched-fonts/Iosevka/config.json.🔧 Your Setup
Anonymice Powerline Nerd Font Complete.ttf)? Iosevka Mono *iterm2,urxvt,gnome,konsole)?none,
fontforge(20201107) to just open the fontUsed both:
★ Optional
Maybe these are related:
#585 #586
The text was updated successfully, but these errors were encountered: