composite character shift

Stephen Rapp's picture

I'm working on a custom script font in FL Studio and noticed that some of my lowercase composite characters had shifted in position slightly. Aren't these supposed to change their metrics whenever the parent character changes? I'm wondering if there is something I've accidentally done that caused this shift. Any ideas?

Stephen Rapp's picture

I just did an experiment in the metrics window. I had an Rè and Re in the window. I took the regular e and moved the left sidebearing further away from the e in metrics mode. The sidebearings of è did not move, but when I did command z (mac) the sidebearing of è snapped in the same distance that my command z had undone. That's just weird!

mekka's picture

I know. FL sometimes shows unexpected behavior when it comes to composites. Maybe this helps.

Mark Simonson's picture

I have a habit of checking the sidebearings of composite glyphs before finishing a font. Sometimes metrics changes to the parent glyph affect the composites and sometimes not. There's probably a pattern to it, but I haven't figured it out.

Stephen Rapp's picture

Thanks Mark and Eric. I've got them reset now. It was a pretty odd way of behaving.

blank's picture

Something else worth noting is that the pulldown in the metrics window that lets you view composites built with a character will often not show all of the composites!

oldnick's picture

There's probably a pattern to it, but I haven't figured it out.

Nor have I, which is why I build my composites only after I have completed kerning of the font...

Mark Simonson's picture

Just been trying some things out with it to try to see what works and what doesn't.

- You need to be very careful about undoing after changing the left side metrics of a glyph that is used elsewhere as a composite. This is true in both the Metrics window and the Glyph window. If, say, you have "O" and "Oacute" and you change the "O" and then undo, the "O" part of the "Oacute" shifts, but the "acute" part doesn't. Consequently, if you go and fix the sidebearings of the "Oacute" the coordinates of the "acute" will be wrong.

- If you do need to change the left sidebearings of a glyph used in composites, it's better to move the glyph in the Glyph window. That will move all the composites by the same amount.

- A possible workaround: Write a Python script to reset the x coordinate of all child composites of a specified glyph to zero. Assuming this is possible, it should fix any composite shift errors caused by this undo bug. It seems like the "Copy to composites" pop-up below the glyph in the Metrics window is meant to do this (in part), but as James notes it seems to have its own problems. And, in fact, using that command has the same effect I described in the first note above, i.e., it shifts all composites, including ones that were okay where they were, such as accents.

Stephen Rapp's picture

Exactly what I saw in the metrics window, Mark.

When I shifted the left sidebearing of the original nothing happened to the composite, but when I did an undo, the composite's left sidebearing shifted the same amount to the right even though it had not shifted the first time.

Mark Simonson's picture

Definitely a bug. It can't be meant to work that way on purpose.

.00's picture

I never expect composite glyphs to do anything when I change the parent glyph. I use this FL feature to correct composites when I change a parent glyph.

paul d hunt's picture

Something else worth noting is that the pulldown in the metrics window that lets you view composites built with a character will often not show all of the composites!

it should if the first component of the composite character is the same as the base glyph. however if you have a diacritic as the first component, it wont show up in the 'Copy to composites' feature shown by James M. above.

blank's picture

however if you have a diacritic as the first component, it wont show up in the 'Copy to composites' feature shown by James M. above.

What determines which is the first component when Fontlab builds the composites? Aliases.dat formatting? Because it does not consistently set the letter as the first component in my fonts.

paul d hunt's picture

what function are you using to build composites? if you're using the 'create glyphs if empty' feature or double-clicking on cells to get this function then yes, the aliases.dat file formatting is what controls the order of components of composite glyphs. however, if you're using a different method to derive composites, i cannot tell you what determines the component order.

emtype's picture

Perhaps this can help with part of the problem:
Some time ago I wrote a little script for check the order of components,
the script only mark the composites that have incorrect order (don't fix the problem).
You can edit this scrip as you want, for instance, you can use your own accents list.

--------------------------------------------
# FLM: EMT_Mark_order_components

# Mark glyph if accent is the first component

from robofab.world import CurrentFont
from FL import *

f = CurrentFont()

# Accents list
acentos = ["grave", "acute", "dieresis", "circumflex", "tilde", "macron", "breve", "dotaccent", "ring", "cedilla", "hungarumlaut", "ogonek", "caron" ]
color = 215

for glyph in f:
> if glyph.components:
>>base = glyph.components[0].baseGlyph
>>if acentos.count(base) == 1:
>>>glyph.mark = color
>>>glyph.update()
>>>print base
--------------------------------------------
(replace > by spaces)

Or download from here:
http://www.emtype.net/tools/EMT_Order_components.py

Stephen Rapp's picture

James, thanks. I didn't realize you could do that in the metrics window.

blank's picture

I use create “create glyphs if empty”. I’ve had to add a lot of stuff to aliases.dat to handle large character sets with uppercase and lowercase diacritical marks, so I probably need to recheck my work. Thanks for the tip.

Ray Larabie's picture

Copy to composites isn't reliable enough to be useful. Before kerning I generate rough composites. Then I delete all composites and generate them again just to make sure nothing went wrong.

paul d hunt's picture

p.s. generating composites using the alias.dat file together with positioning anchors is fairly effective, especially if your character set is relatively small. Just make sure all the 'recipes' for composites are in the alias.dat file, set your anchors, and then use the 'create glyphs if empty' feature to generate composites. if your sidebearings become corrupted, it's not too hard to just trash your composite characters and regenerate them. unless you've moved on to kerning, you probably don't want to use this method to fix composite characters if you've already kerned them. in that case, use the 'copy [metrics] to composites' feature. that or use some fancy python scripting to refresh your glyphs.

Mark Simonson's picture

Just noticed: Among the scripts that are added to FontLab when you install AFDKO is one called "Report or Fix Base Glyph for Composite Accent". Basically, this fixes any composited accented glyphs in which the base character is not the first component.

.00's picture

>>Copy to composites isn't reliable enough to be useful. Before kerning I generate rough composite<<

I'm surprised you find it unreliable. It always behaves as expected when I use it.

James M

Syndicate content Syndicate content