Support for duospaced (Latin/Hangul) fonts in post.isFixedPitch and OS/2.xAvgCharWidth

Support for duospaced (Latin/Hangul) fonts in post.isFixedPitch and OS/2.xAvgCharWidth

Summary

Thank you for your continued work on FontForge. It is an invaluable free tool for font development.

I encountered a font metadata issue when using FontForge to add a glyph to and regenerate D2Coding Ver 1.3.3, a Korean coding font based on NanumBarunGothic.

Reference:
D2Coding Ver 1.3.3 – official GitHub Releases

D2Coding is a monospaced typeface designed for programming. The official D2Coding documentation states that a Hangul syllable has exactly twice the advance width of a Latin character. This is an intentional duospaced design:

Latin / ASCII glyphs    500 units
Hangul / CJK glyphs   1000 units
unitsPerEm             1000

Therefore, two Latin characters occupy the same horizontal grid width as one Hangul character.

The actual glyph advance widths remain correct after regeneration, but two important font metadata values are changed by FontForge.

Actual result

I compared the original D2Coding 1.3.3 font with the font regenerated by FontForge.

In the original font:

post.isFixedPitch = 1
OS/2.xAvgCharWidth = 500

After opening the font in FontForge, adding a glyph, and generating a new TTF:

post.isFixedPitch = 0
OS/2.xAvgCharWidth = 944

post.isFixedPitch

I understand that FontForge may determine post.isFixedPitch by checking whether all glyphs have the same advance width.

However, this does not work well for CJK duospaced fonts.

D2Coding intentionally has two width classes:

Latin / ASCII     500 units
Hangul / CJK     1000 units

This does not mean that the font is proportional.

It is an intentional fixed-width grid in which Latin characters occupy one cell and Hangul/CJK characters occupy two cells.

Therefore, checking whether all glyphs have exactly the same advance width can incorrectly classify this type of font as non-fixed-pitch.

OS/2.xAvgCharWidth

The original D2Coding font contains:

OS/2.xAvgCharWidth = 500

while the FontForge-generated font contains:

OS/2.xAvgCharWidth = 944

The value of 944 appears to be affected by the large number of 1000-unit Hangul/CJK glyphs in the font.

For this type of duospaced coding font, the original value of 500 corresponds to the Latin/ASCII character width.

This is consistent with the original D2Coding font, which uses 500-unit Latin characters and 1000-unit Hangul/CJK characters.

Why this matters

These values are not merely cosmetic metadata.

Some applications appear to use font-level metrics such as post.isFixedPitch and/or OS/2.xAvgCharWidth when determining how a font should be treated or displayed in fixed-width contexts.

As a result, the regenerated font can behave differently from the original even though the actual glyph advance widths in the hmtx table remain correct.

In my testing, this resulted in visible spacing/layout problems with Hangul characters in certain applications.

This made the problem particularly difficult to diagnose because the actual glyph widths appeared to be correct when inspected with fontTools.

I was able to fix the problem using Python/fontTools

I was able to correct the generated TTF myself using Python and fontTools.

Specifically, I changed:

post.isFixedPitch     0 → 1
OS/2.xAvgCharWidth    944 → 500

After making these corrections, the metadata matched the original D2Coding font and the resulting layout problem was resolved.

Therefore, the problem can be corrected programmatically.

However, requiring a user to run a separate Python/fontTools post-processing script after every FontForge font generation is not an ideal workflow.

The purpose of this issue is therefore not to request a workaround. I would like FontForge itself to provide a way to specify this information when generating the font.

Feature request: CJK duospaced/fixed-pitch option

I would like to suggest adding an explicit option in FontForge's font settings or Generate Fonts dialog for this type of font.

For example:

Font width model:( ) Proportional
( ) Fixed Pitch
( ) CJK Duospaced / Double-Width

The exact user interface and terminology are, of course, up to the FontForge developers.

The important point is that the font author should be able to explicitly tell FontForge:

This is an intentionally duospaced fixed-width font. Latin characters occupy one cell, while CJK characters occupy two cells.

When this option is selected, FontForge could generate the appropriate metadata automatically, including:

post.isFixedPitch
OS/2.xAvgCharWidth

For example, for D2Coding:

Latin / ASCII width     = 500
Hangul / CJK width      = 1000
post.isFixedPitch       = 1
OS/2.xAvgCharWidth      = 500

The actual implementation does not necessarily need to use these exact values or this exact UI.

The main request is to provide a reliable, built-in way for a font author to specify that a font uses an intentional CJK duospaced fixed-width design.

Why an explicit option may be preferable

I understand that automatically determining whether a font is fixed-pitch can be difficult.

A font containing both 500-unit and 1000-unit glyphs may appear to be a mixed-width font if FontForge simply checks whether all glyphs have identical advance widths.

For this reason, an explicit user-selectable option may be preferable to relying entirely on an automatic heuristic.

It would also preserve the current behavior for existing fonts while giving CJK font authors a way to explicitly specify their intended design.

Reference: D2Coding

D2Coding is a useful real-world example of this type of font.

The official D2Coding repository describes D2Coding as a monospaced typeface and states that a Hangul syllable has exactly twice the advance width of a Latin character.

The version used for this investigation is D2Coding Ver 1.3.3.

Official release page:

https://github.com/naver/d2-coding-font/releases

The 1.3.3 release is listed on the official repository as D2Coding Ver 1.3.3.

Existing workaround

I also found a community plugin called fontforge_ot_fixup that can correct post.isFixedPitch after font generation for this type of situation.

The existence of such a workaround suggests that this may be a recurring problem for authors of CJK duospaced fonts.

It would be very useful if similar functionality could be incorporated directly into FontForge, or exposed as an option during font generation.

Expected result

For a CJK duospaced font such as D2Coding, FontForge should provide a way for the font author to specify the intended design and generate metadata consistent with that design.

For example:

Latin / ASCII width     = 500
CJK / Hangul width      = 1000
post.isFixedPitch       = 1
OS/2.xAvgCharWidth      = 500

The actual implementation can be different. The important requirement is that FontForge should allow the font author to explicitly preserve or define the metadata appropriate for a CJK duospaced font.

Reproduction information

The following files and information are available if they would be useful for reproducing the issue:

• Original D2Coding 1.3.3 TTF

• FontForge-generated TTF

• fontTools output comparing the relevant tables

• head, hmtx, maxp, OS/2, post, and cmap table data

• Details of the glyph added before regeneration

• Screenshots showing the resulting spacing/layout difference

I would be happy to provide the sample font files and additional fontTools output if they would help with reproduction.

Thank you for taking the time to investigate this and for continuing to maintain and improve FontForge.

Best regards,

[Your Name]

Summary

Thank you for your continued work on FontForge. It is an invaluable free tool for font development.

I encountered a font metadata issue when using FontForge to add a glyph to and regenerate D2Coding Ver 1.3.3, a Korean coding font based on NanumBarunGothic.

Reference: [D2Coding Ver 1.3.3 – official GitHub Releases](https://github.com/naver/d2-coding-font/releases)

D2Coding is a monospaced typeface designed for programming. The official D2Coding documentation states that a Hangul syllable has exactly twice the advance width of a Latin character. This is an intentional duospaced design:

Latin / ASCII glyphs    500 units
Hangul / CJK glyphs   1000 units
unitsPerEm             1000

Therefore, two Latin characters occupy the same horizontal grid width as one Hangul character.

The actual glyph advance widths remain correct after regeneration, but two important font metadata values are changed by FontForge.

Actual result

I compared the original D2Coding 1.3.3 font with the font regenerated by FontForge.

In the original font:

post.isFixedPitch = 1
OS/2.xAvgCharWidth = 500

After opening the font in FontForge, adding a glyph, and generating a new TTF:

post.isFixedPitch = 0
OS/2.xAvgCharWidth = 944

post.isFixedPitch

I understand that FontForge may determine post.isFixedPitch by checking whether all glyphs have the same advance width.

However, this does not work well for CJK duospaced fonts.

D2Coding intentionally has two width classes:

Latin / ASCII     500 units
Hangul / CJK     1000 units

This does not mean that the font is proportional.

It is an intentional fixed-width grid in which Latin characters occupy one cell and Hangul/CJK characters occupy two cells.

Therefore, checking whether all glyphs have exactly the same advance width can incorrectly classify this type of font as non-fixed-pitch.

OS/2.xAvgCharWidth

The original D2Coding font contains:

OS/2.xAvgCharWidth = 500

while the FontForge-generated font contains:

OS/2.xAvgCharWidth = 944

The value of 944 appears to be affected by the large number of 1000-unit Hangul/CJK glyphs in the font.

For this type of duospaced coding font, the original value of 500 corresponds to the Latin/ASCII character width.

This is consistent with the original D2Coding font, which uses 500-unit Latin characters and 1000-unit Hangul/CJK characters.

Why this matters

These values are not merely cosmetic metadata.

Some applications appear to use font-level metrics such as post.isFixedPitch and/or OS/2.xAvgCharWidth when determining how a font should be treated or displayed in fixed-width contexts.

As a result, the regenerated font can behave differently from the original even though the actual glyph advance widths in the hmtx table remain correct.

In my testing, this resulted in visible spacing/layout problems with Hangul characters in certain applications.

This made the problem particularly difficult to diagnose because the actual glyph widths appeared to be correct when inspected with fontTools.

I was able to fix the problem using Python/fontTools

I was able to correct the generated TTF myself using Python and fontTools.

Specifically, I changed:

post.isFixedPitch     0 → 1
OS/2.xAvgCharWidth    944 → 500

After making these corrections, the metadata matched the original D2Coding font and the resulting layout problem was resolved.

Therefore, the problem can be corrected programmatically.

However, requiring a user to run a separate Python/fontTools post-processing script after every FontForge font generation is not an ideal workflow.

The purpose of this issue is therefore not to request a workaround. I would like FontForge itself to provide a way to specify this information when generating the font.

Feature request: CJK duospaced/fixed-pitch option

I would like to suggest adding an explicit option in FontForge's font settings or Generate Fonts dialog for this type of font.

For example:

Font width model:

( ) Proportional
( ) Fixed Pitch
( ) CJK Duospaced / Double-Width

The exact user interface and terminology are, of course, up to the FontForge developers.

The important point is that the font author should be able to explicitly tell FontForge:

This is an intentionally duospaced fixed-width font. Latin characters occupy one cell, while CJK characters occupy two cells.

When this option is selected, FontForge could generate the appropriate metadata automatically, including:

post.isFixedPitch
OS/2.xAvgCharWidth

For example, for D2Coding:

Latin / ASCII width     = 500
Hangul / CJK width      = 1000

post.isFixedPitch       = 1
OS/2.xAvgCharWidth      = 500

The actual implementation does not necessarily need to use these exact values or this exact UI.

The main request is to provide a reliable, built-in way for a font author to specify that a font uses an intentional CJK duospaced fixed-width design.

Why an explicit option may be preferable

I understand that automatically determining whether a font is fixed-pitch can be difficult.

A font containing both 500-unit and 1000-unit glyphs may appear to be a mixed-width font if FontForge simply checks whether all glyphs have identical advance widths.

For this reason, an explicit user-selectable option may be preferable to relying entirely on an automatic heuristic.

It would also preserve the current behavior for existing fonts while giving CJK font authors a way to explicitly specify their intended design.

Reference: D2Coding

D2Coding is a useful real-world example of this type of font.

The official D2Coding repository describes D2Coding as a monospaced typeface and states that a Hangul syllable has exactly twice the advance width of a Latin character.

The version used for this investigation is D2Coding Ver 1.3.3.

Official release page:

https://github.com/naver/d2-coding-font/releases

The 1.3.3 release is listed on the official repository as D2Coding Ver 1.3.3.

Existing workaround

I also found a community plugin called fontforge_ot_fixup that can correct post.isFixedPitch after font generation for this type of situation.

The existence of such a workaround suggests that this may be a recurring problem for authors of CJK duospaced fonts.

It would be very useful if similar functionality could be incorporated directly into FontForge, or exposed as an option during font generation.

Expected result

For a CJK duospaced font such as D2Coding, FontForge should provide a way for the font author to specify the intended design and generate metadata consistent with that design.

For example:

Latin / ASCII width     = 500
CJK / Hangul width      = 1000

post.isFixedPitch       = 1
OS/2.xAvgCharWidth      = 500

The actual implementation can be different. The important requirement is that FontForge should allow the font author to explicitly preserve or define the metadata appropriate for a CJK duospaced font.

Reproduction information

The following files and information are available if they would be useful for reproducing the issue:

• Original D2Coding 1.3.3 TTF
• FontForge-generated TTF
• fontTools output comparing the relevant tables
• head, hmtx, maxp, OS/2, post, and cmap table data
• Details of the glyph added before regeneration
• Screenshots showing the resulting spacing/layout difference

I would be happy to provide the sample font files and additional fontTools output if they would help with reproduction.

Thank you for taking the time to investigate this and for continuing to maintain and improve FontForge.

Best regards, Sukju Lee

D2Coding_FontForge_test.zip