FontBureau / Opentype-1.8-Axis-Proposal

Apache License 2.0
0 stars 1 forks source link

Overview.Readme #58

Open sberlow opened 6 years ago

sberlow commented 6 years ago

Overview: Axes Proposal Part I

Most type users are familiar with the weight, width and postural (slant), attributes of a typeface family, and many users are familiar with fonts mastered for different optical size ranges. Traditionally some of the most common attributes are available as named font instances (or styles) within font families. These attributes are recorded in the font metadata fields of the OpenType v1.0 specification, along with other values in the OS/2 table (e.g. cap height and x-height). But these could not be altered by users, and this led to widespread simplification about how typography is formed from the attributes of typefaces.

Increasing numbers of type users over the past quarter century of static type composition, as for print, with this meta data applied to Latin and other world scripts, have found difficulties with the limited metadata, and compositions mixing scripts in use can involve users wanting to manipulate more parameters than the format contains, or applications offer. In addition, and combinatorially, the development of digital publishing in PostScript or via http; has brought together the perfect need for a more in-depth and complete set of metadata contained in fonts.

The variable fonts specification, included in the recent OpenType v1.8 font format has been demonstrated capable of changing that situation by the creation and use of a collection of axes more powerfully suited to the tasks of responsive world typography. Variable fonts launched with some registered axes that pertain to these attributes, such as width and weight, and introduced new ones such as optical size. This proposal contains additional axes pertaining to Latin and universal attributes that many users are familiar with, such as x height, and some that are less obvious, such as the vertical depth of descenders.

This initial proposal is for the primary set of axes that are inter-related, and form a gestalt system for Latin, and beyond. For world scripts, it offers the potential for any world’s script to be the default around which a variable is designed, or for a default to contain all of the world’s scripts, offering a multitude of options for many users. Following the pervious examples, it means a Latin Geometric Sans variable font with weight and width axes, meaning each instance in the variable space has width and weight meta data, it can now have an x-height parameter under separate control for better appearance at small sizes, and thus multiple possible styles for each width and weight. Or a Latin design with weight, width and optical size axes, in a font with Chinese glyphs offering the same, can have multiple descender lengths depending on whether Chinese or Latin is the primary script in a text run.

Instead of choosing common general terms and then dissecting such a meaning down to this purpose, we created axis tag names for all of our proposals to represent direction, color and alignments of glyph groups, creating it’s own language, (one that has become quite convenient internally as we discuss the details of all kinds of type design projects, variable or not) . We chose value ranges to form a unified programmable set, built on typographic tradition where measures of variation are reasoned about in per-mille-of-em, points and degrees, among other things. This allows the definition of values relative either to a variable font, or values absolute and shared among any other fonts so measured.

So, this proposal includes axes that change Latin type attributes, but includes some that are inherent to all writing systems, when represented in a single variable font. Beyond these and into the decentralization from Latin parameters, an important aspect of these proposed “lower level” axes is they can be used to define ‘higher level’ axes like weight, by blending, or specifying instance of the lower level axes as extremes of the registered axes. This allows both developers and users to control the low level parameters of high level type attributes with precision for a multitude of applications alluded to above. Part of this includes proposing ‘Parametric Weight’ and ‘Parametric Width’ axes that offer the same per-mille-of-em user experience as our other axes, and thus differ from the registered axes, wght and wdth in value systems.

We believe these axes allow type users, especially software developers and educators, to have a clearer picture of how typography is shaped by the attributes of typefaces. A near-future proposal, will follow with an overview containing world script alignments, time-base axes and axes for glyph-referencing among instances.

(Maybe: Making the system interoperable via registration is not essential to realizing the full value of variations. But a network effect is at play: as the potential functionality for typographers increases when each attribute can be combined with the others, registered axes or not, the exponential possibilities not being interoperable will likely exacerbate issues of responsive design and world scripts, beyond public programability or user interface-ability beyond local levels. )

sberlow commented 6 years ago

@dberlow Could you please rewrite paragraph 2? It is not clear

Increasing numbers of type users over the past quarter century of static type composition, as for print, with this meta data applied to Latin and other world scripts, have found difficulties with the limited metadata, and compositions mixing scripts in use can involve users wanting to manipulate more parameters than the format contains, or applications offer. In addition, and combinatorially, the development of digital publishing in PostScript or via http; has brought together the perfect need for a more in-depth and complete set of metadata contained in fonts.

davelab6 commented 6 years ago

I'll try and send my complete revision of copy tonight later

On Dec 9, 2017 7:10 PM, "Sam Berlow" notifications@github.com wrote:

@dberlow https://github.com/dberlow Could you please rewrite paragraph 2? It is not clear

Increasing numbers of type users over the past quarter century of static type composition, as for print, with this meta data applied to Latin and other world scripts, have found difficulties with the limited metadata, and compositions mixing scripts in use can involve users wanting to manipulate more parameters than the format contains, or applications offer. In addition, and combinatorially, the development of digital publishing in PostScript or via http; has brought together the perfect need for a more in-depth and complete set of metadata contained in fonts.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/TypeNetwork/Opentype-1.8-Axis-Proposal/issues/58#issuecomment-350515050, or mute the thread https://github.com/notifications/unsubscribe-auth/AAP9yzWlP3X--AtXgI9ZgzL-yx6125JMks5s-yFigaJpZM4Q40gH .

sberlow commented 6 years ago

Everyone using fonts is familiar with the weight, width and postural (slant) attributes of a typeface family, and many professional typographers are familiar with fonts mastered for different optical size ranges. Traditionally some of the most common attributes are available as named font instances (or styles) within font families. These attributes are recorded in the font metadata fields of the OpenType v1.0 specification, along with other values in the OS/2 table (e.g. cap height and x-height.)

But these could not be altered by users, and this led to widespread simplification about how typography is formed from the attributes of typefaces. Users want to manipulate more parameters than static font formats contain, or applications could offer. The metadata that was available was mostly for Latin, and the users of other world scripts have found difficulties with more limited metadata, especially when mixing scripts on a page for print or digital media.

The variable fonts specification in the OpenType v1.8 font format changes that situation. We see the possibility to solve many typographic problems with it, if it includes a more in-depth and complete set of attributes that users can interact with, or adjust through programming.

OpenType variable fonts launched with registered axes that pertain to some of these attributes: Width, weight, optical size. This proposal contains additional axes that are universal attributes, and also some specific to Latin. Those may be familiar to many users, such as cap height, and some may be less obvious, such as the vertical depth of descenders.

This primary set of axes for Latin are interrelated, and form a gestalt system. The system can be extended by other axes, not in this proposal, for all the world’s scripts. A Latin variable font with these axes can be adjusted to harmonize with a static font from any of those scripts. For example, such a font paired in a document with Chinese text can have multiple descender lengths, depending on whether Chinese or Latin is the primary script in a text run.

sberlow commented 6 years ago

Everyone using fonts is familiar with the weight, width and postural (slant) attributes of a typeface family, and many professional typographers are familiar with fonts mastered for different optical size ranges. Traditionally, the most common attributes are available as named font instances (or styles) within font families. These attributes and others are also recorded in the font metadata fields of the OpenType v1.0 specification, such as values in the OS/2 table (e.g. cap height and x-height.)

But these could not be altered by users, and this led to widespread simplification about how typography is formed from the attributes of typefaces. Users want to manipulate more parameters than static font formats contain, or applications could offer. The metadata that was available was mostly for Latin, and the users of world scripts have found difficulties with more limited metadata, especially when mixing scripts on a page for print or digital media.

The variable fonts specification in the OpenType v1.8 font format changes that situation. We see the possibility to solve many typographic problems with it, if it includes a more in-depth and complete set of attributes that users can interact with, or adjust through programming.

OpenType variable fonts launched with registered axes that pertain to some of these attributes, such as width, weight, optical size, and slant. This proposal contains additional axes for attributes that are universal for all scripts and designs, and also some specific to Latin, such as cap height and vertical depth of descenders.

This initial proposal for Latin axes is interrelated, and forms a gestalt system. The system can be extended with more axes, not in this proposal, for all the world’s scripts. A Latin variable font with these axes can be adjusted to harmonize with a static font from any of those scripts. For example, such a font paired in a document with a non-variable Chinese font can have multiple descender lengths, depending on whether Chinese or Latin is the primary script in a text run. We expect to see single variable fonts that contain several scripts and several sets of glyph group alignment axes.

We carefully chose these axis names and tags to convey their systematic nature. Instead of choosing familiar, common, general terms (like "x height" or "weight" or "spacing") with widely understood meanings, and then dissecting a specific meaning for use in a sharply defined axis using that name, we created names that may at first seem unfamiliar, but are descriptive – and soon become intuitive.

These names represent a patterned sequence of direction, form and glyph group alignment. This pattern is the foundation for a new kind of discourse about type that has become very convenient internally at Type Network for discussing the details of all kinds of type design projects, variable or not, with our clients, including the Google Fonts team. We have made the distinction between ‘Universal’ parametric axes and ‘Latin’ parametric axes. The naming scheme helps to de-emphasize the Latin script as a default.

We also carefully designed the axes value ranges to form a unified programmable set that is built on typographic tradition, where measures of variation are reasoned about in per-mille-of-em, points, and degrees. This allows users to define spatial values relatively, which is especially useful when specifying typography with variable fonts, or to work with absolute values that can be found in any font.

Most of these axes are “lower level” in that they can be used in concert to define “higher level” axes (like a “weight” or “x height” axis.) Currently this means finding 2 positions on a set of lower level axes, and instantiating them as new masters, to be re-inserted into the design space as the extremes of a new axis. For users, the ability to control the low level parameters of high level type attributes with precision increases the number of typographic problems that they can solve. For typeface designers, their design process is simplified, as the number of masters that they are required to draw from scratch is reduced, while increasing the number of high level axes they can offer users.

Overall, we believe these axes allow type users, especially software developers and educators, to have a clearer picture of how typography is shaped by the attributes of typefaces. A near-future proposal, will follow with an overview containing world script alignments, time-base axes and axes for glyph-referencing among instances.

dberlow commented 6 years ago

Great,

Sent from my iPad

On Dec 12, 2017, at 1:39 PM, Sam Berlow notifications@github.com wrote:

Everyone using fonts is familiar with the weight, width and postural (slant) attributes of a typeface family, and many professional typographers are familiar with fonts mastered for different optical size ranges. Traditionally, the most common attributes are available as named font instances (or styles) within font families. These attributes and others are also recorded in the font metadata fields of the OpenType v1.0 specification, such as values in the OS/2 table (e.g. cap height and x-height.)

But these could not be altered by users, and this led to widespread simplification about how typography is formed from the attributes of typefaces. Users want to manipulate more parameters than static font formats contain, or applications could offer. The metadata that was available was mostly for Latin, and the users of world scripts have found difficulties with more limited metadata, especially when mixing scripts on a page for print or digital media.

The variable fonts specification in the OpenType v1.8 font format changes that situation. We see the possibility to solve many typographic problems with it, if it includes a more in-depth and complete set of attributes that users can interact with, or adjust through programming.

OpenType variable fonts launched with registered axes that pertain to some of these attributes, such as width, weight, optical size, and slant. This proposal contains additional axes for attributes that are universal for all scripts and designs, and also some specific to Latin, such as cap height and vertical depth of descenders.

This initial proposal for Latin axes is interrelated, and forms a gestalt system. The system can be extended with more axes, not in this proposal, for all the world’s scripts. A Latin variable font with these axes can be adjusted to harmonize with a static font from any of those scripts. For example, such a font paired in a document with a non-variable Chinese font can have multiple descender lengths, depending on whether Chinese or Latin is the primary script in a text run. We expect to see single variable fonts that contain several scripts and several sets of glyph group alignment axes.

We carefully chose these axis names and tags to convey their systematic nature. Instead of choosing familiar, common, general terms (like "x height" or "weight" or "spacing") with widely understood meanings, and then dissecting a specific meaning for use in a sharply defined axis using that name, we created names that may at first seem unfamiliar, but are descriptive – and soon become intuitive.

These names represent a patterned sequence of direction, form and glyph group alignment. This pattern is the foundation for a new kind of discourse about type that has become very convenient internally at Type Network for discussing the details of all kinds of type design projects, variable or not, with our clients, including the Google Fonts team. We have made the distinction between ‘Universal’ parametric axes and ‘Latin’ parametric axes. The naming scheme helps to de-emphasize the Latin script as a default.

We also carefully designed the axes value ranges to form a unified programmable set that is built on typographic tradition, where measures of variation are reasoned about in per-mille-of-em, points, and degrees. This allows users to define spatial values relatively, which is especially useful when specifying typography with variable fonts, or to work with absolute values that can be found in any font.

Most of these axes are “lower level” in that they can be used in concert to define “higher level” axes (like a “weight” or “x height” axis.) Currently this means finding 2 positions on a set of lower level axes, and instantiating them as new masters, to be re-inserted into the design space as the extremes of a new axis. For users, the ability to control the low level parameters of high level type attributes with precision increases the number of typographic problems that they can solve. For typeface designers, their design process is simplified, as the number of masters that they are required to draw from scratch is reduced, while increasing the number of high level axes they can offer users.

Overall, we believe these axes allow type users, especially software developers and educators, to have a clearer picture of how typography is shaped by the attributes of typefaces. A near-future proposal, will follow with an overview containing world script alignments, time-base axes and axes for glyph-referencing among instances.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.