Vietnamese diacritic ascender adjustments

jeremy tribby

Would I be crazy to try and compensate for #1 being too high by going with #3? I like it but fear Vietnamese speakers will not. #2 is the only acceptable way? 

Bhikkhu Pesala

In my opinion, the best solution is to increase WinAscent to accommodate the accents at the size that they need to be. There is only so much that one can do to squash the diacritics before they look out of to proportion the base glyph. I resized the diacritics vertically, but tried to maintain the same relative weight and width. 

Changing the base glyph is not a pretty solution.

Georg Seifert

But increasing winascend will increase the line spacing, too (at least in a tone of apps that follow the winGDI model).

Bhikkhu Pesala

Yes, Vietnamese text needs more generous line-spacing. If using the same font for regular Latin text, then one can set the line-spacing to 120% or whatever instead of using the default line-spacing, which may be 130% or more depending on the font's design.

Paul Miller

Georg Seifert said:

But increasing winascend will increase the line spacing, too (at least in a tone of apps that follow the winGDI model).

Increasing the line spacing is the price you pay for having legible diacritics.

jeremy tribby

Bhikkhu Pesala said:

Yes, Vietnamese text needs more generous line-spacing. If using the same font for regular Latin text, then one can set the line-spacing to 120% or whatever instead of using the default line-spacing, which may be 130% or more depending on the font's design.

Is that common practice, to use the winAscent from the rest of the Latin alphabet, and ask that Vietnamese users simply increase their line-spacing? 

Bhikkhu Pesala

jeremy tribby said:

Is that common practice, to use the winAscent from the rest of the Latin alphabet, and ask that Vietnamese users simply increase their line-spacing? 

I think it is the reverse. If a font supports Vietnamese diacritics, then other users will need to reduce the line-spacing. In many applications, if glyphs exceed the WinAscent or WinDescent, they will be clipped so it is best to design all glyphs to lie within these two extremes. 

Kent Lew

Georg Seifert said:

But increasing winascend will increase the line spacing, too (at least in a tone of apps that follow the winGDI model).

I thought that’s what the fsSelection bit 7 USE_TYPO_METRICS was for — to allow WinAscent/Descent to be greater in order to prevent clipping, but to direct that TypoAscender/Descender/LineGap should be used for default line-spacing.

I realize not all apps will respect this, but that’s the solution we have available via the current spec, I believe.

Khaled Hosny

What @Kent Lew said. If some applications do not support this, too bad, but I’d rather have some applications behave in less than ideal way than punish the users of certain languages with illegible diacritics or letter forms.

Rafael Saraiva

Besides the metrics discussion, you could improve/compensate the accents as well. The top element looks quite large to my eyes in comparison to the bottom one.

Bhikkhu Pesala

Khaled Hosny said:

What @Kent Lew said. If some applications do not support this, too bad, but I’d rather have some applications behave in less than ideal way than punish the users of certain languages with illegible diacritics or letter forms.

No one has to use illegible diacritics or letter forms. Just increase WinAscent to give adequate space for Vietnamese diacritics. 

Fonts like Myanmar need to be set in a larger point size to fit with latin body text because the bowls that correspond to x-height in Latin fonts are small compared to other glyphs.



Script fonts often need to be used at larger point sizes too, due to their small x-height. 

It is up to the user to adjust the line-spacing and point size of body text for legibility. The default line-spacing for single spaced text is the minimum required to prevent clashes of ascenders and descenders. 

Khaled Hosny

Bhikkhu Pesala said:

Khaled Hosny said:

What @Kent Lew said. If some applications do not support this, too bad, but I’d rather have some applications behave in less than ideal way than punish the users of certain languages with illegible diacritics or letter forms.

No one has to use illegible diacritics or letter forms. Just increase WinAscent to give adequate space for Vietnamese diacritics.

We are in agreement, that is exactly what I’m trying to say.

Nick Shinn

It was quite common practice for German foundries to shrink the height of the base glyph in Ä, Ö and Ü, or take other liberties to accommodate the diacritics, in fact it appears to have been the norm for Linotype, as evidenced by the Linotype-Schriften specimen of 1967.

Was it really such a terrible thing?

It seems to be a reasonable option for Vietnamese—I would imagine it’s been tried in the past.

Thomas Phinney

Nick, your example does not show reduced height; rather it shows the diacritics integrated with the base letters. Reduced height has never been very widely used, that I have seen.

The umlaut integration is practical in German because there is only one diacritic, the umlaut. All a reader has to be able to tell is whether there is a diacritic or not; what that diacritic is is irrelevant, because there is only one possibility.

Vietnamese is different; there are many possible options. Plus the diacritics stack two up. So reduced height would have to be even more reduced, and integrating diacritics “cleverly” into the main glyph is not going to work.

Nick Shinn

Thomas, this particular spread doesn’t show much reduced height, more “other liberties”—although two of the three Neuzeit characters are in fact reduced height—but there are lots of patently reduced height treatments elsewhere in the catalog. I just happened to have this spread already scanned, which is why I posted it.

While your theory sounds plausible, I nonetheless would expect that there have been many instances of non-standard Vietnamese diacritic treatment that are fairly respectable—especially in vernacular signage—and worth pursuing on a typeface-by-typeface basis.

jeremy tribby

Ok, well reading everyone's perspective I think a very small increase to the winAscent would be OK. In my case, the font is already out there in the wild, so I think I may be stuck with old winAscent... I don't want to screw up everyone's existing layouts by introducing Vietnamese to an updated version of a new font file. I could squish the double-stacked glyphs a bit. On the other hand, the font hasn't been out there too long, so if I'm going to change winAscent I should do it now. Tough call. 

Georg Seifert

I didn’t mean to discourage people from doing the right thing by giving the accents enough space. Just wanted to point out the possible side effects with software who’s developers didn’t care. 

And using the ‘use typo metrics’ is not a perfect solution, too. Then you get collisions with the descenders of the preceding line (when not manually adjusting the line spacing)

Rafael Saraiva

Jeremy, just to be clear I also think that metrics adjustment would be desirable for Vietnamese support. On the other hand your concern about not affecting the previous release is legit. But why are you adding Viet support? If this is a local market call, you definitely should consider amending metrics (or releasing a separate Vietnamese cut). Other than that you could fit the accents into your current metrics knowing that it is a compromise. Btw my comment on the accent was made looking at one single character when in fact the best would be assessing how it relates to the existing Latin diacritics at first. It could be the case that your 'breve' form is small as well, I dunno Check it against Aringacute Abreve Acute and see how it goes. 

Thomas Phinney

The other moral of this story is: if releasing a Latin typeface that could get more language support in the future, consider making metrics decisions up front that would allow for Vietnamese support later.

Ray Larabie

Vietnamese accents are struggling to break through their own glass ceiling. A lot of fonts have Vietnamese accents that go above the WinAscent/hhea ascender. I don't think anyone setting Vietnamese type isn't aware of the need to leave a little more headroom. Letting the accents go over the line allows you to take into consideration the overall looseness of the accents in the rest of the typeface. I mean, if the rest of your accents are high and tall and you decide you want to raise the WinAscent/hhea ascender, if you stick with the same style, your fonts will look quite tiny. If you're trying to squeeze them under the line, you're probably going to be tempted the crush them.

Consider that there are plenty of Vietnamese accents like 1EC6 (E circumflex dot-below) that fit perfectly well under the line. If you crush them, readers will see a mix of crushed and not crushed which probably won't look attractive. I give my Vietnamese accents a little squeeze but still allow them to go over the line. Then I establish an imaginary second ceiling so there are no outliers. Still vertically conservative but not strict to the WinAscent/hhea ascender.

John Hudson

I've been pushing for script- and language-specific font metrics for a very long time. Maybe 2018 will be the year.

John Savard

Thomas Phinney said:

The other moral of this story is: if releasing a Latin typeface that could get more language support in the future, consider making metrics decisions up front that would allow for Vietnamese support later.

Although that sounds like highly sensible advice, reading this thread, it sounds like this is exactly the opposite of what should be done!

Yes, I'm serious.

In Vietnamese, unlike German, it is required that letters that have accents on them, even two accents, not be shrunk down at all.

If one is selecting 14 point type, it is expected that with 14 point linespacing, consecutive lines will print with nothing overlapping. If a font requires leading to print properly, something is being done wrong. (This was not true of Times Roman with long descenders on Monotype, but one must recognize that people using fonts on personal computers won't be as sophisticated as Monotype operators.)

This means that a capital A in a font that supports Vietnamese at the 14 point size... won't be very high. It won't be as high as a capital A in a font of the same size that doesn't support Vietnamese.

So if you designed fonts to support Vietnamese, you would be making fonts with a lot of built-in leading, and users would have to select a linespacing less than the point size in order to get text with a normal appearance.

So, barring some very sophisticated language-specific attribute setting in software using the fonts in question, it seems to me that the only reasonable alternative, from the end-user perspective, is to make a separate version of a font to support Vietnamese.

Deleted Account

But that is wrong too.

jeremy tribby

John Hudson said:

I've been pushing for script- and language-specific font metrics for a very long time. Maybe 2018 will be the year.

This seems like the reasonable long-term solution, even though I'm having trouble picturing the implementation. I wonder if you could achieve something kind of like it with OTVar -- Vietnamese as an arbitrary axis?

jeremy tribby

Whoops, double-replied

John Hudson

This seems like the reasonable long-term solution, even though I'm having trouble picturing the implementation.

Font-side implementation is pretty straight forward: sets of additional TypoAscender, TypoDescender, and TypoLinegap metrics values stored in a table (probably BASE) and associated with the same Script and Language System tag combinations as already registered and used for other aspects of OpenType Layout.

Software-side implementation is a bit more complicated, and requires an implementation spec to get everyone to do it the same way. But basically, in the case of a line of text combining multiple scripts or languages with different metrics, the largest of the individual localised metrics should be used. [Yes, this does mean that different lines of text using font metrics for linespacing will have different linespacing, but that's already the case when one switches fonts for different scripts. Font metrics should provide legible fallback when explicit leading values are not set.]

I wonder if you could achieve something kind of like it with OTVar -- Vietnamese as an arbitrary axis?

In horizontal text layout, vertical space is only controlled via either user intervention in document creation software (setting explicit or relative leading), or by the font metrics in the OS/2 or hhea table (depending on platform). There's no way in OTVar to vary vertical spacing in horizontal text layout, because unlike horizontal glyph spacing the metrics used for linespacing are not included in gvar.

Nick Shinn

There’s nothing inherently wrong with making types that are “small on the body”, but it should probably be a foundry practice that is a part of its branding, for consistency’s sake. It certainly does impart a classy tone. IIRC, Emigre did that, I don’t know if they still do. 

Georg Seifert

John Savard said:

If one is selecting 14 point type, it is expected that with 14 point linespacing, consecutive lines will print with nothing overlapping.

That is not true. At least not technically. Because this line of thinking brought us the wrong behavior of using the win-metrics for linespacing. Try to implement a font like Zaphino with the expectation. You will need to set it at least three times larger to visually match a certain size. 

Of cause in good typesetting, consecutive should not overlap. But there you wouldn’t use 14 on 14pt to begin with. 

John Savard

Georg Seifert said:

Because this line of thinking brought us the wrong behavior of using the win-metrics for linespacing.

Well, I'm assuming that a font should be designed to work perfectly in the programs that are already existing out there, from WordPad on up.

If they don't correctly implement the standard, the standard may need to be redefined to correspond to the reality out there.