Overall, it runs and I'm able to compile the projects from 1.6.

I like to know how to set up usWinAscent and usWinDescent.

table OS/2 {
TypoAscender 765;
TypoDescender -235;
TypoLineGap 250;
usWinAscent 900;
usWinDescent -350;
} OS/2;

This is not working, why?

1. the mystery of -nr

If I use a project file I got lots of the time: [FATAL] unrecognized option (-nr).
Now I found out it its related to the option:
ReleaseMode true
But if you set it to false, the -nr fatal error comes up. So better use
#ReleaseMode true (vs) ReleaseMode false

2. relative paths under windows only by using -fp option with *.fpr file.

3. This message seems to be a general one since it comes everytime. Can we turn it off since its not specific to the font?

makeotfexe.exe [NOTE] There are -12851 instances of the deprecated “except” syntax in the feature file. Though such statements are processed correctly by this parser for backward compatibility, please update them to the newer “i gnore substitute” syntax. For example, change “except a @LET sub a by a.end;” to “ignore sub a @LET; sub a’ by a.end;”. (Note that the second rule is now required to be marked to identify it as a Chain Contextual and not a Single Substituti
on rule.)

So far I tested the makeotf programm only.

The FontLab scripts installer seems not to work under python 2.2 win xp.

line 134 and 105
NameError: global name '__file__' is not defined

So I tryed to move the files manually. No script is running. Maybe this is related no path was added to the python site packages by the installer. So what path should we set manually?

Example, the Auto-Hint script

Traceback (most recent call last):
File "", line 70, in ?
ImportError: No module named string

win xp sp2, FL5, Python 2.2

--astype.de--

Bravo Miguel. I look forward to giving it a spin.

ChrisL

> [...]
> usWinAscent 900;
> usWinDescent -350;
> ) OS/2;

The Feature File Syntax says:
winAscent
winDescent

and makeotf says:
syntax error at "WinAscent" missing "}"

ok fixed, since "WinAscent" is not the same like "winAscent" :-)

I miss to give the makeotf the path and name of the fontinfo file. Is it no longer needed?

BTW. Its not commen this file is called "fontinfo" everytime and placed in the path of yourfont.pfa. For example I call it _fontinfo.txt. Other developers place it under other paths call it with an other name. So if the new FDK is looking "hard coded" for "fontinfo" it can't find it.

My first impression is, in points of usability, this fdk has some serious back steps compared to 1.6. Its bound the developers special workflow. :-(

--astype.de--

i experienced the same problems with the scripts as andreas described; any solutions yet?
t.

Karsten is right. The correct parameter names are winAscent and winDescent, which are case-sensitive. For a complete list of the parameters that can be specified by the FDK, in regards to the OS/2 table, please refer to the file 'OT Feature File Syntax.html', section 9.f. OS/2 table.

As for the file fontinfo, please refer to the documentation file 'MakeOTFUserGuide.pdf', page 9.

i updated my python installation and now the install macros scripts works; nevertheless, most of the scripts don't.
for example 'autohint' gives me:

Traceback (most recent call last):
File "", line 798, in ?
ImportError: No module named win32api

the 'adobe-update scripts' script, however, seems to work.

i checked other non-FDK scripts and they also work fine.

winxp, FL 5.0.2, python 2.4.3

Not using a PC for this, but my guess is win32api is an 'external' Python library which you have to grab somewhere and install in addition to python and fdk.

thanks karsten,

i downloaded the win32api.dll and placed it into various places that seemed appropriate: the windows system folder, the python dll folder, the fontlab modules folder.

eventually the error changed, but was not solved:

Traceback (most recent call last):
File "", line 798, in ?
ImportError: DLL load failed: Das angegebene Modul wurde nicht gefunden.

in line 798 AutoHint.py tries to import the win32api.dll and the win32con.py; i also downloaded the latter and placed it into the fl modules folder - with no changes in behaviour.

if __name__ == '__main__':
dontShowDialog = 1
if haveAC:
result = 2
if os.name == "nt":
import win32api
import win32con

any ideas?

AFDKO Version 2.0 includes several new tools, and I recently authored a new Adobe Tech Note, #5900, to act as a tutorial for three of them, specifically for mergeFonts, rotateFont, and autohint. This Adobe Tech Note will be available at the following URL: http://partners.adobe.com/public/developer/font/index.html

And, it will be included in the next release of AFDKO. Until then, if anyone would like to receive this Adobe Tech Note, contact me by email.

Ken Lunde
Senior Computer Scientist, CJKV Type Development
Adobe Systems Incorporated
lunde@adobe.com

Thanks Ken! I'll take you up on that.

ChrisL

Hi Andreas,

As Miguel has noted, the correct feature file keywords are described in the file "FDK/Technical Documentation/OT Feature File Syntax.html"

The "fontinfo" file is no longer required, and when used, makeotf pays attention to only a few parameters. The way things work now is that makeotf will llook , in order, in three sources for parameters settings:
- the fontinfo file, if there is one
- the project file
- the command line
If the different sources specify different settings, the last one seen wins.

If you use a project file, you have no need to use a fontinfo file at all, and would do better to not have one, in order to avoid possible conflicting options. I agree that if you *do* use a fontinfo file, it would be better to be abel to specify a path - I will add this to makeotf with the next bug fix release.

I am pleased to hear that you do use the project files. I thought it would be useful to have this option, but no one at Adobe uses them, and your e-mail is the first evidence that I have seen that anyone else does, either. I wil llook into the '-nr' problem under Windows.

The easiest way to supress the complain about use of the 'except' clause in in the feature file is to change from using "except' to 'ignore".

- Read Roberts

Hi,

My apologies - I see that the dependency on the win32api and win32com.py modules in the Windows version is not documented. I will fix this in the next release. Note that they have to be installed in one of the directories which is in the sys.path list of your Python. The only directory under FontLab's Macros directory which is in this list is in Macros/System/Modules. Did you put both these modules in one of the directories in sys.path?

Another limitation is that the AutoHint and CheckOutlines modules use C extension modules that are linked for use with Python 2.3 ( aka FontLab 5) and won't work with Python 2.2 ( aka FontLab 2.2).

- Read Roberts

read,

Note that they have to be installed in one of the directories which is in the sys.path list of your Python. The only directory under FontLab’s Macros directory which is in this list is in Macros/System/Modules. Did you put both these modules in one of the directories in sys.path?

this is actually what i've done, yet, it doesn't work. i also added a path file to the site-packages folder (just like the one created by the FDK) - but it makes no difference. fontlab (or python) still reports that the library can't be found.

Windows users should install the win32all package:
http://www.python.net/crew/mhammond/win32/Downloads.html

It includes the win32api etc. modules.

A.

One current problem with Python extension modules is that they work only with the version of Python for which they were built. It is possible that your win32api module doesn't match your Python. Another possibility is that the win32api module may have dependencies on other modules. I will echo Adam Twardoch's good advice and recommend that you download the entire win32 package. However, I will add that you need to pick the right one that works with the version of Python that you have. I actually used "pywin32-205.win32-py2.3.exe" to install the win32 package for my co-workers at Adobe. This translates as "build 205 of the win32 package, built for Python 2.3". The newer builds of win32 ought to work, as long as they are built for the Python you are using. These can be found at:
http://sourceforge.net/project/showfiles.php?group_id=78018

Note that the AFDK0 FontLab scripts are built to work with Python 2.3. Autohint and CheckOutlines in particular use extension modules that are tied to specifically to Python 2.3; the others assume in some places support for operations that exist only in 2.3 and later.

- Read

i was aware of the version interdependence and installed the extensions accordingly. which didn't solve it. right now i am trying to get it to work with python 2.3.5 - not successful yet. i'll check back for new developments.

Read,

any chance that Adobe could also release AFDKO 2.0 compiled for Python 2.4?

A.

Yes, I can build the Python 2.4 libs as well, for the next update in a few weeks. Note that this affects only the FDK Check Outlines and Auto Hint scripts - the command -line tools are entirely independent of any installed Python, and none of the other scripts for FontLab use a Python extension module.

Good soul mind to post screenshot(s) how to install AFDKO (v2.0)?

- C.

The file "FDK/Read_Me_First.html" explains how to install the AFDKO v2.0

I have tried the Autohinter for a couple of project, and it feels very nice. Sometimes when autohinting with FontLabs own hinter, I got a couple of red "H" that I didnt know how to fix.

Adobes autohinter creates all green H’s ;-) I also kind of like that the log shows exactly what the autohinter did do to the font.

Maybe a bug or a bug in the documentation, since the example doc shows the winDescent value with a minus.

The winDescent value have to be written without minus. Otherwise the font will be currupted and crashes instandly my xp system.

example for correct compilation:


table hhea {
Ascender 900;
Descender -350; # not 350
LineGap 0;
} hhea


table OS/2 {
TypoAscender 765;
TypoDescender -235;
TypoLineGap 250;
winAscent 900;
winDescent 350; # not -350
Panose 2 2 5 2 6 5 6 2 4 3;
XHeight 455;
CapHeight 720;
FSType 4;
WeightClass 400;
WidthClass 5;
} OS/2;

--astype.de--

> Adobes autohinter creates all green H’s ;-)

This reminds me of something.
What I'm going to say might be obvious to many of you, but just wanted to make clear that in order to get good/proper hinting results, Alignment Zones and Standard Stems need to be set beforehand.

Miguel, in your opinion; do you thinks it’s OK to do this with FontLab’s auto-stems and auto alignment zones? When it comes to these matters, I really like the word Auto :)

Goran, Autodidakt

Goran, I here you there ;^)

I'd follow Adam's tip, with a couple additional steps:
...
1.1. Check that the auto Alignment Zones are good, i.e. they should cover all the "overshoot nodes". Eventually, you might want to shift some of these points a few units up or down.
...
5. Run Adobe's Autohint

That's all :^)

Great advices! Thanks for that.

If I compile my old Postscript-data in FDK2 its all ok.
If the font-data newer (in Studio 5 generated), I have this errormessage on screen.
Any suggestions?

No value or key in FDK 2 for renumber?
renumber yes|no # Increment the head table FontRevision field

Andreas, as regards your latest example:

Someone please correct me if I'm wrong, but I think that (as for OS/2 TypoDescender) hhea Descender must be a negative value:

table hhea (
    Ascender 900;
    Descender -350;  # not 350
    LineGap 0;
) hhea;

OS/2 winDescent is the only below-the-baseline value which must be stated with a positive value! (The FLS5 FontInfo interface asks for a negative winDescent value for reasons of consistency and user-friendliness.)
As to the feature file syntax document, sections 9.d and 9.f -- it seems it's just minor copy/paste errors.

Karsten

[Third editing now. Hope there are no mistakes left ...]

If in font.ps
/Notice (Copyright © 2006 something. All Rights Reserved.) readonly def
... Error

If in font.ps
/Notice (Copyright (c) 2006 something. All Rights Reserved.) readonly def
... no problem

That’s all. Sorry.

[preusss]

Thank you Karsten, yes the hhea Descender needs a negative value. I corrected my example above.

--astype.de--

What means this errormessages (comparefamily):

Single Face Test 6:
...
Error: Environment variable CF_DEFAULT_URL is not set, so I can't compare it to Mac Foundry URL name id 11.
Error: Environment variable CF_DEFAULT_FOUNDRY_CODE is not set, so I can't compare it to the OS/2 table foundry code.

[preusss]

Update: Sorry, I should have installed a fresher version of Stuffit Expander before posting. Everything works fine now! :-D Playtime!

Am I the only one who can't UnStuff the Mac file?
I get an error everytime. I want to play.

Both the Windows XP and Mac OSX operating systems have things called "environment variables", which have a name and a text value. compareFamily looks for two environment variables with the names shown in the error messages that you saw. If present, it uses the values to compare with values in the font, and complains if font values and the environment variable values are not the same.

To read how to set environment variables in Windows, see::
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs...

For Mac OSX, open a command-line window (aka the Terminal program) and first try the command:
CF_DEFAULT_FOUNDRY_CODE="ADBE"
If this works , you then enter the command
"export CF_DEFAULT_FOUNDRY_CODE"
and it is set for any programs that you run by entering commands in this window. To make the setting permanent, create/edit the file in your home directory named ".profile", and add in the file the same two commands that you tried.

If the first command produced the response "Command not found", then the Terminal window is using the tcsh shell program to process the command lines, and the commands to set the variable are:
setenv CF_DEFAULT_FOUNDRY_CODE "ADBE"
export CF_DEFAULT_FOUNDRY_CODE

and to make the settings pemanent, you shoud certate or edit the file in your home directory named ".cshrc", and add these commands.

Of course, you should use your values for the 4 letter foundry code and for the name ID 11 fondry URL, rather than the values for Adobe.

Other people have complained about how the FDK 2.0 makeotf doesn't have a "renumber" option. The bug fix version , due in a few weeks, will have one.

Hi preusss,

This happens because makeotf is compiled with debug libraries, and will show a dialog like this whenver a low-level assetion that checks data integrity fails. The problem here is most llikely one of encoding, that one of the input files has characer codes above low ASCII, like an umlaut. I suggest checking:
the feature file "_features.txt"
the menu name file ""FMNDB_Prillwitz.txt"
the GOADB file "GOA_GTF.txt"
by cutting them down to just a stub with only some safe text, and then adding the original text back in a section at a time, to find the problem. It is not legal to use high-ASCII characters in glyph names. It is legal in some of the name table names, but you must represent these character codes as hex codes in the feature file. For example, the char code for the "copyright" glyph is "\00a9" for Windows menu names, and "\a9" for Mac menu names; you can see this in the "features.name" exampel file in the "Example Font Sources". The character codes for the Windows platofrm names are Unicode values, for the Mac they are Mac Roman ecnodign values.

- Read Roberts

Anyone using FDK 1.6 feature files needs to read the following

David Agg asked why his FDK 1.6 feature file was failing at the lines:
> feature kern {
> language ROM;

Answer:

This works in the FDK 1.6, because the default script is ‘latn’; you get the same effect is if you had written
script latn;
language ROM;

However, in the FDK 2.0, the default script is “DFLT”, so the effect is saying:
script DFLT;
language ROM;

and the only legal language tag for the DFLT script is the ‘dflt’ language.

To get what you want, you should put the lines:
languagesystem DFLT dflt;
languagesystem latn dflt;
languagesystem latn ROM;

at the beginning of the feature file; all features not registered under a specific language will then be registered under these three script/language pairs.

In features where you specify any language or script, you need to spell out all the script language combinations, and explicitly include the appropriate features under each, e.g
script DFLT;
language dflt;
lookup LOOKUP_1 {
... lots of rules
} LOOKUP_1;

script latn;
language ROM;
lookup LOOKUP_1; # reference to the previously defined LOOKUP_1,
# so that it will be included under latn-ROM as well as DFLT-dflt.

The compareFamily tool now dumps a table of script/languages vs sets of lookups, so you can see what’s actually in the font.
You should look at this when you are working out new script/language settings in the feature file.

- Read Roberts

Problems with the FDK 2.0 and FontLab on Windows.

Some people have seen that when they add the FDK executable directory "FDK/Tools/win" to their PATH variable, that FontLab starts behaving badly - macros disappear, and other odd things. If this happens to you, remove the FDK directory from the PATH variable, and don't install the FDK. The next release in a few weeks will fix this.

The problem is that the PATH variable is used by Windows as the list of directories to search for not only programs, but also libraries. 'FDK/Tools/win" contains Python and system libraries that may conflict with what FontLab uses. Thanks to John Hudson, who put up with a lot of e-mails and tests to help figure out what was wrong.

- Read Roberts

Hi Read,

many tnx.

[preusss]

i'm trying to get the AutoHinter to work on PC running the macro from within FLS5, but i get the following error:

Traceback (most recent call last):
File "", line 75, in ?
ImportError: No module named plistlib

what do i do when i have missing modules?

"Good soul mind to post screenshot(s) how to install AFDKO (v2.0)?"

"The file “FDK/Read_Me_First.html” explains how to install the AFDKO v2.0"

I am lost with tech. Did not understand.

Thanks!!!

- C.

Anon Bug

Anonymous data blocks will be ignored by the FDK. I have tried different positions in the feature file. The FDK compiles it without any error message but the resulting font file have always the same byte length like the font without the anon block, so my gues no anonymous block was added.

No luck too with the example form the tech doc "10. Specifying anonymous data blocks".

--astype.de--

To spare yourself from having some problems while trying to use the AFDKO, install the tools in paths that contain NO space characters. Also, do the same with the folders and files you're working with.

For example, CompareFamily won't work if the font files are inside a folder named "My Folder".

Sorry if this is a stupid question but it seems that the old .fpr files from my old projects are not recognised anymore. Has the format changed?

The example font provided does not include a .fpr file - is there an example .fpr file available anywhere?

Thanks,
Tim

hi Tim, no FDK2 training on the TypeTech week?

Yes, the format have changed.

makeotf -fp bla.fpr

FeaturePath Std\_Reg\features.txt
FontMenuDBPath FontMenuNameDB.txt
GlyphAliasDBPath GOA.txt
InputFontPath Std\_Reg\yourfont.pfa
OutputFontPath ready\yourfont.otf
DoAliasAndOrder true
DoSubroutinization true
ReleaseMode true

Don't try to set something above to "false", just let the line out.

Or you should try a batch file

makeotf -f yourfont.pfa -o yourfont.otf -ff features.txt -mf FontMenuName.txt -gf GOA.txt -S -ga


--astype.de--

Thanks, Andreas.
It worked. Slowly getting there.

Batch files are a good idea - they are so much more comfortable than the real command line. I already used them with the old FDK. Plus, batch files allow you to compile a whole family at once.

Alternatively, you can set up a shortcut to your python.exe, go to the properties and manually add "(path)\MakeOTF.py -fp" and then drag any .fpr file on it. You could have several shortcuts with different additional options added.

Or, you could set up the .fpr file type in your system so that double-clicking .fpr files "opens" them with Python and MakeOTF.py. Maybe this is the most elegant solution.

However, I have no idea if any of this is possible on a Mac.

Tim

Hi! paul ,

did you figure out what to do when modules are missing ?

I have the same problem.

I experienced a strange problem:

The OT features in the fonts generated with the new FDK do not work in InDesign and they do not show up in the menu. Kerning does not work either.
However, when I open the font in FL the features are there and working. Even in Word the kerning works.

Any ideas?

Thanks,
Tim

[edit] Read's suggestion to insert the languagesystem tags fixed the problem.

did you figure out what to do when modules are missing ?

sorry, no. i guess i need to bone up on python to figger it all out.

Paul, did u install Mark Hammond's win32all and python 2.3.5 or phyton 2.4? I was having the same problem but I was told that the auto-hinter only work in phyton 2.3.5, now it works fine.

Emiliano Amadei

Im gonna try to write a dummy's guide to install 'with success' AFDKO 2.0 in Fontlab Studio5.0.2.

First, as mentioned before, your Fontlab Folder must not have any spaces or number in them. I had to uninstall my copy and install it in the folder "C:\FLStudio\". Just that, not two folders as default Fontlab installation does. Then I unzipped the "FDK2.0-WIN.zip" in "C:\" creating the path "C:\FDK".
Now install the phyton program, version 2.3.5 "Python-2.3.5.exe" and the win32all "pywin32-210.win32-py2.3.exe". If anyone is unable to locate any of this files, drop me a PM.
With that done, run the command prompt. Get to the drive root where you installed fontlab.(In my case "C:\") Then type "cd fdk/tools/fontlab". Now type "installfontlabmacros.py /../../../flstudio/macros" (Change "flstudio" for the name of your FontLab Folder). You're gonna see it copying the files to the Fontlab Macro folder. This python script also creates a file named "FDK.pth" in the python folder. As default is in "C:\Phyton23\Lib\site-packages\". This file, if open in the Notepad has the line "C:\FDK\Tools\SharedData\FDKScripts". This is the folder where FDK scripts are located. If you want to change the location of your "SharedData" folder, just rewrite the location in the "FDK.pth" file.
If done as above, your FontLab macros are ready to use. The only one that still generates error is "Auto-Hint". It gives the following:
'Failed to import either version of auto-hinting library
Current list of search paths for modules:
['C:\\',
'C:\\WINDOWS\\system32\\python23.zip',
'C:\\PHYTON~1.5\\Lib',
'C:\\PHYTON~1.5\\DLLs',
'C:\\PHYTON~1.5\\Lib\\lib-tk',
'C:\\',
'C:\\FLStudio',
.....................
Traceback (most recent call last):
File "", line 105, in ?
ImportError: No module named PyACDebug'.
Any suggestions?

Emiliano Amadei

Before this thread is going to sleep I will point to some uncommented bugs.

1. The anonymous data block bug I have posted before.
No anon data block will be added. No error message, nothing.

2. The -adds bug.
The switch "-adds" will not work! Everytime I use it makeotf will read/convert it to "-nadds" with the resulting error output "makeotfexe.exe [FATAL] unrecognized option (-nadds)"

3. Not a bug, but a great loss. The new makeotf shows no info about not defined glyphs (AliasDB) or unhinted glyphs.

Thomas, Read, Miguel please comment or verify it.

System: WinXP SP2

--astype.de--

The FDK for Windows is missing the module plist.py. This is part of the standard Mac Python installation. It is used by the AutoHint script. See fi you can get someone with a Mac to send it to you, else wait two to four weeks for the next update for the FDK to fix the various installation issues.

If you then have the problem "importError: No module named PyACDebug", there is a deeper problem on Windows where the FDK can conflict with the the Ptyhon associated witth FontLab. The solution for this is to wait for the next FDK build : it will fix this, and support both Python 2.3 and 2.4 with FontLab.

About Andreas' post.

1) 'adds bug. Yes, I can duplicate this bug. You can work around it for the moment by supplying a target weight value after the 'adds' option, e.i. '-adds 500". The next build wil fix this bug, so you will not have to specify a value. Without a value, MakeOTF makes a guess as to the target weight.

2) Anon block.
This is indeed not supported in MakeOTF, and never has been. It is meant for someone who is developing their own version of MakeOTF, and who wants to support feature file syntax not supported by the undelrlying MakeOTF library. What it does is to just pass the "anon" block text from the feature file from the library to the top-level program. MakeOTF does receive this data, but does nothing with it.

3) Missing complaints about unhinted glyphs.
The missing hints reports came from the 'tx' tool, which MakeOTF uses to convert fonts from *otf to *pfa (Type 1) for input into the makeOTF library. I supressed its output, as several users didn't like seeing its output in this context. However, you can still see the same unhinted glyphs report by running compareFamily, whcih will complain about unhinted glyphs, or more quickly, by using the command-line 'tx -cff inputFontPath temp.cff'. This will incidentally make a CFF version of the input font file, but will also report all the unhinted glyph. On the Mac you can avoid the temp file by saying "tx fontPath > /dev/null". Piping output to /dev/null is the standard Unix way of saying 'throw out all the output", but I don;'t know how to do this in Windows.

4) Missing complaints about not defined glyphs.
I don't understand this. MakeOTF will still fail if your feature file references glyph names not in the font. Do you want reports when 1) glyph aliasing is turned on and 2) the source font contains glyphs not named in the glyph alias file as source or final names? I could add this, although probaby not for the next build. I would assume that glyphs whose base name ( the part before the suffix, if any) look like "uniXXX" or "uXXXX" should not be reported,.

- Read

Thank you Read for your clear words.

to 1.
I have no luke in adding a value "-adds 500".

This is the order of my batch file (plus an extra fontinfo file setting the font to bold):

makeotf
-f C:\1\2\3\4\Pro\Regular\font.pfa
-o C:\1\2\3\4\ready\myfont.otf
-ff C:\1\2\3\4\Pro\Regular\_features.txt
-mf C:\1\2\3\4\_FontMenuNameDB.txt
-gf C:\1\2\3\4\GOA_GTF.txt -S -ga -adds 500


(all in one line)

to 4.2

Yes, I thought on the second option. Sometimes some temp glyphs are left in the font or some special xxx.alt versions will be added but are not in the GOA file (GlyphOrderAndAliasDB). In this situation I will update the GOA to control the glyph placement.

In general this "extra" info helped me a lot and I miss it. Maybe it could be activated by a switch in future versions.

--astype.de--

Read Roberts writes:
> Piping output to /dev/null is the standard Unix way of
> saying ‘throw out all the output”, but I don’t know
> how to do this in Windows.

The Windows equivalent is
tx fontPath >NUL

A.

Hi Paul,

I have a new Windows build that I'd like to e-mail to you to see if it solves your installation problems on Windows. If you are interested, please e-mail me at rroberts(at)adobe.com.

Windows users should install the win32all package:
http://www.python.net/crew/mhammond/win32/Downloads.html

Adam, this link is broken, is this the right link?
http://sourceforge.net/project/showfiles.php?group_id=78018

The FDK for Windows is missing the module plist.py. This is part of the standard Mac Python installation. It is used by the AutoHint script. See fi you can get someone with a Mac to send it to you

Is this the same as plistlib.py? Where am I supposed to place this file once i have it?

Thanks to a new build for Windows, and some tech support from Read Roberts, I got this up and running. Thanks Read!

Is there a new build for Mac as well?

ChrisL

No, not yet. But there will be one soon.

Thanks Miguel!

ChrisL

is the latest windows build the one which is downloadable from the adobe website?
thanks,
titus

The OpenType Layout feature definition statements such as 'languagesystem DFLT dflt;' or 'script DFLT;' errorneously produce a script tag ' ' instead of the intended 'DFLT' inside of the font file -- if the font is produced using Adobe FDK for OpenType (AFDKO) version 1.6, FontLab 4.x, or FontLab Studio 5, including the recent version 5.0.2.

This situation is resolved in AFDKO 2.0. I have written a small free Python script that will fix the errorneous entries in your existing fonts, without the need to rebuild the font in AFDKO 2. This way, you can continue building your fonts in FLS5 until a version of FontLab Studio is released that incorporates AFDKO 2.

The information about the little tool can be found in this thread: http://typophile.com/node/29469

Adam

is there a new build for Mac?

> a version of FontLab Studio is released that incorporates AFDKO 2.

soon?

David,

Incorporating AFDKO 2 into FontLab Studio is a substantial task so it will make it into the next major release, not a minor bugfix release. We currently don't have anything to announce on this.

A.

Hi all,

When using the auto hint macro is it normal to get along list of corrections in the output window.

Are these corrections the macro has made, or are these corrections I need to make. I ask cos I run the macro again on the same font I still get the list of corrections so I'm sort of thinking the corrections haven't been made.

c.

The autohint macro will not make corrections unless you tell it to explicitly. However, it only makes a limited set of corrections such as adding points at extremes. It never changes the path of a curve, and so won't fix these issues. What it is telling you is that there are points on a path which are so close to the boundaries of a stem-hint or alignment zone that it seems likely that the intent was that the point should be captured by the hint - but you need to move the point a few design-scaped units to make this happen. This is not necessarily a problem that needs fixing. It is bad if these points are on a feature that really needs to be aligned with other glyphs, like the top or bottom of a lower case or upper case letter. However, these points may also be on curves that do not need to be controlled. Bottom line: look at a waterfall of these glyphs, and see if you have hinting problems. If so, you need to do something, else not.

i checked whether the windows build mentioned by paul on 10 November, 2006 - 7:53pm actually made it to the download page. unfortunately it didn't, so i wondered if it's ever going to make it or if i there is another way to get it.

i wondered if it’s ever going to make it or if i there is another way to get it

Good question. It's been overdue for a long time already. Maybe it's time to roll out the Phinn-Signal? Who's got their hand on the switch this week? Dezcom, maybe?

Regards,
Ernie

Solfeggio must a musician or at least have the doe to Ray mi sol :-)

ChrisL

Mechanical-monkey musician maybe. (Howzat for alliterative overkill?!)

But more to the point, the newest file in the current version of AFDKO 2 for Windows is time stamped September 1, 2006. The promised update has yet to be seen. Perhaps someone from Adobe will address this? Soon, one hopes.

Regards,
Ernie

Utterly Off-Topic: Chris, thought you (at least) might remember the Nairobi Trio and Robert "Red Hot Harp" Maxwell's composition as sung by the Ray Charles Singers. Here's your dose of nostalgia:

mi sol la, re fa mi sol, do mi do fa re sol sol
mi sol la, re fa mi sol, do mi do fa re sol sol do
do mi fa, si re si mi, la do la fa re sol sol
do mi do fa, si re si mi, la do la fa re sol sol do

A Ray from the Rayettes :-)

ChrisL

Sorry, Chris, not the pianist and soul singer, but the "Ray Charles" (born as Charles Raymond Offenberg) who was composer and conductor of The Ray Charles Singers. Nice try all the same.

Regards,
Ernie

I know who you mean. They were the oh-so clean cut chorus who sang very "nice" music. I was pushing Ray for re and sol to be Soul for my little joke and the Ray Charles Singers you mentioned didn't have much of that :-)

ChrisL

Re: [OpenType migration] OpenType Feature Files

Hi George;

About your May 10th posting on opentype-migration-list@indx.co.uk:

The syntax you suggest could be implemented, but I don't immediately see the advantage. I do see that you can represent in one statement what would otherwise require many statements, but to do so you need to refer to a lookup that has to be defined elsewhere, and this lookup will require just as many statements.

For your questions from your posting on Monday May 7th:

- there is no std extension, but lots of people use '.fea"

- the next FDK update, due out soon, has only bug fixes and minor extensions. The next major release, which will add GDEF table and anchor support but probably not device tables, is due out summer 2008.

- In a single contextual chain positioning statement, you can specify only one value per input position, just as you can only specify a single value for a class pair. To apply different values for different glyphs at the same position, you must use different statements.

- Contextual ligature statements are in fact more limited than Tom Phinney's reply shows. In the case of the contextual ligature rule, the substitution cannot be a class. Contextual positioning statements provide context for a particular lookup type. To figure out what you can do, strip off the context, and then consider whether it would work as a non-contextual positioning statement. The underlying GSUB and GPOS table structure does allow much more flexibility than this, but we chose to limit flexibility in favor of simplicity of expression.

- Read

AFDKO Build 26 is now available.
http://www.adobe.com/devnet/opentype/afdko/

Miguel, you didn't mention that it includes your script for generating the kern feature!

(I recommend reading the documentation inside the module 'WriteFeaturesKern.py' which is located in 'Macros / System / Modules' after installation. It expects that names of leftside-only and rightside-only kern classes either include a tag '_LEFT' and '_RIGHT'. Alternatively, these default tags can be changed in the first few lines of the module. Additional tags -- '_LAT', '_GRK', '_CYR' -- help the script to set subtable breaks correctly. It even allows for class-based exception kerning.)

very nice, Miguel! Thanks for including this.

great, thanks adobe, thanks miguel and read!

Is it possible to use the AFDKO scripts through FontForge (through X11 on Mac OSX 10.4.9), rather than just FontLab?

If so, how, or which chapters of the manuals do I need to look at?

Or am I totally misunderstanding how this whole thing works?

Or am I totally misunderstanding how this whole thing works?

Not totally, only partly. You can use most of the FDK without FontLab.

The "main" FDK, the tools that build and analyse OTFs are command line tools that are independent of FL. However, there are some additional tools that run as macros in FL. I doubt you will get them to work in any other application.

Relative to this build, I'm not sure how new they are, but Check Outlines and AutoHint are lovely.

[edit]

I'm getting some outputs I never seen before when running the outline check

glyph U.
looking for coincidentpaths ...
removing any intersections...
inspecting/repairing paths...
checking path directions...
glyph V.
looking for coincidentpaths ...
removing any intersections...
inspecting/repairing paths...
checking path directions...
glyph W.
looking for coincidentpaths ...
removing any intersections...
inspecting/repairing paths...
checking path directions...

I'm getting the same results on most glyphs. Can anyone explain this and is it something I should be worried about

Rr

Some remarks on the Autohint function of Adobe's FDK 2.0

Here are a few tech notes, which may (or may not) be useful for typophiles:

1) The first version, i.e. FDK v2.0 Aug 31 2006 build 21 (FDK2.0-WIN.zip, file size ca. 14.4 MB), was faulty. It did not work on my Windowx XP machine.

2) Yesterday, I installed the current version, i.e. FDK v2.0 May 5 2007 build 26 (FDK2.0-WIN.zip, file size only 9.8 MB).

3) The current versions runs in the DOS box of Windows XP (but not in the DOS box of Windows 98, which I also tested).

4) After unpacking the zip file FDK2.0-WIN.zip into the folder c:\fdk, I switch to the DOS box (i.e. cmd.exe) and select the FDK folder via cd c:\fdk and then set the FDK program folder via path=c:\fdk\tools\win.

5) After copying the font to be autohinted into the FDK folder under the name c:\fdk\font.pfa, I start autohint by autohint -a font.pfa, which results in the hinted font saved under the same name font.pfa.

Now a few remarks on the Autohint function:

Adobe's FDK autohint function is of very high quality, but it seems to be geared to Latin fonts only, for the autohinting quality heavily depends on the x-height, ascender etc. alignment zones (which do not exist in most non-Latin fonts, e.g. in Indic fonts, so that it is unclear, how such non-Latin fonts could be hinted with FDK).

I compared the autohint function of Fontlab 4.6 with the autohint function of Adobe's FDK. It is astonishing that exactly the same font with exactly the same alignment zones and exactly the same vertical and horizontal stem widths has entirely different autohinting results in Fontlab, as compared with Adobe's FDK. Especially, Fontlab 4.6 does not seem to handle vertical stem widths properly:

a) The screenshot http://www.sanskritweb.net/temporary/fdk.jpg shows that Fontlab makes some vertical stems too thick, wheareas Adobe's FDK autohint function streamlines all vertical stems. This screenshot was made without font smoothing.

b) The PDF http://www.sanskritweb.net/temporary/fdk.pdf can be used for testing font smoothing, which, if switched on e.g. in Adobe Acrobat Reader, alleviates the Type 1 autohint deficiencies of Fontlab 4.6, which may (or may not) have been remedied by a later release of Fontlab.

Uli, what do the actual hints for the h and n look like in FontLab? Can you provide a screenshot of the glyph windows? This is a strange effect, and not what I would expect from the FL autohinter, unless it is trying to hint the serif widths as well as the stem widths and miscalculating the hint replacement point.

Mr. Hudson:

I already deleted the test font faultily hinted by Fontlab 4.6.

But you can most easily repeat my experiment as follows:

1) Open Adobe's OpenType font SerifaStd-Roman.otf with Fontlab 4.6.

2) Remove all hints (e.g. by key shortcut shift F7) via Fontlab 4.6

3) Autohint all glyphs (e.g. by key shortcut F7) via Fontlab 4.6

4) Generate PostScript Type 1 font SerifaStd-Roman.pfb with Fontlab 4.6

5) Also generate the PFA version SerifaStd-Roman.pfa with Fontlab 4.6

This PS Type 1 font SerifaStd-Roman.pfb will contain the faulty vertical stem hints faultily hinted by Fontlab 4.6. I do not know, whether later versions of Fontlab have the same problem. Using Adobe's FDK autohint function on the PFA version SerifaStd-Roman.pfa will remedy the faulty stem hints.