Initial and Medial-Final Latin characters



  • 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.
  • Peter BakerPeter Baker Posts: 101
    Could rlig be made to solve Jacob's problem?
  • Craig EliasonCraig Eliason Posts: 1,129
    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.

    Aren't the rules for long/short s so complicated that a font shouldn't be trying to make that call?
    (Sorry for drifting off topic.)
  • Nick ShinnNick Shinn Posts: 1,712
    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>
  • Peter BakerPeter Baker Posts: 101
    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.
  • 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).
  • Jacob CasalJacob Casal Posts: 99
    edited May 2019
    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:
    v(<-swashy)iv(<-swashless default)acious
    v(<-swashless default)acious
    With 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. :)
Sign In or Register to comment.