Editing component(s) within component glyph (feature request)

Is there any chance to enhance the editor so one could edit the component(s) within actual glyph?

That will add a lot complexity (scaled, rotated). And it might be dangerous if you can change stuff everywhere.
Can you give a scenario where it would be useful.

That would be great: it is useful when you starting to make group of letters like /pdqb or /nhum. Looking at the bowl without the stem can be realy confusing. What so more it really can speed up workflow.

I think something like “unblock/block editing components” button should help with dangerous part of it.

I do not see the advantage over double clicking the component, as currently implemented. Much quicker and easier than activating and deactivating a lock.

1 Like

Most of my components overlap shapes in the glyph, so I have to look on the lonely bowl, which is very confusing and gives incomplete view. Now, to cope with this issue, during editing bowl I’m coping/pasting whole (for example) letter /b to the component. It is much much more slower and harder than activating and deactivating a lock.

Have you thought about editing the paths first , and then use Component from Selection?

I agree with you. I did not think so far. Separate editing definetly gives more control over a single component.
My concerns are more about “jumpy“ user experince: double click, component appears right, eyesight moves along, one loses focus a bit. One more double click by accident and one can get confused.
I came accros this idea during early pahases of type design, while tweaking non-exported components (e.g. _serif, _stem, etc), when editing component instantly breaks the word in two halves.
So it would be useful for this kind of components or those user can opt.

I have to say I agree with this @domenf and @RafalBuchner proposal. I use components a lot to construct my letters from individual parts (stems, archs, bars…). Editing separate arch without the context of the letter is strange (so I do the same workaround @RafalBuchner does). I agree that unlocking the components would be a fantastic edition to the workflow.

Other example: I like to edit diacritics in the context of letters. So everytime I design ogonek or cedilla, I add a temporary letter to see the accent together with the letter. Editing components in the same place as the original glyph would help me to be more efficient.

An idea: what if unlocking of the component for editing would lock the rest? Appart from editing the component per se, this would give users editing capability in the context of the letter: in the right position, mirroring or rotation.

Erich, your idea works well in the initial stage of the design. But it does not help at all in later stages of the process when anchors are set etc.

If wanting to see how editing the component affects composites, we can put the component and the composite side by side in the edit window. That way you can edit the bowl while simultaneously previewing bdpq next to it, so you can see the ‘context of the letter’. That also shows how it looks when flipped, and with the different stem treatments. What extra benefits would unlocking the component add?

What extra benefits would unlocking the component add?

few thinks:

  1. comfort: for me it is still very hard to edit not the same glyph that i’m thinking of, specially if it involves sophisticated inktraps etc
  2. I’m often editing letters in blocks of text like nnbnnooboo: of course during editing I’m looking at changes in spacing. If changes in component causes changes in spacing, then every additional glyph in edit view is very bad for testing.

I think that there are more examples, when opening new component glyph is (sorry for my language) real pain in the arse, but these two examples appeard just in last two-three minutes.

@Bendy, editing a component in the context is just faster. That’s all.

Of course I can display aogonek and eogonek letters next to my ogonekcomb. But it is not as convenient as to draw ogonek attached to the letter. So I temporarily add letter “a” to my ogonekcomb glyf while editing, but it means I don’t see the context then: “e” of the eogonek is covered by the temporary letter “a”.

And according to my quick experience with FL6, that’s one one the few features of FL6 I wish to have in Glyphs.

I see. It’s not something I’ve ever felt the need for, and I am used to working with a huge number of components in non-Latins. I personally don’t think I’d want to edit a live component in a composite unless I was sure I was considering all the other contexts and orientations of that component. But maybe it’s something that would become useful if the option was there.

The way it is described, it would be a separate Component Editor tool, which would also solve the lock/unlock problem.

But what I still don’t get is two things:

  1. the advantage over double clicking and editing the original next to the compound: If you do it with the current implementation, you have an immediate preview in the compound(s) next to it. Editing in place would mean that you would first have to insert compounds next to it for a preview, or hold down the space bar every once in a while to access the preview.
  2. How should scaled and rotated components be treated? And how should smart components be treated? I am afraid this is going to add enormous complexity, ie. more problems than it could solve.
  1. How should scaled and rotated components be treated? And how should smart components be treated? I am afraid this is going to add enormous complexity, ie. more problems than it could solve.

Damn, I never scaled or rotaded components. I only used smart components. Maybe problem should be solved not in letter-glyph but in component glyph? Something like “treat this component like letter: /user input/”. Ant then in the component glyph, in preview panel we can see shapes and spacing of choosen letter.

Or maybe it is stupid idea, I have to think about it. But the point is that I, as the user, think about feature like this a lot: coping/pasting caused me a lot of errors, corrections of these errors, additional work and pain :slight_smile:

I would need to look over your shoulders when you work, to see why you copy and paste so much. Perhaps then I can suggest a shortcut or a quicker approach etc., or I finally understand what this is all about :slight_smile: Contact me in a DM if you are interested and want to arrange a Skype session.


The easiest solution would be a reporter plugin that checks if a glyph is used as a component and draw the rest of the shapes in the background.


One less context switch and layer of indirection, thereby making the process less cumbersome. Avoiding the glyph of interest jumping to the next line because you happened to reach the editor width. Avoid having to zoom out to get the two or more components of the glyph on screen while you have reference glyphs around it.

I hit these issues all the time while working on the basic glyphs of my font and it regularly makes me think about not using components for basic glyphs.

Just like a scaled and rotated view on the component in its’ original grid, just with global side-effects.