Question about com.adobe.type.autohint in UFO about afdko HOT 22 CLOSED

Alternatively, to be compliant with plist XML, the structures could be converted to, I dare say it, superbly readable plist XML, which for the above example would be something like this:

<lib>
  <dict>
    <key>com.adobe.type.v2.autohint</key>
    <dict>
      <key>hintSetList</key>
      <array>
        <dict>
          <key>element</key>
          <string>hintset</string>
          <key>pointTag</key>
          <string>ab02</string>
          <key>elements</key>
          <array>
            <dict>
              <key>element</key>
              <string>hstem</string>
              <key>pos</key>
              <integer>-14</integer>
              <key>width</key>
              <integer>211</integer>
            </dict>
            <dict>
              <key>element</key>
              <string>hstem</string>
              <key>pos</key>
              <integer>455</integer>
              <key>width</key>
              <integer>180</integer>
            </dict>
            <dict>
              <key>element</key>
              <string>hstem</string>
              <key>pos</key>
              <integer>856</integer>
              <key>width</key>
              <integer>211</integer>
            </dict>
            <dict>
              <key>element</key>
              <string>vstem</string>
              <key>pos</key>
              <integer>74</integer>
              <key>width</key>
              <integer>336</integer>
            </dict>
            <dict>
              <key>element</key>
              <string>vstem</string>
              <key>pos</key>
              <integer>819</integer>
              <key>width</key>
              <integer>336</integer>
            </dict>
          </array>
        </dict>
        <dict>
          <key>element</key>
          <string>hintset</string>
          <key>pointTag</key>
          <string>hr02</string>
          <key>elements</key>
          <array>
            <dict>
              <key>element</key>
              <string>hstem</string>
              <key>pos</key>
              <integer>21</integer>
              <key>width</key>
              <integer>-21</integer>
            </dict>
            <dict>
              <key>element</key>
              <string>hstem</string>
              <key>pos</key>
              <integer>455</integer>
              <key>width</key>
              <integer>180</integer>
            </dict>
            <dict>
              <key>element</key>
              <string>hstem</string>
              <key>pos</key>
              <integer>739</integer>
              <key>width</key>
              <integer>328</integer>
            </dict>
            <dict>
              <key>element</key>
              <string>vstem</string>
              <key>pos</key>
              <integer>74</integer>
              <key>width</key>
              <integer>336</integer>
            </dict>
            <dict>
              <key>element</key>
              <string>vstem</string>
              <key>pos</key>
              <integer>850</integer>
              <key>width</key>
              <integer>305</integer>
            </dict>
          </array>
        </dict>
      </array>
    </dict>
  </dict>
</lib>

from afdko.

I really like this idea. This means that the generic plist parser will be able to read and write the extensions without knowing about them. I think that has been part of the design of both plist and glif.

from afdko.

I think the 2nd plist example is better as it is Human readable, a goal of
UFO. Not pretty but better than base 64 IMHO

I'm curious what practical issues Adobe folks have encountered with this
non spec compliant data

from afdko.

There have been no consequences in the Adobe Type Dept work flow. This is because the autohint and checkOutlines programs write the edited glyph data to a non-default glyph layer but still mark the UFO font as format 2. This means the entire layer is effectively private data, and is not seen by Robofont, and hence cannot cause problems. As soon Robofont can read ufo format 3, I will fix the hack of marking the font as format 2.

I strongly dislike the idea of using base64 encoding, as the whole point of formats like UFO is that it can be read end edited directly in a text editor. I like Adam's "superbly readable plist XML.". If no-one comes up something better, let's do that. I will do this eventually, which probably means in Feb. Anyone else is welcome to do it earlier in the AFDKO, and at any time in their own tools. I still expect more changes, as I am committed to supporting whatever the UFO format finally specifies as hint format.

from afdko.

cc @frank-trampe

from afdko.

which probably means in Feb.

Who knows, maybe @typesupply will have finished the official hints repr by then.

from afdko.

@readroberts any progress with the plist-compliant version of this? Seems like UFOv4 is still some time away.

from afdko.

Also looking forward to any progress on this issue.
I think the alternative Adam is proposing is very sensible: it seems best to avoid data.

from afdko.

The ball is more in my court than Read's at this point. It is on my list to standardize and backwards port it to UFO 3. The hint data will be stored in the lib under a public key, rather than being a full part of GLIF. I'm hoping to get to it in the next few weeks. (My day job is very busy right now.) For more info on why this isn't easy, there is a long discussion about TTF hints in my Robothon presentation from last week. It should be online in the future.

The discussion about this will all take place on the UFO Specification mailing list.

from afdko.

Looking forward to see this as official specification so that we can all easily align.

However I think adam's suggestion of XML plist compliant glif lib is good, although it may eventually be a bit space-consuming...

And since there is no standard Visual TrueType hinting, I think the definition of hint data stored in the UFO's lib.plist should be flexible and open, so that various types of visual commands could be stored there, including new ones that do not yet exist.

from afdko.

I am waiting on the new specification before I do any work on the FDK. I also like Adam's approach to making the data be plist compliant, but will be happy to follow whatever goes in the spec. The current Type1 hint is very much T1 specific - it would be good to have common syntax for the elements that are common between T1 and TT - there are some!

from afdko.

@readroberts @twardoch for the “superbly readable plist XML” … i came across the same problem without having watched this thread and ended up converting to a slightly different format:

  <key>com.fontfabrik.hintsets</key>
  <array>
    <dict>
      <key>pointTag</key>
      <string>hr00</string>
      <key>stems</key>
      <array>
        <string>hstem 0 -21</string>
        <string>hstem 350 26</string>
        <string>vstem3 46 40 188 40 330 40</string>
      </array>
    </dict>
  </array>

Since everything under elements or stems is postscript specific it doesn’t matter much code-wise whether all attributes are encoded verbosely in xml or simply written as a simple postscript-like string, and it makes for an even more human readable glif structure.

:-)

from afdko.

That's actually pretty good. Given it's under consideration to use VTTalk for storing high-level TT hinting — VTTalk would most likely look quite similar, since it's also "plain text", which can be logically converted into an array of strings, one per line. And TT assembly hinting also could follow this. Very good!

from afdko.

Thanks so much for support, but even in the postscript hintset case this is semantically incomplete: the given pointTag labels depend on contour order and their respective starting points.

When anything changes, the label will survive but the hint replacement will have to be regenerated, most likely resulting in different hint sets and pointTag labels to become valid again. And the information needed to do so isn’t encoded in the autohinter output. ‘Links’ would be more useful than raw hint positions and widths.

For higher level hinting commands as in VTTtalk we would like to see point tag references to source point indices and to target points that become touched (in horizontal or vertical direction), and the ascii strings that make up the actual command then need to be marked to make clear which arguments are indices… possible but not simple. And perhaps better suited to a less generic representation…

from afdko.

@readroberts is the new spec out?

from afdko.

I am going ahead and revising the AFDKO private T1 hint format to a plist-compatible format. I very much like the proposal above from nlsp on April 1st, and am pretty much adopting that. The first pass of this is now checked in under the AFDKO Open Source site, and full build will be coming to the Adobe download site in a week or two. As before, I consider this a temporary format, and will switch over to whatever the UFO spec developers work out, when that happens. The format is documented as hintFormat2 in FDK/Tools/SharedData/FDKScripts/ufoTools.py.

from afdko.

No complaints or comments in several months! Closing.

from afdko.

I just checked the Source Sans repo. It still uses the incompatible format. This leads to a lot of data loss if the file should be processed by a standard compiling parser, as it has to skip everything.

Can we just agree on a spec to store the PS hints as first class elements next to the contours in the glif? There we can use the syntax as is because it can be plain XML, without the requirements of plist.

from afdko.

yes please!

from afdko.

from afdko.

I wouldn't want to change the core GLIF structure. It means that changing the hinting would change the main structure of the GLIF, and would break compatibility. If we'd ever want GLIF2, then yeah, but then we should think about other things as well rather than just adding PS hints.

from afdko.

In the long run, I would much rather see a unified syntax for TrueType and PostScript hinting added to the GLIF spec, but I second Tal in that it is a lot of work, and I don't know how to do the unified syntax part - the formats are very different. For the short term, I strongly support Tal's proposal, and am happy to jump start this by submitting a PR for some documentation for public.postscript.hints. For the record I happened to have implemented a first pass implementation of this, but I don't consider it to be an Adobe spec - several people contributed to it, and this was after the AFDKO was OpenSource'd.

I just submitted PR #53 Add documentation for public.postscript.hints to unified-font-object/ufo-spec.

from afdko.