Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Contrast (CNTR) axis #42

Open
vv-monsalve opened this issue May 19, 2022 · 11 comments
Open

Add Contrast (CNTR) axis #42

vv-monsalve opened this issue May 19, 2022 · 11 comments
Labels
--new-axis New variable axis definition

Comments

@vv-monsalve
Copy link
Contributor

Fonts to be onboarded that have this axis:

  • Palindrome (still a private project)

Originally posted and discussed at google/fonts#2888


This new custom axis is included in the WIP project Palindrome to change the principle contrast from translation to expansion.

101862652-c8ef3e00-3b40-11eb-96b5-a23d623fb5fc

#Contrast Transition, base on https://github.com/originaltype/palindrome#variable-font
tag: "CTTR" 
display_name: "Contrast Transition"
min_value: 0.0
default_value: 0.0
max_value: 2.0
precision: -1
fallback {
  name: "Translation"
  value: 0.0
}
fallback {
  name: "Expansion"
  value: 1.0
}
fallback {
  name: "Rotation"
  value: 2.0
}
description: 
    "The modulation between thick and thin strokes and their characteristic "
    " contrast patterns migrate between different models of transition."

@vv-monsalve vv-monsalve changed the title Add Contrast Transition axis Add Contrast Transition (CTTR) axis May 19, 2022
@vv-monsalve
Copy link
Contributor Author

vv-monsalve commented Jun 7, 2022

Updating this proposal to include the Transitional fallback now included on the font project.

#Contrast Transition, base on https://github.com/originaltype/palindrome#variable-font
tag: "CTTR" 
display_name: "Contrast Transition"
min_value: 0.0
default_value: 0.0
max_value: 3.0
precision: -1
fallback {
  name: "Translation"
  value: 0.0
}
fallback {
  name: "Transitional"
  value: 1.0
}
fallback {
  name: "Expansion"
  value: 2.0
}
fallback {
  name: "Rotation"
  value: 3.0
}
description: 
    “The modulation between thick and thin strokes and their”
    “ characteristic contrast patterns migrate between different”
    “ models of transition transforming the overall font design.”

Palindrome2

@vv-monsalve vv-monsalve added the --new-axis New variable axis definition label Aug 23, 2022
@vv-monsalve
Copy link
Contributor Author

vv-monsalve commented Jul 20, 2023

Updating the metadata fields following the defined specifications for custom axes and the definitions in the font that is introducing the axis:

#Contrast Transition, based on https://github.com/originaltype/Illusio-VF
tag: "CTTR" 
display_name: "Contrast Transition"
min_value: 1.0
default_value: 1.0
max_value: 3.0
precision: -1
fallback {
  name: "Default"
  value: 1.0
}
fallback_only: false
description: 
    “The modulation between thick and thin strokes and their”
    “ characteristic contrast patterns migrate between different”
    “ models of transition transforming the overall font design.”

@vv-monsalve
Copy link
Contributor Author

vv-monsalve commented Aug 18, 2023

After a new revision to the axis we considered the following changes.

Display name: Contrast Type
To make it a more general-purpose axis that could allow for different implementations. It could control any of the elements of contrast (amount, location, transition), or some of them in a blended way.

tag: CTTY

Type of axis and range
A continuous range axis with a range 1.0..10.0 where each unit (1.0, 2.0) would indicate "whole" designs, and the intermediates are very intermediate. The 1 to 10 range will also help to communicate that there could be more than the three positions used in the font introducing the axis.

min_value: 1.0
default_value: 1.0
max_value: 10.0
precision: -1

Description
Yet to be revised and refined

“Adjust the one or more elements of contrast (amount, stress, transition)"
" to migrate between different models of contrast transforming the overall font design.”

cc @davelab6, @arturschmal

@vv-monsalve vv-monsalve changed the title Add Contrast Transition (CTTR) axis Add Contrast Type (CTTY) axis Aug 23, 2023
@davelab6
Copy link
Member

allow for different implementations

communicate that there could be more than the three positions used

Hmm. Since the range can always be expanded later, I am wary of preemptively doing so.

This typeface is made with reference to the Noordzij model of contrast - famously illustrated in the Noordzij Cube - and I wonder that in the GIF above, the Transitional design should be 0, with Translation at -1 and Expansion at +1 - to show these pull the design in different directions, and the default is a blend of the two.

(And then the 3rd dimension of the Cube is implemented as Weight.)

@davelab6
Copy link
Member

I also wonder if Transitional should be Rotation?

@vv-monsalve
Copy link
Contributor Author

vv-monsalve commented Aug 23, 2023

Hmm. Since the range can always be expanded later, I am wary of preemptively doing so.

We discussed this, but checking Element Shape as a reference, which is a similar case of a continuous range axis allowing to have "elements" defined at certain positions, that Axis goes 0--100, and the font introducing it uses 1--16 we considered the current 1--10 range. It starts at 1 to indicate "whole" designs, in which case 0 was not meaningful.

the Transitional design should be 0, with Translation at -1 and Expansion at +1

Part of the original discussion for this axis included identifying that there are other models to control the contrast of a font (e.g. Rotation) and, therefore that this axis shouldn't be confined to these three models.

This is why we are considering registering the axis with a name and range that could leave space to support different implementations. E.g., a new font could use it to go from Translation to Rotation, or even in a broader sense, to go from "normal" to "reverse" without having to register a new axis.

@davelab6
Copy link
Member

a new font could use it to go from Translation to Rotation

I'm unsure.... My proposal also addresses a problem I see with that proposal...

fallback {
  name: "Translation"
  value: 0.0
}
fallback {
  name: "Expansion"
  value: 1.0
}
fallback {
  name: "Rotation"
  value: 2.0
}

Which is that a typeface could only offer contrast transitions of the translation and rotation kinds, and the 1.0 value wouldn't match the definition. Going beyond 2.0 to 3.0 and up to 10 (can we even actually today theorize of 10? In the original discussion @tiroj mentioned 1 more), the chance to skip some kinds, or arrange them in different orders, is big.

Yet, it seems highly speculative to me how those might work. Translation and Expansion are demonstrated as working on a continuum where the interpolation is useful. I don't like 0.0 to 0.5 to 1.0 as the 0.5 is a wholly coherent and drawn design here, and the 0 isn't an absence of the thing being varied. 1.0 to 2.0 to 3.0 is ok, but doesn't convey the min and max are pulling in different (conceptual) directions. -1 to 0 to +1 has that.

to go from "normal" to "reverse" without having to register a new axis.

In the original discussion, reverse contrast is proposed as within a different axis, "Contrast Location", as well as "Contrast Amount".

@arturschmal
Copy link

This typeface is made with reference to the Noordzij model of contrast - famously illustrated in the Noordzij Cube - and I wonder that in the GIF above, the Transitional design should be 0, with Translation at -1 and Expansion at +1 - to show these pull the design in different directions, and the default is a blend of the two.

I think this discussion has overlap on my thinking about what the default state of Illusio VF should be. Conceptually I don't think I'm comfortable with having either Translation or Expansion as a default. It would make more sense to me to have the blend (Transitional would be the best fitting term from a typographic history pov I guess) )of the two as the default state. This would show the user that you could get variations in opposite directions of the axis.

With this in mind having Transitional as 0 and Translation and Expansion at -1 and +1 would seem a gracious solution.

@vv-monsalve
Copy link
Contributor Author

Which is that a typeface could only offer contrast transitions of the translation and rotation kinds, and the 1.0 value wouldn't match the definition.

By admitting that there could be more to it beyond the concepts we've discussed (translation, expansion, rotation), we considered that the axis could be more broadly registered.

We no longer register the axes with fallbacks defined per axis registry, which opens room for the above possibility. We have registered the latest axes, making the type of axis and range as open as possible to multiple implementations. For this axis, the idea is to allow the use of the positions within the range to define "whole" designs by modifying the contrast. It could be either this historical approach of Illusio font or any other.

(can we even actually today theorize of 10?

We can definitely review the maximum value of 10 and decrease it. However, the idea of registering the axis with a higher max value is also to communicate from the registry itself that the axis could be used in different ways (beyond the most known models of contrast).

I don't like 0.0 to 0.5 to 1.0 as the 0.5 is a wholly coherent and drawn design here, and the 0 isn't an absence of the thing being varied. 1.0 to 2.0 to 3.0 is ok

Agree

but doesn't convey the min and max are pulling in different (conceptual) directions. -1 to 0 to +1 has that.

Registering the axis this way would tie it to the implementation of the “different directions” that Illusio is doing. But again, the axis could be used differently.

In the original discussion, reverse contrast is proposed as within a different axis, "Contrast Location", as well as "Contrast Amount".

Indeed. But precisely, the current idea is to register this axis in a way that allows all sorts of changes in contrast: location, amount, or transition without registering different separated axes. Similar to how the wgth axis operates with the multiple ways the "weight" might change or be interpreted by different fonts. We are now proposing this axis to work in a blended way.

We had mainly two reasons here:

  1. The parametric axes XOPQ and YOPQ can already work to control the "contrast amount", so we do not foresee registering a specific axis for this.
  2. Illusio is changing the contrast location (stress) following the contrast transition, so the axis is already blended.

@davelab6
Copy link
Member

Alright, fair point that we no longer centrally name axis positions.

So, I guess this is either a Contrast Type axis, where there can be 1, 2, 3, or more contrast-types offered along it; or, it is to be a Contrast Transition axis, where there are only 1 or 2, +1 or +1/-1.

I also do see your point about registering it in a future facing way, and since John points out there are 4 known kinds of contrast, I am OK if we all agree Contrast Type and then a range 1..2..3..4.

But I also wonder about -1..4, to allow both the current "pulling in opposite directions" and a future "catalog of options along a line" modes of varying contrast :)

@vv-monsalve
Copy link
Contributor Author

vv-monsalve commented Aug 25, 2023

After the last revision to this axis, it was decided to register it as a general-purpose axis around Contrast, with the following definitions agreed upon:

#Contrast, based on https://github.com/originaltype/Illusio-VF
tag: "CNTR"
display_name: "Contrast"
min_value: 1.0
default_value: 1.0
max_value: 4.0
precision: -1
fallback {
  name: "Default"
  value: 1.0
}
fallback_only: false
description: 
    “The modulation between thick and thin strokes and their”
    “ characteristic contrast patterns migrate between”
    “ different models.”

@vv-monsalve vv-monsalve changed the title Add Contrast Type (CTTY) axis Add Contrast (CNTR) axis Aug 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
--new-axis New variable axis definition
Projects
None yet
Development

No branches or pull requests

3 participants