Howdy, Stranger!

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

Peter Constable


Peter Constable
Last Active
  • Re: [OTVar] Next step for variable fonts: process for registering design variation axes

    Kashida glyph insertion can only work if there is a completely-flat stroke to be elongated. That's a significant constraint.
  • Re: [OTVar] Emotional Type/ Sharing technique for interpolating between angular to cursive masters

    Hi, @Promphan Suksumek. Interesting project, and nice to see OT1.8 variable fonts being used.

    One comment about the variation implementation: you have used the 'wght' axis with values from -1000 to +1000. You should change to a custom axis tag, such as 'EMOT'. There are two problems with using 'wght' as you have: the valid numeric range for the 'wght' axis is 1 to 1000, and the variation in your font is not weight! See Registered design-variation axis tag: 'wght' for a description of the 'wght' axis. A custom axis tag can be anything you choose so long as it uses uppercase letters (details on syntax here).
  • Re: Is there a way to create a font that uses the two Shift keys differently?

    To provide a more detail beyond what Simon said (a bit technical, but useful to understand): 

    Digital text has an encoded form, which almost ubiquitously is Unicode. This assigns a numeric encoding for every character of every writing system, and that is how characters are stored in a computer or transmitted between computers. For example, the numeric value 65 (in Unicode hex notation, U+0041) is used as the encoded representation for Latin capital letter "A"; the value 3,627 (U+0E2B) is used to represent Thai letter ha "ห", etc.

    Everything that happens when entering, processing, or displaying text is done in terms of the encoded representation inside the computer. When you press a key on a keyboard and see something display on the screen, there is not a direct connection from keyboard to font. Rather there are two sequential interactions: the keypress results in generating the encoded representation stored in the computer, then a separate process takes that encoded representation and displays it on the screen using a font.

    The important point here is that there is no direct connection between a shift key or any other key and a font. The effect of pressing keys is to generate Unicode encoded sequences stored in the computer, and what the effect is of any key depends entirely on the programming of a keyboard input method. In principle, a keyboard input method can be created to allow two shift keys to behave differently in terms of the encoded sequences that get generated, but that is not common. On the other hand, it is not uncommon for the right Alt key on a PC to have different effects than the left Alt key.

    When creating a font, you generally should not be thinking about keying sequences that produce different visual results. Rather, you should think in terms of Unicode character sequences, and creating a font that will produce a display of text that reflects the Unicode-defined semantics of the encoded characters. Then, if you need a particular keying experience, there would be an independent exercise of creating an input method that produces a Unicode character sequence from the desired keypress sequences.

    If you create a font that produces some custom association between keystrokes and display, then most likely what you will have done is to create a font that assigns glyphs to Unicode encoding in a misaligned way, so that the font does not match the underlying Unicode semantics of the data. That will make the font and the data produce unusable by anyone except if displayed by that font.

    Back in 2001, I wrote a chapter in a book explaining these concepts; it's available online here:

    In section 4, I gave an example of how this approach leads to data that works with the specific font but doesn't get along with anything else, which can lead to unexpected and undesired results.

    Hope that's not way too long to be helpful.
  • Re: Proposal for font distribution/installation app

    Great! Android now has a “downloadablefonts API” :) 
    As has Windows 10 had.

    Dave's links to the font-resource and fonts-in-xml pages mention use of a font within the app package. That's been supported in Windows app packages since Windows 8. The main difference is that Android allows you to designate font files as a distinct "font" resource type, whereas in Windows they are just binary file assets. (They can be embedded into the package resource index (.pri) file rather than loose.)

    Downloadable font support is new in the latest Android release. We had support for downloading fonts from a Windows library in the first Windows 10 release, and added support for downloading fonts from any cloud font service in the Windows 10 Creators Update (spring 2017).

    The interesting things that Android has done are (i) to be able to incorporate a downloadable font in an app by making a declaration in the app manifest, and (ii) explicit handling of certs.
  • Re: Are we heading towards a "VariableFontCloud"?

    See the Typo Labs presentation by Akiem Helmling and Bas Jocobs, starting around 17:00 to 20:40.