Howdy, Stranger!

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

Peter Constable

About

Username
Peter Constable
Joined
Visits
561
Last Active
Roles
Member
Points
159
Posts
147
  • Re: FontLab VI now shipping

    @Thomas Phinney : OK, I can't resist the pun:

    "FontLab VI, our ultra bold font editor"

    But what if I want to design other weights?

    ;-)

    Congratulations to everyone at FontLab on this important and exciting milestone!
  • 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:

    http://scripts.sil.org/cms/scripts/page.php?item_id=IWS-Chapter03

    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: [OTVar] Next step for variable fonts: process for registering design variation axes

    And now a third proposal, this also from Renzhi: for a PPEM axis. See the proposal details here:
    https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/tree/master/Proposals/PPEM_Axis

    This proposed axis would be pretty different from the kinds of axes (registered or otherwise) than we've seen before, so it will deserve careful consideration and good discussion.
  • 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.

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

    I'd add to what Dave said: 

    Software that supports variable fonts is likely to support whatever axes are in a given font, custom or registered, in terms of exposing in UI and ability to select and use variants. 

    But software is not going to know what a custom axis is doing, and so cannot do anything with it beyond allowing manual selection of an axis value by the author. Even if two fonts have custom axes using the same axis tag, software can't assume there is any connection between them, so if you switch from one to another any setting for custom axes will likely be cleared and need to be redone.