Welcome to Typophile
Please Sign in.

Plastica: Experimental 3D typeface issues

Primary tabs

6 posts / 0 new
Last post
Vít Šmejkal's picture
Offline
Joined: 24 Sep 2007 - 7:14am
Plastica: Experimental 3D typeface issues
0

Hello guys,
I’m nearly finishing work on my new experimental 3D typeface called Plastica. I’m facing few problems I would like to discuss.

It is CFF OpenType made in FontLab on PC. Outlines are very precise and I used atypical custom UPM of 2300 units (23 modules at 100 units). But this should be fine regarding to older nodes on Typophile.
There are two versions: Plastica One (Striped) and Plastica Two (Outlined).
And here is what I struggle with:

1) On-screen rendering issues:

This font is naturally intended to be used at higher font-sizes. It also works quite well when set above cca 70 pt. There is intentionally no hinting at all – I suppose the outlines are way too complex for this - would you agree on this?

However, some weird things are happening at lower sizes. Some glyphs become randomly lighter or bolder and it all mysteriously changes over different pointsizes. Do you have any idea what this could be and how to improve rendering?
(note: all outlines are exactly aligned, correct curve direction set, etc.)

2) Tracking Gaps:

So far, glyph sidebearings are set exactly to zero, however small unpleasant “visual” gaps between letters sometimes occur. Would you perhaps suggest to set some small overlaps? (ie. negative sidebearings?) If so, how big regarding to 2300 UPM? On left, right, or both sides?
(but I’m affraid it could reversely make the transitions to look bolder - that happens sometimes too, see the “rendering" image)

3) Leading Gaps:

The line leading should be also seamless. So far, it is set up to work perfectly when leading=pointsize. However default leading in applications is usually around 120% of the given pointsize. It works this way at least in Adobe apps as far as I know. Is this the cross-platform/cross-app standard?
Ergo, would you suggest to modify font metrics so it connects seamlessly at 120% rather then at 100%?

4) Kerning:

Unfortunately it is not possible to make traditional kerning - glyphs would ugly overlap. Instead I introduced special alternates to the most extreme letters like AFLTPJVW and some other glyphs. There are up to 3 alternates for each of these glyphs (left, central, right version). In the end it works quite well. However, it is also pretty tedious work to correctly set it up manually by picking different alternates from Glyph palette.

Do you thik this could be possibly automated via some smart OT substitution? I was trying with no success - but I’m not much a programmer. Do you have any ideas?

I would really appreciate any help or advice.
Thanks in advance,
Vit

Note: I have also noticed that Illustrator (CS6) omits “space” glyph when converting font into outlines even if it’s not empty. I think this must be an Illustrator’s bug, because it works fine in InDesign. As a precaution I put simple “space” substitution to solve this problem.

Theunis de Jong's picture
Offline
Joined: 22 Apr 2008 - 5:06pm
0

At least some (and possibly all) of these problems are screen-only.

The random thickening must be due to pixel rounding. Since you don't have hinting, the rendering engine is free to do what it likes (including not hinting at all). Hinting -- or lack thereof -- and on-screen representation depends on what text rendering engine you are using. Windows' is different from OS X's, and some software such as Adobe's Creative "Suite" have type rendering engines of their own. (I quote "Suite" because, as you found out, there are unaccounted-for differences between the individual programs.)

If your primary target is for screen only, or you find it important, you need to address your issues, but: some of them cannot easily be fixed. The intercharacter white line/overlap problem, for example, is because a pixel needs to be drawn .. or not. Without overlap, the pixel may disappear due to rounding; with, you get a slightly fatter pixel than wanted.

... Both the idea and its execution are pretty awesome, by the way.

Vít Šmejkal's picture
Offline
Joined: 24 Sep 2007 - 7:14am
0

Thank you, Theunis,
I agree the rendering issues are probably screen-only problem. I'm quite sure the outlines itself are OK.
And I know the rasterizing is really tricky in this very case, it will never be perfect at smaler sizes.
However I think at least all the glyphs should look consistent at certain pointsize - what should be the possible reason why some render bolder or lighter? (all the horizontal stripes/outlines are perfectly aligned and of exactly same width, ergo any eventual pixel rounding should be the same too?)

I have tested it on PC only so far and it looks very similar over many different apps (Adobe and others)

Regarding vertical gaps: I'm starting to believe that some small glyph overlap could make it better, I just wander what realtive value would be best.

Cheers,
Vit

Craig Eliason's picture
Offline
Joined: 19 Mar 2004 - 1:44pm
0

Cool project!
I can't help with the rasterization issues, but can assure you that changing out better fitting versions of letters can certainly be done with OpenType. What you want to look for are "contextual alternates."
http://opentypecookbook.com/ is a good introduction geared to those new to it.
https://www.glyphsapp.com/tutorials/features-part-2-contextual-substitut... also might be useful (even if you're not using Glyphs).
For the leading, I would think you would want to leave it alone and trust the end-user to set the text solid if that's the desired effect.

K Cerulean Pease's picture
Joined: 19 Oct 2003 - 5:03pm
0

To prevent those gaps, I'm pretty sure all you should need is one unit of overlap on each side.

You can do your kerning thing with calt but you will probably have to do it without the little diagonal spacing glyphs. Opentype does one-to-one substitution or many-to-one; it won't insert more glyphs.

erwindenissen's picture
Offline
Joined: 31 Aug 2007 - 1:12pm
0

The typeface is really fascinating.

If a little overlap does the trick, go for that.

@cerulean OpenType also has one-to-many substitutions, but no direct support for many-to-many.