Which design works best?
I’m still undecided on how best to design ligatures. I have opted for a design that doesn’t alter the letter spacing. Here are some I designed for Verajja, my version of Bitstream Vera. The top row is plain text, the second row is Verajja ligatures, the third row is DejaVu ligatures. Which design do you like best?
Ligatures.png
I must be missing something, because I decided for which choice to vote yet cannot find out how to cast a vote.
Could you explain what one needs to do to vote please?
William Overington
You have to send some cookies to Erwin. 
When you click “View Results”, you are no longer able to vote. But when you open the topic again, you should be able to vote. Try this:
http://forum.high-logic.com:9080/t/design-of-common-ligatures/1313/1
Thank you both for replying.
I found that I could not find out how to cast a vote.
So, I posted a reply. The system asked me to log in. This I did, then I made my post. I then used the back button of the browser to go back to the index page and refreshed. I then clicked on this thread so as to check that my post had been accepted properly and the system then invited me to vote.
I suspect that one needs to be logged on when one accesses the thread in order to be offered the opportunity to vote. So, if someone is looking at the thread without being logged on, he or she may not be offered the chance to vote, which might well explain why the thread has so many views and only a few votes.
William
Mrs Eaves is an example of a font with some interesting ligatures.
I finally got back to reviewing this post and wondered how your lig spacing is going?
It would seem your guideline of not altering letter spacing clearly wasn’t used in the Mrs Eaves wonderful example. I think that would be preferable to trying to maintain word width as the gaps are very evident between the i and the n in some of the examples.
This is really a specialized font with nothing but unusual letter combinations, like TR, CC, THE (?), LA, VA and AV, etc. Must have been fun to put together and must be a challenge to use.
With a font like Mrs Eaves you definitely need Open Type features to use it. Although one might manage OK with Œ, it would be a pain inserting other ligatures from the Private Use area.
I have added a few more ligatures to my fonts: ft and st, and maintain the same spacing. I wrote macros for Open Office that makes inserting or removing them very quick.
I suspect that almost no-one uses them, but as a font design exercise it was interesting.
As I said a year ago, that seemed the promise of Open Type, which was supposed to be supported in Vista, particularly with regard to these auto-substitution ‘enhanced’ features. I don’t yet have Vista, so I don’t know.
But there is a need, perhaps, for an extensive range of special abbreviations and ligature pairs or triples (“ssi” in necessity, for ex). Here’s an example of a font I created with Font Creator in order to duplicate the text in a document from the 16th century. For example, the ‘long s’ has a form that cheats the next letter in close, but also that stands off against a tall letter. That’s two separate Unicode cells, neither of which are the letter, “s”. So throughout this text, the underlying ‘ASCII’ is filled with special Unicode callouts and other things in order to get the proper ‘slugs’ represented (it’s easy as I have almost all the special cells using either Shift or Ctrl and the numeric keypad as customized button pad (in a way like some CAD systems)). “S” is used at the end of words, but in two alternate forms. Some are Unicode standard, ct, etc. The ‘fi’ and so on. But some are ‘private area’ as well. If the underlying text read as one would expect, and all these special characters were added by the OS, it would certainly be better when it comes time to search text. As it is, I make this possible only by using a series of regexp substitutions and loading the plain text into a separate window.
Although one might manage OK with Œ, it would be a pain inserting other ligatures from the Private Use area.
Inserting other ligatures from the Private Use area does, however, in a way simulate the way that someone using a ligature in handsetting some metal type for letterpress printing in olden days would have needed to proceed. The need for a ligature would have needed to be realized and a piece of metal type for the ligature selected from the compartment in the type case which contained that sort.
Some are Unicode standard, ct, etc. The ‘fi’ and so on. But some are ‘private area’ as well.
There is no regular Unicode standard for a ct ligature glyph. Unicode does have code points for the following seven ligature glyphs, at U+FB00 to U+FB06 inclusive.
ff
fi
fl
ffi
ffl
long s t
st
Some years ago I suggested some Private Use Area glyphs for some other ligatures, one of which is a ct ligature.
http://www.users.globalnet.co.uk/~ngo/golden.htm
I have since started to make fonts and have included many of them in some of my fonts. I have also used a few other Private Use Area code points for ligature glyphs in a few of my fonts, such as Chronicle Text, Quest text, Sonnet to a Renaissance Lady and Herb Garden, all of which have threads in the Gallery section of this forum.
But there is a need, perhaps, for an extensive range of special abbreviations and ligature pairs or triples (“ssi” in necessity, for ex). Here’s an example of a font I created with Font Creator in order to duplicate the text in a document from the 16th century.
The golden ligatures colection includes such items as a long s long s i ligature glyph. In the golden ligatures collection, the long s long s i ligature glyph is at U+E757.
There is another system MUFI, the Medieval Unicode Font Initiative, which has Private Use Area codepoints for many items, including some ligatures.
In the http://www.mufi.info/specs/MUFI-Alphabetic-2-0.pdf document, at page 80, is LATIN SMALL LIGATURE LONG S LONG S I at U+EBA7.
I have just found LATIN SMALL LIGATURE CT at U+EEC5 in that document. The golden ligatures collection has a ct ligature at U+E707.
Could you possibly say please what mappings you used for the ct ligature and for the other ligatures that you used?
Having just found the ct ligature and various other ligatures which I have used in the MUFI document I am thinking that I should update my fonts so that the MUFI code points are used for the ligatures as well.
This matter of ligatures does get quite interesting as the official Unicode position is that no new code points will be encoded for ligatures, yet there is clearly a need to encode ligatures in plain text for use in systems which do not have OpenType capability to use ligatures in one of the Unicode ways: those ways being, using a ct ligature as an example, use ct in order to leave the matter to the font, use c ZWJ t in order to specify the use of a ligature (assuming that the font and application can together support that request), use c ZWNJ t in order to specify that a ligature should not be used (assuming that the font and application can together support that request).
The version 2.0 MUFI specifications, in pdf format, are available from the following web page.
http://www.mufi.info/specs/MUFI-Alphabetic-2-0.pdf
http://www.mufi.info/specs/MUFI-CodeChart-2-0.pdf
William Overington
28 April 2007
As you said, already:
FB00 LATIN SMALL LIGATURE FF
FB01 LATIN SMALL LIGATURE FI
FB02 LATIN SMALL LIGATURE FL
FB03 LATIN SMALL LIGATURE FFI
FB04 LATIN SMALL LIGATURE FFL
FB05 LATIN SMALL LIGATURE LONG S T
FB06 LATIN SMALL LIGATURE ST
0152 LATIN CAPITAL LIGATURE OE
0153 LATIN SMALL LIGATURE OE
017F LATIN SMALL LETTER LONG S
E259 LATIN CAPITAL LIGATURE OE WITH ACUTE
E25D LATIN CAPITAL LIGATURE OE WITH MACRON
E659 LATIN SMALL LIGATURE OE WITH ACUTE
E65D LATIN SMALL LIGATURE OE WITH MACRON
EBA1 LATIN SMALL LIGATURE LONG S H
EBA2 LATIN SMALL LIGATURE LONG S I
EBA3 LATIN SMALL LIGATURE LONG S L
EBA6 LATIN SMALL LIGATURE LONG S LONG S
EBA7 LATIN SMALL LIGATURE LONG S LONG S I
EBA8 LATIN SMALL LIGATURE LONG S LONG S L
EBC8 LATIN CAPITAL LIGATURE OE WITH DOUBLE ACUTE
EBC9 LATIN SMALL LIGATURE OE WITH DOUBLE ACUTE
EBE4 LATIN CAPITAL LIGATURE OO WITH DIAERESIS
EBE5 LATIN SMALL LIGATURE OO WITH DIAERESIS
EEC5 LATIN SMALL LIGATURE CTEECE LATIN SMALL LIGATURE FFT
EECF LATIN SMALL LIGATURE FFY
EFAD LATIN SMALL LIGATURE OC
EFE9 LATIN SMALL LIGATURE OO WITH ACUTE
F20A LATIN CAPITAL LIGATURE OO
These cover a lot. I left out the AE ligatures. And oddly, I’ve never seen an “fj”.
But you can see even in the short example that there is a ligature for “us”, and not shown for “es”, “as”, etc. in the italic. And the wide long S before a letter that is full height, like “h”, or “k”, “l”, etc, ‘stands off’, as opposed to when followed by “o”, “e”, etc. In my font, I didn’t attempt to duplicate these as separate ligatures, but rather used a wide long S for the one, and a narrow one for the other. There’s double-L (LC). There’s even a double s with a leading long s and a trailing, s. And I’m sure I’m leaving some out here, as well.
There are also any number of variations. The ending “s” in the italic is shown using two separate symbols. In the same font, their are different 'g’s, different 'z’s, and so on. Different cap “W”, and sometimes a larger LC “w”. Sometimes as leading caps, there are fancier versions. Now I guess these and other variations could all be included as separate fonts, rather than Unicode cells. But it might get confusing.
There’s also abbreviations and ligatures in old Greek texts, 100s I think, which I presume made it easier to quickly write the Greek by hand and was transferred to early print.
There’s another thing, too. Many of these ligatures, abbreviations and alternatives were dropped by many presses even by the 17th century. Some of the standard “fi”, “ff”, etc survive to this day. And there’s still quite a few. But many were dropped.
To answer one of your questions, no I didn’t use the same cells for many of these, except for the few called out at the FB block, at the top here, which you already mentioned.
Thank you for your reply.
At first, as I read through your post, I thought that you had used the MUFI recommendations in your font.
However, at the end you wrote “To answer one of your questions, no I didn’t use the same cells for many of these, except for the few called out at the FB block, at the top here, which you already mentioned.”, so it appears that you used some other codepoint allocations? Is that correct?
I have been thinking about these new MUFI recommendations in relation to my golden ligatures collections. MUFI has a different codepoint for a ct ligature. With long s ligatures, the golden ligatures collection has some which are in MUFI and some which are not in MUFI, and MUFI has some which golden ligatures does not have.
For example, the golden ligatures collection has a long s k ligature at U+E754, whereas, as far as I have found at present, MUFI does not have that ligature.
I am hoping to produce a version of my Chronicle Text font with those Private Use Area ligature glyphs and some others from the font that are included in MUFI also mapped to the MUFI recommendations. Also I am hoping to add into the font a few of the ligature glyphs which MUFI has which the golden ligatures collection does not have. As well as ligatures there are also a few other items to double map, such as the precomposed glyphs for M macron, m macron, N macron and n macron and some other ligatures such as pp.
I have come to the conclusion that a central issue is that, as at the present time, with OpenType support not in wide use, that entering transcripts using Private Use Area precomposed glyphs is a good idea, yet that a method is needed so that, in the future, transcriptions to regular Unicode can be made, preferably by an automated method.
There are issues such as how one would decompose a ct ligature. For example, is it as ct or is it as c ZWJ t because one did have a ligature in the first place?
I have been wondering whether those people who are interested could devise a coding, maybe in XML format, maybe in some other format, such that the meaning of Private Use Area ligature glyphs could be added into the font in the Description section of font, so that in the future the font file could, in principle, be accessed by a special purpose application program which could extract that information and use it for such purposes as producing an OpenType version of the font and for decomposing into regular Unicode any text which had been keyed using the font. For example, a text file containing a U+E707 character which had been keyed using my Chronicle Text font could be decomposed automatically by using information from the Description section of the font that U+E707 represents a ct ligature in that font. The coding would allow a default statement with a meaning such as “all Private Use Area encodings not specifically mentioned in the above list are those in the MUFI version 2.0 documentation” so that descriptions need not be included in each font. Thus if someone includes a ligature glyph not in MUFI version 2.0 in a font, the font could have the decomposition information available within the font in a format which some future automated system could understand. The coding system used would best be published and deposited somewhere.
Have you noticed the hypothetical ligatures which are in the Chronicle Text font? These are mapped to U+E716 to U+E71B. These are bi, di, hi, pi, pl, vi respectively.
http://forum.high-logic.com:9080/t/gutenberg-and-ligatures/1034/1
William Overington
29 April 2007
No, but it might make for a good standard. They do include a lot that I’ve never seen in old documents. But I’m sure they are found, maybe from German printers.
Since we have the seven at the start of FB, one can take those off the table. The ‘high Latin’ provides for the long S and both AE and OE small and cap. So those can go.
What remains? In my case, a cell is needed for the stand-off long S (your dupe in E7E0 Chronicle could serve that purpose, though you use the same right margin/right-bearing in each). I see that you have cells in Chronicle for long S B, etc. I thought, again, that simply having a stand-off long S and then a normal long S was a better solution. In yours you need various cells for the separate combinations, which you have in E7xx.
Missing, of course, are the rest of the long S ligatures and triples. While there is ffi, already, there is not yet long S fi, nor f long S i, etc.
MUFI has in EBAx long S h, long S i, long S l, long S S (though I’ve seen two variations on this), long S S i. Chronicle has these in various places in E7xx.
There is a need for ct. And the example font above suggests some might like an “it” ligature. Chronicle includes many variations on the fs or sf with a third letter. MUFI does not.
MUFI suggests quite a variation in old texts, many of which variations I have never seen. And those that I have seen and wished to duplicate were not part of MUFI, though many are included in your Chronicle.
Don’t the open type extensions that allow auto-substitution look to Unicode cells, anyway? I haven’t set up a font that way. So I don’t know.
I would think some kind of table would be needed, even duplicating any MUFI or other ‘standard’. People will surely have unexpected needs, and might need to put various symbols in private area which hadn’t been anticipated by others. But I thought the extended open type features were based on table lookup? If that’s not done, then one has to hardcode the Unicode right into the text.
Or are you suggesting that the Unicode be hardcoded in that way, but that table could be used by the app to somehow create a virtual text which is perfectly searchable? in addition to using perhaps another table for auto-substitution.
As I said before, what I do is rely on a particular ordering of regexp to run through the text and replace the Unicode with lower Latin letters. But I have to generate a separate document, which is then searchable.
There is a gap of 12 empty cells in Alphabetic Presentation Forms after ligature st from FB07 to FB12 — personally I think that is where they belong because that is what they are.
This is the reasoning as to why the golden ligatures collection starts at …7 in U+E707 rather than at …0 so that the golden ligatures collection follows on from the …0 to …6 of the U+FB00 to U+FB06 range.
This issue was discussed at length in the Unicode mailing list about five years ago. Unicode was at that time, and I have no reason to think that that has changed, strongly opposed to adding any more Alphabetic Presentation Forms for things like a ct ligature. It is something to do with the seven items in U+FB00 to U+FB06 only being included so that there can be round trip capability with one of the older character sets which Unicode replaced. It is also something to do with the concept that if new codes were added for ligatures then software packages would need to know how to decompose the ligature into its constituent unligated parts. In the end, the Unicode Technical Committee discussed it at one of their meetings and there was a minute which, as I seem to remember, all but totally closed the door on any more ligatures being given regular Unicode code points.
William
Actually, the golden ligatures collection runs from U+E707 to U+E7BF.
The character at U+E7E0 is one of the ligatures from my science fiction story scenario.
http://www.users.globalnet.co.uk/~ngo/ligscifi.htm
I am sorry if I have caused confusion.
The following web page introduces and indexes the golden ligatures collection.
http://www.users.globalnet.co.uk/~ngo/golden.htm
The following page adds some of the ligatures you mentioned.
http://www.users.globalnet.co.uk/~ngo/ligatur3.htm
In addition, I produced the following page: perhaps some of the code points might be the ones’s that you are seeking.
http://www.users.globalnet.co.uk/~ngo/ligatur4.htm
Your post has lots of other interesting items as well. I am hoping to reply more fully.
Hopefully these code points will be of interest.
William
It was previously suggested that the unassigned areas at the beginning of FB could also house ligatures.
I suggested using a wide long S instead of separate ligatures, for combinations of long S followed by letters with left ascenders. A table could be used to make the substitution of the symbol for the regular s, should the flow control find, sb, sf, etc.
‘high’ Latin: AE, OE, small and cap, and the normal long-S.
FB00 small double F
FB01 small FI
FB02 small FL
FB03 small FFI
FB04 small FFL
FB05 small LONG-S T
FB06 small ST
then
FB07 small CT
FB08 wide long-S
FB09 small double long-S (MUFI EBA6)
FB0A small long-S I (MUFI EBA2)
FB0B small long-S L (MUFI EBA3)
FB0C small long-S F
FB0D small double long-S I (MUFI EBA7)
FB0E small double long-S L (MUFI EBA8)
FB0F small double long-S F
FB10 small double long-S (alt version)
FB11 small long-S H (MUFI EBA1)
FB12 small long-S F I
Arabic might have E8xx in some fonts.
So E7xx might be safe. And that’s what you’ve used.
Much like the Greek and extended, at this point, one is left with a number of long-S/F or F/long-S combinations with one or more letters following. It could get tedious, and the particularly if one needs to have cells composited with ‘half-marks’, as in the Greek.
MUFI has the OE and OO with marks. AE must be somewhere. So those are ‘standard’.
I think the ones above capture most of the common ligatures. But again, if one has to spell out all the possible combinations, and then with marks, that could get tedious. But these might be useful:
small long-S F L
small long-S F F
small F long-S L
small F double long-S
small double long-S T
small I T
small A, E, I, O, U with script S (italic font)
They do include a lot that I’ve never seen in old documents. But I’m sure they are found, maybe from German printers.
I think that MUFI tries to include characters from manuscript documents as well as from printed sources. My golden ligatures collection was intended just for printed sources, in particular English 18th Century, so that the information of ligature usage could be conserved and displayed in transcripts using ordinary font technology.
What remains? In my case, a cell is needed for the stand-off long S …
I have not seen the term “stand-off long S” before.
MUFI suggests quite a variation in old texts, many of which variations I have never seen. And those that I have seen and wished to duplicate were not part of MUFI, though many are included in your Chronicle.
As for the rest, if you would like to state what they are, maybe we can work out some Private Use Area codes for them so that we are both using the same codes.
Don’t the open type extensions that allow auto-substitution look to Unicode cells, anyway? I haven’t set up a font that way. So I don’t know.
As I understand it, the answer is that usually no, but they can do. When you say Unicode cells, that is perhaps not the best way to think of it. Unicode has code points, font maps have cells, each cell contains a glyph, or maybe no glyph, such as the space and various specialist spacing characters.
In order for an application, such as a desktop publishing program, to use a TrueType font, a cell needs to be mapped to a Unicode code point. What you term is cell is often just called a glyph, though since you use the term cell, then upon thinking about it, I think that perhaps that is a better terminology as the cell contains a glyph.
With an OpenType font, in those parts where glyph substitution is used, the glyph does not need to be mapped to a Unicode code point as the glyph is selected using the glyph substitution rules which a font designer has added into the font. The glyph can be mapped to a Unicode code point if the font designer chooses to do so, usually a Private Use Area code point in practice, so that people using non-OpenType aware applications can access the glyph, perhaps to produce a display using a desktop publishing package: however, some people are against that practice: however, I happen to think that it is a good idea.
I would think some kind of table would be needed, even duplicating any MUFI or other ‘standard’.
Yes.
People will surely have unexpected needs, and might need to put various symbols in private area which hadn’t been anticipated by others.
Yes.
But I thought the extended open type features were based on table lookup?
Well, glyph substitution for ligatures is based on table lookup. Please note that that is done with glyph numbers not Unicode codes, presumably because all glyphs in a font have a glyph number yet all glyphs in a font need not be mapped to a Unicode code point.
If that’s not done, then one has to hardcode the Unicode right into the text.
If you mean hardcode the Private Use Area codes for the ligature glyphs into the text, then yes.
Or are you suggesting that the Unicode be hardcoded in that way, but that table could be used by the app to somehow create a virtual text which is perfectly searchable? in addition to using perhaps another table for auto-substitution.
I am not quite sure that I have understood what you mean here, but I think that the answer is probably no. However, you may have suggested a good idea here as an interim solution until OpenType becomes widely used.
As I said before, what I do is rely on a particular ordering of regexp to run through the text and replace the Unicode with lower Latin letters. But I have to generate a separate document, which is then searchable.
regexp?
What I was trying to suggest is that if someone is making a TrueType font with ligature glyphs in the Private Use Area, because he or she cannot, or does not in some situation, produce OpenType fonts then the TrueType font could contain notes, in some format which is both human readable and machine understandable, in the Description part of the TrueType font, so that at some later stage the font could, in principle, be converted to an OpenType font using an automated method.
William Overington
1 May 2007
I have now uploaded Chronicle Text M version 0.261 to the web.
http://www.users.globalnet.co.uk/~ngo/CHRONTXM.TTF
This is a special version of Chronicle Text 0.26 with the following changes.
Twelve ligature glyphs are mapped to the MUFI 2.0 recommendations and the original mappings removed. This was done by copying the original glyphs, adding the mappings then deleting the original glyphs together with their mappings. This resulted in the glyphs which are mapped using MUFI 2.0 being in code point order above the remaining glyphs which are mapped using the golden ligatures mappings. The MUFI 2.0 mapped items are as follows.
U+EBA1 LATIN SMALL LIGATURE LONG S H
U+EBA2 LATIN SMALL LIGATURE LONG S I
U+EBA3 LATIN SMALL LIGATURE LONG S L
U+EBA6 LATIN SMALL LIGATURE LONG S LONG S
U+EBA7 LATIN SMALL LIGATURE LONG S LONG S I
U+EBA8 LATIN SMALL LIGATURE LONG S LONG S L
U+EEC5 LATIN SMALL LIGATURE CT
U+EEC9 LATIN SMALL LIGATURE FJ
U+EECB LATIN SMALL LIGATURE FT
U+EECE LATIN SMALL LIGATURE FFT
U+EED1 LATIN SMALL LIGATURE GG
U+EED6 LATIN SMALL LIGATURE PP
The science fiction ligatures have been removed, as have the PUA copies of glyphs from the regular Unicode range above U+0100 which were originallyadded to facilitate copy and paste operations in some graphic making circumstances. Also the U+F001 and U+F002 mappings of fi and fl have been removed, the font repostscripted and the glyphs for fi and fl moved to be with the other ligature glyphs in the U+FB0. range.
I have changed the design of f and long s themselves so that a gap will show in ligaturable situations if a ligature glyph is not used. This is rather back to front of the way that metal ligatures were designed. In those cases the metal ligature was to avoid a clash with an overhanging part of an f or a long s. In this font the gap is used so that people can more easily tell that a ligature glyph is in use.
Thus the font has twelve ligature glyphs mapped according to MUFI 2.0 and many more mapped using mappings from the golden ligatures collection. There are several more glyphs that I may be able to move, such as tt and tz, yet I am wondering how to change the designs so that the use of a ligature is noticeable. Also, hopefully I can move M macron, m macron, N macron and n macron when I have studied MUFI 2.0 soem more. Also, I can hopefully add some of the MUFI glyphs which are not in the golden ligatures collection and not in the font at present.
Anyway, here is a black letter font with some MUFI 2.0 mappings for ligature glyphs, so hopefully it might be of interest.
William Overington
1 May 2007
Wide long-S. The small long-S H would use a stand-off long-S. A small long-S E would not. That’s all. In other words, one uses a different long-S, depending, instead of specifying composite-glyphs/cells for each possible ligature.
Again, I would assume it’s a table. That is, if “CT” is found, then the Unicode CT cell is associated with it in the table and that it what is displayed when the text is ‘flowed’. If a small “SS” were found, the table would point to the proper ligature. And in my case if small “SH” were found, it would point to two letters/glyphs, one for small wide long-S, and one for the small H. Of course, as I have seen alternate forms for “SS”, I don’t know how alternates would be triggered (perhaps by a tag juxataposed with the letter if one is using HMTL?).
Short of all that, when I said ‘hardcoded’, I meant that all the Unicode callouts are specified right in the HTML formatted text. That means the text can’t be searched, for all the embedded special characters. In my example, I also have an English translation that doesn’t use ligatures. But for some of the still standard ligatures, I would rather than it did.
Instead, as a workaround or hack, I use a series of regular expressions (regexp, or regex) to filter the HTML formatted text to remove all of the hardcoded ligatures, placing the result in a new page/window so that it might be searched. So in the example I showed, previously, the filtered resulted would show “CT” instead of the “CT” ligature.
But again, I’d just as soon that the filtered result, itself, retain a few ligatures because these simply look better. With open type extensions this would be possible. Without it, even a few hardcoded ligatures would make the document unsearchable, unless the search phrase itself included the Unicode codes.
The ‘character’ is the one thing, and its mapping particularly to a Unicode value is another. I didn’t mean to be confusing, if I was, previously.
In other words, just explain the idiosyncratic mapping, as a sort of essay embedded in the font, so that conversion to some future standard, as yet unknown, might be made easier? Wouldn’t that information be self-evident to someone using a program like Font Creator?
You’ve made changes. What do you think of the extra ‘FBxx’ glyphs suggested previously. Those are some very common ligatures.
If one could take those off the table, it leaves, as suggested before:
small long-S F L (E793)
small long-S F F (don’t know if this is needed)
small F long-S L
small F double long-S
small double long-S T (E75C)
small I T
small A, E, I, O, U with script S (italic font)
You include, in addition
small double long-F T (EECE)
But then you have a requirement for the others, as well.
What about (you can see the ‘script’ S in the word, Catechumenus, in the previous example - and IT was suggested by the other previous example in the thread):
EEE0 small long-S F L (E793)
EEF1 small F long-S L
EEF2 small F double long-S
EEF3 small double long-S T (E75C)
EEF4 small double long-F T (EECE)
EEF5 small I T
EEF6 small A small script S (italic font)
EEF7 small E small script S (italic font)
EEF8 small I small script S (italic font)
EEF9 small O small script S (italic font)
EEFA small U small script S (italic font)
I mentioned that there are alternatives, as often found in Greek ligatures and abbreviations. Perhaps alternatives would not merit a Unicode composite, but would simply be an alternative font, or just the bold version of the font, etc. So instead of worrying about an alternate long-S, one just has the long-S, and that’s it, and no A script small S, etc, either (though I think this latter might benefit from having it specified in Unicode)?
I could give an example, as well, of some of the greek abbreviations and ligatures I selected, from among MANY, which I placed in 3A5x, 3A8x, and 501x:
As I mentioned in another thread, the grayscale works very well, even in small size fonts. However, it does require that Font Smoothing be enabled in Windows. If it isn’t, the font looks awful. I wouldn’t mind having the option to hint in Font Creator. It’s been suggested, before.
