caryll / otfcc

Optimized OpenType builder and inspector.

otfcc

The otfcc is a C library and utility used for parsing and writing OpenType font files.

Key features

• JSON serialization of TrueType and CFF OpenType fonts.
• Building OpenType fonts from JSON.
• Full support for OpenType features (GSUB, GPOS and GDEF), CID-keyed CFF, vertical metrics, and more.
• 4× faster than ttx on CFF OTF, and 40× on TTF.
• 900× faster than makeotf for building a fully-optimized CFF OTF.

Installation

Windows

You can download the prebuilt binaries here.

Mac

If you have Homebrew, just run the following in your terminal.

brew tap caryll/tap
brew install otfcc-mac64

Note: a full Xcode installation is required. Please refer to the instructions here if you see an error related to xcode-select.

Otherwise, you may need to click the “Releases” above, and download the archives in it.

Arch Linux

The package otfcc can be found here.

Build from Source

See below.

Usage

otfccdump : Dump an OpenType font file into JSON

otfccdump [OPTIONS] input.[otf|ttf|ttc]

 -h, --help              : Display this help message and exit.
 -v, --version           : Display version information and exit.
 -o <file>               : Set output file path to <file>. When absent the dump
                           will be written to STDOUT.
 -n <n>, --ttc-index <n> : Use the <n>th subfont within the input font.
 --pretty                : Prettify the output JSON.
 --ugly                  : Force uglify the output JSON.
 --verbose               : Show more information when building.
 --ignore-glyph-order    : Do not export glyph order information.
 --glyph-name-prefix pfx : Add a prefix to the glyph names.
 --ignore-hints          : Do not export hinting information.
 --decimal-cmap          : Export 'cmap' keys as decimal number.
 --name-by-hash          : Name glyphs using its hash value.
 --add-bom               : Add BOM mark in the output. (It is default on Windows
                           when redirecting to another program. Use --no-bom to
                           turn it off.)

otfccbuild : Build an OpenType font file from JSON

Usage : otfccbuild [OPTIONS] [input.json] -o output.[ttf|otf]

 input.json                : Path to input file. When absent the input will be
                             read from the STDIN.

 -h, --help                : Display this help message and exit.
 -v, --version             : Display version information and exit.
 -o <file>                 : Set output file path to <file>.
 -s, --dummy-dsig          : Include an empty DSIG table in the font. For some
                             Microsoft applications, DSIG is required to enable
                             OpenType features.
 -O<n>                     : Specify the level for optimization.
     -O0                     Turn off any optimization.
     -O1                     Default optimization.
     -O2                     More aggressive optimizations for web font. In this
                             level, the following options will be set:
                               --merge-features
                               --short-post
                               --subroutinize
     -O3                     The most aggressive opptimization strategy will be
                             used. In this level, these options will be set:
                               --force-cid
                               --ignore-glyph-order
 --verbose                 : Show more information when building.

 --ignore-hints            : Ignore the hinting information in the input.
 --keep-average-char-width : Keep the OS/2.xAvgCharWidth value from the input
                             instead of stating the average width of glyphs.
                             Useful when creating a monospaced font.
 --keep-unicode-ranges     : Keep the OS/2.ulUnicodeRange[1-4] as-is.
 --keep-modified-time      : Keep the head.modified time in the json, instead of
                             using current time.

 --short-post              : Don't export glyph names in the result font.
 --ignore-glyph-order, -i  : Ignore the glyph order information in the input.
 --keep-glyph-order, -k    : Keep the glyph order information in the input.
                             Use to preserve glyph order under -O2 and -O3.
 --dont-ignore-glyph-order : Same as --keep-glyph-order.
 --merge-features          : Merge duplicate OpenType feature definitions.
 --dont-merge-features     : Keep duplicate OpenType feature definitions.
 --merge-lookups           : Merge duplicate OpenType lookups.
 --dont-merge-lookups      : Keep duplicate OpenType lookups.
 --force-cid               : Convert name-keyed CFF OTF into CID-keyed.
 --subroutinize            : Subroutinize CFF table.
 --stub-cmap4              : Create a stub `cmap` format 4 subtable if format
                             12 subtable is present.

Building

otfcc can be built on a number of platforms. It uses the premake build system.

It was developed and optimized for Clang/LLVM, therefore it is strongly recommended to compile with Clang/LLVM, but if that's not possible GCC is also supported, GCC version 5.1 or later being the preferred choice for performance.

Linux (or other Unix-like)

On Linux, Either Clang/LLVM or GCC can be used to build otfcc.

1. Install the latest Clang/LLVM or GCC if you do not have it already.
2. Install premake5 and make it available in your path.
3. Run the following from the command line (Change config when necessary):

premake5 gmake
cd build/gmake
make config=release_x64

If you have Ninja installed on your system, you can use ninja either:

premake5 ninja
cd build/ninja
ninja otfccdump_release_x64 otfccbuild_release_x64

Change the targets above when necessary.

Windows

On Windows, building otfcc is tested under the toolchains listed below. The default premake5 vs2015 will produce a Visual Studio solution using Clang-CL as its compiler.

• GCC 5.1 included in TDM-GCC, or GCC 6.1.0 in MinGW-W64. Run the following from the command line (Change the config when necessary):

  premake5 gmake
  cd build/gmake
  make config=release_x64

  To use Ninja like that in Linux, you need to specify the --os=linux when using premake5 ninja.

• Visual C++ Building Tools (Mar 2016) with Clang/LLVM 3.9. Only Release build is tested. Run the following from the Visual C++ Command Prompt:

  premake5 vs2015
  msbuild build\vs\otfcc.sln /property:Configuration=Release

Mac OS

premake5 (can be installed via brew install premake --devel, or be found in the dep/bin-osx directory) provides ability to produce XCode projects. Run

premake5 xcode4

And then you can open build/xcode/otfcc.xcworkspace and build with XCode. You can find built binaries in bin/.

Please ensure that Xcode’s Developer Mode is enabled.

To build binaries in your terminal, run

xcodebuild -workspace build/xcode/otfcc.xcworkspace -scheme otfccbuild -configuration Release
xcodebuild -workspace build/xcode/otfcc.xcworkspace -scheme otfccdump -configuration Release

otfcc's Issues

Phase One Iteration Plan

• Dumping TrueType Tables
  • Glyph Order
  • head
  • hhea
  • OS/2 (version 1 - 5)
  • maxp (ttf only)
  • name
  • cmap (format 4 and 12 in Unicode encodings)
  • post (version 2 and 3)
  • loca, hmtx and glyf
  • prep, fpgm and cvt (cvt is currently exported as bytes, instead of shorts)
  • gasp
  • vhea and vmtx
• Writing TrueType Tables
  • Glyph Order
  • head
  • hhea
  • OS/2 (version 1 - 5)
  • maxp (ttf only)
  • name
  • cmap (format 4 and 12, for both platform 3 and 0)
  • post (version 3 only)
  • loca, hmtx and glyf (hmtx is not optimized yet)
  • prep, fpgm and cvt
  • gasp
  • vhea and vmtx

Convert CID OTF to CFF OTF?

Can I use otfcc to convert CID OTF to CFF OTF?

Phase 4: CFF Continued

In this phase:

• Unify cff_blob and caryll_buffer
• Add optimization to CFF writer, in order to reduce file size as more as possible. (Currently otfcc produces rmoveto, rlineto and rrcurveto only, which makes @kenlunde’s SHS increased about 4MB after a dump-build cycle.)
  • Basic phantomize (-O1) — 2MB reduction on SHS.
  • Advanced optimization (-O2) — Another 2MB reduction. It is now 17448KB vs original 17406KB. (Enabling --ignore-glyph-order will produce a 17285KB result.)
  • Subroutinization (-O3).
  • Add a -O level to control optimization force.
• Add support for full VORG
• Support LTSH
• Improved feature table writer (#26)
• Support BASE.

There seem to be some missing steps for building for Mac.

So far, it's just installing premake5, but I'm giving up on that for now. Not on homebrew which means it's tedious on El Capitan.

otfcc.js via emscripten?

Do you have plans to compile otfcc via emscripten, so it could work in a browser via JS?

--add-bom for -o

锘

What dose "otfcc" mean?

I just curious about why dose this library named otfcc?
And how to pronounce? o-t-f-c-c?

otfccbuild 0.6.2 hangs while converting SourceHanSansJP and SourceHanSansKR

Source Han Sans 1.004
for example: SourceHanSansJP-Regular.otf, SourceHanSansKR-Regular.otf
(But it's fine for SourceHanSansCN and SourceHanSansTW)

$ otfccdump -v
This is otfccdump, version 0.6.2.
$ otfccbuild -v
This is otfccbuild, version 0.6.2.

It hangs while using the following one-line command

$ otfccdump SourceHanSansJP-Regular.otf | otfcc-c2q | otfccbuild -o SourceHanSansJP-Regular.ttf

If I take the two-steps approach

$ otfccdump SourceHanSansJP-Regular.otf | otfcc-c2q > dump
(complete in reasonable time)
$ otfccbuild dump -o SourceHanSansJP-Regular.ttf
(hang and consume almost all CPU resources)

BTW, it's fine for all SourceHanSans while using otfcc 0.6.1

OS: Ubuntu 16.10 64bit
GCC: 6.2.0 20161005
Premake : 5.0.0-alpha10
GMake: 4.1
otfcc built with:

$ premake5 gmake
$ cd build/gmake/
$ make config=release_x64

Mac OS X building info

In the Mac OS X building info section, you could add that premake5 can be installed via brew:

brew install premake --devel

global-buffer-overflow in /lib/support/unicodeconv/unicodeconv.c:40:2

Test Version

dev version, git clone https://github.com/caryll/otfcc.git

Test Program

otfcc/bin/release-x64/otfccdump [infile]

Asan Debug Information

➜  release-x64 git:(master) ✗ ./otfccdump ../../../crashes_1/2018-12-30-01-global-buffer-overflow.otf   
=================================================================
==46365==ERROR: AddressSanitizer: global-buffer-overflow on address 0x0000008be881 at pc 0x0000004582e5 bp 0x7fff894427d0 sp 0x7fff89441f80
READ of size 95 at 0x0000008be881 thread T0
    #0 0x4582e4  (/home/moonagirl/megic_afl/otfcc/bin/release-x64/otfccdump+0x4582e4)
    #1 0x86c0c1  (/home/moonagirl/megic_afl/otfcc/bin/release-x64/otfccdump+0x86c0c1)
    #2 0x844322  (/home/moonagirl/megic_afl/otfcc/bin/release-x64/otfccdump+0x844322)
    #3 0x68c74d  (/home/moonagirl/megic_afl/otfcc/bin/release-x64/otfccdump+0x68c74d)
    #4 0x4fb6ec  (/home/moonagirl/megic_afl/otfcc/bin/release-x64/otfccdump+0x4fb6ec)
    #5 0x4eb79f  (/home/moonagirl/megic_afl/otfcc/bin/release-x64/otfccdump+0x4eb79f)
    #6 0x7f893917c82f  (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #7 0x418c88  (/home/moonagirl/megic_afl/otfcc/bin/release-x64/otfccdump+0x418c88)

0x0000008be881 is located 0 bytes to the right of global variable '<string literal>' defined in '../../lib/support/unicodeconv/unicodeconv.c:40:22' (0x8be880) of size 1
  '<string literal>' is ascii string ''
SUMMARY: AddressSanitizer: global-buffer-overflow (/home/moonagirl/megic_afl/otfcc/bin/release-x64/otfccdump+0x4582e4) 
Shadow bytes around the buggy address:
  0x00008010fcc0: 00 00 00 06 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9
  0x00008010fcd0: 00 07 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
  0x00008010fce0: 02 f9 f9 f9 f9 f9 f9 f9 00 00 00 06 f9 f9 f9 f9
  0x00008010fcf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x00008010fd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x00008010fd10:[01]f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
  0x00008010fd20: 00 00 00 00 01 f9 f9 f9 f9 f9 f9 f9 00 04 f9 f9
  0x00008010fd30: f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 00 00 f9 f9
  0x00008010fd40: f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
  0x00008010fd50: f9 f9 f9 f9 00 05 f9 f9 f9 f9 f9 f9 00 04 f9 f9
  0x00008010fd60: f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 00 07 f9 f9
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==46365==ABORTING

POC file

https://github.com/moonAgirl/Bugs/blob/master/otfcc/2018-12-30-01-global-buffer-overflow.otf/

CFF Subroutinizer

• Add a Subroutinizer to CFF support (in charstring_il.c, or a separate file).
• Assign to otfcc’s -O3

cc. @huntzhan @schriftgestalt

Cannot properly dump transformation matrix in U+1D1D in Noto Sans

This is original U+1D1D in Noto Sans:

After running

otfccdump.exe NotoSans-Regular.ttf | otfccbuild.exe -o a.ttf

it looks like this:

otfccdump dumps U+1D1D in Noto Sans to this:

        "uni1D1D": {
            "advanceWidth": 618,
            "references": [
                {"glyph":"n","x":38,"y":584,"a":0,"b":-1,"c":1,"d":-1,"roundToGrid":true}
            ],
            "instructions": ["PUSHB_2",0,1,"PUSHW_1",584,"PUSHB_1",51,"CALL"]
        },

It seems that "d" should be 0.

NotoSans-Regular.zip
otfcc version: 0.10.3 (prebuilt Windows x64, downloaded from https://github.com/caryll/otfcc/releases/tag/v0.10.3-alpha)

Variations

Purposal:

1. Design a Functional type and a Ket type to represent the procedure used to produce final coordinates and metrics
2. Metadata:
   • fvar.
   • avar.
   • STAT.
3. TT:
   • gvar.
   • cvar.
   • gasp modifications.
4. CFF2:
   • CFF2.
5. Metrics
   • MVAR.
   • HVAR.
   • VVAR.
6. OTL
   • Conditional feature selectors.
   • GPOS modifications (as well as device tables).
   • GDEF modifications.

Mac install through brew fails

Round-trip Dump and Build appears to change GPOS kerning

Original font has no kern here.

After Dump and Build a new kerning pair has appeared.

otffccdump 0.6.0 Segmentation fault while JSON last brace

Source Han Sans 1.004
for example: SourceHanSansCN-Bold.otf

$ otfccdump -v
This is otfccdump, version 0.6.0.
$ otfccdump SourceHanSansCN-Bold.otf
......
            "latn": {
                "defaultBaseline": "romn",
                "baselines": {
                    "icfb": 35,
                    "icft": 965,
                    "ideo": 0,
                    "romn": 120
                }
            }
        }
    }
Segmentation fault

compared with otfccdump 0.5.2 for the same file:

$ otfccdump -v
This is otfccdump, version 0.5.2.
$ otfccdump SourceHanSansCN-Bold.otf
......
            "latn": {
                "defaultBaseline": "romn",
                "baselines": {
                    "icfb": 35,
                    "icft": 965,
                    "ideo": 0,
                    "romn": 120
                }
            }
        }
    }
}

OS: Ubuntu 16.10 64bit
GCC: 6.2.0 20161005
Premake : 5.0.0-alpha10
GMake: 4.1
otfcc built with:

$premake5 gmake
$cd build/gmake/
$make config=release_x64

otfcc-0.6.0 binary Google Drive

SIGSEGV when feeding otfccdump with crafted otf file

As of 48e5245, when feeding otfccdump with some crafted otf files, it may crash with backtrace like:

$ gdb --args ~/FOT/otfcc-debug/bin/debug-x64/otfccdump c01.otf
Reading symbols from /home/hongxu/FOT/otfcc-debug/bin/debug-x64/otfccdump...done.
gdb$ run
Starting program: /home/hongxu/FOT/otfcc-debug/bin/debug-x64/otfccdump c01.otf

Program received signal SIGSEGV, Segmentation fault.
0x000055555556920a in readOtf (_sfnt=0x5555558406c0, index=0x0, options=0x555555840260) at ../../lib/otf-reader/otf-reader.c:43
43                              GlyfIOContext ctx = {.locaIsLong = font->head->indexToLocFormat,
gdb$ bt
#0  0x000055555556920a in readOtf (_sfnt=0x5555558406c0, index=0x0, options=0x555555840260) at ../../lib/otf-reader/otf-reader.c:43
#1  0x0000555555565c51 in main (argc=0x2, argv=0x7fffffffbef8) at ../../src/otfccdump.c:199

poc.zip

The binary is compiled with default debug_x64 config; for other compilations such as -O0 -fsanitize=address, it may hang with infinite loop.

Adobe Tin?

Does this project have any relation to Adobe Tin? Adobe published a fairly complete C++ parser code in 2008-2010, under a liberal license (MIT-style I think). Is there a reason why this is better? What's the differences?

[Request ?] Dump/import specific table from/to otc

Another feature request regarding existing ttx feature. See if there's a chance too.

Make otfcc a library.

missing return

there seems to be a missing return blob; in 'cff_writer.c:153'.

Could not convert Source Han Serif to TTF

While doing

otfccdump.exe NotoSansMonoCJKsc-Bold.otf | otfcc-c2q | otfccbuild.exe -o NotoSansMonoCJKsc-Bold.ttf

worked for Source Han Sans / Noto Sans CJK, it fails at the new Source Han Serif fonts:

otfccdump.exe NotoSerifCJKsc-Black.otf | otfcc-c2q | otfccbuild.exe -o NotoSerifCJKsc-Black.ttf
<...>\npm\node_modules\otfcc-c2q\c2q_cli.js:7
process.stdin.on('data', function (buf) { glyfsource += buf.toString(); });
                                                            ^

RangeError: Invalid string length
    at Socket.<anonymous> (<...>\npm\node_modules\otfcc-c2q\c2q_cli.js:7:61)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:188:7)
    at readableAddChunk (_stream_readable.js:176:18)
    at Socket.Readable.push (_stream_readable.js:134:10)
    at Pipe.onread (net.js:547:20)
otfccbuild : Parse into JSON : [ERROR] Cannot parse JSON file "(null)". Exit.

otfcc 0.9.6 on macOS x64 yields invalid OTF font after simple roundtrip

repro:

# fetch https://github.com/caryll/otfcc/archive/v0.9.6.tar.gz and unarchive
./dep/bin-osx/premake5 ninja
cd build/ninja
ninja otfccdump_release_x64 otfccbuild_release_x64
./bin/release-x64/otfccdump -o Inter-Regular.json Inter-Regular.otf
./bin/release-x64/otfccbuild -o Inter-Regular-otfccbuild.otf Inter-Regular.json

The input file Inter-Regular.otf is from the Inter v3.11 release and is verified to work correctly in a variety of font parsers (also it passes the macOS Font Book validator)

However the output file is not only MUCH larger in size but also does not work on macOS. Font Book validation fails with “System Validation” error:

Attached here is the input font file, resulting output font file and the JSON dump, to save you some time:
otfs-and-json.zip

Here are TTX dumps with a diff:
ttx-with-diff.zip

I also tried building the latest master from git which yields the exact same results.

Env:

$ uname -rsv
Darwin 18.7.0 Darwin Kernel Version 18.7.0: Sun Dec  1 18:59:03 PST 2019; root:xnu-4903.278.19~1/RELEASE_X86_64
$ ./bin/release-x64/otfccdump -v
This is otfccdump, version 0.9.6.
$ shasum Inter-Regular.otf
389bb3dbdb1bc81c96b000688ed672180b3ee78d  Inter-Regular.otf

clock_gettime not available on OS X

Hi, and thanks for working on this!

I tried to compile it on my mac, but it seems like the function clock_gettime is not available on that platform. This is what I get from make:

$ make all
clang -O3 -Wall -c otfccdump.c -o build/otfccdump.o
otfccdump.c:87:2: warning: implicit declaration of function 'clock_gettime' is invalid in C99 [-Wimplicit-function-declaration]
        clock_gettime(CLOCK_REALTIME, &ends);
        ^
otfccdump.c:87:16: error: use of undeclared identifier 'CLOCK_REALTIME'
        clock_gettime(CLOCK_REALTIME, &ends);
                      ^
otfccdump.c:96:16: error: use of undeclared identifier 'CLOCK_REALTIME'
        clock_gettime(CLOCK_REALTIME, &begin);
                      ^
1 warning and 2 errors generated.
make: *** [build/otfccdump.o] Error 1

Here a link where they discuss about alternatives to clock_gettime for OS X:
http://stackoverflow.com/questions/5167269/clock-gettime-alternative-in-mac-os-x

Thanks.

Cosimo

Glyph names changing

When dumping a TTF the glyph for U+0009, U+000D has it's name changed to "nonmarkingreturn". This does not seem to be the case for OTF (CFF) fonts.
Would it be possible to have an option flag to preserve post tables names if a post table is present?

Unable to build with latest gcc (6.2.1-5)

[~/bin/otfcc-0.6.3]: gcc --version
gcc (Debian 6.2.1-5) 6.2.1 20161124

[~/bin/otfcc-0.6.3]: premake5 gmake
Building configurations...
Running action 'gmake'...
Generated build/gmake/Makefile...
Generated build/gmake/deps.make...
Generated build/gmake/libotfcc.make...
Generated build/gmake/otfccdump.make...
Generated build/gmake/otfccbuild.make...
Done (164ms).
[~/bin/otfcc-0.6.3]: cd build/gmake/
[~/bin/otfcc-0.6.3/build/gmake]: make
==== Building deps (debug_x32) ====
Creating bin/x32/Debug
Creating obj/x32/Debug/deps
emyg-dtoa.c
json-builder.c
json.c
sds.c
Linking deps
==== Building libotfcc (debug_x32) ====
Creating obj/x32/Debug/libotfcc
bkblock.c
bkgraph.c
consolidate.c
GDEF.c
chaining.c
common.c
gpos-cursive.c
gpos-pair.c
gpos-single.c
gsub-ligature.c
gsub-multi.c
gsub-reverse.c
gsub-single.c
mark.c
caryll-font.c
caryll-sfnt-builder.c
caryll-sfnt.c
json-reader.c
json-writer.c
cff-charset.c
cff-codecs.c
cff-dict.c
cff-fdselect.c
cff-index.c
cff-opmean.c
cff-parser.c
cff-string.c
cff-value.c
cff-writer.c
charstring-il.c
subr.c
logger.c
otf-reader.c
unconsolidate.c
otf-writer.c
stat.c
aglfn.c
base64.c
buffer.c
glyph-order.c
handle.c
json-ident.c
options.c
primitives.c
sha1.c
ttinstr.c
unicodeconv.c
BASE.c
CFF.c
COLR.c
CPAL.c
GDEF.c
LTSH.c
OS_2.c
SVG.c
../../lib/table/SVG.c: In function ‘otfcc_buildSVG’:
../../lib/table/SVG.c:129:12: warning: ‘main’ is usually a function [-Wmain]
  bk_Block *main = bk_new_Block(b16, svg.length, // numEntries
            ^~~~
VORG.c
cmap.c
cvt.c
fpgm-prep.c
gasp.c
glyf.c
hdmx.c
head.c
hhea.c
hmtx.c
maxp.c
name.c
build.c
classdef.c
constants.c
coverage.c
dump.c
otl.c
parse.c
read.c
build.c
classifier.c
common.c
dump.c
parse.c
read.c
extend.c
gpos-common.c
gpos-cursive.c
gpos-mark-to-ligature.c
gpos-mark-to-single.c
gpos-pair.c
gpos-single.c
gsub-ligature.c
gsub-multi.c
gsub-reverse.c
gsub-single.c
post.c
vhea.c
vmtx.c
functional.c
Linking libotfcc
==== Building otfccdump (debug_x32) ====
Creating ../../bin/Debug-x32
Creating obj/x32/Debug/otfccdump
otfccdump.c
../../src/otfccdump.c: In function ‘main’:
../../src/otfccdump.c:57:7: warning: variable ‘no_bom’ set but not used [-Wunused-but-set-variable]
  bool no_bom = false;
       ^~~~~~
stopwatch.c
Linking otfccdump
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/6/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/6/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
collect2: error: ld returned 1 exit status
otfccdump.make:138: recipe for target '../../bin/Debug-x32/otfccdump' failed
make[1]: *** [../../bin/Debug-x32/otfccdump] Error 1
Makefile:58: recipe for target 'otfccdump' failed
make: *** [otfccdump] Error 2
[~/bin/otfcc-0.6.3/build/gmake]: 

Downloaded otfcc from https://github.com/caryll/otfcc/archive/v0.6.3.tar.gz
Downloaded premake5 from https://github.com/premake/premake-core/releases/download/v5.0.0-alpha10/premake-5.0.0-alpha10-linux.tar.gz

Running Debian Sid/Testing

Phase 3, CFF

In this phase, otfcc will be able to read and write CFF outlines.

The CFF table data will be separated into two records:

• The existing glyf for curves;
• A new record CFF_ for metadata.
  • CFF Parser
    • Metadata
    • Outline & Metrics
    • Hints
    • CID
  • CFF Writer
    • Metadata
    • Outline & Metrics
    • Hints
    • CID
  • JSON format integration

MATH Table

I always want to make a math font. SUPPORT THIS.

• Parsing
• Writing
• Test with open-source font payloads: XITS/Asana/Libertinus/...

Phase Two Iteration Plan

In Phase Two, we will mainly focus on features.

• GSUB
  • 1. Single
  • 2. Multiple
  • 3. Alternate
  • 4. Ligature
  • 5. Context
  • 6. Chaining Context
  • 7. Extension Substitution (NOTE: All extensions will be “flatten” — which means that the output JSON will not contain this table type. Also, when writing a binary table, if the subtables offset reaches 65535 bytes, extensions will be automatically used.)
  • 8. Reverse chaining context
• GPOS
  • 1. Single
  • 2. Pair
  • 3. Cursive
  • 4. Mark-to-base
  • 5. Mark-to-ligature
  • 6. Mark-to-mark
  • 7. Context
  • 8. Chained Context
  • 9. Extension Positioning
• GDEF
  • Glyph classes
  • Ligature caret
  • Other metadata (markAttachClassDef)

[Request] export CMAP keys in hexdecimal

I see current CMAP keys are still in decimal only, so I'm here to if there's a chance to support this...

'advanceWithMax' field under 'hhea' should be 'advanceWidthMax'

Base on the output file of version 0.9.6, under the table 'hhea', there's a field advanceWithMax which might be a misspelling. According to Microsoft's opentype website and Apple's , the field should be advanceWidthMax.

Add otfcc-macos.arm64-0.10.4.zip for M1 devices.

I have built the binaries for M1 and they are located here:
https://github.com/hfhchan/otfcc-macos.arm64/releases/tag/v0.10.4

Dumped JSON file does not conform with JSON standard which leads to decoding problems

Dumped JSON file, contains encoded strings, which could error prone while decoding in scripting languages like Python.

These encoded strings, especially those in the name table, are directly dumped as bytes, and are not always uniformly encoded because they are stored encoded in fonts as bytes when the corresponding platform is Windows.

JSON decoding, for example, in Python 3, the json.load() or json.loads() accept str instead of bytes, and when we try to decode the bytes, the problem would occurs because the JSON file could contain mixed encoded bytes. The same could also happen when we consider the JSON generation problem in Python 3. Most third party JSON parsing packages in Python faces the same problem. And many C/C++ JSON parsing library also assume the JSON should use Unicode encoding (RapidJSON, for example). But there are ShiftJIS and GBK in these dumped bytes for many Chinese and Japanese fonts. Decisions made by these software is reasonable because according to RFC-7159, section 8.1,

JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32. The default encoding is UTF-8, and JSON texts that are encoded in UTF-8 are interoperable in the sense that they will be read successfully by the
maximum number of implementations; there are many implementations that cannot successfully read texts in other encodings (such as UTF-16 and UTF-32).

Similar articles appear in ECMA-404 as well.

I definitely can write a JSON parsing package based on YAJL's tokenizer and its corresponding JSON parser, which uses bytes as its sole data exchanging type even in Python 3, and I am actually working on one. However, I am hoping there could be a more elegant solution. For example, when dump JSON, use base64 to do an additional encoding, or decode them and encode to Unicode before dump. Or provide a manipulate API for other language is also preferable.

Hope these information is self-contained and can help you understand the problem.

bitmap font info related segments does not supportted?

Bitmap font info related segments Such as EBDT and EBLC does not exported with current version.

[Help] Issues compiling on latest Ubuntu

I was hoping you could help me with this.

I was trying to compile https://github.com/be5invis/Iosevka by myself but I fail at compiling otfcc for it, as I'm not exactly keen with compilers and environments.
There were other errors before, which I was able to solve by installing libc6-dev-i386.

==== Building otfccdump (debug_x32) ====
Creating obj/x32/Debug/otfccdump
otfccdump.c
../../src/cli/otfccdump.c: In function ‘main’:
../../src/cli/otfccdump.c:55:7: warning: variable ‘no_bom’ set but not used [-Wunused-but-set-variable]
  bool no_bom = false;
       ^
stopwatch.c
Linking otfccdump
bin/x32/Debug/liblibotfcc-tables.a(glyf.o): In function `coord_to_json':
/home/dev/otfcc/build/gmake/../../src/tables/glyf.c:356: undefined reference to `roundf'
bin/x32/Debug/libexternals.a(json-builder.o): In function `json_measure_ex':
/home/dev/otfcc/build/gmake/../../dep/extern/json-builder.c:672: undefined reference to `floor'
collect2: error: ld returned 1 exit status
otfccdump.make:138: recipe for target '../../bin/Debug-x32/otfccdump' failed
make[1]: *** [../../bin/Debug-x32/otfccdump] Error 1
Makefile:98: recipe for target 'otfccdump' failed
make: *** [otfccdump] Error 2

Running 16.04 LTS (Xenial), uname -a is:

Linux dev-vm 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Separate the two formats of GlyphOrder -- or make it completely invisible from users

Proposal:

• Rename the string-to-index GlyphOrder into "glyph_map".
• Separate the index-to-string GlyphOrder, maybe we should not use the hash table now.

Pretty-print contours as well

When using --pretty it would be nice to see a newline for each contour value.

"contours": [[{"x":-16383,"y":16383,"on":true},{"x":16383,"y":16383,"on":true},{"x":16383,"y":-16383,"on":true},{"x":-16383,"y":-16383,"on":true}]]

to

"contours": [[
    {"x":-16383,"y":16383,"on":true},
    {"x":16383,"y":16383,"on":true},
    {"x":16383,"y":-16383,"on":true},
    {"x":-16383,"y":-16383,"on":true}
]]

Integer precision

The code compiles fine with Xcode/clang in 64 bit mode. But it produces a lot warnings because the code mixes definitions of size_t and uint32_t. On 32 bit both are the same so that would not show up as a problem.

Name glyphs using its hash

This is an interesting approach about merging TTFs into a TTC: we can name the glyphs using its hash (SHA-1 or SHA-256), then use a very simple script to perform the merge process.

Key problems:

• References: May be solved by recursively name its components, and encode its hash using the components' hash.

`error: format string is not a string literal` in _TSI.c

I'm trying to build otfcc v0.8.4 for NixOS. With Clang/LLVM as well as GCC I'm getting the following errors:

../../lib/table/_TSI.c:87:13: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security]
        loggedStep(tag) {
                   ^~~
../../lib/support/aliases.h:8:85: note: expanded from macro 'loggedStep'
                      (options->logger->startSDS(options->logger, sdscatprintf(sdsempty(), __VA_ARGS__)), true);           \
                                                                                           ^~~~~~~~~~~
../../lib/table/_TSI.c:87:13: note: treat the string as an argument to avoid this
        loggedStep(tag) {
                   ^
                   "%s", 
../../lib/support/aliases.h:8:85: note: expanded from macro 'loggedStep'
                      (options->logger->startSDS(options->logger, sdscatprintf(sdsempty(), __VA_ARGS__)), true);           \
                                                                                           ^
../../lib/table/_TSI.c:128:13: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security]
        loggedStep(tag) {
                   ^~~
../../lib/support/aliases.h:8:85: note: expanded from macro 'loggedStep'
                      (options->logger->startSDS(options->logger, sdscatprintf(sdsempty(), __VA_ARGS__)), true);           \
                                                                                           ^~~~~~~~~~~
../../lib/table/_TSI.c:128:13: note: treat the string as an argument to avoid this
        loggedStep(tag) {
                   ^
                   "%s", 
../../lib/support/aliases.h:8:85: note: expanded from macro 'loggedStep'
                      (options->logger->startSDS(options->logger, sdscatprintf(sdsempty(), __VA_ARGS__)), true);           \
                                                                                           ^
3 warnings and 2 errors generated.

I've followed the instructions with:

premake5 gmake
cd build/gmake
make config=release_x64

Any input on how to solve this?

Subsetting

In the README you state how many times faster otfcc is than ttx; fontTools also provides a subsetter, and I wonder if otfcc might also provide a subsetter :)

Node.js bindings of otfcc?

Any idea to make otfcc a Node.js binding? For example:

const otfcc = require('otfcc');
const data = otfcc.dumpFromFile('font.ttf');
// do something
otfcc.buildFromJSON(data, { optimizeLevel: 3, ignoreHints: true });

Currently I'm using child_process to manually invoke otfcc, which is really a pain.

JSON schema

Hello. Sometimes I feel uncertain about otfccdump's output so I have to look into the source code. Is there any descriptive documents (like JSON schema) about JSON format used in OTFCC?

Option to get relative contour values

In the spec I read about coordinates:

First coordinates relative to (0,0); others are relative to previous point.

Yet the coordinates dumped with otfcc all seem to be relative to (0, 0). Is there any way to dump/compile them relative to the previous point?

(This is a very similar request I did for ttx/FontTools if you want an example)