AFDKO 2.0 : Post your feedback here

Miguel Sousa's picture

If you're using the new AFDKO (v2.0), we would like to hear your feedback. Please use this thread for your comments, wishes, concerns, bugs found, and/or anything related with the tools contained in the new AFDKO. Thanks!

Andreas has already started.

Emiliano Amadei's picture

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

Emiliano Amadei's picture

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

andreas's picture

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--

Read Roberts's picture

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.

Read Roberts's picture

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

andreas's picture

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--

twardoch's picture

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.

Read Roberts's picture

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.

paul d hunt's picture

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

paul d hunt's picture

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?

paul d hunt's picture

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

dezcom's picture

Is there a new build for Mac as well?

ChrisL

Miguel Sousa's picture

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

dezcom's picture

Thanks Miguel!

ChrisL

titus n.'s picture

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

twardoch's picture

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

david h's picture

is there a new build for Mac?

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

soon?

twardoch's picture

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.

coop's picture

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.

Read Roberts's picture

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.

titus n.'s picture

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.

solfeggio's picture

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

dezcom's picture

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

ChrisL

solfeggio's picture

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

dezcom's picture

A Ray from the Rayettes :-)

ChrisL

solfeggio's picture

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

dezcom's picture

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

Read Roberts's picture

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

k.l.'s picture

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.)

paul d hunt's picture

very nice, Miguel! Thanks for including this.

titus n.'s picture

great, thanks adobe, thanks miguel and read!

cuttlefish's picture

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?

Tim Ahrens's picture

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.

eolson's picture

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

Tim Ahrens's picture

[edit]

RachelR's picture

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

Uli's picture

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.

John Hudson's picture

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.

Uli's picture

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.

Tim Ahrens's picture

As far as I can remember, these instructions are not sufficient in order to exactly reproduce what you did. In addition, FL considers your settings for minimum and maximum stem widths. You would need to provide your settings for this, as well.

dezcom's picture

FontLab 5 hinting is an improvement over 4.6 as well.

ChrisL

Andreas Stötzner's picture

Can anybody here recomend a viable how-to intro for building up OpenType features?
Perhaps I’m the idiot on this thread, but I’d like to manage it, as a type designer who is not a technician …
Thanks for any advice.

Miguel Sousa's picture

Andreas, the OT Feature File Specification is available here http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html

And on this page http://www.adobe.com/devnet/opentype/afdko/ you'll find a link to ExampleRomanFonts.zip which you may use as a guide.

William Berkson's picture

Where do I put the "example font sources" folder on my PC so that I can see the Minion example in Font Lab?

k.l.'s picture

It's not really meant to be studied in FontLab, but rather to indicate which folders and files AFDKO needs, their hierarchy, and how feature files interact in this hierarchy (e.g. the separate 'kern' feature). The feature files themselves have wonderful examples for writing features -- AFDKO feature file syntax in action. So these are best studied in a plain text editor.
(I'm a bit oldfashioned and have made printouts of the sample feature files to read them unplugged.)

William Berkson's picture

Thanks, Karsten, I'll read them with a text editor and print them out.

blank's picture

I’m a little behind the curve, but thought this might be useful to others. I was having horrible problems with my outlines getting mutilated by my laser printer. It turns out that the Fontlab’s autohinter was doing some really nasty stuff and the bad hinting was screwing up my laser printer output. Switching to the Adobe autohinter solved my problems.

Of course, not using a crappy printer would have prevented this from ever being a problem, but that’s another story…

dezcom's picture

James,
Your potential clients may also have "crappy printers" so it may be well that you went through the process.

ChrisL

Miguel Sousa's picture

I'll take this opportunity to point out that the Autohint macro will not apply Flex hints, whereas the Autohint you can run from the command line does.

Syndicate content Syndicate content