When an Arabic ligature is generated, it automatically spaces the glyph as it treats Latin ligatures. In other words, it assumes that the combined glyphs go from left to right while they actually go from right to left. In the snapshot I uploaded, for example, the letter “yeh-ar.fina” takes the side-bearing of “teh-ar.medi” and vice versa. This obviously takes a great effort to fix manually with each ligature.
What you see on the screenshot is only the placeholder glyph that is shown when the glyph has no outline. Add components and it will position them and adjust the spacing just fine.
Thank you for the quick response!
It worked exactly as you said. Strangely, it didn’t always worked liked this for me. The problem is that I already fixed all my glyphs so I don’t have a proof anymore 
I might bug you with this later though when I have more details 
Thanks again
Georg, I think I just recognised the real extension of the issue.
The problem appears in ligatures like “sad-yehHamzaabove” (as in many other cases). The spacing of the glyph is correct as long as I have the default components applied. The problem is that the orthographic result that glyph offers by simply applying components is not the best. This requires creating a new component that better represents the ligature and can be applied in other related ones. When the default components are replaced with the alternative one, the issue appears as the default spacing applies a flipped side-bearings. The attached screenshot demonstrates what actually happens (top are default components with correct default spacing and non-satisfactory orthography. bottom is new orthographically correct alternative that causes the spacing to be messed up).
I hope this makes sense!
You disabled the automatic alignment (the metrics values doesn’t say ‘auto’ any more). Then the metics keys are applied but those are incorrectly set. so make sure that the spacing in the `sad_yeh-ar’ glyph is set correctly, you have defines anchors (‘top_1’ and ‘top_2’) and that you enable automatic alignment. If you then select the hamza, you can select to what anchor it should attache when clicking on the anchor symbol in the grey info box.
Thanks again Georg.
My last question is hopefully simple. I have (top_1 and top_2) anchors but I also have other anchors (top_dot_1, bottom_dot_1, and bottom_dot_2). (I needed those to set a different height for vocalisation marks than dots). Could these be a reason that is ruining the automatic alignment?
I just saw that I missed answering that.
The second set of anchors should not cause a problem per se. I could imagine that the underscore in the name is a problem. I would try to use a different naming scheme.
And a suggestion. I saw a file with anchors like this. In most cases the top and top_dot anchors where on the sane horizontal position, just on different hights with the top a similar distance in most glyphs. You could simplify the setup quite a bit by changing the anchor position in the marks and dots. Put the top (in the base glyph) at the edge of the outline (and not 80 units above). Then move the _top anchor in the mark down by 80 units. The top_dot anchor was maybe 20 units above the glyph. By moving the _top_dot anchor down 20 units (and rename it to _top) you can use the same anchor. only if you really need an horizontal difference, then you an use a top.dot anchor and select it from the anchor button in the components info box. That defines the distance of the mark/dop only in the mark/dot itself instead of setting it in every base glyph.
Thank you Georg. It’s thoughtful from you to get back to this!
Your tip on anchors positioning also sounds useful. I’ll try these soon. Thanks again