BBox 125% Limit ¿Yes, or No?

[Pablo Impallari]

For Latin webfonts, we have been told not to exceed 125% of the UPM.

https://code.google.com/p/googlefontdirectory/wiki/HowToGenerateWebNativeFonts
"When designing a web font, to ensure the optical size is conventional, the maximum total glyph height (from lowest point in the family to highest point in the family) should be no more than 125% of the UPM. Eg, 1,250 or 2,560. "

Pretty much all the Devanagari fonts I've seen so far, goes beyond this limit.

I'm struggling to fit everything under 1250, but some shapes start to look cramped.
So, I wanted to ask it:
- Is this limit still to be maintained for Latin+Devanagari webfonts?
- Or we can get rid of it, and use a bigger Bbox?

[Eben Sorkin]

I would not advise going beyond 125% of the UPM e.g. 1250 in a 1000 unit UPM or 2560 in a 2048 UPM.

I have have seen 2% wiggle room maybe before things get cut off but better safe than sorry. When you see Deva text set it is usually at a size that is nominally larger than a roman would be. This is try win Chinese too. Greater stroke complexity/density forces us in that direction.

I would not worry about if it seems small compared to roman type and would instead compare your approach to other similar designs. If it looks small compared to those then you may need to change your proportions in some way. 

-e.

--
--
Google Font Directory Discussions
http://groups.google.com/group/googlefontdirectory-discuss

---
You received this message because you are subscribed to the Google Groups "Google Font Directory Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefontdirectory...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dave Crossland]

Scale the Latin smaller than normal.

[Erin McLaughlin]

Whoops, Dave beat me to it.

Yup, this is the reason why it's important to do the height extremes early on in the design. That way, if you need to scale the Latin down, you can then change the weight of the Devanagari to match, before you get too far into the design.

[Liang Hai]

I'm not the best one to give advice, but since Dave invited... some thoughts of mine:

Not sure what "to ensure the optical size is conventional" exactly means... Optical size is mainly influenced by x-height and cap height, isn't it?

Maybe Dave was talking about those extreme cases, for example, Zapfino, which has an unusually big optical size and big BBox.

According to my understanding, the BBox limit practice has more to do with —

1. Technical issues: many rendering environments clip the rasterization result vertically, many text areas (bottons, for example) have a limited vertical space, on consideration of typical Western fonts only;

2. Typesetting issues: for typesetters who are not so familiar with Devanagari, or for typesetting cases where Devanagari is not the major script, a smaller line height (say, 1.2) might be used, then there might be overlap between lines.

However, even though BBox itself doesn't ensure how optical size will be, a BBox limit does limit the optical size of Devanagari typeface.
Some consistencies and some usabilities are hard to maintain in a Devanagari typeface, so you need to decide to compromise some of them:

Point 1. Consistency of optical size between Devanagari and Latin in your typeface.

Point 2. Consistency of optical size between Devanagari in your typeface and Devanagari in common typefaces.

Point 3. Consistency of optical size between Latin in your typeface and Latin in common typefaces.

Point 4. Usability of Devanagari in a small line height (and conforms the BBox limit).

Point 5. Usability of Devanagari in a small point size.

If we examine some typical designs (see below), we can see:

- Point 2 doesn't really exist. :P

- Adobe Deva compromised both Point 1 (Deva part appears small) and 3 (a bit smaller than the standard Minion), but both in a mild way.

- Kohinoor Deva compromised Point 4, and the Latin part of it is specially designed to match Indic scripts' structure.

- Kokila compromised Point 3 (small Latin) and 5 (small Latin and Deva). And actually, even though there's hardly some convention of the optical size of Deva, Kokila's Deva is too small. So I'd like to consider it compromised Point 2 also. All these compromises of Kokila is for Point 4.

- Nirmala UI compromised Point 4, similar to Kohinoor Deva. Personally I feel its Deva part is too tall compared to Latin, so maybe Point 2 is violated also, maybe because of Point 4?

- Skolar Deva compromised Point 4 also, similar to Kohinoor Deva.

So... You need to decide yourself what to do. Personally I prefer Kohinoor Deva and Adobe Deva's solutions.

Best.

Liang Hai

[Raph Levien]

One more data point, in case it's helpful. The default text height in android is 2163 ascent, 555 descent. This is what TextView widgets get clipped to if there's no explicit padding (and, of course, designers tend to work just in Latin, so are unlikely to set it). This gives you 1.327 to play with.

In L developer preview release, there's an optional "elegantTextHeight" setting, part of the public API, that changes the measurements to 2500, 1000. Obviously this is L-only and opt-in, so it's hard to count on, but I am doing what I can to increase usage. Other scripts (Telugu, Kannada, Arabic with all the tashkil) are harder to fit in the regular default space.

Hope this helps.

Raph

--

[Eben Sorkin]

Some environments like Adobe Indesign notably - will not cut off glyphs. 

However for the purposes of a google web font the question is almost exclusive - they care about web browsers.

For these 125% is the safe limit. Go beyond that and you can expect your shapes to be cut off both above and below. 

You have quite a lot of options about how much is above or blow a baseline. Browsers are flexible about that. But the overall height should not exceed 125% of the the EM space.

-e.

[Dave Crossland]

Hi Eben

Do you have a test page handy showing this clipping?

Cheers
Dave

[Denis Jacquerye]

Hi,

The real question should be whether the Devanagari fonts are going to be used in layouts designed for Latin or in layouts designed for Devanagari.

If the font are configured properly, things should not get clipped (except when there's a technical restriction like on Android, designed for Latin — compare Droid Naskh with Droid Naskh UI, the non UI fonts go way beyond 132% and are fine, if not better, on non UI layouts).

Denis Moyogo Jacquerye

[Eben Sorkin]

Denis - I am pretty sure that web browsers cut off rather than whatever android’s OS can do natively is the standard Google wants us to adhere to. Google is a web centric company. Dave - please correct me if I am mistaken about this.

About my tests:

I made all my tests several years ago. I bet that Firefox alone has been through 10+ updates since then.

It may be worth while having something people can see so they know that 125% of the em really does matter. 

My tests were very boring looking - my font was basically a big ruler. :-P

I made several test fonts. Some were 125% 126, 127 etc. But just having marks above & below was not enough. I also made fonts that exceeded the 125% above the baseline and some that did it below - and both.

But it would be fairly simple to do again - just a bit tedious. 

I would be willing to make a several ruler fonts to test ( a bit less ugly that the originals) if someone was willing to make the test HTML.

If we do this again I think it would be smart to use Em units, px and whatever else and to have a spreadsheet showing precisely where the cut offs are for each browser and browser version OS etc. 

Because the results I got at the time were very consistent with only a few browsers being very slightly more generous 1% more or something I decided that being conservative was better.

The other thing to remember (and this may be the reason Denis is claiming 132% is OK) is that browsers will render single lines without clipping in a more generous way. But as soon as you have two or more lines the 125% rule is applied.

I am also going to disagree with Denis about layouts. I think it makes sense to assume that the the vast majority use case is going to be layouts with mostly or even all Devanagari. But the fonts should be capable of working in layouts in which the scripts have a more even mix and where Latin is the majority as well. 

Re: Droid Naskh - it is huge. 2474 Asc and -1437 Desc which is 3948 or 1,388 units more than the combined 2560 units I have seen as safe. It is also 1.542% of the EM of 2048.

My best guess is that it was made with the phones in mind not the web. It would be interesting to ask about it and to test it. If they found a way to get past the 125% rule I would be overjoyed. But I don’t think they have. Dave, what do you know about this?

-e.

 

[Dave Crossland]

On 20 July 2014 11:43, Eben Sorkin <sorki...@gmail.com> wrote:

Dave, what do you know about this?

I got the 125% from you, and the '3 sets of vertical to the bounding box, 0 linegaps' from Raph's https://code.google.com/p/googlefontdirectory/wiki/VerticalMetricsRecommendations and http://levien.com/webfonts/vmtx/

I agree that we are overdue for an updated battery of tests on this topic as browsers and OSs have churned in the last 4 years.

Ajanthan or Vitaly can make test fonts via script and the needed web pages also; if you describe it, I'll get it made :)

[Eben Sorkin]

Writing a program to generate the fonts and HTML tests is a great idea. 

I went back over my old tests because I did find you could push *very slightly* beyond 125% of the em. What I found was that in a 1000 EM you could get 1005 units safely which is 100.5%. In a 2048 EM you can get 2574 units. It is far easier to remember 125% of the em though. :-P

To re-test this I think what we need is:

• Test pages whose title and headline text indicates what is being tested e.g. "126% of the EM"

• We could also “push” both above and below. e.g.. 101% above the baseline and 25% below ( exceeding by 1% above) vs  100% above the baseline and 26% below ( exceeding by 1% below). This information should also be indicated in the HTML.  e.g. “0.1 above baseline" or 1% below baseline”. I don’t expect that we will see a difference by pushing above or below but we could certainly re-check this.

• Test pages must test multi-line use not single line use. Web browsers are more permissive with single lines.*

• Test pages should use a wide line spacing of perhaps 150% of the font size** to make it easier to see a cut.

• Test pages should use a very large font size so the cut off is easier to postively identify***

• We could use a 1000 EM square to keep the math simpler and matching 1% or even 0.1% changes. We could of course also do 2048 but I found that the EM square being different didn’t change anything - which good. That is what you would hope would be the case. So again, I don’t suggest that we worry about a 2000 or 2048 EM.****

• I think we should tests for a range of possible heights probably 120%-130% with steps in the em unit size e.g. 1 em or 0.1% change per test.

* I am pretty confident that line spacing has no impact on cutoff behavior but that could be tested if you wanted to.

** You could vary line spacing to see if you get changes but I don’t believe you will see any.

*** The font size also does not impact the cut as far I was able to see but you could add this as a variable if you wanted to.

**** You could also test other EM sizes such as 100 EM units or 2000, or 2048 but I suspect that we will not see changes. 

In terms of font design for the test let me tell you what didn’t work and what I did about it. The first thing I did was to build a ruler and try to see individual lines being cut. I felt very clever but - I wasn’t. This was a huge pain. When you are building a font at 1000 it doesn’t let you make shapes that are less than 1 em in high. But far more crucially 1 em rectangle renders very very badly. It was extremenly hard to interpret the result. I needed a different plan and a test in which it was very easy to see a negative and positive result. 

What I ended up doing instead was to create one block that equaled the height I was testing and two others one above and one below that should in theory be cut off. I offset these blocks to the right. If I could still see either one I knew there was more potential room. When I could no longer see the blocks to the right I knew I had reached the maximum vertical height.

I am attaching an example OTF with an em of 1000. The ascender value is 1000 and a descender is -250. I have added glyphs in the “A" and “a” positions with blocks matching these values. Blocks rising and descending from these values are set to the right. I labeled the middle block indicating what % of the EM is being taken up. However if the font name itself and HTML showing the fonts label things well the label in the font itself won’t be needed. 

If my old tests are still correct you should be able see a very small sliver of both of the blocks ( above and below) that exceed this hight.

[Denis Jacquerye]

Hi,

The metrics of Testidea.otf will trigger overlapping and clipping in some places.

I’d set hhea.ascender = 1000 instead of 750 and keep hhea.descender = -250 to get the 125% of em, hhea.lineGap can be 0. That will prevent overlapping of the main block in many applications. If the main block was bigger those values would have to match it.

OS2.usWinAscent and OS2.usWinDescent are also out of order, making some applications clip anything above 1000 or below 0. They can be set to the absolute value of hhea.ascender and hhea.descender respectively, but it might be more appropriate for them to match head.yMax and head.yMin. See http://www.microsoft.com/typography/otspec170/os2.htm

For OS2.sTypoAscender and OS2.sTypoDescender, as per the recommendations in http://www.microsoft.com/typography/otspec170/recom.htm they should add up to 100% of em.

I very much encourage other people to ask questions, comment on this and also to poke holes in my method if they are there to find.

I hope this is useful.

-e.

[Eben Sorkin]

I made the font too quickly.

Here is an updated version with the OS values ( and some others) corrected.

Google ( via Raph) has overruled the idea of MS’ 100% of the em idea - for web fonts. 

[Denis Jacquerye]

Yeah, following https://code.google.com/p/googlefontdirectory/wiki/VerticalMetricsRecommendations works well for browsers.

But the point is that going beyond 125% is fine as long as you set the font metrics accordingly (given there's no other technical restrictions like the 132% of em UI).

--
--
Google Font Directory Discussions
http://groups.google.com/group/googlefontdirectory-discuss

---
You received this message because you are subscribed to the Google Groups "Google Font Directory Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefontdirectory...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
--
Google Font Directory Discussions
http://groups.google.com/group/googlefontdirectory-discuss

---
You received this message because you are subscribed to the Google Groups "Google Font Directory Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefontdirectory...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Denis Moyogo Jacquerye
African Network for Localisation http://www.africanlocalisation.net/
Nkótá ya Kongó míbalé --- http://info-langues-congo.1sd.org/
DejaVu fonts --- http://www.dejavu-fonts.org/

[Eben Sorkin]

If what you are saying is that for fonts in general the restriction isn’t required. That is clear. I agree.

But if you are developing a font for web use I’ll keep suggesting 125% of the EM until we see tests that show some vast majority of browsers don’t  cut off shapes above & below.

-e.

[Eben Sorkin]

For the purposes of our Deva design I will be doing a smaller more focused version of this test this evening. I’ll let you know what I find.

-e.