Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[makeotf] update docs to describe how to invoke 5- and 6-digit Unicode values needed for SPUA-A and SPUA-B #1177

Closed
mbutterick opened this issue Jun 29, 2020 · 8 comments · Fixed by #1179

Comments

@mbutterick
Copy link

Docs:

The third field is a Unicode value, specified in the form uniXXXX or uXXXX, where XXXX is a Unicode value (hexadecimal).

Codepoints in SPUA-A are represented with 5 hex digits; those in SPUA-B with 6. The four-digit limitation on codepoints in the GOADB means that one cannot make a font with codepoints in these areas.

@benkiel
Copy link
Contributor

benkiel commented Jun 29, 2020

Not well documented there, but for those above 4 digits, use uXXXXX or uXXXXXX. uni is only for four digits, afaik

@punchcutter
Copy link
Contributor

Yes, that's not so clear. We'll update the docs.

@mbutterick
Copy link
Author

mbutterick commented Jun 29, 2020

Oh really? Here’s a (disassembled) pfa and a goadb that uses the 6-digit convention. Though makeotf compiles the font, the resulting font has no codepoints.

%!
0 dict dup begin
/FontName /Test def
/Private 0 dict dup begin
/RD {string currentfile exch readstring pop} def
/CharStrings 5 dict dup begin
/D {
0 1000 hsbw
0 0 rmoveto
0 1000 rlineto
1000 0 rlineto
closepath
endchar
} def
/C {
0 1000 hsbw
0 0 rmoveto
0 1000 rlineto
1000 0 rlineto
closepath
endchar
} def
/B {
0 1000 hsbw
0 0 rmoveto
0 1000 rlineto
1000 0 rlineto
closepath
endchar
} def
/A {
0 1000 hsbw
0 0 rmoveto
0 1000 rlineto
1000 0 rlineto
closepath
endchar
} def
/.notdef {
0 1000 hsbw
0 0 rmoveto
0 1000 rlineto
1000 0 rlineto
closepath
endchar
} def
end % of CharStrings dict
def
end % of Private dict
.notdef .notdef u000000
space space u000020
A A u000041
B B u000042
C C u000043
D D u000044

If I replace the above goadb with one that uses the 4-digit convention:

.notdef .notdef u0000
space space u0020
A A u0041
B B u0042
C C u0043
D D u0044

The resulting font has the expected codepoints.

@mbutterick
Copy link
Author

makeotf logging output with 6-digit goadb:

makeotfexe [WARNING] missing /FontBBox (default inserted)
makeotfexe [WARNING] FontMenuNameDB file was not specified or not found. [Test]
makeotfexe [WARNING] <Test> cmap{plat=1,script=0,lang=0}: empty encoding
makeotfexe [WARNING] <Test> unable to patch FontBBox in CFF table
makeotfexe [WARNING] <Test> cmap{plat=3,script=1,lang=0}: empty encoding

With 4-digit goadb:

makeotfexe [WARNING] missing /FontBBox (default inserted)
makeotfexe [WARNING] FontMenuNameDB file was not specified or not found. [Test]
makeotfexe [WARNING] <Test> unable to patch FontBBox in CFF table

@punchcutter
Copy link
Contributor

You can't mix the lengths like that. If something can be represented by 4 digits then you use 4. If it requires 5 or 6 then you use 5 or 6. I guess maybe that could also use clarification.

@benkiel
Copy link
Contributor

benkiel commented Jun 30, 2020

@mbutterick in my GOADB files, I'm not using the third column (often) to assign unicode, just changing the final name (first column) to the uXXXXX value. That works. So, @punchcutter, there could be something there that isn't working but should

@punchcutter
Copy link
Contributor

I'm not sure what might not be working. It all seems to be working for me using 4, 5, or 6 digit unicodes to either rename or set the Unicode value.

@mbutterick
Copy link
Author

FWIW this GOADB works for me.

.notdef .notdef u0000,uF00000
space space u0020,uF00020
A A u0041,uF00041
B B u0042,uF00042
C C u0043,uF00043
D D u0044,uF00044

@mbutterick mbutterick changed the title [makeotf] update GOADB parser to support 5- and 6-digit Unicode values needed for SPUA-A and SPUA-B [makeotf] update docs to describe how to invoke 5- and 6-digit Unicode values needed for SPUA-A and SPUA-B Jun 30, 2020
punchcutter added a commit that referenced this issue Jul 5, 2020
Update STAT handling to write version 1.2 table only if there are Format 4 Axis value tables
Warn if unregistered axis tags are not uppercase
Warn if Format 2 default value is not in min-max range
Fail if DesignAxis tag has already been defined
Fail if Axis Value Table of the same format has already been defined with the same values

Add `[name]` to name table messages
Warn when overwriting existing nameid
Fail if GSUB or STAT are defined before name table and name table sets nameids above 255: #1178

Docs:
Clarify use of Unicode values in column 3 of GlyphOrderAndAliasDB #1177
punchcutter added a commit that referenced this issue Jul 9, 2020
Update STAT handling to write version 1.2 table only if there are Format 4 Axis value tables
Warn if unregistered axis tags are not uppercase
Warn if Format 2 default value is not in min-max range
Fail if DesignAxis tag has already been defined
Fail if Axis Value Table of the same format has already been defined with the same values

Add `[name]` to name table messages
Warn when overwriting existing nameid
Fail if GSUB or STAT are defined before name table and name table sets nameids above 255: #1178

Docs:
Clarify use of Unicode values in column 3 of GlyphOrderAndAliasDB #1177
1div0 pushed a commit to 1div0/afdko that referenced this issue Dec 29, 2020
Update STAT handling to write version 1.2 table only if there are Format 4 Axis value tables
Warn if unregistered axis tags are not uppercase
Warn if Format 2 default value is not in min-max range
Fail if DesignAxis tag has already been defined
Fail if Axis Value Table of the same format has already been defined with the same values

Add `[name]` to name table messages
Warn when overwriting existing nameid
Fail if GSUB or STAT are defined before name table and name table sets nameids above 255: adobe-type-tools#1178

Docs:
Clarify use of Unicode values in column 3 of GlyphOrderAndAliasDB adobe-type-tools#1177
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants