Component compatibility

In some cases, it’s super helpful that Glyphs considers differing components to be incompatible. For example, most often you would want to be warned that somehow a /breve-cy got put into your bold master where the others have /brevecomb (which might be rather hard to see).

But in other, admittedly rarer cases, differing components are intended. I have a pixel font that has some masters putting different pixel components in corresponding places. In this case the differing pixels are all point-compatible themselves. It would be handy here if compatibility indicators were triggered not by differing components, but only by differing components that are incompatible.

Not sure what a per-font setting interface would be to have that, but I thought I’d throw it out there as something I’d find useful.

What do you try to achieve with this setup?

Imagine a pixel font with say 3 x 8 components for a capital I

OOO
OOO
OOO
OOO
OOO
OOO
OOO
OOO

In the Regular master, all the pixels are the same little circle component. But maybe in the Gradation master, each horizontal row uses a successively lighter component from the one below. And in the Outline master, the 6 middle pixels surrounded by others are components with smaller paths.

Admittedly this is a very specialized situation. But more broadly it feels to me like interpolating between different but compatible components shouldn’t be a problem.

It is a performance and update problem.

You could implement this with one smart component.

1 Like

Ah, okay, so the pixels will not be calling for differing components, but for the same component at differing smart settings? I can work on a script to try out that conversion. (Will that change help with my crazy-long export times?)

I would solve this with a single master.

  • Static fonts: you can have various alternate pixels and swap them in with a Rename glyphs parameter in Font Info > Exports.
  • Variable fonts: you can add one or more virtual masters, and add the corresponding brace layers only on the pixel glyph.

That way you do not need to manage compatibility issues at all.

1 Like

:exploding_head: I’ll play with that.
Could I keep both export strategies in the same Glyphs file?

Rainer’s suggestion might not work for your setup as it expects all pixels to be the same per glyph. And especially the “slightly heavier per row” cries for a smart component (as you don’t need a new component for each row).

About the crazy export time: do you have activated autohinting? (Don’t do that). If it is still slow, can you send me the file?

1 Like

Sent.

Can number value tokens be used to set Smart Component settings? (Putting them in the dialog doesn’t seem to be working; maybe by scripting?) Using per-master variables there would be a huge advantage for this.

Working on a script to swap out the differing component refs for the same component with different values.
When iterating through the old components, thus

component.name = "_part.smartPixel"
sizeToAssign = sizeMin + ((shade-1)*(sizeRange/6))
component.smartComponentValues['size'] = sizeToAssign

I’m finding the components succesfully switch to the new reference, but the size assigning is not working (all are set at their axis minimums).

(I tried component.setPieceValue_forKey_(sizeToAssign, ‘size’) too based on this thread but that didn’t work either.)

Do I need to “convert” the existing component to smartness somehow? Do I need to delete the old and create a new one?

EDIT:

Simply this

myLayers = Glyphs.font.selectedLayers
for layer in myLayers:
	newComponent = GSComponent("_part.smartPixel",(0,0))
	newComponent.smartComponentValues['size'] = 70
	layer.components.append(newComponent)
	print(newComponent.smartComponentValues)

gets me the new component, and prints that its “size” value is 70, but in the edit window the new component is set at its minimum values.

Your code works for me. You need to make sure you use the right key. There is a property name and an Id. On a newly created smart glyph, the IDs are UUIDs (long random strings). When you save, close and re-open the file the property name and the axisId is set to the same value.

You can check the axisId like this,

Layer.components.append(newComponent)
print(newComponent.component.smartComponentAxes[0].axisId())
1 Like

Okay thanks. This now works.

    component.name = "_part.smartPixel"
    sizeAxis = component.component.smartComponentAxes[0].axisId()
	sizeToAssign = sizeMin + ((shade-1)*(sizeRange/6))
    component.smartComponentValues[sizeAxis] = sizeToAssign

Don’t quite get the “component.component” part. (This is all within a “for component in layer.components” loop.)

This gives you the glyph object that then component is pointing at.

1 Like

Another idea about long export times:

  • disable overlap removal as long as you’re testing)
  • disable subroutinization (for CFF exports, needs a parameter)

I’ve been testing with ttf variable fonts, so neither of those would be applicable, right?

Yes, they are only for static or CFF exports.