adobe-type-tools / afdko Goto Github PK
View Code? Open in Web Editor NEWAdobe Font Development Kit for OpenType
Home Page: https://adobe-type-tools.github.io/afdko/
License: Other
Adobe Font Development Kit for OpenType
Home Page: https://adobe-type-tools.github.io/afdko/
License: Other
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.
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>
$ checkOutlines -4 font.otf
focusOptionParseError: 'Option Error: Unknown option <-4>.'
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.
On Debian/Ubuntu, kernCheck and compareFamily are both looking for AGD.TXT instead of AGD.txt and failing.
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.
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.
Mark Simonson mentioned a bug in makeotf on the robofab list about how it wont make TTFs if path to working directory has spaces
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
.
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?
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
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
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 =
.)
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
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 {
.)
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
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.
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.
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."
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.
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?
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.
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?
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
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.
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 :)
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?
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?
N.
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?
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.
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"/>
When embedding FDK inside RoboFont a subprocess.call
works fine but the stdout and stderr got lost...
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
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?
There are a few packaging systems that I could see AFDKO being included in:
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? :)
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?
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
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"?
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
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!
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(">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.
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:
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.
Following #52, I suggest that table overflow error messages should warn users to check for 'upstream' overflows.
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?
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?
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
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.
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.
See fontforge/fontforge#2500 (comment). Adobe themselves don’t go by this restriction.
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
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.
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
feature ss01 {
featureNames {
name "®";
};
[...]
} ss01;
yields:
makeotfexe [FATAL] <PSFont-Regular> invalid token (text was "�") [../family.fea 219]
@readroberts: Hopefully this is not by-design?
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.