Mysterious Lines over Glyphs

Domenico's picture

I'm currently working on a font and I've found an issue which baffles me, shown here: http://members.optusnet.com.au/d-esign/misc/brushy_glitch.png. As you can see there are these out of place lines over the "u" and "y" glyphs, and they're not the only affected glyphs. The issue crops up in Photoshop when the font is displayed at small sizes or has anti-aliasing off. What's weird is that the lines don't actually exist on the vectors, FontLab renders them appropriately and there's nothing suspect on the offending glyphs which sets them appart from the others that render properly.

Help would be much appreciated.

Thanks,
Domenico.

blank's picture

I suspect that you never disabled automatic glyph hinting and that Photoshop does not like whatever hints FontLab came up with. Try deleting all of the hints in the fonts and turn off the automatic hinting options in Fontlab preferences, then generate a new font.

kegler's picture

It has nothing to do with hinting. It is poor node placement as caused by auto tracing. turn on the font audit too in fontlab and get rid of all of the bad and excessive nodes.

Thomas Phinney's picture

Yeah, there must be some bad vector paths there. Sometimes insanely sharp angles in the outline can cause those sorts of rendering artifacts.

T

Domenico's picture

Thank you all for the replies.

@ James: I disabled automatic glyph hinting and generated an OT PostScript font to no avail.

@ Richard: Illustrator does create some poorly placed and voluminous amounts of nodes but it's the only way to achieve the desired brush effect. FontAudit was unable to find any problems.

@ Thomas: The paths are a little awkward but nothing like this has cropped up in my past experiences with more complicated paths.

I found that saving the font as OT TrueType solves the problem, irregardless of whether auto hinting was set on or off http://members.optusnet.com.au/d-esign/misc/brushy_glitch_2.png. Because my technical knowledge is a little bleak and you're the experts, what fixed the problem by changing formats?

Fontgrube's picture

> saving the font as OT TrueType solves the problem

sounds like a "quick and dirty" solution to me. Maybe you can find the problem nodes examining the glyphs manually. BTW the spacing between h and y is too tight. Andreas

Domenico's picture

"sounds like a “quick and dirty” solution to me"
I know that's why I'm hoping someone can impart what saving as TrueType may have done differently.

Don't worry I'm still looking at the nodes, although I don't know what I'm looking for; as I mentioned above "there’s nothing suspect on the offending glyphs which sets them appart from the others that render properly".

Thank you for the pick-up on the spacing, although the font is far from completion; I still need to create more glyphs, and metrics and kerning won't be touched until I can definitively find what's wrong.

Micha Mirck's picture

In FontLab goto "Generating OpenType PS (otf) and uncheck "use subroutines to compess outlines in the CFF table". Helped me a lot when having big fontfiles.

good luck,
Micha

Domenico's picture

Thanks Micha, I gave your solution a try but still no change when generating a PostScript file http://members.optusnet.com.au/d-esign/misc/brushy_screenshot.png.

Micha Mirck's picture

that's funny....
could it be that the old fontfile is still in the fontcache?? And is the new fontfile much bigger than the old one??? Should be about 2 times the size of the original.

kegler's picture

Since you still don't believe Thomas or myself with our advice, you can send the file to me and for $100 per glyph (donated to charity) I will fix each one for you.

Micha Mirck's picture

Richard. I have had similar experiences with a 3000+ glyph font. Funny things like disappearing glyphs and for example an 'à' without the hole, but a perfect 'a'. I don't know if there is a maximum OTF-fontsize, but in CS applications there seems to be a maximum fontsize when you use subroutines to compress the outlines (with FontLab). The problem described above didn't occur in Quark and also didn't happen when I made the font into an OpenType TT.

Thomas Phinney's picture

Although I suppose anything is possible, I would be very surprised if subroutinization was responsible for the rendering issues seen in the original post.

I wasn't saying the *complexity* of the paths was a problem, but having an extremely acute angle in the outline can definitely create the kinds of "spikes" you are seeing in that screen shot. I remember the first time I saw what looks to me like the same problem, during development of Chameleon fonts for PostScript 3 printer ROMs....

Cheers,

T

Domenico's picture

@ Micha: When it comes to re-installing fonts I always make sure to delete the installed files, restart the system (if necessary, when some files don't delete) and install. I also tried the OTF font without subroutines on an Windows XP system that has never seen the file before and still the same issue http://members.optusnet.com.au/d-esign/misc/brushy_screenshot_2.png.
The OTF font file without subroutines is 164KB and the OTF font file with subroutines is 152KB.

@ Richard: You're hilarious.
I'll give you one glyph for $0 and you can fix it without removing detail from it. I'll keep the $100 to buy a pretty badge for my Typophile avatar.
OK jokes aside, I'm reluctant to remove nodes because I don't want to sacrifice detail and because the font as is, shows no artefacts when saved in TrueType. Because you insist, I'll pick at the glyphs and see how much needs to be changed to get it rendering properly, if there's too much detail lost I'll move on or stick with the (as Andreas put it) "quick and dirty" TrueType solution.

@ Thomas: Subroutinisation isn't the problem as the lines still crop up irregardless of whether the outlines are non-compressed or compressed as shown in the screenshots. I'll be on a particular lookout for sharp angles.

@ All: Thanks for the help, it's much appreciated.

Domenico's picture

I've been chipping away at the glyphs and the results are quite pleasing with minimal effect on detail http://members.optusnet.com.au/d-esign/misc/brushy_lines.png (What a relief; I won't have to pay Richard $230,000 to fix my glyphs).
A key to the above linked image: The red dots represent clearly shown lines, yellow dots represent hidden lines which come up when the font size is reduced or when a block of text is in edit mode and the green dots represent resolved glyphs.

Thomas Phinney's picture

The spikes showing up only at certain ppem sizes or ranges is another identifying characteristic of the issue Richard Kegler and I were writing about... I will be somewhat surprised if that is not the cause of the problem.

Cheers,

T

Syndicate content Syndicate content