Can UFO-specific extension settings be stored in a property list (.plist) file, in the UFO?

StephenNixon

Scenario: an extension that provides glyph-specific visualizations to assist drawing. These visualizations can be offset in different ways, specific to the glyph.

Need: a way to store these UFO-specific, glyph-specific settings.

Goal: avoid storing data in .glif files themselves, as this could mess with the clarity of version control history (e.g. changing the extension visualization would appear as a change to the glyph, when it is merely a layer of additional information.

Rough plan: I think that a new .plist file can be created and inserted into a UFO, in order to store information such as this. This would be distinct from storing extension-specific preferences because the offset values wouldn't be globally applicable.

Question: Is it true that one could make a .plist file and store data within it? E.g. could I make viz_settings.plist and store a dictionary of glyphs & their offset settings within it? I'm having a hard time finding documentation of this type of thing, but I wouldn't want to mess with it if it is somehow a bad idea.

Thanks for any insights!

StephenNixon

@gferreira

Awesome, thanks for making it so clear! Okay, yes, this is very easy to work with, now.

gferreira

@StephenNixon if you wish to create your own .plist files, you can do it using the plistlib:

import plistlib

# write to .plist file

myCustomData = {
    'A' : 100,
    'B' : True,
    'C' : 'hamburgefons',
    'D' : [10, 20, 30, 50],
}

plistPath = 'myFolder/test.plist'

with open(plistPath, 'wb') as f: 
    plistlib.dump(myCustomData, f)

# read from .plist file

with open(plistPath, 'rb') as f: 
    myData = plistlib.load(f)

print(myData)

StephenNixon

(FontParts issue added at https://github.com/robotools/fontParts/issues/439)

StephenNixon

I don't think Glyph.lib is the best idea, because it adds data to the glyph that isn't really relevant to the actual history of that glyph – it's only a visualization, and not (in my mind) pertinent to the development history of a particular glyph. In particular, I don't want a change to the visualization to be indicated as a change to the glyph, in a project's commit history.

However, font.lib might be better. I think that probably, font.data is the most appealing solution, but still relatively unclear on how to use. But, it's probably the kind of thing that will be clearer with experimentation. Probably, it would be simpler if added to FontParts.

tal

To add another bit of implementation detail to Frederik's response... You can access the data directory abstractly through the font.data attribute of the defcon font object. (Get to this with font.naked() This will return the DataSet object that you can put/pull raw data into/from. I don't think this is wrapped by fontParts yet. It's probably worth opening an issue on the fontParts project about this.

frederik

yes, there are even multiple options!

the lib: font.lib and glyph.lib with reversed domain lib key, a lib can handle numbers, strings, lists and dicts.

if you have more complex data to store you can also use the data folder.

SOLVED Can UFO-specific extension settings be stored in a property list (.plist) file, in the UFO?