I am working on a typeface for technical documentation composed of characters in solid blocks. When typed in a sequence, the blocks should appear together to each other forming a solid background with no gaps between the characters. The blocks fill the entire width of the character.
Problem:
Hairline gaps appear between the glyphs.
I see this in Illustrator (Mac or Windows) and in FrameMaker (Windows).
I have even tried to create an overlap of the background extending beyond the glyph left and right by 5 units, but it makes no difference.
Glyphs Version: 3.0.2
Characteristics of the Typeface:
The typeface has only one master and a single weight.
There are no kerning pairs on any of the characters.
The characters have one of three widths, so it is not technically monospaced: 500, 1000, 1500 with an em-size of 1000.
I have tried setting the “.monospace” number value in the master settings as suggested here:
… but, other than left-aligning the wide characters (which breaks my design, but it was just an attempt to see what would fix the problem), the gaps continue the same as before when I used the typeface.
Before I export, I run the following each time:
Glyph:
Update Glyph Info
Update Glyph Metrics
Paths:
Correct Path Direction
Export Settings:
File Format: .otf
Outline Flavour: PostScript/CFF
Options (makes no difference checked or unchecked):
Remove Overlap
Autohint
In Illustrator:
Kerning: Auto or zero (makes no difference)
Tracking: 0
Any suggestion as to a solution would be much appreciated.
It’s a quirk of pixelation, and text rendering engines are not über precise down to the sub pixel levels. The only way to make sure to get rid of the hairline gaps is to make the overlap larger, which is commonly seen in connecting scripts like Arabic.
My solution would be OpenType, and make overlapped variant appear when a letter is followed by another. I have made a sample Glyphs file. I hope it helpsOverlap Test.glyphs (1.3 KB) .
Thanks very much for the information and for the sample file! A lot of overlap is necessary. I first tried 25 units and it did nothing. 100 units, like you used, seems to do the trick. The hairlines show most when the type is small, so a pixel in the wrong direction as part of pixelation could result in a gap, which is probably why overkill is necessary. I’ll continue to test the solution you propose. Thanks again!
You’re welcome! 25 units is not enough? That’s a little surprising. I wonder what OS + application + font size you are looking at. Would you mind posting a screenshot here? And depending on the target environment and needs, I could suggest a simpler trick.
I take that back that the problem was fixed with the 100 unit overlap. Looked fine everywhere until I viewed it as a PDF on an iPad (Acrobat Pro).
The problem appears at small display sizes only. It’s not so much the size of the type itself as I can tell, but the size at which it is viewed. If I zoom in on-screen, the problem disappears. The problem appears in the applications I author in (Illustrator or FrameMaker) as well as in the PDF output.
OS/Application combinations:
macOS 11.2.2, Illustrator 2021, macOS Preview, Adobe Acrobat DC
iPadOS 14.4: DropBox PDF viewer, Acrobat Reader
Windows 10: Illustrator 2021, FrameMaker 2019, Adobe Acrobat DC
I am attaching a screenshot.
I have been noticing the top of the comma is missing a pixel. Some aliasing is showing on the bottom of the 2 as well. So far, I have only done the 100 unit outdent on the right side of the 4 and 5 (which still have 5 units outdent on the left side). The comma has no outdent on either side.
The characters are actually in the Japanese Full-Width range (the 4 is \uFF14). This has to do with the way FrameMaker is making me work on paragraph numbering.
This is a project designed for PDF output, primarily for online viewing, but also print.
Thanks for offering to look at the file, but it turned out that I was having a cache problem with the new versions of the typeface on the Mac. A 20 unit overlap does in fact seem to do the trick very nicely. I also implemented the “cut-off” corners as in the sample–a really great idea!
I found an article on your website about font cache problems and setting up the Adobe Fonts folder, which I have now done. I’ll also continue to study the sample .glyphs file you sent me and weigh whether the OpenType features you show could help.
