My Advice: this belongs in the Build forum!

Alex, I'm developing a font with extended Latin support and faced similar difficulties.

Probably, the best place to begin with is this post from Adobe's Typblography. You may use these glyph lists as a reference, although you can freely mix glyphs from any Latin-N group.

To add glyphs to your font in FL, use Ctrl+G and type the glyph names. If your base glyphs (let's say, A and acute) have anchors defined, FL will follow these marks to define diacritical position (when creating Á). Otherwise, it will centralize the diacritic. In view of this, a good practice is to define anchors to all plain glyphs and all diacritics before creating the accented characters.

The pages mode will not include automatically the glyphs you need.

About the ligatures, clig is a feature on by default in all ID versions. If you are creating special ligatures which your users may prefer not adopt, there is dlig (dscritionary ligatures). Usually, standard ligatures (like ff, fl and fi) are defined in clig feature, while more unusual ones (like ct, st, Th) are defined in dlig.

You may also find useful this link about OT features definition.

Specifically about language support, I did research in Wikipedia for each target language alphabet. Another good information on this is available in this site about diacritics.

Thank you, Freiberger.

Very helpful. This was exactly the information I needed.

Thanks again for pointing me in the right direction.

Much appreciated.

Best, Alex

A useful link for understanding diacritics.
http://diacritics.typo.cz/

Usually, standard ligatures (like ff, fl and fi) are defined in clig feature...

Shouldn't that be the "liga" feature?

But anyway, I've never been able to understand why a separate "clig" feature is necessary, it seems redundant.

@Nick Shinn

Yes, I agree Nick. I also think that the 'liga' feature was meant for the standard ligatures. And, I thought the 'clig' was meant specifically for other letter substitutions. But, as Freiberger points out the 'dlig' is best for alternates and variation substitutions. Especially, since it's 'off' by default, and user can enable. Much better solution for this sort of thing.

But, it's great to get others to comment and offer advise on this subject.

I for one, have always been confused, a little, by all these 'feature' flavors.

If other's can shed additional light on the matter would be welcome.

This type of exchange is very constructive and helpful.

Best to work in a standard way to avoid user confusion.

Thanks all again.

Hmm, I always thought {clig} was mostly for non-latin scripts? We will have to wait for a true guru but they only come to the Build forum :-)

We will have to wait for a true guru but they only come to the Build forum
Or hmm, you know, you can actually read the documentation your self.

Ops... please read liga where I wrote clig!

Anyway, I think that two features to control ligatures is very good. This way font designers can separate the normal ligatures from the unusual, more stylish others. So we have more freedom to experiment with ligatures and the user gets the option to use them or not.

Re #1, I use the text file option with Generate Glyph, and use four separate files: Latin Extended A uppercase, LEA lowercase, setup fraction and make fraction. I keep separate upper and lower case files in case I want to make a unicase or small caps font. My Latin Extended A uppercase test file reads as follows reads as follows:

Agrave, Aacute, Acircumflex, Atilde, Aring, Aringacute, Adieresis, Amacron, Abreve, Aogonek, AEacute, Ccedilla, Cacute, Ccircumflex, Cdotaccent, Ccaron, Dcaron, Dcroat, Egrave, Eacute, Ecircumflex, Edieresis, Emacron, Ebreve, Edotaccent, Eogonek, Ecaron, Gcircumflex, Gbreve, Gcaron, Gdotaccent, Gcedilla, Hcircumflex, Hbar, Eng, Igrave, Iacute, Icircumflex, Idieresis, Itilde, Imacron, Ibreve, Iogonek, Idotaccent, IJ, Jcircumflex, Kcedilla, Lacute, Lcedilla, Lcaron, Ldotaccent, Lslash, Nacute, Ncedilla, Ncaron, Ntilde, Ograve, Oacute, Ocircumflex, Otilde, Odieresis, Omacron, Obreve, Ohungarumlaut, Oslashacute, Racute, Rcedilla, Rcaron, Sacute, Scircumflex, Scedilla, Scaron, Scommaaccent, Tcedilla, Tcaron, Tbar, Ugrave, Uacute, Ucircumflex, Udieresis, Utilde, Umacron, Ubreve, Uring, Uhungarumlaut, Uogonek, Wcircumflex, Yacute, Ycircumflex, Ydieresis, Zacute, Zdotaccent, Zcaron

The actual file has no spaces after the commas but, in the interest of easy reading, they are included in this example.

As an aside, I wonder why Adobe 'broke' the ligature feature in InDesign when 'tracking' is implemented. You can -minus tracking all you want and ligature(s) or substitutions remain intact, but just try to +plus tracking (usually +20 to +30) and the ligature automatically breaks and reverts to individual keystrokes.

In 'Illustrator' this doesn't occur, and in QuarkXPress you can adjust the parameters when ligatures revert back to keystrokes. I know the thinking at Adobe was that they are doing the right thing...after a word is tracked open too much the ligature looks 'odd' so they break the connection.

But, really, this does us all a disservice and prevents us the 'type designers' and the 'font users' from controlling how they want the font to work? Yes/no?

My problem now is that even if I use the 'dlig' feature table for all my letter combination substitutions, they will revert as soon as the copy is tracked more than (+20) or so. And, there is no way that I can prevent this or control the event.

Any ideas?

Could it it because after +20 tracking, spacing of 'fi' or 'fl' etc. looks too tight?

Would you like new ligatures for +20 tracking?

That's not the point. I agree with the reasoning, but why not allow the user to adjust the parameters 'if and when' this occurs.

Ligatures is one thing, but if I use the 'clig' or 'dlig' tables to enable 'other type glyph substitutions' it will 'break' if tracking is implemented.

Is there any other way around this?

The only real solution, at the moment, is for the 'user' to manually select the 'alternate glyph' or other 'letter transformation' from the 'glyph window. Then you can track all you want without any issues. But, this is a tedious process for the 'user' and not as easy as toggling a feature 'on' or 'off'.

Just frustrated. Any other ideas?

You could use {calt} instead of ligatures in many cases. A good example for economy is that an alternate "f" instead of an "fl" ligature allows its use with every tall stemmed glyph, if desired.

@ oldnick

Thank you for your list and working techniques. Makes sense.

My 'Eastern European' list happens to match yours now.

Question:

I have come across other 'Pro fonts' where additional glyphs such as (Bdotaccent, Ddotaccent, Fdotaccent, Ldotaccent, Pdotaccent and Tdotaccent) including l'case come in the font. But, these glyphs do not even appear in the new 'extended latin 4-5' sets. Are these needed? What languages are these used for anyway?

Can anyone shed any light on this as well? Thanks.

@ dezcom

Thanks, this idea of using 'calt' lookup table for replacing default glyphs with alternates works.

But, it's active as default, in InDesign.

Can this feature somehow be turned off as default. And allow user to 'toggle on' if desired.

This is really the solution I want and prefer.

Is there a way in FontLab to adjust some parameter (or coding) in order to prevent 'calt' from being active as default.

Is this possible? Thanks.

Bdotaccent, Ddotaccent, Fdotaccent, Pdotaccent and Tdotaccent are used in traditional Irish typography. I'm not aware about Ldotaccent. There is Ldot, used in Catalan. L' is the correct form to represent Lcaron in Slovak.

There is no way to control a feature on/off from the font code. This is an OT definition and would be implemented the same way by all apps.

Put your {calt} feature code for things you don't want on by default in a stylistic set. The code is the same except you call out ss01 , etc,. instead of {calt}

@ Freiberger, thank you for the explanation.

Bdotaccent, Ddotaccent, Fdotaccent, Pdotaccent and Tdotaccent are used in traditional Irish typography. And, Ldot

Are there Unicodes for these glyphs?

@ dezcom, stylistic set (ss01), off by default, will work great. I'll try it. Thanks.

Alex, I suggest you to download the PDF Unicode charts for Latin (and also other blocks your font would support, as combining diacritics or symbols). They are here: http://www.unicode.org/charts/

You can search for any character using PDF search field. Just note that Unicode charts does not uses the naming "Adotaccent". They adopt "A with dot above" as the glyph description. Anyway, you can find the glyphs easily in the Latin blocks (there are a total of seven blocks of Latin script).

Probably late October we will have a new Unicode version available (6.0). Anyway, no relevant changes were proposed to Latin blocks (as far as I remember, there is just the inclusion of a pair of African special characters proposed).

Another place for useful basic information on diacritics is typo.cz, at least for European languages. Here's the page on the dot accent:

http://

You have all helped me complete a task that seemed challenging from the start.

Much appreciated.

This forum is indeed a great resource.

Again, many thanks to everyone.

If anyone is interested, I came across a fabulous list of 2, 3 and 4-letter most common word combinations that would be helpful to anyone wanting to build a stylistic set of alternate 'letter forms'.

http://www.math.toronto.edu/jjchew/scrabble/lists/common-234.html

Alex,

if you install the Fontographer 5 demo, in FontLab Studio you'll get several new encodings. In the "OpenType" group, there'll be "OpenType LatPro", which is an encoding encompassing 403 glyphs for all important pan-European Latin characters. There is also "OpenType LatPro SC", which adds small caps for all these characters, as well as various types of numerals and additional ligatures.

Both encodings use the newest glyph name conventions recommended by Adobe and FontLab.

Various folks' comments and questions:

> Put your {calt} feature code for things you don't want on by default in a stylistic set.

? That would be 'salt' instead. 'calt' is for contextual/connecting alternates.

Similarly, 'clig' is for contextual ligatures.

> As an aside, I wonder why Adobe 'broke' the ligature feature in InDesign when 'tracking' is implemented.

Because when the text is tracked too much, typically the ligatures tend to start looking as if they are spaced incorrectly. It was Eric Menninga's idea, but I supported it. I think I ran it by the rest of the type team at the time, but my memory is a bit fuzzy. This was no later than InDesign 2.0 around summer 2002.

> You can -minus tracking all you want and ligature(s) or substitutions remain intact,

Really? That is arguably a bug, but then again, when do you have minus tracking more than about -20 or so?

Regards,

T

@ Thomas Phinney

Thank you for clarifying the use for 'salt' vs. 'calt' tables. Good to know.

Your argument for the reasoning to 'break' the ligatures when plus tracking is valid. I understand.

Still, I and many others, I'm sure would have preferred to leave it the way it use to work.

Always best to let the user decide and adjust the parameters as needed.

Besides, that's why you can toggle ligatures 'on' or 'off', to allow users to decide if the ligature works correctly or not.

Wouldn't you agree?

And, if you are going to implement something then do it consistently.

Adobe Illustrator does not 'break' the ligatures.

And, QuarkXPress and other applications do not do this.

So why be different, if not better?

...when do you have minus tracking more than about -20 or so?

It's all the rage.

<< Put your {calt} feature code for things you don't want on by default in a stylistic set.

? That would be 'salt' instead. 'calt' is for contextual/connecting alternates.>>
Thomas,
This was in response to Alex's question, "Can this feature somehow be turned off as default. And allow user to 'toggle on' if desired."

When you make a connecting "f" that is only used when preceding an "l, b, k, etc" you are indeed connecting alternates, it is not a question of style. I was just trying to give Alex a workaround for ligatures using "fl"as an example.

Chris

Re Alex Kaczun's reply to Thomas Phinney on ligatures and tracking:

What I'd always thought would be nice would be if there was some sort of informational feature (sort of like the 'size' feature) which would allow the font to specify how much tracking various features (liga, dlig, calt, etc.) would tolerate since this varies considerably depending on the design. InDesign's +20 limit is likely not appropriate in all cases.

André

Alex: this list you pointed out contains common two, three, and four letter words -- not common combinations; these are known as "bigrams" (sometimes they are called "digraphs", but actually that's something else).

You need a substantial corpus to do the calculations yourself, but fortunately this is a popular area of research :-) (and I bet that's just because it can help in decrypting encoded messages!).

Wikipedia on Bigram shows a frequency list of the most common two or thee dozen bigrams.

@ agisaak—Yes, exactly. I agree. The original version of InDesign 2.0 did allow parameter settings to adjust tolerances when desired. I wish they would fix this and bring back that capability.

@Theunis de Jong—Thanks, I know the task is daunting, but I was finally able to put together a list of about 300-400 common letter combinations. I had to stop because it was giving me a headache. It will have to suffice. If someone else came up with their own list please share. Thanks.

Okay, I have one final question (I hope) on encodings. Everything everyone spoke about here was very helpful.

But, I still have a question about small capital accent encodings.

Can anyone sled any light on this topic as well.

Can I just name these glyphs 'Sacute.small'. 'Tcaron.small', etc., and have no encoding for these glyphs?

The Opentype table 'smcp' will transpose all the lower case (plus accents) to small caps (plus accents). Right?

Or, do I have to find encodings for all these small capital accented glyphs.

Please advise anyone. Thanks.

There are not separate encodings for smallcaps since they are not their own letter, just a form of the encoded glyphs that are associated with them via the opentype feature code and classes. I would name your smallcap glyphs the same as the glyph they refer to plus an extension as you have shown above. I personally use ".sc" because it is brief yet clear to me. This way, I can see many more glyphs in a string than if I use something longer like ".small"--that is just my preference.

I also use .sc for the same reason. And what dezcom described equally applies to petite caps, swashes, tabular figures or alternate design to given glyphs (if your font includes these sets).

Correspondence between small caps and "normal" glyphs is made just through classes and OT features (c2sc and smcp).

Be aware OT replaces glyphs according to its position in the class. So, your 15th glyph on a class will be replaced by the 15th glyph on the other class you are using –no matter if one is Eacute and other is Edieresis.sc.

This becomes important because there are glyphs without corresponding lowercase or uppercase (German long s, G inverted comma above, Ezsett, etc).

@ dezcom—Thanks, I will use your suggested extension. Makes sense.

@ Freiberger—I would really like to grasp what you are saying, exactly.
As long as I'm including all the glyphs associated in 'smcp' table, everything will convert okay (from lower case to small cps).

What is this position class replacement you are referring to?

Please elaborate. I really need to know if something might break in my font. Thanks.

Glyph order and total number of glyphs in all classes that may be substituted for eachother must match.

ChrisL

Oh, okay. That's what I was hoping to hear. Thanks.

Doesn't that go without saying... if you are going to include table transformations, then yes, this is essential.

I though I was missing something else in my general setup.

But, all is right with the Universe again :)

It's a small technicality, but the table is GSUB, and 'smcp' is a layout feature (subtable) in the GSUB table. 'smcp' is not a table of its own.

(Not sure it matters here, but sometimes it's important to know things like 'smcp' being part of the GSUB table....)

Cheers,

T

>>But, all is right with the Universe again<<

or did you mean "Univers" instead ;-)