does anyone know of a way to change a selection of metric widths simultaneously? eg. in a monospace design, change all examples of width 483 to 484. I can’t do it with find/replace, or so it seems
You can use scripting from the Macro Panel to make such adjustments.
For example, change the width of all layers with a width of 483 to 484 like so:
for glyph in Font.glyphs:
for layer in glyph.layers:
if layer.width == 483:
layer.width = 484
thank you
You can also select glyphs in the font view and use the info box in the lower left to change the spacing.
thank you
Hello, this script is very useful.
I have one more question. The script currently modifies values by adding or subtracting from the right side. If I want to perform additions or subtractions from the center, how can I adjust this script?
You need to change the script to do half of the adjustment to the left and half to the width/rsb.
Is there a way to do this with evenly added space, without having to use a script?
I can’t think of any context where it would be useful to set any number of glyphs to a specific width by extending (or reducing) the glyph width to the right, but there are several cases where doing so by extending (or reducing) the glyph width from the centre is useful: monospaced fonts and when creating tabular numbers from regular numerals.
To my mind, the centre point makes the most sense as the default behaviour when using the info box to set the glyph width – or even better, if it could use the selected point of origin in the Transformations panel.
(Edit: If all the glyphs you want to resize have the same width to begin with, you can use Transform Metrics in relative mode and then add/subtract half of the difference between the original width and the desired width to the LSB and RSB – but that won’t work if the glyphs have different original widths, of course.)
I don’t understand. Are you trying to add a specific amount of spacing to the left and right for a number of glyphs? You can do this with Transform Metrics, and check the Relative checkbox.
No, I’m trying to make all the selected glyphs have the same, fixed total width (including sidebearings), but in such a way that whatever extra width is required to get to that total width is evenly distributed on either side.
In this case, it was to make tabular numbers, so for example I had glyphs with values like this:
0
– LSB 74, RSB 82, total width 964 (path width = 808)
1
– LSB 122, RSB 89, total width 788 (path width = 577)
When I set my tabular numbers to a fixed width (let’s say 1000 units), I still want 1
to have a bit more LSB than RSB, the same way the proportional one does – so the extra width should go evenly on either side. For 0
, I would be adding 36 units, so 18 on either side; whereas for 1
, I would be adding 212 units, so 106 on either side, yielding this:
0
– LSB 92, RSB 110, total 1000 (path width = 808)
1
– LSB 228, RSB 195, total 1000 (path width = 577)
I ended up doing it with a script, but it would be better if simply setting the width in the info box took care of both sidebearings automatically.
Here is the script, for good measure (also sets the metrics key to none so that updating metrics doesn’t reset the sidebearings to their proportional parent’s values):
tgt = 1000
for glyph in Font.selection:
glyph.leftMetricsKey = None
glyph.rightMetricsKey = None
for layer in glyph.layers:
diff = (tgt - layer.width) / 2
layer.LSB += diff
layer.RSB += diff
Have you tried the RMX Monospacer?
Monospacer unfortunately requires multiple masters, which I don’t have in this font, so that won’t work here.
But I still cannot think of any possible context where the current behaviour would be desirable – when would it ever make sense to adjust the RSB, and only the RSB, when you manually change the width of the glyph?
When you slant shapes to make an oblique, you need to shift them horizontally by a certain amount, for example.
I would suggest setting a width key for all your monospace glyphs and then running HT LetterSpacer. That will optically centre them within your defined monospace width.
But would you ever manually set the glyph width in that context? I would set the sidebearings directly when slanting for an oblique (and most likely both sides would need to be adjusted), rather than changing the width.
I wasn’t familiar with the LetterSpacer script. It does seem to have the same drawback as the script I posted above that it won’t work for component glyphs with automatic alignment.
This updated version of the script posted above does, by adjusting the sidebearings relative to the auto-alignment (also updated to store the target width of tabular glyphs as a numberValue
in each master instead of defining it in the script):
tgt = Font.selectedFontMaster.numbers["tabularGlyphWidth"]
for glyph in Font.selection:
isAutoAligned = False
l = glyph.layers[Font.selectedFontMaster.id]
l.leftMetricsKey = None
l.rightMetricsKey = None
for component in l.components:
if component.automaticAlignment == True:
isAutoAligned = True
if isAutoAligned == True:
diff = (tgt - l.width) / 2
sym = "+" if diff > 0 else "-"
l.leftMetricsKey = "=" + sym + str(diff // 1)
l.rightMetricsKey = "=" + sym + str(-(-diff // 1))
else:
diff = (tgt - l.bounds.size.width) / 2
l.LSB += diff
l.RSB += diff
I don’t understand. That’s the point of automatic alignment…? You’re not able to set side bearings for automatically aligned glyphs.
You can set relative sidebearings, to be added to or subtracted from the inherited values. For example, if your five.tosf
uses five.osf
as a component and your target tabular glyph weight is 1100 units:
- Component (
five.osf
) metrics: path width800
, LSB72
, RSB48
= width920
- Padding required: 1100 – 920 = 180
- Calculated
five.tosf
metrics: path (component) width920
, LSB==+180
(252), RSB==+180
(228)
If you subsequently change the sidebearings of the component’s base glyph, you’ll of course need to update the tabular derivatives as well, but that would be the case for any solution that retains automatically aligned components.
That’s not automatic alignment. You disabled automatic alignment in that case.
And yes, that’s the thing with using non-aligned components and why it’s almost always a bad idea.
Monospace figures should be properly designed with width and stroke compensation anyway.
Just running HTLS over all monospace glyphs (even with non-aligned components) works just fine.
No, automatic alignment is still enabled. That’s what =(=)
means. If I disable auto-alignment, it works, of course, but that defeats part of the purpose of using components.
I learnt something new!
I still don’t see how HTLS wouldn’t work, though.
I haven’t played around with it too much (the required parametres aren’t quite self-explanatory, and I haven’t hunted down what they each represent yet), but from a quick run-through with HTLS, the output in the macro window console informs me that it simply skips auto-aligned glyphs altogether, so it only works on the same glyphs as my original script.