Add U+F000 pixels/em hint indicator to Regular/Italic/Bold/BoldItalic variants

[Paul Sladen]

The pixels per em 7-segment readout driven by the hint engine at U+F000 ('') is only present in the Regular from the DejaVu Sans font.

Ideally it, or an equivalent should be added to all variants to aid effective debugging; either coding from scratch, or using the DejaVu code if the licensing terms converge.

Update: we have permission (Thank you) from the original author of the DejaVu code for the debug glyph to use it in the Ubuntu Font Family, but it's waiting only legal discussions at the Canonical end (as current copyright holders) on how to incorporate the contribution in a non-exclusive way.

Ben Laenen's implementation works by executing MPPEM and then moving the nodes/segments that are /not/ needed for that size to the left-hand edge using ALIGNRP. See bytecode documentation at:

  http://developer.apple.com/fonts/TTRefMan/RM05/Chap5.html#MPPEM

The DejaVu implementation can be found with:

  apt-get source ttf-dejavu
  ttf-dejavu-2.30/src/DejaVuSans.sfd (search for 'uniF000')

note that this should not be incorporated until we've worked out the legal boilerplate to make this happen.

[Malcolm Wooden (malcolm-daltonmaag)]

This may be referring to an unhinted beta version of the font. Seperation is there.

[Malcolm Wooden (malcolm-daltonmaag)]

Wrong reply!

[Paul Sladen (sladen)]

Currently we're relying on the substitution mechanism to bring in the pixels-per-em indicator from Deja.

[Paul Sladen (sladen)]

Malcolm and I had a quick brainstorm at how to do this on Tuesday 2010-11-16, thus the reckoning:

The key is to move the nodes for each component of the glyph to all be in the same position, the easiest way of doing this is to multiple the x and y coordinates by zero so that they all end up at the same position in the corner/edge creating a zero-width line and thus "disappearing". It needs to be possible to distinguish the four states:

  (a) Manual hints no used, this will be the default rendering of the glyph)
  (b) Manual hints in use (size readout, preferably human readable)
  (c) Manual hints in use (size bigger than read-out).

Each of these must be visually distinguishable from each other. We know from relying on the DejaVu substitution (a) is shown by "88", that "01"? to "87" was PPM sizes from the hint engine and that (c) is rendered as "HI".

[Ben Laenen (benlaenen)]

Since I created these glyphs, you're free to copy them, as they belong to the public domain part of DejaVu. You can also just copy the hinting instructions because they don't use anything font specific.

btw, there is a difference between U+F000 and U+F001: the first one will give you the horizontal ppem, and the second one the vertical ppem (or the other way around, I forgot). So in some subpixel rendering engines, U+F000 will be U+F001 times 3. But they will usually give the same number.

How it technically works: the glyphs are made of two times seven segments, and each segment is a simple rectangle. The instructions ask for the ppem. And then with some small calculations to get both digits (after a check to check whether the number is less than 88) and an IF instruction for each number that each digit can represent, it does an ALIGNRP to the left phantom point (i.e. the left boundary of the glyph) for each segment that's not needed for that number. Since these unneeded glyphs will then be zero-width "lines", they become invisible.

So to get these in the Ubuntu font: just copy the outlines from DejaVu (you may have to adjust the metrics, but it doesn't matter, you only have to keep the point numbers at the same locations to make it easy for the hinting instructions). Then just copy the instructions as well, which should be very easy, but I don't know how VTT works here :-)

[Ben Laenen (benlaenen)]

typo:
"Since these unneeded glyphs will then be zero-width "lines", they become invisible."
should be
"Since these unneeded segments will then be zero-width "lines", they become invisible."

[Paul Sladen (sladen)]

Good catch Ben, unfortunately as it is a bug comment I can't go and edit the original, but your explanation will hopefully serve as a reminder!

[Paul Sladen (sladen)]

A further conversation with Ben noted that if the present MPPEM (measure pixels-per-em) in the code is replaced by MPS (measure point size) it will be possible to derive the dpi setting the user is running at aswell.

[Paul Sladen (sladen)]

Note: that the version included in 0.70 is a from-scratch rewrite by Dalton Maag and not based on Ben's pragmatic code or implementation (although Ben definitely gets credit for the inspiration). The current solution is effectively using a large table of delta exceptions, which only exist for the range 9–69 ppem, meaning that it is not possible to differentiate between >=69 ppem and having the hint engine disabled. If this proves a problem we can probably look into using a more pragmatic method later.

High-level GUI source can be found with:

  strings -a sources/VTT/Ubuntu-*-hinting.ttf | grep -A10 0xf000

[Paul Sladen (sladen)]

A debug symbol created using delta-overrides got shipped in the base four.