Height and vertical sidebearings

[Denis Jacquerye]

The UFO specification has glyph properties width and height. From the width, one can get the left and right sidebearings. One could get bottom and top sidebearings from the height.

If the bottom sidebearing behaves like the left sidebearing then it is actually the distance between the baseline and the lowest outline y-coordinate (yMin).

But in most cases a glyph should keep its baseline at y=0 for horizontal layout and have a different bottom sidebearing line for vertical layout.

Take 'g' for example.

In vertical layout:

1.a If it has a positive or zero bottom sidebearing, its outline won’t overlap with the next glyph’s advance height.

1.b If it has a negative bottom sidebearing, its outline will overlap with the next glyph’s advance height.

In horizontal layout:

2.a If it has a positive or zero bottom sidebearing, its outline sits on top of the baseline.

2.b If it has a negative bottom sidebearing, its outline extends below the baseline.

In this case one would want 1.a. in vertical layout and 2.b. in horizontal layout.

The current specification doesn’t support this as there is no baseline information.

If there was a glyph baseline property, then

bottom sidebearing = baseline + yMin

or the other way around

baseline = bottom sidebearing - yMin

Would it make sense to add a baseline property to glyphs in the UFO specification?

In http://unifiedfontobject.org/versions/ufo3/glyphs/glif/#advance, the height attribute is defined as the "vertical advance".

The glyph baseline property could be defined as:

attribute name: baseline

data type: integer or float

description: The vertical distance between the bottom of the vertical advance and the baseline. Optional, requires height to be defined.

default value: 0

[Behdad Esfahbod]

The way I've seen this commonly modelled is to specify the vertical
origin, from which what you call baseline can be derived. I find the
term baseline confusing when used the way you define it.

> --
> You received this message because you are subscribed to the Google Groups
> "Unified Font Object Specification" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ufo-spec+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
behdad
http://behdad.org/

[Denis Jacquerye]

Thanks Behdad,

Would this be better?

attribute name: verticalOrigin

data type: integer or float

description: The 'y' coordinate of the top of the vertical advance. Optional, requires height to be defined.

default value: same as height

Should this be an attribue of advance or in the lib as public.verticalOrigin?

Cheers

[Behdad Esfahbod]

On Thu, Jul 14, 2016 at 11:15 PM, Denis Jacquerye <moy...@gmail.com> wrote:
> Thanks Behdad,
>
> Would this be better?
> attribute name: verticalOrigin
> data type: integer or float
> description: The 'y' coordinate of the top of the vertical advance.
> Optional, requires height to be defined.
> default value: same as height

A better default value is horizontal-ascender. That's what shaping
engines use (AFAIK) if the font is CFF and no VORG table is available,
or it's TrueType-flavored and vmtx is not available.

[Denis Jacquerye]

That makes sense, but does that work with default height being zero?

[Denis Jacquerye]

Here’s an update on the proposal.

This can be a public lib key in glif.

public.verticalOrigin

This key is used for representing the "vertical origin" 'y' coordinate used for vertical layout. The value for the key must be an integer or float. This data is optional. Authoring tools can use this data and the advance element's `height` attribute to create the VORG and vmtx tables.

Cheers

[Behdad Esfahbod]

On Fri, Jul 15, 2016 at 2:04 AM, Denis Jacquerye <moy...@gmail.com> wrote:
> That makes sense, but does that work with default height being zero?

Humm. Not sure I understand. Default height should be 1em IMO.

[Behdad Esfahbod]

SGTM.

[Denis Jacquerye]

Thanks.

I made a PR: https://github.com/unified-font-object/ufo-spec/pull/41

On Sat, 16 Jul 2016 at 09:20 Behdad Esfahbod <beh...@behdad.org> wrote:

SGTM.

On Sat, Jul 16, 2016 at 1:14 AM, Denis Jacquerye <moy...@gmail.com> wrote:
> Here’s an update on the proposal.
> This can be a public lib key in glif.
>
> public.verticalOrigin
> This key is used for representing the "vertical origin" 'y' coordinate used
> for vertical layout. The value for the key must be an integer or float. This
> data is optional. Authoring tools can use this data and the advance
> element's `height` attribute to create the VORG and vmtx tables.
>
> Cheers
>

[Tal Leming]

Perfect, thanks! I've merged it into the spec.

Thanks,
Tal