adobe-type-tools / afdko Goto Github PK

Adobe Font Development Kit for OpenType

Home Page: https://adobe-type-tools.github.io/afdko/

License: Other

Python 11.86% Shell 0.01% Makefile 0.02% C 52.15% C++ 6.03% C# 0.01% Yacc 0.07% PostScript 29.49% Objective-J 0.01% CMake 0.22% ANTLR 0.14%

afdko's Introduction

Adobe Font Development Kit for OpenType (AFDKO)

The AFDKO is a set of tools for building OpenType font files from PostScript and TrueType font data.

This repository contains the data files, Python scripts, and sources for the command line programs that comprise the AFDKO. The project uses the Apache 2.0 Open Source license. Please note that the AFDKO makes use of several dependencies, listed in the requirements.txt file, which will automatically be installed if you install AFDKO with pip. Most of these dependencies are BSD or MIT license, with the exception of tqdm, which is MPL 2.0.

Please refer to the AFDKO Overview for a more detailed description of what is included in the package.

Please see the wiki for additional information, such as links to reference materials and related projects.

📣 Recent News

The Python port of psautohint was (re)integrated into the AFDKO repository as "otfautohint"

More information can be found in docs/otfautohint_Notes.md

Installation

The AFDKO requires Python 3.8 or later. It should work with any Python > 3.8, but occasionally tool-chain components and dependencies don't keep pace with major Python releases, so there might be some lag time while they catch up.

Releases are available on the Python Package Index (PyPI) and can be installed with pip.

Note for macOS users: we recommend that you do not use the system Python. Among other reasons, some versions of macOS ship with Python 2 and the latest version of the AFDKO is only available for Python 3. You can find instructions for using Brew to install Python 3 on macOS here: Installing Python 3 on Mac OS X. Also: pyenv is a great tool for installing and managing multiple Python versions on macOS.

Note for all users: we STRONGLY recommend the use of a Python virtual environment (venv) and the use of python -m pip install <package> to install all packages (not just AFDKO). Calling pip install directly can result in the wrong pip being called, and the package landing in the wrong location. The combination of using a venv + python -m pip install helps to ensure that pip-managed packages land in the right place.

Note for Linux users (and users of other platforms that are not macOS or Windows): When there is not a pre-built "wheel" for your platform pip will attempt to build the C and C++ portions of the package from source. This process will only succeed if both the C and C++ development tools and libuuid are installed. See build from source below.

Installing

Option 1 (Recommended)

Create a virtual environment:
```
python -m venv afdko_env
```

Activate the virtual environment:

macOS & Linux
```
source afdko_env/bin/activate
```
Windows
```
afdko_env\Scripts\activate.bat
```

Install afdko:
```
python -m pip install afdko
```

Installing the afdko inside a virtual environment prevents conflicts between its dependencies and other modules installed globally.

Option 2 (not recommended unless there is a global conflict)

Local user installation afdko (info):

python -m pip install --user afdko

Updating

Use the -U (or --upgrade) option to update the afdko (and its dependencies) to the newest stable release:

python -m pip install -U afdko

To get pre-release and in-development versions, use the --pre flag:

python -m pip install -U afdko --pre

Uninstalling

To remove the afdko package use the command:

python -m pip uninstall afdko

Build from source

First you must have installed the development tools for your platform.

On macOS, install these with:

xcode-select --install

On Linux (Ubuntu 17.10 LTS or later), install these with:

apt-get -y install python3.8
apt-get -y install python-pip
apt-get -y install python-dev
apt-get -y install uuid-dev

On other POSIX-like operating systems, libuuid and its header files may be in a package named libuuid-devel or util-linux-libs. The source code for libuuid is maintained in the util-linux repository.

On Windows, you need Visual Studio 2017 or later.

To build the afdko from source, clone the afdko GitHub repository, ensure the wheel module is installed (python -m pip install wheel), then cd to the top-level directory of the afdko, and run:

python -m pip install .

Developing

If you'd like to develop & debug AFDKO using Xcode, run:

CMake -G Xcode .

For further information on building from source see docs/FDK_Build_Notes.md.

Note

It's not possible to install the afdko in editable/develop mode using python -m pip install -e . ; this is because the toolkit includes binary C executables which setup.py tries to install in the bin/ (or Scripts/) folder, however this process was only meant to be used with text-based scripts (either written in Python or a shell scripting language). To work around this problem (which really only impacts the few core afdko developers who need to get live feedback as they modify the source files) you can use alternative methods like exporting a PYTHONPATH, using a .pth file or similar hacks. For further details read this comment.

Major changes from version 2.5.x

The AFDKO has been restructured so that it can be installed as a Python package. It now depends on the user's Python interpreter, and no longer contains its own Python interpreter.
Two programs, IS and checkoutlines were dropped because their source code could not be open-sourced. These tools are available in release version 2.5.65322 and older.

Note

If you install the old AFDKO as well as the new PyPI afdko package, the tools from the newer version will take precedence over the older. This happens because pip adds the afdko's package path at the beginning of the system's PATH environment variable, whereas the old installer adds it at the end; this modification to PATH is not undone by the uninstaller. If you want to completely remove the path to the newer version, you will have to edit the PATH. On the Mac, this means editing the line in your login file that sets the PATH variable. On Windows, this means editing the PATH environment variable in the system's Control Panel.

afdko's People

Contributors

Stargazers

Watchers

Forkers

anthrotype denisfitz57 moyogo davelab6 sannorozco wayna1974 kvilhaugsvik rrthomas acidburn0zzz holomorph schriftgestalt zedmar pauldhunt virgilming glasseyes jamesgk nasty27 pradnyanaik17 nuttshell daltonmaag codeman38 mashabow jessamynsmith stglolry bitforks grzegorzrolek kanou-h kalapi sheep426 princeofdarkness76 brawer uikit0 arno-enslin yochju blakejia preusstype aleftype venkatarajasekhar issuu hasimir frejsoya behnam behdad shinchu bams curzy pmphxs sasabonsam blueshade7 mrhso explife0011 ilyafinkelshteyn gilphe masakura areebmoin linecode felipesanches plutext 1div0 lianchan dalavancloud whitemike889 prathyushasajja kohler sambacha z4rd agileehsan carlosdetoro newtypo mxlcpu bwry msoxzw paulyc sergeresko ln-north download8866 gitter-badger molandtoxx han-jingyu yuhonghong7035 fontlab carsonslovoka simoncozens ystallonne alagong antlarr-suse gavz tacitum jinjunmax petercon iosevka-mayukai medicalwei spiratype drj11 fwkg daocalendar jhruby mbrukman netap495l vsujeesh

afdko's Issues

Strikeout/Underline

I report a problem with strikeout and underline, noticed by Jens K. on robofont forum.
I have the same problem.

"I noticed that the values in RFont.info.openTypeOS2StrikeoutSize and RFont.info.openTypeOS2StrikeoutPosition are not written into a generated OTF. Instead, the openTypeOS2StrikeoutSize is always the same as the postscriptUnderlineThickness and the openTypeOS2StrikeoutPosition is set to the x-height * 0.6, it looks like some kind of FDK fallback is taking place there."

`makeotf` error

We are just starting to use FDK on Mac and Linux and seeing many problems with paths, Like this.. Any idea what Im doing wrong? or fix this
/Users/Pathum/bin/FDK/Tools/osx/makeotf: line 18: /Users/Pathum/bin/FDK/Tools/osx/Python/Current/bin/python: No such file or directory

cc @paarandika

Can't install FDK FontLab macros

Can't instal FDK FontLab macros MAC OSX, Yosemite 10.10.5, FontLab Studio 5.1.4. After sucessfull installation of FDK i can't instal macros. I have following messages. Can somebody HELP please. Thank you.

Licensing clarifications in headers

Can you please clarify that various cmaps are under 3-clause BSD and some FontLab macros are under MIT in LICENSE.txt at the root of the project?

Also, many files still have the following restricted license information in their headers:

"Patents Pending

NOTICE: All information contained herein is the property of Adobe
Systems Incorporated. Many of the intellectual and technical
concepts contained herein are proprietary to Adobe, are protected
as trade secrets, and are made available only to Adobe licensees
for their internal use. Any reproduction or dissemination of this
software is strictly forbidden unless prior written permission is
obtained from Adobe. "

which is probably not your intent, can they please be removed?

Thanks.

makeotf MarktoBase offset overflow

I have a font family of 5 weights, exported from FL with the AFDKO 'make instances' script.

When compiling the fonts, I've started getting a makeotf error that did not occur previously with the same typeface:

makeotfexe [FATAL] <Nassim-Semibold> MarkToBase lookup subtable in GPOS feature 'mark' causes offset overflow.

This applies to four out of five instances - the Regular compiles just fine. Could anybody point out where the issue might be coming from?

Thanks in advance,
titus

casing of Tools/SharedData/AGD.TXT filename extension

On Debian/Ubuntu, kernCheck and compareFamily are both looking for AGD.TXT instead of AGD.txt and failing.

Typo in GDEF table docs

In http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html#9.b there is a stray LigatureCaret which I think is a typo, and probably was meant to be the (not implemented) LigatureCaretByDev.

Mark-to-base positioning rule error

When running makeotf with a feature file containing a mark-to-base positioning rule, I always get the following error (or something like it):

makeotfexe [ERROR] <My-Font> MarkToBase or MarkToMark error 2: A previous statement has already assigned the current mark class to another anchor point on the same glyph 'A'. Skipping rule.  [features.fea 7]

A trivial example feature definition which causes this error:

languagesystem DFLT dflt; 

feature mark {

    lookup mark1 {
        markClass uni0300 <anchor 0 509> @mark_class;
        pos base A <anchor 280 678> mark @mark_class;                                          
    } mark1;

} mark;

This error does not occur with the pre-compiled FDK, just with the latest code from GitHub.

Option -4 doesn't work

$ checkOutlines -4 font.otf
focusOptionParseError: 'Option Error: Unknown option <-4>.'

[makeotfexe] Improve overflow error messages to help diagnose issues

Following #52, I suggest that table overflow error messages should warn users to check for 'upstream' overflows.

[otc2otf] Add option to specify output path of ttf/otfs being output

Considering subfonts in some ttcs may not contain a Postscript name in the name, otc2otf may rewrite files it already written. Therefore giving an option to specify output paths will be useful, pretty like

otc2otf input.ttc -o output-%.ttf
otc2otf input.ttc -o output1.ttf output2.ttf output3.ttf # valid when the quantity of subfonts in input.ttc is 3

[makeotfexe] hotconv featgram.c Xcode compiler: many errors from unnecessary parens in featgram.c

The -Wparentheses-equality warning is useful for more than just extra parens, and I'd like to keep it. Solved the problem by fixing the source code in featgram.c. A short -term solution: I replaced all occurrences of "(if|while) (\s+(LA(1)==([^)]+))\s*)" with " \1 (LA(1)==\2)". Short-term because this will have to be repeated every time someone regenerates the featgram.c file by running the ANTLR parser. Needs to eventually be fixed in the ANTLR parser itself.

subprocess.call

When embedding FDK inside RoboFont a subprocess.call works fine but the stdout and stderr got lost...

https://github.com/adobe-type-tools/afdko/blob/master/FDK/Tools/SharedData/FDKScripts/FDKUtils.py#L83

Had to change it to subprocess.Popen to retrieve stdout and stderr

popen = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
popenout, popenerr = popen.communicate()
if popenout:
    print popenout
if popenerr:
    print popenerr

(I cannot test this on all kinds of environments)

thanks

Packaging

There are a few packaging systems that I could see AFDKO being included in:

wheel for Python pypi
brew recipe (with python considerations) for Mac
nuget for Windows
deb for Ubuntu PPA and then Debian and Ubuntu
rpm for Fedora

I'm curious if the adobe-type-tools folks have any objections to any of the above, or if pull requests to include relevant files for these will be accepted? :)

The packages should include LICENSE for open source tools

I found that the ttx included in AFDKO is an opensource tool with MIT license, which requires distributor to include its license with any distribution.

ssXX descriptive names are restricted to ASCII

feature ss01 {
    featureNames {
        name "®";
    };
   [...]
} ss01;

yields:

makeotfexe [FATAL] <PSFont-Regular> invalid token (text was "�") [../family.fea 219]

@readroberts: Hopefully this is not by-design?

[question] Why does AFDKO need NAME table items with PID=1 for feature names?

NAME table items with PID=1 are no longer needed, since OS X accepts fonts without them and no sane person is using Mac OS 9 in 2015 :)

[makeotf] Non-deterministic output for GPOS type 2

With makeotf v2.0.90 Nov 19 2015, the following feature file:

languagesystem DFLT dflt;

feature kern {
    pos T one 100;
    pos T two 200;
    pos T two.oldstyle 200;
    pos T three <3 3 3 3>;
    pos T four 400;
} kern;

gives non-deterministic (and wrong) output for the kerning pair T four. Example ttx output:

  <GPOS>
    <Version value="1.0"/>
    <ScriptList>
      <!-- ScriptCount=1 -->
      <ScriptRecord index="0">
        <ScriptTag value="DFLT"/>
        <Script>
          <DefaultLangSys>
            <ReqFeatureIndex value="65535"/>
            <!-- FeatureCount=1 -->
            <FeatureIndex index="0" value="0"/>
          </DefaultLangSys>
          <!-- LangSysCount=0 -->
        </Script>
      </ScriptRecord>
    </ScriptList>
    <FeatureList>
      <!-- FeatureCount=1 -->
      <FeatureRecord index="0">
        <FeatureTag value="kern"/>
        <Feature>
          <!-- LookupCount=1 -->
          <LookupListIndex index="0" value="0"/>
        </Feature>
      </FeatureRecord>
    </FeatureList>
    <LookupList>
      <!-- LookupCount=1 -->
      <Lookup index="0">
        <!-- LookupType=2 -->
        <LookupFlag value="0"/>
        <!-- SubTableCount=2 -->
        <PairPos index="0" Format="1">
          <Coverage>
            <Glyph value="T"/>
          </Coverage>
          <ValueFormat1 value="4"/>
          <ValueFormat2 value="0"/>
          <!-- PairSetCount=1 -->
          <PairSet index="0">
            <!-- PairValueCount=3 -->
            <PairValueRecord index="0">
              <SecondGlyph value="one"/>
              <Value1 XAdvance="100"/>
            </PairValueRecord>
            <PairValueRecord index="1">
              <SecondGlyph value="two"/>
              <Value1 XAdvance="200"/>
            </PairValueRecord>
            <PairValueRecord index="2">
              <SecondGlyph value="two.oldstyle"/>
              <Value1 XAdvance="200"/>
            </PairValueRecord>
          </PairSet>
        </PairPos>
        <PairPos index="1" Format="1">
          <Coverage>
            <Glyph value="T"/>
          </Coverage>
          <ValueFormat1 value="15"/>
          <ValueFormat2 value="0"/>
          <!-- PairSetCount=1 -->
          <PairSet index="0">
            <!-- PairValueCount=2 -->
            <PairValueRecord index="0">
              <SecondGlyph value="three"/>
              <Value1 XPlacement="3" YPlacement="3" XAdvance="3" YAdvance="3"/>
            </PairValueRecord>
            <PairValueRecord index="1">
              <SecondGlyph value="four"/>
              <Value1 XPlacement="400" YPlacement="27071" XAdvance="15280" YAdvance="7843"/>
            </PairValueRecord>
          </PairSet>
        </PairPos>
      </Lookup>
    </LookupList>
  </GPOS>

Note the line <Value1 XPlacement="400" YPlacement="27071" XAdvance="15280" YAdvance="7843"/> towards the end. The values for YPlacement, XAdvance and YAdvance are not deterministic; here are a few outputs from running makeotf on the same input file:

<Value1 XPlacement="400" YPlacement="30032" XAdvance="514" YAdvance="30072"/>
<Value1 XPlacement="400" YPlacement="2384" XAdvance="642" YAdvance="2424"/>
<Value1 XPlacement="400" YPlacement="18256" XAdvance="385" YAdvance="18296"/>
<Value1 XPlacement="400" YPlacement="-18096" XAdvance="256" YAdvance="-18056"/>

setsnapl.pl -o results vary hugely

perl setsnap.pl -o -l36 -u128 -r72 < font.otf.hstm.txt
A hairline weight and the result is:
[16] 156 30

What is the secondary value (156) and tertiary value (30) for? Are they measuring the wrong direction, i.e. the counters?

dead code in cswrite.c (autohintlib/ac)

There is a lot code like this:

#if DEBUG
            sws("10 div");
#else
            sws("10 div");
            /* WRTNUM(10); OUT(ESC); OUT(DIV); */
#endif

Can someone explain the commented code? Can it be removed?

Versionned release zip files (and folder) with version major.minor.change

Please provide versionned release zip files with complete version major.minor.change on the AFDKO website:

Something like, for example, AFDKO-2.50-63782.zip which then expands into a folder called AFDKO-2.50-63782/ would help isolate different versions much better and also make installation easier.

Thanks.

tx fails to convert font.ttf to temp file on Windows (permission denied)

Hello,

Whenever I try to compile a TTF/OTF, tx returns a permission denied error on Windows.

makeotf [Note] Converting source font 'font.ttf' to temporary Unix Type1 font file 'font.ttf.tmp'.
makeotf [Error] Failed to convert input font 'font.ttf' to temp file 'font.ttf.tmp' with tx.
tx converting to T1 font: <tx: file error <Permission denied> [(t1w) tmpfile]
tx: fatal error

I can only compile the font if I run the command with admin rights.
I have raised the same issue on another forum, and @readroberts replied that it's an issue with the Windows implementation of "tmpfile".
Hopefully somebody can help fixing this.
Thank you for your support.

Cosimo

[spec] Remove the 31 chars in glyphnames restriction

See fontforge/fontforge#2500 (comment). Adobe themselves don’t go by this restriction.

Is `-m32` necessary?

Hi,

I tried to build afdko in 64-bit Linux machine, but due to -m32 flag, the ELF binary is for 32-bits. I wonder, is this flag -m32 necessary? Can I build an afdko for 64-bits system only?

question about glyph printing into PDF with transparency.

I want to publish a PDF with glyph comparison cells among several fonts. In it, each grid cell has compared glyphs, a glyph on top of another glyph(s).
is there a possible way to draw glyphs into PDF with transparency like below?

in this example, red colored glyph is on top of blue colored glyph.

In reportlab, it is possible to draw glyphs and fill its color with 'alpha=x.x' value like this.
colorValue = Color(0, 0, 100, alpha = 0.5)

But, in fontPDF module, I just found like this.

Color values are set as a triplet of (Red, Green, Blue) values between 0 (dark)
and 1.0 (light). Examples:
(1.0,0,0) is red
(1.0, 1.0, 1.0) is white

If I should add transparency, to which module should I do?

Thanks in advance

autohint AutoHinting program v1.46 Feb 10 2105

The subject says it all. This is the current latest download from the adobe site FDK

FDK. v2.5 March 3 2015 change number 63782 is in the FDKReleaseNotes.txt file. Which of those date is the correct one?

[Wish] FEA syntax extension: += and +{

I’d like to request two extensions of the FEA syntax (given of course this is also implemented in AFDKO):
#1. Defining a named class in fragments

Variant 1.1

When defining named classes, the syntax @classname += [glyph1 glyph2...] should be permitted, which would allow one to define a named class in multiple fragments. It should allow for the following constructs:

@LNUM += [one two three]; 
@LNUM += [four five six];

which would be equivalent to the current:

@LNUM = [one two three four five six];

(Optional: the implementation should allow using the += operator even if the class name is used for the first time — then it would simply behave as =.)

Variant 1.2

The same could be achieved in a less-invasive way (without changing the syntax) if the implementation in AFDKO is changed to allow the following:

@LNUM = [one two three];
@LNUM = [@LNUM four five six];

Currently, this method produces an error: can't define a glyph class in terms of itself.
#2. Defining any {} construct in fragments

Variant 2.1

When defining any construct that is enclosed in {} (feature, lookup, table, anonymous), the syntax feature smcp +{ definitions } smcp; should be permitted, which would allow one to define a construct in multiple fragments. The order of the constructs (lookups) should still by determined by the first occurrence of a construct with a particular name or tag. This should allow for the following constructs:

feature smcp { 
  sub a by a.sc;
  sub b by b.sc;
  ...
  sub z by z.sc; 
} smcp; 

feature liga { 
  sub f i by f_i; 
} liga; 

feature smcp +{ 
  sub ampersand by ampersand.sc;
} smcp;

This would be equivalent either to:

feature smcp { 
  lookup smcp1 { 
  sub a by a.sc;
  sub b by b.sc;
  ...
  sub z by z.sc; 
  } smcp1; 
 lookup smcp2 { 
  sub ampersand by ampersand.sc;
 } smcp2; 
} smcp; 

feature liga { 
  sub f i by f_i; 
} liga;

or preferably to:

feature smcp { 
  sub a by a.sc;
  sub b by b.sc;
  ...
  sub z by z.sc; 
  sub ampersand by ampersand.sc;
} smcp; 

feature liga { 
  sub f i by f_i; 
} liga;

(Whatever is more convenient / makes more sense from the implementation point of view.)

(Optional: the implementation should allow using +{ even if a construct’s name is used for the first time — then it would simply behave as {.)

Variant 2.2

The same could be achieved in a slightly less invasive way by adding a new keyword append which could precede any { character (similarly to how the useExtension keyword is used).

In this variant, the following syntax would be possible:

feature smcp { 
  sub a by a.sc;
  sub b by b.sc;
  ...
  sub z by z.sc; 
} smcp; 

feature liga { 
  sub f i by f_i; 
} liga; 

feature smcp append { 
  sub ampersand by ampersand.sc;
} smcp;

What do you think? Is this feasible? (I’m not sure whether the FEA parser works linearly or not.)

Adam

Can I safely remove the AFDKO CLI tools without breaking it?

When installing ADFKO for SourceCodePro I was disappointed that AFDKO took the liberty of editing my dot files on my behalf, if this is necessary I understand but if not I'd like to know how to remove them.

As well, is there a list of which dot files are updated with ADFKO calls for the CLI tools so I can revert them?

Thanks!

debug and release?

There is a ton of stuff (Makefiles) duplicated where the only difference is the word "debug" or "release" and a -g in CFLAGS. The shell wrapping (FOO/build/linux/gcc/BuildAll.sh) unconditionally builds both. Why? It's simple enough to just build with debug symbols, then strip them out if you don't want them.

[otf2otc] Support `glyf` table merging

Currently merging ttf files using otf2otc may produce a ttc file containing multiple glyf tables, however sometimes we need a ttc file with one single glyf containing all distinct glyphs (both outline and gridfit should be considered) in the source font, and multiple cmap, GSUB and GPOS tables.

Completion of error handling

I have looked at a few source files for your current software. I have noticed that some checks for return codes are missing.

Would you like to add more error handling for return values from functions like the following?

makeInstancesUFO fails to generate Source Sans Pro instances

When I run:

makeInstancesUFO -d ItalicMasters/SourceSansPro-Italic.designspace

I get the following error:

Reading design space file: SourceSansPro-Italic.designspace ...
adding SourceSansPro-ExtraLightIt to build list.
adding SourceSansPro-LightIt to build list.
adding SourceSansPro-It to build list.
adding SourceSansPro-SemiboldIt to build list.
adding SourceSansPro-BoldIt to build list.
adding SourceSansPro-BlackIt to build list.
Building 6 instances...
Built 6 instances.
Applying UFO normalization...
Applying post-processing...
    doing overlap removal with checkOutlinesUFO ../Italic/ExtraLightIt/font.ufo ...
Traceback (most recent call last):
  File "/afdko/FDK/Tools/linux/../SharedData/FDKScripts/CheckOutlinesUFO.py", line 967, in <module>
    run(sys.argv[1:])
  File "/afdko/FDK/Tools/linux/../SharedData/FDKScripts/CheckOutlinesUFO.py", line 908, in run
    newGlyph, glyphDigest, changed, msg = test(newGlyph, glyphDigest, changed, msg, options)
  File "/afdko/FDK/Tools/linux/../SharedData/FDKScripts/CheckOutlinesUFO.py", line 711, in doOverlapRemoval
    changed, msg = removeTinySubPaths(newGlyph, options.minArea, changed, msg) # Tiny subpaths are added by overlap removal.
  File "/afdko/FDK/Tools/linux/../SharedData/FDKScripts/CheckOutlinesUFO.py", line 485, in removeTinySubPaths
    cArea = (cBounds[2] - cBounds[0])*(cBounds[3] - cBounds[1])
TypeError: 'NoneType' object has no attribute '__getitem__'


Error in checkOutlinesUFO ../Italic/ExtraLightIt/font.ufo
Quitting after error.

cvXX featureNames yields corrupt binary code

I tried to add featureNames to my cvXX features in the same way it is done with ssXX, here is a sample code:

feature cv01 {
    featureNames {
        name "Superscript \00AE"; # Windows English
        name 1 0 0 "Superscript \A8"; # Mac English
        name 3 1 0x040c "\00AE \00E0 l\2019exposant"; # Windows French
        name 1 0 1 "\A8 \88 l\D5exposant"; # Mac French
    };
    [...]
}

The AFDKO gives no warning or error whatsoever yet ttx decompilation errors:

           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/__init__.py", line 391, in __getitem__
             table.decompile(data, self)
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otBase.py", line 44, in decompile
             self.table.decompile(reader, font)
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otBase.py", line 568, in decompile
             table[conv.name] = conv.read(reader, font, table)
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otConverters.py", line 245, in read
             table.decompile(reader, font)
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otBase.py", line 563, in decompile
             l.append(conv.read(reader, font, table))
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otConverters.py", line 182, in read
             table.decompile(reader, font)
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otBase.py", line 568, in decompile
             table[conv.name] = conv.read(reader, font, table)
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otConverters.py", line 245, in read
             table.decompile(reader, font)
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otBase.py", line 568, in decompile
             table[conv.name] = conv.read(reader, font, table)
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otConverters.py", line 245, in read
             table.decompile(reader, font)
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otBase.py", line 563, in decompile
             l.append(conv.read(reader, font, table))
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otConverters.py", line 141, in read
             return reader.readUInt24()
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otBase.py", line 162, in readUInt24
             value, = struct.unpack("&gt;l", b'\0'+self.data[pos:newpos])
         error: unpack requires a string argument of length 4

I may or may not be using wrong syntax or whatnot (I did not find relevant documentation on Adobe's website) but in any case, I don't think that the compiler should pull off what seems to be an alignment error in the generated code.

cc @TiroTypeworks

Remove unnecessary null pointer checks

An extra null pointer check is not needed in functions like the following.

Would you like to add the following semantic patch approach to a test directory?

@Remove_unnecessary_pointer_checks1@
expression x;
@@
-if (\(x != 0 \| x != NULL\))
    free(x);

@Remove_unnecessary_pointer_checks2@
expression x;
@@
-if (\(x != 0 \| x != NULL\)) {
    free(x);
    x = \(0 \| NULL\);
-}

@Remove_unnecessary_pointer_checks3@
expression a, b;
@@
-if (\(a != 0 \| a != NULL\) && \(b != 0 \| b != NULL\))
+if (a)
    free(b);

@Remove_unnecessary_pointer_checks4@
expression a, b;
@@
-if (\(a != 0 \| a != NULL\) && \(b != 0 \| b != NULL\)) {
+if (a) {
    free(b);
    b = \(0 \| NULL\);
 }

How do you think about to apply a corresponding update suggestion which can be generated by the software "Coccinelle"?

cvxx FeatureParams history

Is there a reason that OpenTypeFeatureFileSpecification.html says:

8.d. UI Label names for Character Variant 'cv01 - cv99') features
As of the OpenType specification 1.7, UI label names are allowed for Character Variant features.

when in fact the UI labels were present when cvxx was introduced in version 1.6 of the specification?

ttxn error

Traceback (most recent call last):
  File "/usr/local/bin/FDK/Tools/osx/../SharedData/FDKScripts/ttxn.py", line 2308, in <module>
    run(sys.argv[1:])
  File "/usr/local/bin/FDK/Tools/osx/../SharedData/FDKScripts/ttxn.py", line 2300, in run
    ttf = ttnDump(input, output, options, showExtensionFlag, supressHints, supressVersions, supressTTFDiffs)
  File "/usr/local/bin/FDK/Tools/osx/../SharedData/FDKScripts/ttxn.py", line 2211, in ttnDump
    disassembleInstructions=options.disassembleInstructions)
  File "/usr/local/bin/FDK/Tools/osx/Python/Current/lib/python2.7/site-packages/FontTools/fontTools/ttLib/__init__.py", line 281, in saveXML
    self._tableToXML(tableWriter, tag, progress, quiet)
  File "/usr/local/bin/FDK/Tools/osx/../SharedData/FDKScripts/ttxn.py", line 1983, in _tableToXML
    dumpOTLAsFeatureFile(tag, ttxnWriter, self)
  File "/usr/local/bin/FDK/Tools/osx/../SharedData/FDKScripts/ttxn.py", line 1916, in dumpOTLAsFeatureFile
    otlConverter.otlFeatureFormat(writer)
  File "/usr/local/bin/FDK/Tools/osx/../SharedData/FDKScripts/ttxn.py", line 1537, in otlFeatureFormat
    self.buildClasses()
  File "/usr/local/bin/FDK/Tools/osx/../SharedData/FDKScripts/ttxn.py", line 1626, in buildClasses
    handler = self.classHandlers.get( (lookup.LookupType, subtable.Format), None)
  File "/usr/local/bin/FDK/Tools/osx/Python/Current/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otBase.py", line 531, in __getattr__
    raise AttributeError(attr)
AttributeError: Format

roundf is not included in math.h for Visual Studio 2010

although part of C99 standard, the roundf function was only included in MS Visual Studio only from version 2013:
http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-library-support-in-visual-studio-2013.aspx

When I try to build the AFKDO using Visual Studio 2010, I get the following error:

"C:\UsersLocal\cosimo.lupo\Documents\GitHub\afdko\FDK\Tools\Programs\tx\build\win\vc10\tx.sln" (Build target) (1) -> "C:\UsersLocal\cosimo.lupo\Documents\GitHub\afdko\FDK\Tools\Programs\tx\build\win\vc10\tx.vcxproj" (default target)
(2) ->
(Link target) ->
  absfont.lib(absfont_dump.obj) : error LNK2019: unresolved external symbol _roundf referenced in function _writeRea l [C:\UsersLocal\cosimo.lupo\Documents\GitHub\afdko\FDK\Tools\Programs\tx\build\win\vc10\tx.vcxproj]
  svgwrite.lib(svgwrite.obj) : error LNK2001: unresolved external symbol _roundf [C:\UsersLocal\cosimo.lupo\Document s\GitHub\afdko\FDK\Tools\Programs\tx\build\win\vc10\tx.vcxproj]
  ufowrite.lib(ufowrite.obj) : error LNK2001: unresolved external symbol _roundf [C:\UsersLocal\cosimo.lupo\Document s\GitHub\afdko\FDK\Tools\Programs\tx\build\win\vc10\tx.vcxproj]
  ..\..\..\exe\win\release\tx.exe : fatal error LNK1120: 1 unresolved externals [C:\UsersLocal\cosimo.lupo\Documents \GitHub\afdko\FDK\Tools\Programs\tx\build\win\vc10\tx.vcxproj]

There are three modules where the roundf is used, all in the lib: absfont_dump.c, svgwrite.c and ufowrite.c. Because of the unresolved external symbol, the tools tx, mergeFonts and rotateFont cannot be successfully built on Windows using vc10.
The *.sln files version read "Visual Studio 2010", and also the name of the folders for the Windows build is "vc10" (i.e. MS Visual Studio 2010). So one would expect to compile the AFDKO code with Visual Studio 2010.

If I define the roundf function like below, then I can successfully compile everything:

/* roundf was only included in math.h as of MS Visual Studio 2013, so we must define our own. */
#if _MSC_VER < 1800
static float roundf(float num)
{
    float integer = ceilf(num);
    if (num > 0)
        return integer - num > 0.5f ? integer - 1.0f : integer;
    return integer - num >= 0.5f ? integer - 1.0f : integer;
}
#endif

(I found the code for roundf here, but there's nothing special about it).

However, the organization of the AFDKO sources is very complex and I don't know where to place this function so that I can include it in all the required modules.

Could anybody help me out?

The file featgram.g is mising from HOT sources

It seems that several source files under FDK/Tools/Programs/makeotf/makeotf_lib/source/hotconv are generated from a featgram.g ANTLR grammar file but that file is missing. Was this intentional (meaning that one should modify the generated file) or just an oversight.

Question about com.adobe.type.autohint in UFO

Adobe's storage format for PS hints in the GLIF lib is as follows:

<lib>
 <dict>
 <key>com.adobe.type.autohint</key>
 <data>
 <hintSetList>
   <hintset pointTag="ab02">
     <hstem pos="-14" width="211" />
     <hstem pos="455" width="180" />
     <hstem pos="856" width="211" />
     <vstem pos="74" width="336" />
     <vstem pos="819" width="336" />
   </hintset>
   <hintset pointTag="hr02">
     <hstem pos="21" width="-21" />
     <hstem pos="455" width="180" />
     <hstem pos="739" width="328" />
     <vstem pos="74" width="336" />
     <vstem pos="850" width="305" />
   </hintset>
 </hintSetList>
 </data>
 </dict>
 </lib>

but in light of the discussion on the ufo-spec list ( https://groups.google.com/d/topic/ufo-spec/yZ8CrPWoAI4/discussion ), the contents of the element inside the lib must be base64-encoded, so the above code should look like this:

<lib>
 <dict>
 <key>com.adobe.type.autohint</key>
 <data>
 ICA8aGludFNldExpc3Q+CiAgICA8aGludHNldCBwb2ludFRhZz0iYWIwMi
 I+CiAgICAgIDxoc3RlbSBwb3M9Ii0xNCIgd2lkdGg9IjIxMSIgLz4KICAg
 ICAgPGhzdGVtIHBvcz0iNDU1IiB3aWR0aD0iMTgwIiAvPgogICAgICA8aH
 N0ZW0gcG9zPSI4NTYiIHdpZHRoPSIyMTEiIC8+CiAgICAgIDx2c3RlbSBw
 b3M9Ijc0IiB3aWR0aD0iMzM2IiAvPgogICAgICA8dnN0ZW0gcG9zPSI4MT
 kiIHdpZHRoPSIzMzYiIC8+CiAgICA8L2hpbnRzZXQ+CiAgICA8aGludHNl
 dCBwb2ludFRhZz0iaHIwMiI+CiAgICAgIDxoc3RlbSBwb3M9IjIxIiB3aW
 R0aD0iLTIxIiAvPgogICAgICA8aHN0ZW0gcG9zPSI0NTUiIHdpZHRoPSIx
 ODAiIC8+CiAgICAgIDxoc3RlbSBwb3M9IjczOSIgd2lkdGg9IjMyOCIgLz
 4KICAgICAgPHZzdGVtIHBvcz0iNzQiIHdpZHRoPSIzMzYiIC8+CiAgICAg
 IDx2c3RlbSBwb3M9Ijg1MCIgd2lkdGg9IjMwNSIgLz4KICAgIDwvaGludH
 NldD4KICA8L2hpbnRTZXRMaXN0Pgo=
 </data>
 </dict>
 </lib>

At FontLab, we have a similar problem, so at this point we've introduced a switch when writing UFO, to either write it in the invalid, human-readable form (1st example) or in the valid, base64-encoded form (2nd example).

Do you know if AFDKO is "ready" to support (read) the base64-encoded variant? Also, are there plans to switch to the valid form when writing it?

Thanks,
Adam

Need help on proper uses of Makeotf in Lohit project

This is not an issue with makeotf. But i am facing this while using it with Lohit project. Basically i am loosing font encoding after building font.

Following steps i am following:

git clone https://github.com/pravins/lohit.git
cd lohit/odia/
../generate.pe Lohit-Odia.sfd (This will generate Lohit-Odia.ttf)
makeotf -f Lohit-Odia.ttf -ff Lohit-Odia.fea (It gives me following errors.)

makeotf [Note] Converting source font 'Lohit-Odia.ttf' to temporary Unix Type1 font file 'Lohit-Odia.ttf.tmp'.
makeotf [Note] Writing options file ./current.fpr
makeotf [Note] Running makeotfexe with commands:
   cd "/NotBackedUp/git/github/lohit/odia"
   makeotfexe "-f" "Lohit-Odia.ttf.tmp" "-o" "Lohit-Odia.ttf.temp_cff" -ff "Lohit-Odia.fea" -ga -gf "Lohit-Odia.ttf.temp.GOADB" -mf "FontMenuNameDB" -shw
makeotfexe [FATAL] Glyph renaming is requested, but the Glyph Alias And Order DB file was not specified.
makeotf [Error] Failed to build output font file 'Lohit-Odia.ttf.temp_cff'.

Then i modify makeotfexe command.
5. makeotfexe "-f" "Lohit-Odia.ttf.tmp" "-o" "Lohit.ttf." -ff "Lohit-Odia.fea" -nga -mf "FontMenuNameDB" -shw

But problem is output Lohit.ttf does not have proper encoding.

Also how can i convert TTF to Type1 using makeotf presently is does conversion auto. Did not found any command for same.

makeotf_lib hotconv/name.c lost one brace?

Something must have been lost here by accident:

diff --git a/FDK/Tools/Programs/makeotf/makeotf_lib/source/hotconv/name.c b/FDK/Tools/Programs/makeotf/makeotf_lib/source/hotconv/name.c
index e0eff27..e26418f 100644
--- a/FDK/Tools/Programs/makeotf/makeotf_lib/source/hotconv/name.c
+++ b/FDK/Tools/Programs/makeotf/makeotf_lib/source/hotconv/name.c
@@ -452,7 +452,7 @@ static char* translate2MacDflt(nameCtx h, char *src)
        *dst = 0;
        return begin;
        }
-
+}


 /* Add menu names and standard names. */

As one might guess it gives terrible compiler errors below this point.

Malformed example in spec

In the OpenType Feature File Specification, example 1 of section 6.h.ii. “Specifying Contextual Positioning with explicit lookup references” seems syntactically malformed:

lookup CNTXT_PAIR_POS {
     position T o -10;
     position T c by -12;
} CNTXT_PAIR_POS;

lookup CNTXT_MARK_TO_BASE {
     position base o 
     position base c 
} CNTXT_MARK_TO_BASE;

feature test {
     substitute T' lookup CNTXT_PAIR_POS [o c]' @ALL_MARKS' lookup CNTXT_MARK_TO_BASE;
} test;

Would it be possible to fix the specification, so that the example is syntactically correct?

[makeotf] BaseAnchors for missing mark/base pairs in GPOS type 4 should be empty

In the following feature file for GPOS type 4, not every mark is attached to every base. For the missing pairs, makeotf v2.0.90 (Nov 19 2015) produces an anchor with x=0 and y=0. Instead, shouldn’t it produce empty anchors? Empty anchors would need less space, and they are also semantically different: instead of attaching at origin, the OpenType layout engine will continue trying with the next subtable.

Contrived feature file for testing:

languagesystem DFLT dflt;

markClass [acute grave] <anchor 111 -11> @TOP_MARKS;
markClass macron <anchor 112 -12> @TOP_MARKS;
markClass [cedilla] <anchor 222 22> @BOTTOM_MARKS;
markClass [ogonek] <anchor 333 33> @SIDE_MARKS;

feature test {
    position base a
        <anchor 11 1> mark @TOP_MARKS
        <anchor 12 -1> mark @BOTTOM_MARKS;

    position base [b c]
        <anchor 22 -2> mark @BOTTOM_MARKS;

    position base d
        <anchor 33 3> mark @SIDE_MARKS;
} test;

Output from makeotf for the above feature file; please note the various BaseAnchor elements with XCoordinate=0 and YCoordinate=0:

  <GPOS>
    <Version value="1.0"/>
    <ScriptList>
      <!-- ScriptCount=1 -->
      <ScriptRecord index="0">
        <ScriptTag value="DFLT"/>
        <Script>
          <DefaultLangSys>
            <ReqFeatureIndex value="65535"/>
            <!-- FeatureCount=1 -->
            <FeatureIndex index="0" value="0"/>
          </DefaultLangSys>
          <!-- LangSysCount=0 -->
        </Script>
      </ScriptRecord>
    </ScriptList>
    <FeatureList>
      <!-- FeatureCount=1 -->
      <FeatureRecord index="0">
        <FeatureTag value="test"/>
        <Feature>
          <!-- LookupCount=1 -->
          <LookupListIndex index="0" value="0"/>
        </Feature>
      </FeatureRecord>
    </FeatureList>
    <LookupList>
      <!-- LookupCount=1 -->
      <Lookup index="0">
        <!-- LookupType=4 -->
        <LookupFlag value="0"/>
        <!-- SubTableCount=1 -->
        <MarkBasePos index="0" Format="1">
          <MarkCoverage>
            <Glyph value="grave"/>
            <Glyph value="acute"/>
            <Glyph value="macron"/>
            <Glyph value="cedilla"/>
            <Glyph value="ogonek"/>
          </MarkCoverage>
          <BaseCoverage>
            <Glyph value="a"/>
            <Glyph value="b"/>
            <Glyph value="c"/>
            <Glyph value="d"/>
          </BaseCoverage>
          <!-- ClassCount=3 -->
          <MarkArray>
            <!-- MarkCount=5 -->
            <MarkRecord index="0">
              <Class value="0"/>
              <MarkAnchor Format="1">
                <XCoordinate value="111"/>
                <YCoordinate value="-11"/>
              </MarkAnchor>
            </MarkRecord>
            <MarkRecord index="1">
              <Class value="0"/>
              <MarkAnchor Format="1">
                <XCoordinate value="111"/>
                <YCoordinate value="-11"/>
              </MarkAnchor>
            </MarkRecord>
            <MarkRecord index="2">
              <Class value="0"/>
              <MarkAnchor Format="1">
                <XCoordinate value="112"/>
                <YCoordinate value="-12"/>
              </MarkAnchor>
            </MarkRecord>
            <MarkRecord index="3">
              <Class value="1"/>
              <MarkAnchor Format="1">
                <XCoordinate value="222"/>
                <YCoordinate value="22"/>
              </MarkAnchor>
            </MarkRecord>
            <MarkRecord index="4">
              <Class value="2"/>
              <MarkAnchor Format="1">
                <XCoordinate value="333"/>
                <YCoordinate value="33"/>
              </MarkAnchor>
            </MarkRecord>
          </MarkArray>
          <BaseArray>
            <!-- BaseCount=4 -->
            <BaseRecord index="0">
              <BaseAnchor index="0" Format="1">
                <XCoordinate value="11"/>
                <YCoordinate value="1"/>
              </BaseAnchor>
              <BaseAnchor index="1" Format="1">
                <XCoordinate value="12"/>
                <YCoordinate value="-1"/>
              </BaseAnchor>
              <BaseAnchor index="2" Format="1">
                <XCoordinate value="0"/>
                <YCoordinate value="0"/>
              </BaseAnchor>
            </BaseRecord>
            <BaseRecord index="1">
              <BaseAnchor index="0" Format="1">
                <XCoordinate value="0"/>
                <YCoordinate value="0"/>
              </BaseAnchor>
              <BaseAnchor index="1" Format="1">
                <XCoordinate value="22"/>
                <YCoordinate value="-2"/>
              </BaseAnchor>
              <BaseAnchor index="2" Format="1">
                <XCoordinate value="0"/>
                <YCoordinate value="0"/>
              </BaseAnchor>
            </BaseRecord>
            <BaseRecord index="2">
              <BaseAnchor index="0" Format="1">
                <XCoordinate value="0"/>
                <YCoordinate value="0"/>
              </BaseAnchor>
              <BaseAnchor index="1" Format="1">
                <XCoordinate value="22"/>
                <YCoordinate value="-2"/>
              </BaseAnchor>
              <BaseAnchor index="2" Format="1">
                <XCoordinate value="0"/>
                <YCoordinate value="0"/>
              </BaseAnchor>
            </BaseRecord>
            <BaseRecord index="3">
              <BaseAnchor index="0" Format="1">
                <XCoordinate value="0"/>
                <YCoordinate value="0"/>
              </BaseAnchor>
              <BaseAnchor index="1" Format="1">
                <XCoordinate value="0"/>
                <YCoordinate value="0"/>
              </BaseAnchor>
              <BaseAnchor index="2" Format="1">
                <XCoordinate value="33"/>
                <YCoordinate value="3"/>
              </BaseAnchor>
            </BaseRecord>
          </BaseArray>
        </MarkBasePos>
      </Lookup>
    </LookupList>
  </GPOS>

Expected output — note the empty="1" in BaseAnchors for missing mark/base pairs:

  <GPOS>
    <Version value="1.0"/>
    <ScriptList>
      <!-- ScriptCount=1 -->
      <ScriptRecord index="0">
        <ScriptTag value="DFLT"/>
        <Script>
          <DefaultLangSys>
            <ReqFeatureIndex value="65535"/>
            <!-- FeatureCount=1 -->
            <FeatureIndex index="0" value="0"/>
          </DefaultLangSys>
          <!-- LangSysCount=0 -->
        </Script>
      </ScriptRecord>
    </ScriptList>
    <FeatureList>
      <!-- FeatureCount=1 -->
      <FeatureRecord index="0">
        <FeatureTag value="test"/>
        <Feature>
          <!-- LookupCount=1 -->
          <LookupListIndex index="0" value="0"/>
        </Feature>
      </FeatureRecord>
    </FeatureList>
    <LookupList>
      <!-- LookupCount=1 -->
      <Lookup index="0">
        <!-- LookupType=4 -->
        <LookupFlag value="0"/>
        <!-- SubTableCount=1 -->
        <MarkBasePos index="0" Format="1">
          <MarkCoverage>
            <Glyph value="grave"/>
            <Glyph value="acute"/>
            <Glyph value="macron"/>
            <Glyph value="cedilla"/>
            <Glyph value="ogonek"/>
          </MarkCoverage>
          <BaseCoverage>
            <Glyph value="a"/>
            <Glyph value="b"/>
            <Glyph value="c"/>
            <Glyph value="d"/>
          </BaseCoverage>
          <!-- ClassCount=3 -->
          <MarkArray>
            <!-- MarkCount=5 -->
            <MarkRecord index="0">
              <Class value="0"/>
              <MarkAnchor Format="1">
                <XCoordinate value="111"/>
                <YCoordinate value="-11"/>
              </MarkAnchor>
            </MarkRecord>
            <MarkRecord index="1">
              <Class value="0"/>
              <MarkAnchor Format="1">
                <XCoordinate value="111"/>
                <YCoordinate value="-11"/>
              </MarkAnchor>
            </MarkRecord>
            <MarkRecord index="2">
              <Class value="0"/>
              <MarkAnchor Format="1">
                <XCoordinate value="112"/>
                <YCoordinate value="-12"/>
              </MarkAnchor>
            </MarkRecord>
            <MarkRecord index="3">
              <Class value="1"/>
              <MarkAnchor Format="1">
                <XCoordinate value="222"/>
                <YCoordinate value="22"/>
              </MarkAnchor>
            </MarkRecord>
            <MarkRecord index="4">
              <Class value="2"/>
              <MarkAnchor Format="1">
                <XCoordinate value="333"/>
                <YCoordinate value="33"/>
              </MarkAnchor>
            </MarkRecord>
          </MarkArray>
          <BaseArray>
            <!-- BaseCount=4 -->
            <BaseRecord index="0">
              <BaseAnchor index="0" Format="1">
                <XCoordinate value="11"/>
                <YCoordinate value="1"/>
              </BaseAnchor>
              <BaseAnchor index="1" Format="1">
                <XCoordinate value="12"/>
                <YCoordinate value="-1"/>
              </BaseAnchor>
              <BaseAnchor index="2" empty="1"/>
            </BaseRecord>
            <BaseRecord index="1">
              <BaseAnchor index="0" empty="1"/>
              <BaseAnchor index="1" Format="1">
                <XCoordinate value="22"/>
                <YCoordinate value="-2"/>
              </BaseAnchor>
              <BaseAnchor index="2" empty="1"/>
            </BaseRecord>
            <BaseRecord index="2">
              <BaseAnchor index="0" empty="1"/>
              <BaseAnchor index="1" Format="1">
                <XCoordinate value="22"/>
                <YCoordinate value="-2"/>
              </BaseAnchor>
              <BaseAnchor index="2" empty="1"/>
            </BaseRecord>
            <BaseRecord index="3">
              <BaseAnchor index="0" empty="1"/>
              <BaseAnchor index="1" empty="1"/>
              <BaseAnchor index="2" Format="1">
                <XCoordinate value="33"/>
                <YCoordinate value="3"/>
              </BaseAnchor>
            </BaseRecord>
          </BaseArray>
        </MarkBasePos>
      </Lookup>
    </LookupList>
  </GPOS>

hardcoded architecture

The flag -m32 is littered throughout the build configuration.

~/bin/afdko/FDK/Tools/Programs]$ find -type f -exec grep m32 {} +
./public/lib/config/linux/gcc/gcc.mak: XFLAGS = -m32
./public/lib/config/linux/gcc/gcc_tx.mak: XFLAGS = -m32
./spot/build/linux/gcc/debug/Makefile:CFLAGS = $(STD_OPTS) -m32 -g -I$(ROOT_DIR)/sfnt_includes -I$(SRC_DIR) -DEXECUTABLE=1 -g
./spot/build/linux/gcc/release/Makefile:CFLAGS = $(STD_OPTS) -m32 -g -I$(ROOT_DIR)/sfnt_includes -I$(SRC_DIR) -DEXECUTABLE=1
./sfntedit/build/linux/gcc/debug/Makefile:CFLAGS = $(STD_OPTS) -m32  -g -I$(ROOT_DIR)/../spot/sfnt_includes
./sfntedit/build/linux/gcc/release/Makefile:CFLAGS = $(STD_OPTS) -m32 -I$(ROOT_DIR)/../spot/sfnt_includes
./sfntdiff/build/linux/gcc/debug/Makefile:CFLAGS = $(STD_OPTS) -m32 -g -I$(ROOT_DIR)/../spot/sfnt_includes
./sfntdiff/build/linux/gcc/release/Makefile:CFLAGS = $(STD_OPTS) -m32 -I$(ROOT_DIR)/../spot/sfnt_includes

Is there any reason for this? If you're fine with removing it, I'd be happy to make a pull request.

tx produced incorrectly-positioned pdf on several specific characters (perhaps with nested TTF references), like 'ᾬ'

I am using tx to generate a PDF for Iosevka r0.1.16-p1:

tx -pdf iosevka-regular.ttf iosevka-regular.pdf

However I found some of the characters are incorrect, for example, /uni1FAC and /uni1FD3. I think it is related to nested TTF references.

PDF link: http://pan.baidu.com/s/1kTER5jD

tx version:

be5in ω Z:\iosevka\releases λ tx -v
Versions:
    tx        1.0.61
    absfont   1.0.47
    ctutil    2.0.1
    dynarr    2.0.3
    sfntread  1.0.5
    t2cstr    1.0.16
    cffread   2.0.46
    cffwrite  1.0.40
    sfntwrite 1.0.6
    pstoken   2.0.9
    t1cstr    1.0.15
    t1read    1.0.40
    ttread    1.0.20
    cfembed   2.0.25
    pdfwrite  1.0.5
    svread    1.0.6
    t1write   1.0.31
    svwrite   1.1.9
    uforead   1.0.8
    ufwrite   1.0.1

The online version of the specification is outdated

The web page http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html is “last updated 4 Sept 2012”, but there have been at least two fixes to the specification since then but not reflected there.

Are issues and pull requests useful/welcome?

I can't easily tell from the documentation where to submit fixes for this code, or indeed whether this repository is even usefully canonical: the file AFDKO-Overview.html talks about "this release of the Adobe Font Development Kit", which suggests that what is on github is just a one-off version, not something to be maintained.

Similarly, there are some deficiencies in the documentation (first section of Read Me First doesn't mention Linux, causing confusion) and installation procedure (tries to symlink to ~/bin, a directory that I, for one, don't have) it would be nice to correct, but only if the corrections will improve the AFDKO long-term.

Read_Me_First says: "Adobe has set up a web site where the new versions can be downloaded. The FDK download web site is at the AFDKO Download site", which is discouraging, as that doesn't help me track versions or issues. The file doesn't even mention Github, hence my caution.

So, in sum, is Github just a release platform here, or can I actually use it the way I would with any normal software project?

makeotf wont make TTFs if path to working directory has spaces

Mark Simonson mentioned a bug in makeotf on the robofab list about how it wont make TTFs if path to working directory has spaces

makeotf: Within a ‘vkrn’ feature, value record format A should set YAdvance

The OpenType Feature File Specification says in section 2.e.iv about Value Record Format A: “Here the ‹metric› represents an X advance adjustment, except when used in the ‘vkrn’ feature, in which case it represents a Y advance adjustment.”

However, with makeotf v2.0.90 of Nov 19 2015, the following feature file:

languagesystem DFLT dflt;
feature vkrn {
    position A -100;
} vkrn;

produces the following GPOS table when dumped with ttx:

<?xml version="1.0" encoding="UTF-8"?>
<ttFont sfntVersion="true" ttLibVersion="3.0">

  <GPOS>
    <Version value="1.0"/>
    <ScriptList>
      <!-- ScriptCount=1 -->
      <ScriptRecord index="0">
        <ScriptTag value="DFLT"/>
        <Script>
          <DefaultLangSys>
            <ReqFeatureIndex value="65535"/>
            <!-- FeatureCount=1 -->
            <FeatureIndex index="0" value="0"/>
          </DefaultLangSys>
          <!-- LangSysCount=0 -->
        </Script>
      </ScriptRecord>
    </ScriptList>
    <FeatureList>
      <!-- FeatureCount=1 -->
      <FeatureRecord index="0">
        <FeatureTag value="vkrn"/>
        <Feature>
          <!-- LookupCount=1 -->
          <LookupListIndex index="0" value="0"/>
        </Feature>
      </FeatureRecord>
    </FeatureList>
    <LookupList>
      <!-- LookupCount=1 -->
      <Lookup index="0">
        <!-- LookupType=1 -->
        <LookupFlag value="0"/>
        <!-- SubTableCount=1 -->
        <SinglePos index="0" Format="1">
          <Coverage>
            <Glyph value="A"/>
          </Coverage>
          <ValueFormat value="4"/>
          <Value XAdvance="-100"/>
        </SinglePos>
      </Lookup>
    </LookupList>
  </GPOS>

</ttFont>

Instead of <Value XAdvance="-100"/>, shouldn’t this be <Value YAdvance="-100"/> since the value record format A appears inside a vkrn feature?

Build notes refer to booleanOperations fork that does not exist

The FDK Build Notes.txt file, in its instructions for setting up the Python environment, states:

3.3 BooleanOperations support
This is needed for the checkOutlinesUFO command.

booleanOperations-master: master branch of booleanOperations at:
https://github.com/typesupply/booleanOperations/tree/ufo3/.

This repository does not appear to exist. The original repo at https://github.com/typemytype/booleanOperations still exists, but it does not have a ufo3 branch.