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.

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

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

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.

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.

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

Would you like new ligatures for +20 tracking?

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.

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

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}

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

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.

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.

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

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

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.

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.

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

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

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

or did you mean "Univers" instead ;-)