Initial and Medial-Final Latin characters
Comments
-
The problem with using 'rlig' is that it, too, was originally created for arabic lamalef (لا), and not all applications support it for non-semitic scripts.0
-
Could rlig be made to solve Jacob's problem?
0 -
Peter Baker said:I do something like what Christian is suggesting with long s: have hist (and in my case also a Stylistic Set, since hist isn't available in Word) change all instances of s to long s, and then:
sub @LowerCase_f longs' by s ;<br>ignore sub longs' @AllLowerCaseExceptf ;<br>sub longs' by s ;
It's true that you no longer have the problem of an unwanted substitution at the beginning of a line, but you unfortunately have the inverse problem of an unwanted substitution at the end of a line (or run). I don't know what to do about this, aside from expecting users to tidy up manually.And then you've got the absolutely horrible problem of calt being off by default in MS Word and 90% of your users not knowing to turn it on. If your swash v is the default, most users are going to see only that.
(Sorry for drifting off topic.)0 -
It is possible, but you have to pick your time and place. I’ve chosen 18th century England on a couple of old-style types. I put it in a Stylistic Set, as <hist> is not supported. This seems to pass the “ſciſsors” test:
<div><span style="color: inherit; font-size: inherit; background-color: transparent; font-family: 'Alright Sans from Webtype', 'Lucida Sans Unicode', 'Lucida Sans', 'Lucida Grande';">sub s by longs;</span><br></div><div> sub [f f_f longs] longs' by s ; </div><div>sub longs' [f fi quotesingle hyphen quoteright] by s ;</div><div> ignore sub longs' @lowercase ; <span style="color: inherit; font-size: inherit; background-color: transparent; font-family: 'Alright Sans from Webtype', 'Lucida Sans Unicode', 'Lucida Sans', 'Lucida Grande';">sub longs' by s ;</span></div><div><br></div><div> lookup One {</div><div>sub s longs' by s ;</div><div>} One ;</div><div> lookup Two {</div><div>sub s' s by longs ;</div><div>} Two ;</div>
0 -
Yours is more thoughtful than mine, Nick.Craig: Users asked for it, so I tried to supply it. Problem is, the rules differ by period and country. I targeted 18th-c. English, but it's going to be wrong for, say, medieval Latin. I wonder if I should make it active only for English.0
-
My 'hist' feature is normally maximally simple (at least where s is concerned):
sub s' @lowercase by longs;
I figure that any contextual rule is going to get it wrong for some periods, so the user is likely going to have to tweak the results in some cases no matter what you do, so complicating things seems like a waste of time. (I always order my ligature features after 'hist' so those don't need to be dealt with here).1 -
Christian: Okay, I think I see where you’re coming from now. I’ll go through your answer step by step (and try to be more clear with my own too, sorry about that):(1) yes, swashless is default already and swashy is cycled in by CALT; that part we’re understanding in unison.
Current problem: ignore sub code rules “if there is a letter in the @allLatin class [A B C a b c, etc.] that comes before the swashless default, then it is to remain the swashless default.” The next line’s sub code says “cycle in swashy with CALT in place of the swashless default at any other time.”
Thus at the beginning of any line, word, or after a (same-line) hyphen a swashy gets cycled in to take the place of the swashless default.That is good in every situation except for when a new line begins after breaking in the middle of a word. That is the only instance at the beginning of a line where the swashless default needs to stay.Let’s use “anti-viral” (CALT changes swashless default to swashy) and “vivacious” (swashless default is kept) as examples of what should happen:anti-v(<-swashy)iralv(<-swashy)iv(<-swashless default)aciousanti-
v(<-swashy)iralvi-
v(<-swashless default)aciousWith the current code, both “-viral” and “-vacious” would be swashy through CALT, but we only want a “-viral” type situation to be swashy through CALT. Thus, I ended up using the shortcode “\v\” to manually return to the swashless default in instances like “-vacious.”(2) The solution, as I interpret your answer, is that there is another way to code it with the swashless still being default and swashy cycling in with CALT, as it does now, but in such a way that the “anti-viral,” “vivacious” type of problem is taken care of because the code wouldn’t allow for that problem to occur at all.If that is not what the solution is saying, that leads into what was my admittedly poorly explained concern in my previous comment: a lack of discrimination for contextually choosing swashy or swashless (as per the example of anti-viral and vivacious), for it is not just a matter of preceding letters, but of if the /v belongs to a word that was cut because of a line break or not.I have been testing variations of the code to replicate what your answer is, if different to my code and what Peter interpreted your answer to be. My trouble is in coding it to not care about line breaks and only the preceding letters and having the swashless default and cycled swashy, as you say, while satisfying all other conditions as explained above.If I’m still mistaken, let me know, this is turning out to be a greater learning experience than I expected! I hope I’m not a lost cause in understanding this.0
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 798 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports