Howdy, Stranger!

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

Best Of

  • Re: Small caps as a variable font axis in Glyphs?

    Building on what Dave said, we added a y transparent uppercase axis to Amstelvar, meaning, the caps have full adjustability of height down to the lower case x height, with another axis that extends the cap height almost to the bottom of the em.

    Combined with Full adjustability to the width, weight, and contrast, this y transparent axis gives us the ability to define instances within the space that fulfill the design requirements for all the features of a stylistic instance that contain uppercase congruent contours.

    Small caps do not have to be done this way, someone else can just make an axis where weight height contrast and width does everything from caps to small caps in one axis. But blended and combined from these other axes, y transparent u.c. enables the blending and instancing of not only features, but for instances to use with other scripts, with the Latin being the modified script.

    We did is this to demonstrate our interest, and the interest of others as was expressed in Berlin, to better use all that design space, and hopefully to get beyond what Adam points out where the OS have the runs. Registering axes where instances represent change to a glyph's opentype feature, or change to a Unicode glyph ID, is what we are proposing to use.

    Amstelvar demonstrates feature axis with "magic figures" and with the uppercase I described above, and now that the phases of the moon are Unicode, Zycon has demonstrated the changes to the unicode along an axis for darn near 25 years.

  • Re: Article on typography & culture wars

    Typography is far more politically charged than even most type designers want to admit.
  • Re: LibreOffice 5.3.0 adds OpenType Layout feature support

    It is the same syntax used by hb-view, but separated by ampersand instead of comma:

    $ hb-view --help-features
      hb-view [OPTION?] [FONT-FILE] [TEXT]

    Features options:
      --features=list                       Comma-separated list of font features

        Features can be enabled or disabled, either globally or limited to
        specific character ranges.  The format for specifying feature settings
        follows.  All valid CSS font-feature-settings values other than 'normal'
        and 'inherited' are also accepted, though, not documented below.

        The range indices refer to the positions between Unicode characters,
        unless the --utf8-clusters is provided, in which case range indices
        refer to UTF-8 byte indices. The position before the first character
        is always 0.

        The format is Python-esque.  Here is how it all works:

          Syntax:       Value:    Start:    End:

        Setting value:
          "kern"        1         0         ?         # Turn feature on
          "+kern"       1         0         ?         # Turn feature on
          "-kern"       0         0         ?         # Turn feature off
          "kern=0"      0         0         ?         # Turn feature off
          "kern=1"      1         0         ?         # Turn feature on
          "aalt=2"      2         0         ?         # Choose 2nd alternate

        Setting index:
          "kern[]"      1         0         ?         # Turn feature on
          "kern[:]"     1         0         ?         # Turn feature on
          "kern[5:]"    1         5         ?         # Turn feature on, partial
          "kern[:5]"    1         0         5         # Turn feature on, partial
          "kern[3:5]"   1         3         5         # Turn feature on, range
          "kern[3]"     1         3         3+1       # Turn feature on, single char

        Mixing it all:

          "aalt[3:5]=2" 2         3         5         # Turn 2nd alternate on for range

  • Re: Article on typography & culture wars

    Nothing is beyond weaponizing, as clickbait writers battle for shares.

    But the metaphor of war is nothing new.

    My favourite is “charm offensive” (1956).

  • Re: LibreOffice 5.3.0 adds OpenType Layout feature support

    This is very unobvious for software developers who use existing text layout libraries to solve.

    Their code needs to itemize the text into runs which have the same font, size, script, language system and direction. Then, they query a text engine using a series of Unicodes, the script+languagesystem+direction and receive back a series of glyph IDs and their positions.

    Optionally, the software developer can specify the user-selectable features to be enabled or disabled, but not all layout engines have a mechanism to specify those features for only specific characters.  

    So in many cases, a change in the set of user-selected features constitutes a run break, i.e. a change not only of the font but also a text color or a set of features is treated the same as change of the font. 

    This is an aspect that has never been overly-well defined and described by the spec (in fact, the entire process of text layout hasn't). 

    Even if a layout engine has an API that allows specifying user-selected features on a sub-run level (e.g. using a list-like syntax such as LibreOffice and hb-view do it), it’s still not entirely obvious how those should behave. For example, if I have a word “astra”, and enable a contextual feature only on the 2nd and 3rd character (“st”) and that contextual feature includes lookups that analyze preceding and following context, should the entire word (and beyond) be used for the context matching even though the actual substitutions only apply to the glyphs representing the “st” string?

    Or what should happen if I have the word “AVANT” and specify "kern[2]", i.e. that kerning should only be “applied to the 2nd character” (i.e. “V”)? Kerning on which side? 

    IMO, one conceptual weakness that the current OpenType Layout model has is that the substitutions and positioning steps are typically mushed together in one step, although in fact, they are very very different in their nature. 

    For GSUB processing, you generally need run itemization, because each script-specific  shaping engine does its special thing behind the scenes, automatically applying certain simple GSUB features at certain locations that would otherwise need to be defined as complicated contextual features. For that, the notion of script, languagesystem and directionality is useful. 

    But once all the characters have been converted to glyph IDs, and all the special GSUB pro creating has been done, we arrive at a simple series of glyphIDs laid out horizontally or vertically (not even in any “direction”, really). 

    At this point we enter the GPOS processing where, in reality, script, languagesystem and directionality shouldn’t really matter at all. We have some boxes and we just need to shift them around, depending on what they are and what are their surroundings. 

    The current GPOS model isn't really good for it, it has tons of shortcomings. It disallows positioning across scripts, it makes 2D positioning tedious, so it ends up using different methods for different kinds of positioning: horizontal, verticsl, cursive, math etc. And even defining these relationships is tedious. 

    At this year's TYPO Labs, the panel discussion on liberating digital type design from the metal rectangle spent some time on this: 

    I think we should think of this more and propose much better solutions. The GSUB stuff, especially with USE, is probably pretty decent. But we probably should start thinking about an "UPOS" (Universal Positioning) concept that would redo the way the typographic pieces are positioned in the canvas, in a much more flexible way. 

    This wouldn't necessarily mean a complete change of the paradigm — existing Unicode processing and script-specific, contextual and user-selectable GSUB processing would probably be kept. But once that is done, and the layout engine arrives at collections of typographic pieces to be arranged, instead of using the short-sighted GPOS, a more flexible solution could be used. 

    This could take into account things that happen across text lines, across different fonts, between the same font but at different sizes, across different instsnces of a variable font etc. 

    Maybe it would have a way to “re-run” some substitutions (e.g. try different ones from a GSUB Type 3 lookup) to arrive at a result that produces least clashes or best merges. 

    Either way — I don't think any short-term fix will be much good. The positioning aspect of text layout needs to be revamped comprehensively. 

  • Article on typography & culture wars

    This post is more like @Dave Crossland 's posting, but one has got to do something different once in a while. :smile: happy reading.
  • Re: Why FontCreator hardly used by professionals?

    Sorry Frank, but you cannot legitimately claim the title of the only "obviously not-considered-to-be major/active developer" doing so. My Type 3.2 font editor is also cross platform (actively developed, but not-considered-to-be-major). 
  • Re: LibreOffice 5.3.0 adds OpenType Layout feature support

    The Typography toolbar is developed in association with, the Hungarian free software foundation. These are the people behind Hunspell, the spellchecking and hyphenation opensource engine that is today the de facto standard among many vendors (used by macOS and by Adobe apps). 

    Here is a presentation that Laszlo have 6 years ago about typography support in LO:

    With native OTL support in LO, those efforts could be revived because now it's not just about 1-2 fonts but a vast universe of fonts. 
  • Re: LibreOffice 5.3.0 adds OpenType Layout feature support

    Both Firefox and Chrome (and also XeTeX) suffer from the same issue. When I reported this for Firefox it wasn’t considered a bug. In Scribus I made sure we handle this correctly, but basically everything else in Scribus is broken and it does not allow any arbitrary font feature yet (the underlying format though allow for any feature, so probably one can write an script to provide such a functionality).