i don't think he said there was a hinting plug-in for FontLab, but that FontLab could implement their hinting tools (if they wanted).

Say it ain't so Paul :-(

ChrisL

Well, as I understood it you could use the auto-hinting tool--their pride and joy--as a stand alone-utility.

The new FDK will include the Adobe PS auto-hinter, which can be run on fonts as a stand-alone utility as part of the FDK, and which FontLab will also be able to incorporate into its own programs. I'm pretty sure FontLab will do this, since it will be an improvement over the current FL autohinting, but will give users the option to manually edit the results, which the autohinter does not by itself.

Thanks John!

ChrisL

Adobe's Autohinter exists both as a command-line tool and as a FontLab macro. I actually have been using the latter, which I assume will be included in the next release of the AFDKO. This will happen sometime soon :^)

Actually, we could release the FDK any day now, I just need to settle one question about bumping the OS/2 table version string. What this space.

As Miguel has clarified, the auto-hinter is already a FontLab plug-in macro, and a separate command-line tool. It can be run on both Type 1 and OpenType CFF fonts (or in FontLab on any font with PS style outlines, which can then be exported to Type 1 or OT CFF). However, we could hope for tighter integration into FontLab in a future version of the app.

Cheers,

T

Thomas, what about GPOS lookup types 3?

Thanks Thomas and Miguel! Looking forward to seeing it. Please post the release date when you know it.

ChrisL

Will do :^)

Let's see... FDK is going to be like VOLT?

> Let’s see… FDK is going to be like VOLT?

Would you like to? Why? How? What are you looking forward to?

> Would you like to? Why? How? What are you looking forward to?

Since I don't want this thread to turn to FDK vs. VOLT (there was a thread that started with negative attitude toward MS) - and in order to keep it clean, let us talk about FDK (& FontLab.)

If FDK can support the OpenType features that FL can't handle - that will be great.

I don't know what stage FDK is in, but if it were up to me - to add these features and wait even 6 months - then add & wait.

But since I'm not behind the Adobe curtains I don't know what Adobe is up to. However, since FDK isn't like any other product by Adobe (e.g. InDesign, Photoshop - that you keep everything secret till the release ) maybe you or Thomas can shed some OpenType light.

Thank you.

> If FDK can support the OpenType features that
> FL can’t handle - that will be great.

FontLab Studio 5 uses exactly the same Adobe code that is in AFDKO 1.6. When AFDKO 2.0 is released, it will take some time until that code is incorporated into FontLab Studio, so in the meantime, AFDKO will have some advantage. However, from what I remember seeing at Read Roberts˚ presentation in The Hague, I don˚t think that AFDKO 2.0 will support any new lookup types.

A.

Thanks Adam.

BTW this is 'offcial' ?

That's right: AFDKO 2.0 does not yet add new lookup types. That's in the next big release, some time early next year.

I expect that we will settle the OS/2 version question in the next couple of work days. After that, there may be a delay of up to a week or two before the new FDK bits are actually posted (depends on our web team).

Right now, for most people, I think the FDK is mostly some additional tools, and I don't expect most users will actually build their OT fonts using the FDK. They'll use it for proofing/testing tools, and they'll maybe use some of the scripts and plug-ins.

Regards,

T

I should add that when we add more lookup types, we will support *all* lookup types in the FDK.

T

"I think the FDK is mostly some additional tools, and I don’t expect most users will actually build their OT fonts using the FDK."

Hello Thomas,

but a few people like me compile their fonts with it. So it would be great if the time between each release don't went to long. One of the great features I like is to build and store the font sources splitted into their single parts and to do batch generation.

Which Phyton version will be needed to run the new FDK properly?

--astype.de--

Thanks Thomas for your clarification. I assume the hinting tool you told us about in New York will be part of the "additional tools".

ChrisL

Thanks Thomas.

Adam,

What about FL? - "We plan to support these OpenType specifications elements..."

The T1/CFF auto-hinter is supplied in the new FDK both as a stand-alone application and as a plug-in for FontLab.

One of the improvements is that it no longer relies on any separate Python installation.

Regards,

T

GREAT!!

ChrisL

T1/CFF auto-hinter - the pros & cons?

Pro: This is the auto-hinter Adobe has used for close to two decades now, which we believe is the best auto-hinter available for PostScript style outlines.

Essentially, this is the crown jewels of Adobe font production.

When you have this available to you in a font editor like FontLab, you'll have the option of further tweaking the hints to your heart's content. It's not like you're stuck with the results.

Cons: None that I can think of.

Cheers,

T

Cons: I can't use it right this moment :-)

Bravo to Adobe for releasing it to independent usage and thanks to Thomas for his role in helping font devlopment in all venues.

ChrisL

Thank you Thomas.

is the autohinting with adobe's tool "useable" for, lets say, a free font that should just scale down a bit better than without any custom hinting at all?

im very interested in typedesign, but there's just no way im going to learn that hinting-stuff! :)

What's to learn? The whole point of an auto-hinter is that you don't have to learn much of anything.

Adobe's auto-hinter, like FontLab's, does require that you set zones and stems separately. So you use the auto-blue-zones and auto-stems buttons in FontLab, and then use the auto-hinter. Done!

T

whats to learn? even the barest knowledge of hinting! ;)

i know more or less how hinting works (basicly, i think), but if you say "set zones and stems, auto-blue-zones" and so on.. im already baffled.

but i am sorry, i didnt wanna hijack this thread. i will make my homework and then come back if i have questions.

The FontLab manual explains setting zones and stems. There are also pages on the Microsoft and Adobe sites which explain hinting. Google will find you plenty of sources.

ChrisL

Sorry, didn't mean to be flippant. Here's the easy option explained:

First make your font. :)

Then go into the Font Info, under "Hinting Settings." On the main panel, click the green diamond to get the automatically calculated alignment zones. Then on the "Standard Stems" panel, click the green diamond to automatically calculate standard stems. Then come back out to the font and select all, and auto-hint the font (either using FontLab's existing auto-hinting, with the F7 key, or using the new plug-in when it's available).

Not too tough, eh wot?

Now, it is still worth learning about hinting, but you don't have to know much about it to make use of it. However, for hinting to work well, you do have to understand enough about type design to have actually used overshoot, etc.

Regards,

T

Thomas,

Note that FontLab Studio will automatically compute the stems only when you already have hints in the font. So actually, the process is the other way around:

1. Select all glyphs in the Font Window.
2. Hit F7 to autohint all the glyphs (or choose Tools / Hints and Guides / Autohinting).
3. Go to Font Info / Hinting settings, click on Auto zones and then in Standard stems on Auto stems.

That's it.

Best,
Adam

thomas, thanks alot for your answer (and adam, you too for adding information).

i think for the time i've been doing it i know quite a bit about type design, but what do you mean with overshoot? if it means the simple fact that you have to make round shapes (and "peaks" like the A in some faces) go below and above the xheight / baseline to look as big as other characters (H and O as easy examples) i know what you mean if not, please explain, learning new things is always good.

(and please excuse my semi-hijacking of this thread)

> make round shapes (and “peaks” like the A in some faces) go below and above the xheight / baseline to look as big as other characters (H and O as easy examples)

That exactly what Overshoot means.

Thomas,

will the new version accept the manual setting of usWinAscent
and usWinDescent?

This is an important issue and a lack of the current version and hopefully easy to build in.

--astype.de--

Yes, the FDK 2.0 will allow manual setting of the usWinAscent and usWinDescent. By default, they will be set according to the spec, which is to match the font BBOX values, but this can be overridden.

T

We finally resolved with Microsoft the question of bumping the OS/2 table version number, and the FDK is ready to go. I don't know how long it will take to get onto the web site, however.

We'll post details of the OpenType 1.5 changes to the OS/2 table on Monday, on the OpenType list.

T

Great news Thomas! THANKS!

ChrisL

If the download is online, I believe it. :-)

--astype.de--

Any news? I'm dying to use the new FDK with a utility I'm writing.

Enquiring minds want to know ;-)

Has there been another snag Thomas and Miguel? Seems like this was expected a few months ago.

ChrisL

No more snags. I reckon it'll be out really soon. A few things were finally settled and Read Roberts is "wrapping up the package". And I'm glad to say that meanwhile many improvements were made in the tools, so I think it was worth waiting.

Gracias Miguel!

ChrisL

BTW, can we run the new FDK in native GUI mode in Mac OSX?

AFAIK, the OSX tools are all command line, so no GUI.
But some of the tools have their Fontlab macro equivalent, so those will "have" GUI.

The command line tools are quite more powerful and reliable, tho.
From the "AFDKO Overview" file:
Scripts for FontLab. None of these are polished production tools. They are mostly Python scripts written once and used once for a particular need, with little error checking, and are supplied mostly as an example of how to do something in FontLab.

Nonetheless, we've been pushing the Autohint.py (FL macro) to do everything the autohint (command line) does, since we see a big benefit there. You see, the autohint can't be directly applied to .vfb files ;^)

"...You see, the autohint can’t be directly applied to .vfb files ;^)"

Then how does it work?

ChrisL

The command line autohint requires a Type1 font (.pfa) as the input.
The FontLab macro Autohint can be applied to any font (with PS outlines) you have opened in FL.

Can't wait to try it.

ChrisL

anything about the release?

Yes. The files were already on their way to the web, but meanwhile a bug (related with the implementation of the 'size' feature) was found. This will delay the release a bit, but hopefully not for long.

Any new release date yet?

ChrisL

Early September.

We don't actually know when exactly the files will be posted. Read hands them over, then there's a delay of up to a week or two.

Also, be warned that there's so much new here that those who are not dying for it might be best off waiting a month or two, so that the eager beavers can ferret out any new bugs, first (oops, mixed animal metaphors).

Regards,

T

Maybe you were driving a Cobra to the point :-)

ChrisL

I hope the new FDK (the GlyphOrderAndAliasDB) support more than one glyph name and more than one unicode for each glyph.

--astype.de--

For the first point, do you mean that you want to have multiple possible input names, all of which would yield the same possible output glyph name? What would the FDK do in the case of a collision?

As for the second point, we definitely aren't supporting more than one Unicode for a single glyph. Although such double-mapping is permitted by the OpenType spec, we don't like it because it breaks the reliability of glyph-to-character mapping, as is sometimes necessary in PDF based workflows.

Regards,

T

Hello Thomas,

example for the big letter germandbls:

at the moment I use

Germandbls Germandbls uniEA8A

Adam means, Germandbls is logical from the human perspektiv but not for the current implementation since its not official. So he suggest to use germandbls.cap.

So I like to add both names. Maybe in a form like this:

Germandbls Germandbls uniEA8A germandlbs.cap

ps. In this case I remember to update the Adobe Type engine, not to exchange "hard coded" germandbls bei SS since this is no hard rule for every case and can pruduce invalid names and documents. The feature code should have priority and should not be ignored like the current implementation in InDesign CS and CS2.

The thing with double assignments:
If I remember right, the current FontLab will apply such double codepoints to some glyphs.

And why not? If a glyph have exactly the same outline, spacing and positioning but shares two or more different codepoints, its good to assign all these codepoints to a single glyph. Some kind of "compression".

The problem I see is, if one codepoint is included in feature or kerning code only and an other one uses a different code. In these cases the FDK should report an error and suggest a codepoint splitting.
- The same for shared names.

--astype.de--

Andreas,

The germandbls example you gave is very specific, and has other implications. (We actually have discussed this issue internally). Could you give another example?

> The thing with double assignments: [...] And why not?

As Thomas said, the OTF spec permits double-mapping (a given glyph is mapped to more than one Unicode value), but that makes it hard for Acrobat to reverse map from Unicode encodings to character codes, for searching.

> If a glyph have exactly the same outline, spacing and positioning but shares two or more different codepoints, its good to assign all these codepoints to a single glyph. Some kind of “compression”.

An OpenType CFF (Compact Font Format) font will have the "compression" you're looking for. It's called Subroutinization: process by which common elements in a set of glyphs are decomposed in separate subroutines.

> The problem I see is, if one codepoint is included in feature or kerning code only and an other one uses a different code. In these cases the FDK should report an error and suggest a codepoint splitting.

I don't get it. Does this mean that, for example, you wouldn't put the two Delta (U+0394 and U+2206) in the same kerning class? I might be missing something, but the only reason that would stop me for putting them in the same class, would be if the glyphs' designs were different.

Hello Migel,

yes, the german thing is specific. In general I think most of these double assignment scenarios are very specific. In most cases no real alphabetic or "word building" glyphs are involved, but accents, punctuation, numbers or signs could be. Typically these things will not be searched.

but you ask for samples: (please feel free to post better ones)

hypen 002D, hypentwo 2010
blackstar 2605, star operator 22C6
slash 002F, big solidus 29F8 (depents on the slash design)

If I understand some comments about the CFF compression right, it has its limits if the outline data is reaching a high volume or complexity.

I see the point with the Acrobat compatibility issue, but if someone wants a "proper" PDF for a special long term archive, he should use special or standard clean Adobe fonts too. I don't see the point to restrict it for every possible font development.

If the pdf creator stores the double, tripple assigments too, it should be possible to search these glyphs in a proper way. One step forward is to store language specific warpers/tags around the text elements.

example scenario:

Someone use a tripple mapping for a real alphabetic glyph like B for latin, greek and cyrillic. So, if the search string is given in an unicode enviroment, its always possible to match the right glyph or string, since all unicode assigments are stored. Language specific warpers will help to filter possible "false" strings from other languages.

--astype.de--

> If I understand some comments about the CFF compression right, it has its limits if the outline data is reaching a high volume or complexity.

If you're trying to build, say, a Japanese font with 20,000 glyphs and subroutinize it, you'd better have a lot of RAM. But other than that, I can't think of any limits that we've seen in actual fonts.

Then again, I just woke up from a nap and am still a bit groggy, so maybe I'm forgetting something. Can you give a more specific reference?

T

> If the pdf creator stores the double, tripple
> assigments too, it should be possible to
> search these glyphs in a proper way. One step
> forward is to store language specific
> warpers/tags around the text elements.

Andreas,

you’re talking about introducing more flexibility in the domain where we, font developers, have influence (the way glyphs are named or encoded in the font) but on the other hand you want other domains (applications) to worry about making sure that everything still works fine for the user. In other words, you want to buy yourself some freedom at the expense of application developers.

But this will not work. Font developers are a smaller community and therefore can work out certain standards of behavior better. Application developers are a very large group and their efforts are rather uncoordinated. For example, you say "if the pdf creator". But there are 200 different PDF creators on the market, some relying on partial implementations of the standard (e.g. the Quartz engine in Mac OS X), some relying on implementation of older PDF versions, some relying on the PostScript-to-PDF conversion etc. At least in half of the scenarios, OpenType PS fonts are converted to Type 1 fonts (so cmap, GSUB etc. are all removed and only glyph names travel into the file) and the additional Unicode stream is not stored. Therefore, the PDF really only has a visual glyph representation of the text, there is no metadata. Such PDFs will ALWAYS be better searchable if the each glyph has a unique glyphname and just one Unicode codepoint. You should not think of PDF being only dependant on what Acrobat is doing. The problem is less and less with Acrobat because Acrobat is getting smarter and smarter. But there are many other tools for searching inside of PDFs, for example plugins for Spotlight, Google Desktop Search or Microsoft search etc., and there is no guarantee that they will ever be as smart as Acrobat.

The point in font development, especially with OpenType, is to try to make the fonts work as good as possible in *various* systems and applications. This often includes making some compromises or doing redundant steps to make sure that certain information is present in three different places. I wish it were different but *we* don't have any way to change it.

If you don't like the way the Adobe FDK for OpenType writes the cmap table, you can always change it with a tool like TTX or you can use FontLab Studio 5 to build your fonts.

Adam

Yes, I know, the last part of my comment was wishfull thinking. TTX would be a nice option but it failse to decompiling and recompiling most of my fonts made with the FDK.

Adam, can you verify some glyph of a FontLab5 standard install will get double unicode mappings?

--astype.de--

Andreas,

you can only decompile and recompile a specific table, e.g.

ttx -t cmap yourfont.otf

will produce a file "yourfont.ttx" with only the cmap table. You can edit it, rename to "yourfont2.ttx" and merge into your .otf using

ttx -m yourfont.otf yourfont2.ttx

The result will be a font yourfont2.otf which will contain the new cmap and the rest of the tables will be identical to those in the original yourfont.otf.

In fact, in most cases, you can use one and the same cmap-only .ttx file for the entire family (so you dump and edit once, and then merge it into all fonts in your family that have the same glyphset).

In FontLab Studio 5.0.2, standard.nam (Standard Table) has double-mappings for mu, Delta and Omega, while the AGLFN 1.6 (new) strict table only has the new AGLFN 1.6-compatible assignments. It is explained in the 5.0.2 announcement:
http://fontlab.com/The-News/Announcements/FontLab-Studio-5.0.2/
as well as in the .nam files themselves.

Adam

A.

BTW, I have just uploaded slightly revised versions of the .NAM files to:
http://groups.msn.com/fontlab/tipsandtricks.msnw?action=get_message&mvie...

The archive contains updated .NAM (glyphname-to-Unicode) mapping files for FontLab Studio 5 (and some other of our applications that use these files).

After unpacking these files, please place them on Mac into /Library/Application Support/FontLab/Mapping and on Windows into C:\Program Files\Common Files\FontLab\Mapping .

(Note: Instead doing this, you may also place them into the Mapping folder specified under Options/Preferences / General Options / Folders and paths / Files used by all FontLab products. In this case, the original files that came with your FontLab product will be retained for backup purposes. Please remember that you should place all your user-modified files into this location.)

These files incorporate Adobe Systems’ recent changes to their Adobe Glyph List for New Fonts: the mapping of the “problematic” characters Delta, Omega and mu was changed. The “AGLFN 1.4 (old) strict” table retains the previous mappings (to the "mathematical" codepoints), the “AGLFN 1.6 (new) strict” table includes only the current mappings (to the "Greek" codepoints), while the “Standard Table” now double-encodes the glyphs to map them into both the "mathematical" and the "Greek" slots. The “Standard without afiiXXXXX” table uses uniXXXX names instead of afiiXXXXX names – both sorts of names are valid.

The versions of the files provided here are newer than those included in FontLab Studio 5.0.2. We are making them available for convenience until FontLab Studio 5.0.3 is released.

You can download the archive from:
http://www.msnusers.com/fontlab/msgattachments/163

Regards,
Adam Twardoch
Fontlab Ltd.

At long last! It has arrived! the revered Paul put the annoncement up with a link to light up the night?

One if by land, 2 if by Adobe?

ChrisL

The fdk is out now, maybe we should open a new thread.

And now my biigest concern. How to setup usWinAscent and usWinDescent to provide the same line spacing between font families and between different version of the same font (Std, Pro)?

I hope this is possible by adding it simply to the OS/2 table.

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

But its not working, why?

Since the old .fpr project file format has changed it would be very usefull to provide us with an example file. Ok, the makeotf.py generates it.

I have some guru meditations on windows.

1. the mystery of -nr

If I use a project file I got lots of the time: [FATAL] unrecognized option (-nr)

But I never used such an option. Is this relateded to unix ascii line breaks?

2. no relative paths under windows?

The makeotf don't accepts relative paths if its called without *.fpr file. But with it, it works with relative paths. - Then cames the mysterious -nr error into play.

3. This message on a test font without feature code.

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

Conclusion:

Working with *.fpr files seems to work not properly under windows. So I have to wirte good old *.bat files.

I have the feeling you used these scripts exclusivly under unix/OSX.

--astype.de--

> The fdk is out now, maybe we should open a new thread.

Just did. Please use this thread. Thanks.

> I have the feeling you used these scripts exclusivly under unix/OSX.

It's true that the AFDKO 2.0 was mainly tested on Mac, since that's the platform most of us use, but I'm sure Read Roberts did a fair amount of tests under Windows. Nonetheless, like he said on the Adobe FDK Forum, "the AFKDO v2.0 has been in use for only a few months by three people, so I expect that you will quickly find bugs".

I ran pre-release versions of the FDK under Windows, but I was mostly working with the testing tools rather than production tools (e.g. CompareFamily).

Anyway, off to the new thread.

Regards,

T

i thought this would be as good a thread as any to hijack for some birthday wishes to one of the friendliest, most generous, helpful people in type.* here's hoping it's happy!

*gosh he'd be a good boyscout!

I hope this signal will be picked up. Happy birthday Thomas!

ChrisL

Happy birthday!

Alles Gute, Thomas!

Thanks, all! Birthday was great... good family activities, some fun boardgames, and a fun party with homemade ice cream and cake .

Cheers,

T

it can't get much better than family and homemade ice cream!