Using the "space" in OT features substitutions

PabloImpallari
PabloImpallari Posts: 806
edited July 2013 in Technique and Theory
The /space glyph can be used in OT code in the same way as any other glyph, and it works well inside apps like Illustrator.

Fonts like Underware Liza relies on /space(*) to apply many of their tricks.
* http://underware.nl/case-studies/random-vs-clever/

And many fonts have kerning pairs like T/space or f/space, etc...

But sadly, on the web, everything related to the /space is ignored (OT features, kerning, etc).
Any idea way? or a workaround?
Are the browsers silently replacing the /space by other glyph?

Comments

  • Mostafa Hajizadeh
    Mostafa Hajizadeh Posts: 35
    Different browsers have different engines for text. In which one you found the problem?
  • PabloImpallari
    PabloImpallari Posts: 806
    Firefox and Chrome, on Mac
  • James Puckett
    James Puckett Posts: 1,995
    File bug reports and let the browser programmers know they need to fix this.
  • Nick Shinn
    Nick Shinn Posts: 2,210
    edited July 2013
    One “workaround” useful for many OT features is the ignore coding, which is actually more efficient than using the space character. Are you familiar with that Pablo?
  • PabloImpallari
    PabloImpallari Posts: 806
    edited July 2013
    Yep, I've used ignore for the final forms in Lobster's lowercase. Also for initial and medial forms in other unreleased projects.

    This time I was trying to apply some magic to a whole sentence, instead of just isolated words. But can't do so without the space. It will work in illustrator, but not on the web... :( c'est la vie
  • Adam Twardoch
    Adam Twardoch Posts: 515
    Some applications do not use the "space" glyph to render the word space. They use the width of the "space" glyph for the default width of the word space, but may use a different width, especially when doing full justification. In other words, some apps compose text as separate glyph "clusters", one per word, and just use whitespace (and not the "space" glyph) to set them apart. In such apps, the "space" glyph may not partake in the OT Layout process. One example of such app is XeTeX, the opensource typesetting system. But there are some others as well.
  • PabloImpallari
    PabloImpallari Posts: 806
    edited July 2013
    Thanks Adam, that's interesting.

    As a quick test:
    - Added a small box inside /space, and a big box inside /space.calt
    - Inside 'liga', added: sub @lower space' @lower by space.calt;

    Illustrator is showing the /space.calt big box as expected.

    Both Firefox and Chome are drawing the /space small box, but ignoring the sub
    They seem to be rendering the /space glyph contents, but still ignoring kerning and features.
  • Thomas Phinney
    Thomas Phinney Posts: 2,890
    There are even other Adobe text engines (such as in Flash) that ignore the space and anything the other side of a word break.

    But the Firefox and Chrome problem is a bummer for advanced web typography, for sure.
  • PabloImpallari
    PabloImpallari Posts: 806
    James suggestion of filling a bug report seems the right thing to do.
    But I would not know how to properly describe the issue.
    Perhaps some of you, more experienced, might want to do it?
  • John Hudson
    John Hudson Posts: 3,206
    Since this is something that affects more than one browser, I'll bring this thread to the attention of John Daggett, editor of the W3C CCS Fonts spec.
  • Deleted Account
    Deleted Account Posts: 739
    Worse than no features could happen to some features this way. I think we need the use of some word space-related features to depend on the relationship of the space glyph, (the idealized thing upon which some features are based) vs, the word space (the actual space in which the feature must be presented), or some poor glyph in a narrow column is going to get a lobster in its pants, or worser, as I said.
  • John Hudson
    John Hudson Posts: 3,206
    True enough, but that implies something beyond OpenType Layout features, since these are pretty much tied via their architecture to glyph processing. It would help if there were, at least, a standard model for handling word spacing in software, whether this involved always using a (stretchable) space glyph or always a non-glyph distance. That way, at least we'd have a notional target for a layout mechanism, and could start thinking about ways to vary glyph behaviour relative to word spacing of different widths.
  • Deleted Account
    Deleted Account Posts: 739
    Beyond OT perhaps, but sadly.... still within the bounds of traditional typography. No other glyph in the font changes size at a different rate from the other glyphs. As such, the space glyph opens the window to an existing universe of size-related features we all know is there from history, right next to size-related masters. :)

  • John Hudson
    John Hudson Posts: 3,206
    So we're clear, what sort of space-related features are you thinking about? Yes, spacing is variable relative to justification, and that does suggest to me that kerning between the space and adjacent letters should be proportional to the space width rather than an absolute value. What else?
  • Deleted Account
    Deleted Account Posts: 739
    edited July 2013
    All spacing is variable relative to justification, so all kerning should be proportionally resized in justification, yes.

    But remember, we are working in a handicapped environment — to apps and OS, there are only two kinds of font spacing: monospaced and proportional. All styles that are proportionally spaced, according to apps and OS, are equally adept at tracking, kerning and justification, or not being tracked, kerned or justified? So is each glyph equally adept at tracking, kerning, justification and substitution as these things mix.. at all sizes? It is ridiculous, I think.

    If we just had recommendations of some kind...;)










  • John Hudson
    John Hudson Posts: 3,206
    All spacing is variable relative to justification
    Not the way I do it. :)

Categories