I don’t know about the usefulness of such a feature.
In my opinion, sidebearings are not a static value; rather, they are linked to the amount of whitespace created within a glyph and thus must be flexible. Editing a glyph, you also edit the counter shape, and must account for its changes in the sidebearings.

Regardless, you can achieve the behavior described with a Python script; look into the Robofab ‘marginPen’ module.

I don't think I'd want it on by default, but I might find it useful to have a "tie rod" tool that you could add to link an extreme node to the sidebearing line, which would work in the way you describe.

I stand somewhere between Thomas's overly-mechanical recommendation and Frank's overly-defeatist caveat... There's certainly an advantage to what Thomas has in mind, but it does need to account for internal whitespace. So what about this: the designer defines a ratio (which depending on the design and what the designer believes could be 1:1, or 4:3 or maybe even something more complex) and the shift in the black causes a different shift in the sidebearing depending on the ratio.

Remember that type design is always eyeball-iterative; it's not like any algorithm can obviate that, but good algorithms can certainly save time.

As for what to link it to: isn't that what FontLab's red horizontal line is for?

hhp

Thomas' request makes sense. I don't understand the criticism of it. This is a request for a very simple mechanism that links left/right sidebearing to whatever the glyph's left/right extremum is, and makes sure that the sidebearing value remains the same as outlines get adjusted. Put differently, do not consider sidebearings as implicit in advance width and outline data, instead consider sidebearings as independent of outline data. Such a simple mechanism does not need to care for internal whitespace or any rationes. Plus it is suggested to be optional, so nothing is taken away from you.
(Fond of the idea because I saw a need for it myself when writing the Transformer.)

I will note that most of the time the adjustments I am making are subtle enough that there is no big change in the % of white space. Maybe I'm tweaking the glyph width by 10 or 20 units. But it's enough that the sidebearing had better change.

Karsten: Independent? Never heard of it. :-)

hhp

Oh, I did not want this to come across as “overly-defeatist”; or overly critical of the idea.
I am all for customizing workflows, that is why I mentioned the idea of writing a Python script.
What I described was just my reasoning behind sidebearings-vs-counterspace; which you can agree with, but don’t have to.

Let’s face it – it is not very likely there are going to be features added to FontLab anytime soon; so if this is your editor of choice, you have to help yourself. Fortunately, this is not too difficult of a scripting challenge.

"it is not very likely there are going to be features added to FontLab anytime soon"

I think you are mistaken. :)

I have been surprised by one or two new features even in 5.1.x that I had not heard mentioned....

T

Here's a more complex but, I think, more useful application of Tom's idea: allow explicit linking of sidebearing distance to a specific node on the outline, rather than as a constant relative to the left and right extremes. This would enable one to easily control the distance relative to, e.g. vertical stems instead of serif tips. I considered trying this relative to the FL measuring line, but that needs to be moveable, so it makes more sense to apply the distances explicitly as links between nodes and sidebearings, as illustrated by the green dotted lines in this illustration:

Thomas,

the new FontAudit aspect that you spotted (for MM control vectors) is indeed experimental and undocumented in FLS 5.1. It was actually slated for 6.0 and not yet finished in 5.1 but we "let it slip" anyway -- a bit like the inclusion of the World-Ready Composer in InDesign CS5.

Your suggestion does make sense although it looks like a much better fit for “Victoria”, our next-generation product series (post-FontLab Studio). I’ll try to think how to incorporate it into the new structure.

Thanks,
Adam

John, I think that this is what Mr Eliason has described above.

Independent? Never heard of it. :-)

Hrant, speaking from a technical point of view, there are formats that define sidebearings implicitly (by way of advance width and outline width) like PST1 and TTF, and there are formats that define sidebearings explicitly/independently/additively (lsb, outline width, rsb) like IK. What you think goes on, or think should go on, in a designers mind when designing is a different story.

John, I think that this is what Mr Eliason has described above.

Yes, we're thinking along the same lines. But in terms of user interface I would rather have the "tie rods" stay horizontal, connecting to the sidebearing line at the same altitude, rather than dropping down to the baseline.

Given than I tend to have a lot of horizontal guide lines -- both global and glyph-specific -- plus the existing measurement line, I'd probably prefer to avoid yet another fixedly horizontal 'rod', but I don't have strong feelings about this. The linking of nodes to the baseline intersection of the sidebearings that I illustrated mirrors sidebearing linking in FontLab's TrueType hinting tool, and might usefully be connected with that in the same way that PS stem hints or links can be mapped to TT hints.

Provided I understand you both correctly, you agree on functionality and disagree merely on representation of it. (The rod extends only to one side, so cannot be mistaken for a guide line or measurement line; the sidebearing line could moreover share a color with the rod, so it is obvious that they belong together. Personally I find the link-to-baseline misleading for it suggests that y matters when it is about x alone; it would be difficult to differentiate an additional y related rod, then. What about highlighting the whole region, from sidebearing to x of point, in light color, and mark the related point?)

The rod extends only to one side, so cannot be mistaken for a guide line or measurement line.

Correct, but it could easily fall behind or on top of a guideline, the measurement line or even a horizontal stem hint.

The more I think about it, the more I like the idea of the display being the same as in a sidebearing link in the TT hinting interface: it is in fact the same thing, a means of indicating a particular distance relationship between a point and the sidebearing, one in em units and one in device units.

I'd like to link glyph sets to dynamically have the same width (or match side bearings), based on a master of my choice, so any change I make to the parent automatically propagates to the children. Or even use classes as references as they contain sets I use constantly.

This way, for example, as I modify the shape or sidebearings of an A all of its diacritic children will always match, and I don't have to hand-update all of them. Upper, lower, or small cap x 5+ permutations adds up quickly every time I nudge a point.

Mcs

Stickley, you can do most of what you want to do using Metrics classes in the current FontLab. You can define these classes by left and/or right sidebearing, or by width. Changes to the metrics of a key glyph are not automatically applied to the class members, but can be via the arrow below the base glyph in the Metrics window.

"Changes to the metrics of a key glyph are not automatically applied to the class members,"

This is exactly why I don't bother using metrics classes in FontLab. Current implementation seems completely half-baked.

Now, if it *did* work the other way, it would be fab.

Similarly, with the sidebearing idea that I originally started this discussion with, I don't need any fancy "tie rod." Indeed, I neither need nor want this to be linked to some specific point on the outline—that would be a negative in my book, not to mention more work for the programmer. FontLab already always knows what the sidebearing is. I just want it to move it around to keep it constant. Give me a UI toggle to do so and I'm happy.

Now, I recognize that other folks may have some more elaborate preference for how it would work. I'm just sayin' that what I want is not actually complicated to implement, and that a more elaborate implementation would actually be less functional to me.

T

"...a sidebearing link in the TT hinting interface: it is in fact the same thing..."

Excellent!

Start by adding the side bearing points to the format and display as if they were part of the glyph.
Then subtract the point indices from the equation, they are not important, but can screw things up.
Then, turn your otherwise dumb lump of points into a smart lump, not just the sb/extrema smarts, but all of it.
Then, wrangle up a ui where all the dimensions are present, in traditional drafting locations, off the glyph except diagonals,
Then, we can either change the contour or the dimensions and good things happen, besides it being instructed.

Another, less long-term fun-house route is class-basing side bearings, and locking them.

"Another, less long-term fun-house route is class-basing side bearings, and locking them."

That would also be pretty fab.

Good... 'cause this:
TP>"...I'm just sayin' that what I want is not actually complicated to implement"

... is actually not quite right, i think... If one is moving the x extrema of o, e.g. and the right side bearing is sliding along with it, no big deal — that's basically class spacing. The other way, though, one moves the right side bearing, and what one would like to happen is complicated.

"If one is moving the x extrema of o, e.g. and the right side bearing is sliding along with it, no big deal — that's basically class spacing."

Well, class spacing would be an additional wrinkle on top of that (which I would like to see, actually)

"The other way, though, one moves the right side bearing, and what one would like to happen is complicated."

Maybe you and I have different ideas of what we would like to happen? For me, even if "sidebearings linked to extrema" is on, I'm assuming that's a one-way link and if I deliberately move the sidebearing, that's because I want to change it. So I don't want any change in the current behaviors if I grab the sidebearing and move it: it moves, end of story.

Now, the interactions with class-based sidebearings are interesting, admittedly. Probably if it's the base glyph for the class, the change affects all class members. If it's not the base glyph in the class, then the current glyph becomes an exception in the class?

Cheers,

T

Thomas: Maybe you and I have different ideas of what we would like to happen? For me, even if "sidebearings linked to extrema" is on, I'm assuming that's a one-way link and if I deliberately move the sidebearing, that's because I want to change it. So I don't want any change in the current behaviors if I grab the sidebearing and move it: it moves, end of story.

I think there is a distinction to be made between improved UI behaviours for implementing pre-digital type paradigms in digital fonts -- a little less busyness, but still business as usual -- and implementing control over relationships of shapes in relationships that recognise that outlines and spacing on a UPM grid are directly analogous to outlines and spacing on a device grid. In the latter view, there are kinds of adjustments to spacing in which one would very much like the outlines to intelligently follow changes to width. Or, put it another way, if you can do it in hinting -- or if you used to be able to do it in hinting -- why not do it on the UPM grid?

"So I don't want any change in the current behaviors if I grab the sidebearing and move it: it moves, end of story."

Oh. Like every other advance I've proposed, from reusing pre digitized parts for congruent forms, to epar, i was going to drive to your office in a big ugly tank, point a 14 foot pistol at your screen and force you to use my sbs.

For the others to consider...

What can happen when you stop mousing around on everything can depend on the hierarchy you link to the glyph. One point(s) is always the parent, and the other(s) is the child. So, if you're adjusting the sb in a grade-oriented hierarchy or a hierarchy for linear rendering, then sb points are the parents, while if you're adjusting the sb in a weight-oriented hierarchy or for non-liner rendering it's the glyphs' relevant x min and max that are the parents.

"..implementing control over relationships of shapes in relationships that recognise that outlines and spacing on a UPM grid are directly analogous to outlines and spacing on a device grid."

Yep. Except it's not really "analogous" because they are the same thing unless you get bogged down in non-integer units per em, sub-pixel positioning, a type1-centic mindset, or impure TT interpreters. A grid's a grid, and as such it has rhythm. Fonts, the point size spectrum, frames of film and a few other things also have rhythm. Everything's fine until one wants to combine these rhythms in hostile development environments.

Good stuff David.

hhp

I can see value in what David and John are talking about. I'd still like at least the option to o it my way (among other things, how would you ever be able to change the sidebearing otherwise?). But I'd also be happy to see my simpler version as the v 1.0 implementation; I think the more sophisticated approach would be much harder to do.

T

Frank, going back to your and my 19 August posts, 'criticism' was the wrong word. After reading the discussion which followed again, I think it boils down to this: As long as we deal with dumb outline description and editing tools, Thomas suggestion (meant as an option) is fine, keeping it simple. We will likely do some manual fine-tuning anyway. Once we get parametric shape description and editing tools, however, a more intelligent approach to sidebearings makes sense. What struck me as odd, in retrospect, was the idea to combine too-intelligent sidebearings with non-intelligent outline description.

Silly me: I usually hold out the prospect that my first, absolutely brilliant solution to a particular problem might not stand the test of time. Sacred primordial sidebearings never occurred to me at all. I suppose that's why no one is interested in my stuff anymore...