Font offsets when typing in a text field

Hello font lovers :)

I've got an annoying problem (but then again, aren't all problems annoying?). Well here goes:

I've pursued an old idea of splitting a font in half — one font (half) containing the first set of fragments of each glyph, the second font (half) containing the rest of the fragments. I'm calling the font Unify 1 and Unify 2.

The idea is then to write something with a readable font, then duplicate the text you've just written and add Unify 1 to the first copy and Unify 2 to the second copy. To be able to read the whole thing, you need to put the two copies on top of each other and voila! It's complete.

That was the concept. Now to the problem, which I've explained in this short video:

What to do?

I really hope somebody out there might have a clue as to what's going on here.



Nick Shinn's picture

I've produced a (proprietary) font that does this.

It only works for one case of the alphabet, not other characters.
Type "A" and the left half is set.
Type "a" and the right half is set.
SsOo YyOoUu HhAaVvEe TtOo TtYyPpEe LlIiKkEe TtHhIiSs.


It would also be possible to extend the principle to the whole character set, using OpenType alternates, but you would still have to "double" the text.

So, the first thing to do would be to run a "Find/Change" script that doubles everything:

e.g. "Find A, change to AA" and so on for all characters in the encoding.
Then in the "contextual alternates" feature:

sub A A' by A.alt;

Where A is the left side, and A.alt the right side.

And so on.


It would be easier if OpenType did one-to-many substitutions, but it doesn't.

Nick Shinn's picture

Left and right side are separate glyphs.

Selecting the "right side" glyph selects the inside of the letter.

This technique is long-winded to set up, but does have its merits:
1. Only one font
2. No layering of text boxes
3. Easy to experiment with global colour schemes by editing the colours in the Swatches palette

msmiths's picture

I ran into the same problem when developing Output I which uses a supplemental 'dot' style which you can see here a few slides in -

You can adjust the offset in Area Type Options>Offset>First Baseline of course, but even in the drop-down options there is no setting that by default positions the 'supplement' style exactly as it is positioned using the standard 'Type Tool'. (as opposed to using the 'Area Type Tool')

It would be interesting to hear why the Area Type Tool handles typesetting offsets differently, and if there's anyway to solve the problem.

jokke-svin's picture

Thanks Nick, but I think you're misunderstanding me. I've already designed the whole thing, and my problem is, that Unify 1 offsets upwards (I'm explaining everything in the video).

jokke-svin's picture

@ Mike — Hmm I can't seem to find anything called Area Type Options in FontLab Studio. But the whole things doesn't really seem logic to me. The two fonts are based on the exact same font, and I haven't changed ANY values. I've just modified the glyphs.

msmiths's picture

Joaquim, Sorry… I was referring to the Area Type Options in Illustrator - Type>AreaTypeOptions>Offset>FirstBaseline

I couldn't find the same options window at all in Photoshop… and interestingly enough the same problem does not occur at all in InDesign…

If you can, try setting your type in InDesign and you should see that you won't have the vertical offset problem… you can just do a copy and then paste in place or duplicate layer…

Would love to hear from someone about the discrepancies between the apps and the type tools default offset.

I imagine Adam Twardoch would have some insight or one of the designers from Adobe…


Nick Shinn's picture

Sorry, I didn't view the video.

I suspect the problem with two fonts is that the bounding box is different in each.

If you add some peripheral items (say accents) that are in the exact same position in each font, that might solve the issue.

John Hudson's picture

1. Check that the OS/2 and hhea table vertical metrics settings of both fonts are identical. Do not allow the font creation software to automatically generate these: set them manually.

2. If the problem persists when the vertical metrics are identical, then if may be a font bounding box issue as Nick suggests. The best way to resolve the problem in that case is to put an identical glyph in each font with an outline taller and deeper than the tallest, deepest glyphs in each font. This will equalise the vertical bounding boxes.

jokke-svin's picture

@ Mike — Aaah Illustrator hehe. Well, I guess I could tweak the settings in the software after the font has been generated to compensate for the offset, but the best thing would definitely be to have them identical to begin with to avoid any tweaking afterwards.

@ Nick — That sounds like a possible solution to my problem. I had a feeling that it might have something to do with the BBox, but didn't know how to tweak those settings in FontLab as they were grayed out in the Font Info dialogue. Thanks for the heads up :)

@ John — I checked, and they're exactly identical (and manually set). I just tried to create a glyph (called "fixer") which I positioned so the BBox values of the two fonts are identical as well, but the font still offsets :(

What to do?

msmiths's picture

Yeah I just tried John's suggestions earlier and I'm pretty sure back when I designed Output and it's supplement I tried adding just one glyph that would match the others in height but still had the same problem.

Again, it's really only a problem when setting text with a text box / area type tool in Illustrator or Photoshop but even still it would be nice to know why.

Nick Shinn's picture would be nice to know why.

Because the people who designed those apps know better than mere typographers!
If I was designing a layout app, I would position the top left of the em square of the first line of type at 0, 0 coordinates of the text box, just like real type.


As per my initial post: doing this in a single font has some practical advantages.

jokke-svin's picture

I went through all glyphs systematically to narrow it down to which glyph caused the vertical offset, and it turned out it was the lowercase d. Is it common that the lowercase d defines the vertical offset of a font?

msmiths's picture

Nick, I agree completely… time to stage an Adobe protest!!!

And while were at it, get them to make the accessing of OpenType features more consistent between Illustrator and InDesign… it makes no sense to have the palettes and OT feature access completely different in each app… I wonder if they've changed any of this in CS5?

Miguel Sousa's picture

Joaquim, I suspect that the two fonts either don't have a TypoAscender value in their OS/2 table (making Photoshop resort to heuristics for positioning the first baseline of the paragraph), or if they do the value is not the same in both fonts.

In FontLab, open the Font Info dialog, go to the TrueType-specific metrics pane, switch to "Set custom values", and use the same TypoAscender value on both fonts. Does this fix the problem?

Syndicate content Syndicate content