Robofab margins and component behaviour in Fontlab
Andres Torresi
Posts: 23
After setting a new sidebearing (left of right) for an accent with Robofab (tildecomb, for example) the component change alignment in other glyphs (ntilde, Ntilde, atilde, etc), as the attached image shows.
The code is very simple.
f=CurrentFont()
g=CurrentGlyph()
g.leftMargin=0
f.update()
This doesn't happen changing width attribute, but it does changing leftMargin or rightMargin.
Any ideas why this is happening?
The code is very simple.
f=CurrentFont()
g=CurrentGlyph()
g.leftMargin=0
f.update()
This doesn't happen changing width attribute, but it does changing leftMargin or rightMargin.
Any ideas why this is happening?
Tagged:
0
Comments
-
Note: It doesn't happen with changing width attribute.0
-
The position of a component in a composited glyph is relative to the position of the original reference glyph, which is in turn relative to the origin (0, 0).
If you shift the position of an accent glyph outline relative to its origin, then that shift will be reflected by all components that reference that glyph.
Changing leftMargin shifts the position relative to the origin. Changing rightMargin without a corresponding change to the width shifts the position relative to the origin. Changing the width itself alone does not change the position relative to the origin.
If you’re going to script adjustments to sidebearings of accents that are referenced by components, then you need to include a routine to loop through your glyphs and check for any components with the relevant baseGlyph attribute and adjust its offset by a corresponding amount.
But if you’re using combining [zero-width] accents and you don’t want the components moving in your composited glyphs then why are you repositioning the accent outlines themselves in the first place?1 -
Thanks Kent.
Changing baseglyph or accent sidebearings will alter composite.
I'm working on a spacing script and I want to run it after the composites were creat Eric Van Blockland wrote me in the discussion group:'The left margin does not exist independently of the glyph contours. By setting the leftMargin to 0 you really move the outlines in tildecomb to the left until the leftmost point in the leftmost contour hits the x=0. This move then shows up in all glyphs that have a component referencing tildecomb.'
This doesn't happen when you move sidebearing manually in Fontlab (dragging them in glyph window or entering new values).
So I'm trying to figure out how to change a component sidebearing from a script without alter his related composites.
I think the routine checking baseGlyphs with component offset is the best approach now.
But maybe anyone knows a different way to do this (maybe using FL python reference directly, instead of Robofab).0 -
Because if all this hassle Glyphs.app uses anchors to automatically align the accents all the time.0
-
This doesn't happen when you move sidebearing manually in Fontlab (dragging them in glyph window or entering new values).
Depending upon the action, FontLab usually keeps track behind the scenes and retains the component position independently. (I seem to recall there are some adjustments that FL doesn’t keep track of — like if you do the repositioning directly in the glyph edit window instead of the metrics view. Or vice versa. Maybe an older version.)
But basically, FL is just doing behind the scenes what I suggested above — it’s adjusting the offset of any instance of a component that references the glyph in question to compensate for the move. If you check the offsets of a component in a composite, then make an adjustment to the accent glyph, then go back and look again at the offsets, you’ll see that they changed accordingly.
That’s basically the only way I see around this, within the context of your script.
But if you’re using zero-width combining accents for all your composites and you follow the approach of having these basically centered in relation to the zero point, then you shouldn’t need to have them adjusted by a spacing script; you could just have the script ignore the zero-width glyphs.
0 -
Georg: That feature is amazing. But my problem with Glyphs is I'm not good coding at it. I tried to use Robofab with no exit. I really tried to program something or translate some of my scripts with no luck. I had no problem with Robofont, it's easier for me.
Probably I need to spend much more time reading the documentation.0 -
If you have any problem with scripts in Glyphs feel free to as on the Glyphs forum or write me directly. Glyphs does support roboFab if you install the wrapper from github.com/schriftgestalt/Glyphs-Scripts.
And the functionality you try to solve with this script is already build in (Filters > Transformations > Metrics).0 -
There is a small problem this the robofab wrapper as Glyphs can have more then one master and Robofab not. So I need to map that. This is not always successful.0
-
Thanks Georg!0
Categories
- All Categories
- 40 Introductions
- 3.7K Typeface Design
- 793 Font Technology
- 1K Technique and Theory
- 608 Type Business
- 443 Type Design Critiques
- 535 Type Design Software
- 30 Punchcutting
- 135 Lettering and Calligraphy
- 82 Technique and Theory
- 53 Lettering Critiques
- 478 Typography
- 300 History of Typography
- 113 Education
- 65 Resources
- 491 Announcements
- 78 Events
- 105 Job Postings
- 148 Type Releases
- 159 Miscellaneous News
- 268 About TypeDrawers
- 53 TypeDrawers Announcements
- 115 Suggestions and Bug Reports