Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Adam Twardoch


Adam Twardoch
Last Active
  • Re: FontLab Studio and High Sierra

    Microsoft has a much better record than Apple in catering for users and developers of software in professional markets, including custom-developed software or software that costs several times more than the hardware it runs on. 

    I have both native and virtualized Windows environments and they allow me to easily run apps from the last three decades, including apps from defunct vendors.

    Type design and font development tools are a good example here: I occasionally use pieces of old but still useful software on old Windows, all working fine. On the Mac, I cannot say it's possible. 

    macOS is a fine OS to work on in terms of UI and graphics, but when it comes to stability for developers, it's terrible.

    Every few years Apple changes all of its toolchain, removes things that were previously working fine and forces thousands of developers to rewrite large portions of software from scratch. 

    This does have the "nice" side-effect that developers may charge users upgrade prices because the older versions of their apps stop working on newer macOS, so users come running. On the other hand, on Windows, apps may run forever so users may not be "pressured" into upgrading so easily. 

    The additional problem with Apple is that they tend to be very secretive, so as a  developer, getting detailed information about why something is not working isn't easy. Microsoft always has been more relaxed and cooperative with software vendors. 

    As for exit strategies — I might agree that using cross-platform apps which you can run on more than one OS is indeed a decent contingency plan. Using software that is heavily tied into just one software (and hardware) platform always poses a certain risk.  
  • Re: Public domain pros and cons

    Ray, that sounds like a healthy conclusion. :) 

    One thing that we hadn't mentioned here is multiple licensing: much software (e.g. the FreeType rasterizer) is released under dual licenses, while some fonts are released under multiple licenses. 

    It is possible to release a font under two concurrent licenses, e.g. "OFL and CC0" or "MIT and OFL", or even "OFL and commercial EULA". 

    With multi-licensed software, the user can choose which license is more suitable to their needs and use just that one.

    The tricky thing is that if they modify/extend your font, they math release the changes under just one license, or several. So with a "CC0 and OFL" licensed font, another user could add some glyphs, and release there modified version under "OFL", "OFL and CC0", "just CC0" and, since CC0 is de facto public domain, also under any other license, commercial or opensource, or a combination of licenses. 

    The "OFL and CC0" combo may not be very suitable for your project, but I'm mentioning this mechanism for the sake of completeness. Sometimes, multi-licensing is useful, especially when creating code or fonts which is of interest for various communities, each of them being invested into a particular license or licensing model (e.g. one group wants copyleft code like GPL or OFL, another wants a liberal license like BSD, MIT, Apache 2 or CC0). 
  • Re: Public domain pros and cons


    "copyleft licenses" and "public domain" are pretty much the opposites of each other. If I base my work on a work that has been published under a copyleft license, I must publish my work under the same license. Since OFL is a copyleft license, and it prohibits selling derivative fonts, if I publish my font under OFL, I publish my font “for free” but I also force anybody who’d want to reuse even a few glyphs from my font in their font to also publish their font for free. In other words, other people are prohibited from selling things based on my thing, if I publish it under OFL. 

    That may or may not be want you want as an author. An OFL license is very restrictive in the sense that only the original copyright holder is allowed to sell the fonts, but those who add to the fonts or change something are not. If the original designer passes away or goes AWOL, that “monoply” to make money through sales (and possibly find financing for further improvement) may “freeze” for some 70 or 90 years. 

    “Public domain” (or CC0) is very  different. It's right for you if you, as the original author, are not interested at all in restricting what other people may do with your work. If a font is CC0, others can extend it or modify it or reuse portions of it, and be free to do whatever they want with the results (sell, publish for free, under whatever license etc.). 

    In other words, with copyleft licenses like OFL, you as the original author retain much control over what others may do with your fonts, while with “copynull” licenses like CC0 (public domain) you relinquish all control. 

  • Re: Font Convertor

    for pyftfeatfreeze, I specifically made the search-replace function to work on substrings so spaces can be taken out of the equation. For example, the full name may be "Lato Pro Bold" and the PS namy may be "LatoPro-Bold". I could specify -R 'Lato Pro/Otal Com,LatoPro/OtalCom' but perhaps it's better to just do -R 'Lato/Otal' or -R 'Lato/LatoCust'.

    Beware of situations like, in the above case, -R 'Lato/Lato Cust'. This will inadvertently insert a space into the PS name (so it'll become "Lato CustPro-Bold" which is invalid. (I'll probably fix that so spaces are always removed when needed). 

    But there is a special -S -U 'Cust' method that appends a suffix. That one is done intelligently i.e. the suffix may contain spaces and they will be stripped off when needed. You can use -S -U together with -R. 
  • Re: What is i.latnTRK

    Yes, the point of this is: in most Latin-script languages we have the lowercase-to-uppercase conversion:
    i -> I

    But in Turkish, we have (actually more logical):
    i -> İ
    ı -> I

    In Turkish, the letter "i" represents a vowel similar to English "ee" in "been" or English "y" in "belly" or English "ie" in "fierce". That vowel in Polish is represented by "i".

    The Turkish letter "ı" represents a vowel similar to English "i" in "bin" or "lift", which in Polish is written as "y".

    And Turkish "y" represents a consonant like "y" in English "you" or "boy", in Polish written using "j".

    In English, the distinction between the "ee", "i" and "y" sounds is a bit unclear but in Turkish (or Polish) it's very distinct orthographically.

    Because in Turkish, you have separate case conversions (i -> İ, ı -> I) which are different from other languages, and case conversion also applies to the smcp feature, and because the visual distinction between i and ı should be maintained even in ligatures, and some designers tend to blur this distinction in f_i ligatures by folding or merging the dot, this is how you'd deal with it in an OT font.

    1. You make an i.TRK glyph which is identical to i but it'll be treated differently in subsequent features.

    2. You have a special languagesystem latn TRK in which you only perform one substitution: i -> i.TRK in the "locl" feature

    3. From now on, you know that in the Turkish context, one of two glyphs will appear: i.TRK (with a dot) or dotlessi (without a dot).

    4. In features such as liga, you can safely do things like f i -> f_i and you don't need to think about special lookups for "ligatures with an i" and ligatures "without an i".

    5. Similarly, in the smcp feature, you can safely do i -> (dot vanishes), i.TRK -> (dot stays), dotlessi -> (not dot at all).

    For most languages, the dotted i's uppercase or smallcaps counterpart is a dotless I but for Turkish, the dot needs to stay. So without i.TRK, you'd need special treatment whenever "i" is involved in a feature.

    With "i.TRK", you disambiguate the normal "i" and the Turkish "i" early (locl is among the first features to be processed), and all your subsequent features can be written in a simple way.

    Of course i.TRK is not always required. If your font doesn't have small-caps and your f_i ligatures are drawn so that the dot over the i is fully visible (because you shorten the f's tail rather than elongate it), you shouldn't have a TRK languagesystem or i.TRK.

    f_i ligatures can be used in Turkish but only if those ligatures don't blur the visual distinction between the dotted and the dotless i in such a ligature.