MikeW wrote: ↑
Wed Sep 20, 2017 10:08 pm
General historical info regarding medial s. The rules for a medial s changed depending on what country and/or region of a country its usage is, and what period that usage is too. As the above font is French in design and was first used in the early 1800s in France (designed in the 1790s or so), I used those rules.
Well, to some extent the rules for longs are really quite simple -- as a basic start, and which many early printers followed, every lowercase "s" would be typeset as a longs, unless it was the last letter in the word.
That's the basic
rule -- but then there are certain exceptions that were made (such as some, even many, printers keeping a regular "s" if it was adjacent to a "b" or "k," in particular, and sometimes other letters as well). I did a sort of neo-facsimile ebook version of the First Folio edition of several Shakespeare plays, using an old-style font (not by me) embedded into the book, and in typesetting that I essentially followed the rules of the printer of that First Folio. If for whatever reason you're curious about that, and have an IOS device, you can get it on iTunes here (it's free)...
https://itunes.apple.com/us/book/shakes ... 1169487691
Back to the discussion at hand, this link here is a great overview of all the other various "rules" which one can find in relation to use of the longs, such as what you mentioned regarding punctuation, etc....
http://babelstone.blogspot.ca/2006/06/r ... ong-s.html
And for type designers, if you want to REALLY get nit-picky with your detail, this here is worth a look (along with the scans/images included there via links)...
The author of this latter is talking about his research into old gravestones, but it does provide some interesting food for thought for type designers, too.
How about last first? Triple medial s.
French rules (and in England during certain periods) dictate that a triple medial s has the "regular" s used in the middle location.
Do you have a reference for that, that that was a "rule" (whether in France or anywhere else)? I've never seen that -- although I just searched through the digitized period texts that I've worked on in the past (and am working on now) and can't find a single instance of triple-longs, so I can't come up with an example to look at. If you ask me, though, it just looks weird to have alternating longs with a regular "s" (i.e. "ſsſ"), to me it would look better -- and to my understanding and knowledge of the use of longs, historically -- as simply a triple-longs ("ſſſ").
Of course, the instances of that occurring are very rare -- but to me, it really
stands out, I noticed that immediately with your typesetting of "crossstitch."
And before a hyphen. And ... As far as I can do, the font follows the rules. There is one rule that I am not taking the time to resolve, and that is if an abbreviation ends with a period, the medial s is used. That can be seen in my screen shot. But I can resolve that with scripting in ID & QXP, so I don't care at this point. Maybe one day...
Of course, re hyphens and abbreviations. If there's a period, or hyphen, or whatever else, it's not about whether the word is an abbreviation or not, but the rule is about "where does that bunch of letters end" -- then it's a regular "s."
Chaining context lookups. There are a couple threads here. I can look later for one or more of them.
That would be great! Although I'm not sure if I'm going to "go there" now (see below), but I am sure that it's just a matter of time before I'll want to, so any links you might have would be of great help (now or later).
The u/v characters. Yep, it could be possible to do those according to rules as well. I just don't know what they are and hasn't applied to the above font so haven't looked them up. The substitution happens as one types, like ligatures, if the feature is turned on in a paragraph style.
Oh, that should be very easy for you to implement, actually -- if you've managed to do those longs substitutions, as you already have, then getting the "u" and "v" characters right should be a breeze.
The rule is very simple: any and every case of either "u" or "v" (lowercase) is typeset as a "u," unless it's the first letter in the word, then it's a "v."
And yes, that sounds totally wack-o, seems to make no sense at all (and certainly makes early texts that much more difficult to decipher at times -- for example, the medical/anatomical term "uvula" would be typeset as "vuula") -- but there is
actually a logical explanation for why that was done.
Prior to printing with moveable type, books in Europe were all written in Latin. In Latin, there is actually no "v" character, what we think of as "v" was actually pronounced like a "u" -- or sort-of like a "w." You know that famous phrase "veni vidi vici"? In real
Latin, as it originally was spoken, you don't pronounce the opening letters like a "v" but rather like a "w" -- it's actually pronounced "weni widi wici."
And that's how the use of "u" and "v" came about -- it was a stylistic thing, back when books were written (and copied) by scribes. The letter "v" -- as we know it and pronounce it in English (etc.) -- just simply didn't exist in classical Latin.
And, thus, when books began to be printed in English and other languages, that typesetting rule was just a carry-over from those earlier days.
And this is also why we refer to the letter "w" as "double-yoo" and not "double-vee," of course.
Oh, and as far as uppercase "U" and "V" goes, that was always
typeset as "V" (regardless of where it appears in the word) -- and very often one will also see uppercase "W" typeset as a double-"V" ("VV").
OK. Chaining context lookups can be daunting, especially at first. The order of the rules and lookups can have unexpected results. So it can take a little bit of time to get how one envisions and interprets the rules to work properly. And do note that some applications "break down" before they fully process rules in certain OT Features. So, for instance, QXP cannot currently process the medial s rules no matter how they are written. ID can, dunno about Word, Affinity Designer now can. In instances where there is willingness on the part of application designers, one can work with them to properly support the features. It's why InDesign & AD can properly process the features they do. Quark is working on it, and they have improved their feature support and processing, but there are core issues preventing accomplishment at this time.
Oh, in that case maybe I won't bother with chaining. Not merely because it's "daunting" to learn -- and that's bad enough! I've had a hard enough time working on this first "serious" font of mine as it is!
-- but if it's not commonly supported and can actually cause things to "crash" (so to speak) at times, well, it's probably not worth it for me to get into right now.
As it is, for the texts that I've done using these these old-style fonts, I've basically just typeset all my longs characters wherever they should be such (along with "u" and "v" as they should be, too). I'm pretty used to doing that -- despite it being somewhat of a pain to do so "manually," of course -- but the advantage of that is that if a person switches out the font the document is displaying in (as anyone can easily do with an ebook, for example, which has been my target platform in recent years) then at least the "spelling" of words will still be correct.
I originally did the font for typesetting a series of journals. Now that that is done, I am extending the fonts to include Cyrillic (80% done) and Greek (50% done). Once the regular style is finished, those additions and the OT Feature coding changes need rolled into the bold & corresponding italics as well.
Cool. You're definitely way ahead of me with all this stuff, but I guess the end conclusion, as far as my delving into chaining, etc. for my font, is that I'm probably better off leaving well enough alone for now.
Thanks very much for your replies here, Mike! You've most certainly piqued my interest and curiosity about some things here, even if I am going to just backburner it all for now.
(Thanks, too, to PJMiller for your reply -- not much to add here in response to that, I suppose, that hasn't already been discussed above!)