Optical typography

adamwhite · October 1

It's 2024, and the science of typography still lacks progress.

Here is a small example of a "proper" optical typography setup. Ratios and relationships can vary. I used 48px and 24px typeface sizes with a 24px line height, 96px spacing below the heading, and 48px between paragraphs.

The lecture is not about these specific sizes but about proper x-height and cap-height relationships to margins and line width, based on these parameters.

The problem in the typeface design industry is that people are still constrained by early machine-led typesetting characters and the limitations of the em box. This issue is also present in the DTP and web industries.

I am trying to provide an example of the direction ratios and alignments should take. The engines that run TTF and OTF fonts are problematic because they don't offer solutions for designers to align proper parameters, and software solutions that provide special features are non-existent. Kunst X is working on some, and Decotype, for sure, developed others decades ago (although even they did not address the subject I refer to, as their focus was mainly on Arabic script).

Design freedom is a gift, but in the world of technical specifications, there must be flexibility that encourages progress, rather than adhering to practices from a single era, shaped by one school of thought and specific production standards.

We believe we live in a decade of significant technological progress, but even with machine learning, foundational research topics are lacking. People tend to stay confined within a box of boundaries and false limitations.

Step into 2025 with strong analytical deliberation, and strive to bring real innovations that will open up new fields and liberate us from stagnation.

P.S.

I made this showcase in a 1080 x 1080px resolutions so small 1px gaps exist since certain Adobe Illustrator limitations. If it would be reproduced in a 2X layout than it could be aligned without pixel gaps.

Jasper de Waard · October 1

I actually think I probably agree with you, but if you want to get your point across you should try to communicate in less bombastic and more clear words. What is it that you want?

Thomas Phinney · October 2

Based on past conversations, I do not think I agree with you, but like Jasper I can’t really tell what your point is.

Info about cap height, x-height and more is available data in every font. Apps could choose to make use of it. If they do not, that is not the fault of the font.

Matthew Smith · October 2

Also worth noting that font metrics (ascender, win-ascent, hheaAscender, etc.), are set to accommodate the supported languages of the given typeface.

Your example may work for English, but may not work well for ascender or diacritic heavy languages.

Admittedly, I don’t think you are proposing vertical metrics need to be fixed, but rather tools/software used for typesetting need to have more settings accessible?

adamwhite · October 2

@Jasper de Waard @Thomas Phinney @Matthew Smith
It's "bombastic" since it is not a clear point but a conversation starter. The point is that I can't make only one point, since there is a group of problems needed to be discussed.

Jasper de Waard said:

I actually think I probably agree with you, but if you want to get your point across you should try to communicate in less bombastic and more clear words. What is it that you want?

I want all people related to industry to lead conversations about these issues, to wake up from blindess called "we believe we have the best solutions" or "Microsoft, Apple and similar companies build advanced products" etc.

Thomas Phinney said:

Based on past conversations, I do not think I agree with you, but like Jasper I can’t really tell what your point is.

Info about cap height, x-height and more is available data in every font. Apps could choose to make use of it. If they do not, that is not the fault of the font.

Yes data exists, but the engine still function with em box as the main container and without advanced features (except some) which will allow detail and specialized relations. Every detail relation or feature would need special development inside the software or online app used.

Before that practices in the industry are wrong, since everyone treats relations and dimensions based on em box like it's the era of typesetting machines. That's the problem. Tech can progress but people are stuck in the past. Manual typography can produce more advanced results than digital.

Matthew Smith said:

Also worth noting that font metrics (ascender, win-ascent, hheaAscender, etc.), are set to accommodate the supported languages of the given typeface.
Your example may work for English, but may not work well for ascender or diacritic heavy languages.
Admittedly, I don’t think you are proposing vertical metrics need to be fixed, but rather tools/software used for typesetting need to have more settings accessible?

Yes this is an example for "English" - latin script mostly. Tools/software but the engine itself firstly. As you mentioned other languages, Decotype produced ACE (Advanced Composition Engine) decades ago, which support any kind of advanced script from any language whith unlimited features while reataining unicode input.

Some people don't know about it, other feel inferior when told that they spent their career using and producing for low quality engine setup, and the rest just don't care.

So my main point is to talk about this, to intrigue people to think about it, to research about it, to ask for solutions. When demand exists, corporations will become interested as well.

For an example, with introduction of ACE or similar solution there would be a whole new area for production, so more business, more interesting products, more interesting typefaces and new experiences.

Even now there is a niche for new products with this faulty enviroment, if anyone is interested let me know.

John Hudson · October 2

I think you are just basically wrong about how the em box is treated. The em box is just a scaling unit: it defines what gets scaled to e.g. 10pt size or 12 px size in a given environment. The em box does not constrain the glyph outlines in the way it (mostly) did in metal type, and only in Euroean script fonts does it conventionally have a more or less common relationship to ascender and descender height. In other scripts, the relationship of glyph outlines to the em is much more varied.

Regarding ACE, it is a technology I have been familiar with for many years, and which is brilliant for Arabic text layout because it was designed around the behaviour of that script, including aspects of Arabic that other technologies struggle with. Speaking as someone who makes fonts for many different writing systems, I don’t think ACE is the best solution for all of them, and its model doesn’t provide significant benefit to many scripts in the way it does for Arabic.

It is also worth noting that even within what you characterise as a ‘faulty environment’, new font tooling is overcoming some of the deficits, i.e. the layout architecture matters less in terms of what people can do in type design if the tools work at a higher level. See, for example, the work Simon Cozens has done tooling for development of nastaliq and other Arabic cascading styles. Yes, the OpenType Layout architecture is more cumbersome and less flexible than ACE, but it also works in a lot more places, so tackling the challenges of OTL Arabic development at the tooling level makes more sense to investors like Google than adopting a whole new layout technology. I don’t think any amount of conversation here or elsewhere is likely to change that (and I say that as someone who tried to talk Microsoft into licensing ACE many years ago, long before today’s advances in OTL development tools narrowed the gap between the layout capabilities).

[The proposal to incorporate a WebAssembly shaper directly into OpenType would provide a way to ship an alternate layout model, such as ACE, directly within the font. It would even be possible to write a font-specific shaping engine that enables unique behaviour for a particular typeface design. Personally, I like the idea, but I understand some people have security concerns about runtime text layout.]

Thomas Phinney · October 2

I agree 100% with John. The em is not terribly limiting. If you think it is, give a specific and clear example of something you want to do at the font level, that you think you are prevented from doing by the em.

As John says, it is NOT a “box”; it is just a scale factor. I don’t see any way of getting away from that, nor do I see why it would be desirable. It isn’t so much a constraint as a way for apps and operating systems to understand how to go about sizing the type.

John Hudson · October 2

The horizontal advance width, on the other hand, is a box, and while glyphs are not constrained to that box their interactions are determined relative to it.

cf. Problems of Adjacency.

adamwhite · October 2

@John Hudson @Thomas Phinney

John you said that: "The em box is just a scaling unit: it defines what gets scaled to e.g. 10pt size or 12 px size in a given environment."

That is the problem. Em box is treated as a scaling unit. All relations are based on it. So when you make a distance between heading and paragraph, any margins or padding, it's all calculated in relation to em box size. Even it is not properly rendered in a given size (Look at the screenshots I attached).

First example is a distance made using Align to Glyph Bounds > Area Text and second by using Align to Glyph Bounds > Point Text. (Adobe Illustrator).

Both options are stupid and useless. So with in text processor, DTP software and web development dimensions doesn't have any value. Only by manual setup you can get a meaningful relations.

Further, you can see that em box size of 48px is not really 48px, and when size set by x height and cap height it's properly dimensioned to 48px.

With my examples from the first post (If you looked at the attached file), I showed as well that optical aligment should be organized with more solutions and not just with quotes and hyphen.

Thomas "forced" ACE with Arabic presentation which is his marketing mistake, but you are wrong when saying that ACE is not the best solution for all of them. You just didn't see examples with latin or other scripts. The problem is that we think that so far latin script is presented well with used engines. Try making variable graphemes automatically with it. (Good luck). The matter is that it is even possible on some level, but people are lazy to code so much combinations.

About adopting a whole new layout technology. It's not something so special that it needs years or enormous resources. Anyway if something is backwards than it should be changed, it's called making progress. As well we shouldn't care what Google, Microsoft or Apple plan. Even if they don't adapt to new tech, nothing stops other to produce optimal solution.

adamwhite · October 2

@John Hudson As you have mentioned the proposal to incorporate a WebAssembly shaper directly into OpenType. That is just a one problem of a web tech in general, since besides these font engine problems, web development area is full of backward solutions, ignorant people and anti-tech products by Google. People who call themselves seniors and engineers don't know proper HTML and introduce hyped frameworks and everything which is upside down.

Thomas Phinney · October 3

Also:

> Further, you can see that em box size of 48px is not really 48px

If an app is showing something else, it is not an em.

John Hudson · October 3

That is the problem. Em box is treated as a scaling unit.

It isn’t ‘treated’ as a scaling unit, it is the scaling unit. This concept is fundamental to all digital fonts, even bitmap fonts, even ACE fonts: a defined height within the unitised design space of the glyph that gets scaled to the nominal type size of text. That is what an em is.

If you want to scale other features to a nominal text size—e.g. ascender height + descender depth, you could do that, but you still need the units specified within the glyph design space to be relative to something, i.e. units-per-thing. Making the units relative to the scaling of the font is useful in a variety of ways, not least in being able to affect the visual size of a font at a given nominal size by adjusting a single value in the font data.

Further, you can see that em box size of 48px is not really 48px

I don’t think what you have labeled the em height in your images is actually the em height. I appears to be the caret selection height that Adobe apps derive from a number of different font metrics and is generally taller than the em height.

Johannes Neumeier · October 3

Whatever you propose, if indeed you propose something, it also has to be backward compatible to the existing limited status quo. This is exactly how we ended up with the Frankenstein format that Opentype is.

jeremy tribby · October 3

I might be misinterpreting this thread, but I believe the problem being discussed (or a part of it, anyway) was very recently addressed at the layout level by CSS

https://developer.mozilla.org/en-US/docs/Web/CSS/font-size-adjust

Dave Crossland · October 3

John, "I understand some people have security concerns about runtime text layout."

Kindly, at best, they are misinformed or misunderstanding. There are no more security concerns with WASM than with OTL, since both shaping systems return only 2 things, Glyph IDs and position data, and both have no access to data outside the text engine. What can appear to be done with WASM programs, plus COLRv1, plus OTVar, seem like a lot more is going on, but it really isn't.

A lot of money has been spent on making wasm runtimes secure. A lot more than OT... OT seems more risky to me.

John Hudson · October 3

I deliberately didn’t comment on whether those concerns were valid.

adamwhite · October 3

@Thomas Phinney @John Hudson In web development world we call it em box as a synonim for a em square. The problem is not it being a scale factor. The problem is that em box as a scale factor doesn't mean anything.

Amount of the white space above and below characters is flexible so we have typefaces which variate with. Font engines calculate everything in a relation to em square boundaries and not the reasonable relation to characters itself. With this there is no sense in using any dimensions for line height, spave before and after headings, paragraphs and other text parts.

Engines currently being used don't solve these problems and the whole "science" of typography design is stuck in meaningles typescales and rules which mean nothing.

It's only meaningful if you make manual dimensioning, scaling and other operations.

@John Hudson What ever it is in this case of Adobe Illustrator it is the frame which is used for relations between text and other elements. You can test multiple software types like Word, InDesign, Illustrator and Html and Css as well. In any case the same problem will exist regardless of is software providing the em square boundaries precisely or not.

adamwhite · October 3

@Dave Crossland People don't understand that web browsers are just piece of software and that everything there is because of the decisions and not tech limitations. These problems could be solve in DOS 30 years ago. It isn's anything special. The problem is a lack of knowledge, interest and conversations like this.

Thomas Phinney · October 3

> The problem is that em box as a scale factor doesn't mean anything.

That is simply false.

The em is the unit that the rendering engine scales to the desired point size. That is all that it is, at the font specification level.

Any other concerns you have with it are with implementations outside the font spec, and are not valid or sane objections to the very existence of the em (which is how you have framed your objections). Your time would better be spent on complaining about the app behaviors, and being specific about what it is they are doing that you object to, and what you wish they would do instead.

* * * * *

The other thing that I suspect you have missed is that your typographic desires are massively western-centric. Basing things on cap height and x-height would be fine for western typography and for features for western typography (Latin, Cyrillic, Greek, etc.), but should absolutely not be the “foundation for everything” in a new app or layout system, if you are intending that app to be globally useful… or even work in a comprehensible way with global languages.

There are writing systems that have a baseline and a standard height, but do not have two cases (e.g. the Georgian scripts, Hebrew, Thai, etc.).

There are writing systems that have a “head” line but no real base line and no x-height (all the Indic writing systems).

Not to mention major ones used by over a billion people that have only centering and no baseline or cap height or x-height at all (Chinese and Japanese, and many symbol fonts work this way as well).

(Yes, current font formats force all these fonts to have a nominal baseline, which is kind of a lie... it is messy. There is another whole long post one could write on the issues related to this.)

Besides pure inertia (which should not be discounted!), the other reason we are stuck with the notion of an em is that global typography pretty much REQUIRES a scaling factor that is not tied to design features that are not present in all the world’s writing systems.

adamwhite · October 3

@Thomas Phinney
The problem is that em box as a scale factor doesn't mean anything.

Of course I am talking about it's behavior runned by the engine and apps, not about the em square itself. I am talking about what is current in the text which renders it. I am not talking about abstract ideas. It is how it is at the moment, and as it is used and related to is wrong.

Engine offers the foundational functionality so even apps can make workarrounds, solving problems starts from the engine.

I am talking about "western" typography at the moment. The subject about other type of scripts is a much longer one and the foundation of problems related to those other scripts is that people want them to share these foundations. Engines which run TTF and OTF are produces based on "western" typography properties and other type of scripts are tried to be pushed into it like a Cinderella's sister's leg into the little shoe.

As you mentioned this cross-script subject, therein lies the problem of this narrative that what we have now is the peak of so called western typography, while it is the heritage of limited typesetting enviroment which became standart even now in the era of digital progress (as we believe it is happening).

Real western typograhy would be a rich equivalent to all those eastern and other types of typography, which is today considered only as calligraphy, which is again wrong. Calligraphy is a term describing the art of manual perfection and not the grapheme forms itself.

Curent western typography is partialy an equivalent to current quasi Arabic (Euro-Arabic) disastrous byproduc, while real western typography would be an equivalent to for an example Naskh, Nastaliq, Diwani and other Arabic styles.

Try making penmanship, cursive and other western typography with current engines. Even it's more close to realisation, it's still not advanced enough.

Don't focus on em square being mentioned as it is in an artificial enviroment. If we speak about light, we don't care about the speed of light in the vacum since we are not in the vacuum, and no one is.

Thomas Phinney · October 3

You are the only one talking about a “box”

The em has a very specific and clear meaning. It is what gets scaled to the specified size when setting type. If you set the font at 20 px, it is the em that gets scaled to that value. At 14 point in print, the thing that is set to 14 point is the em, nothing else specific in the font.

I literally do sworn testimony in court on this topic, and one of the ways you can know that I am correct is that millions of dollars can be at stake and that the other side doesn’t try to argue this point. The one time somebody did, is also the only time I saw an opposing expert literally get disqualified.

And the problems of typesetting non-western writing systems are myriad, but none are related to the existence of the em as a scaling factor.

Anyway, I am done with the conversation.

adamwhite · October 3

@Thomas Phinney I hope you are since all the time you just repeating the same thing about em square and objecting it being a box, while I explained that it is a synonim since you know box is squared. Which is not the point of this whole subject.

By the way if you set the font at 20px, em will be bigger than it as I showed at the screenshot, which by the way @John Hudson is not an Adobe Illustrator thing. I tested it with html and css as well.

It's a crazy world of "advanced font tech", people who claim that Shadow DOM is faster than native DOM because "Facebook said it is." and other broken products and trends.

John Butler · October 6

WASM is my favorite programming language name to pronounce.

It reminds me of a much older proposal by Letterror, unjustly dismissed by the Powers That Be as a security risk at the time, to add executable code to fonts. In our current age of more advanced memory protection, hardware virtualization, OSes-within-OSes and whatnot, it’s certainly far more doable.

Thomas Phinney · October 6

> you just repeating the same thing about em square and objecting it being a box, while I explained that it is a synonim since you know box is squared.

Are you on drugs? I never once used the word square in this entire thread! (Although I do in fact think it is a MUCH better word choice in this context than box, given the “restrictive” connotations of the word “box.”)

Eris Alar · October 7

I’m unsure exactly what is being discussed here, but it feels like it may align with a bugbear if mine in layout software where the alignment tools don’t align to the actual edges of the characters. This is especially noticeable when a heading is in say 48pt and body copy is at 12 pt, if both are left aligned the 48pt type is inset slightly.

Mark Simonson · October 7

That's because the left sidebearing increases in size along with the type size. The same is true of the right sidebearing in a fully justified or right justified setting, but those kinds of settings are not as common in display sizes.

Eris Alar · October 7

Yeah, so my wish is in the layout apps they ignore the side bearings in text boxes for type on the edge of the box, or at least give me as the designer the option to choose to ignore them or not :-)

John Hudson · October 7

Hard aligning the edge of glyph outlines doesn’t provide optical alignment, which is more complicated.

Mark Simonson · October 7

You could compensate for this by including an appropriate negative paragraph indent in the stylesheet for larger sizes.

adamwhite · October 7

Image: https://us.v-cdn.net/5019405/uploads/editor/1f/dadduyi7euqw.jpg

adamwhite · October 7

@John Butler Everything is possible, but it's up to the organization of browser development and their decissions. Browsers are making so slow progress that it is ridiculous. It's just a piece of software runing on a certain engine. In regards to typography, you see even in this conversation that people who suposely are experts don't care, so what to say for producers of browser solutions.

People like to live in denial.

Optical typography

Comments

Categories