Giter VIP home page Giter VIP logo

variable-components-in-ufo's Issues

Local sources mixing global axes and local axes

  • We have a .designspace with a Weight axis; the system has two sources: Regular.ufo and Bold.ufo
  • A glyph has a "regular" source and a "bold"
  • We add a local axis to this otherwise normal glyph, so we can specialize it when used as a component
  • Now we have a local variation system for this glyph, and it uses one global axis and one local axis

It would be good if we can still store the Bold source in Bold.ufo.

The local designspace is stored in the default source for the glyph.

We can implement the mixed system in two ways:

  1. All sources for the local system must be listed, and a source must be able to reference a different UFO explicitly
  2. Only sources using local axes are listed, and the global sources are implied to be part of the system, too

The latter allows us to get away wihtout explicitly specifying the non-default UFO source.

Perhaps we should do the following:

  • For each source location, split the local part from the global part
  • Find the global UFO sources matching the global part, store local variation there as layers

Add simple example of glyph-designspace

To illustrate the documentation a basic example would be useful, such as this:
Example of local glyph-designspace

<?xml version='1.0' encoding='UTF-8'?>
<glyph name="VariableGlyph" format="2">
  <outline>
    <contour>
      <point x="-10" y="-10" type="line"/>
      <point x="10" y="-10" type="line"/>
      <point x="10" y="10" type="line"/>
      <point x="-10" y="10" type="line"/>
    </contour>
  </outline>
  <lib>
    <dict>
      <key>com.black-foundry.glyph-designspace</key>
      <dict>
        <key>axes</key>
        <array>
          <dict>
            <key>default</key>
            <integer>20</integer>
            <key>maximum</key>
            <integer>700</integer>
            <key>minimum</key>
            <integer>20</integer>
            <key>name</key>
            <string>height</string>
          </dict>
          <dict>
            <key>default</key>
            <integer>20</integer>
            <key>maximum</key>
            <integer>700</integer>
            <key>minimum</key>
            <integer>20</integer>
            <key>name</key>
            <string>width</string>
          </dict>
        </array>
        <key>sources</key>
        <array>
          <dict>
            <key>location</key>
            <dict>
              <key>height</key>
              <real>20.0</real>
              <key>width</key>
              <real>20.0</real>
            </dict>
          </dict>
          <dict>
            <key>layername</key>
            <string>width=200,height=700</string>
            <key>location</key>
            <dict>
              <key>height</key>
              <integer>700</integer>
            </dict>
          </dict>
          <dict>
            <key>layername</key>
            <string>width=700,height=700</string>
            <key>location</key>
            <dict>
              <key>height</key>
              <integer>700</integer>
              <key>width</key>
              <integer>700</integer>
            </dict>
          </dict>
          <dict>
            <key>layername</key>
            <string>width=700,height=200</string>
            <key>location</key>
            <dict>
              <key>width</key>
              <integer>700</integer>
            </dict>
          </dict>
        </array>
      </dict>
    </dict>
  </lib>
</glyph>

The Default glyph has 3 additional layers used as sources in the designspace above:
Layer width=200,height=700

<?xml version='1.0' encoding='UTF-8'?>
<glyph name="VariableGlyph" format="2">
  <outline>
    <contour>
      <point x="-10" y="-350" type="line"/>
      <point x="10" y="-350" type="line"/>
      <point x="10" y="350" type="line"/>
      <point x="-10" y="350" type="line"/>
    </contour>
  </outline>
</glyph>

Layer width=700,height=200

<?xml version='1.0' encoding='UTF-8'?>
<glyph name="VariableGlyph" format="2">
  <outline>
    <contour>
      <point x="-350" y="-10" type="line"/>
      <point x="350" y="-10" type="line"/>
      <point x="350" y="10" type="line"/>
      <point x="-350" y="10" type="line"/>
    </contour>
  </outline>
</glyph>

Layer width=700,height=700

<?xml version='1.0' encoding='UTF-8'?>
<glyph name="VariableGlyph" format="2">
  <outline>
    <contour>
      <point x="-350" y="-350" type="line"/>
      <point x="350" y="-350" type="line"/>
      <point x="350" y="350" type="line"/>
      <point x="-350" y="350" type="line"/>
    </contour>
  </outline>
</glyph>

source name?

Should the source have a "name" key?

This is a UI-only field that could be ignored when building a font. In Fontra, the source name is an important UI feature, and I think the representation in UFO should be able to store it.

It could perhaps also be an optional field, falling back to the layername.

Add simple example of a glyph using variable components

To illustrate the documentation, a simple example like the one below would be useful.
Here the glyph Box uses 4 instances of the variable glyph VariableGlyph.

<?xml version='1.0' encoding='UTF-8'?>
<glyph name="Box" format="2">
  <advance width="500"/>
  <outline>
  </outline>
  <lib>
    <dict>
      <key>com.black-foundry.variable-components</key>
      <array>
        <dict>
          <key>base</key>
          <string>VariableGlyph</string>
          <key>location</key>
          <dict>
            <key>height</key>
            <integer>700</integer>
            <key>width</key>
            <integer>80</integer>
          </dict>
          <key>transformation</key>
          <dict>
            <key>rotation</key>
            <integer>0</integer>
            <key>scaleX</key>
            <integer>1</integer>
            <key>scaleY</key>
            <integer>1</integer>
            <key>skewX</key>
            <integer>0</integer>
            <key>skewY</key>
            <integer>0</integer>
            <key>tCenterX</key>
            <integer>0</integer>
            <key>tCenterY</key>
            <integer>0</integer>
            <key>translateX</key>
            <integer>40</integer>
            <key>translateY</key>
            <integer>310</integer>
          </dict>
        </dict>
        <dict>
          <key>base</key>
          <string>VariableGlyph</string>
          <key>location</key>
          <dict>
            <key>height</key>
            <integer>700</integer>
            <key>width</key>
            <integer>80</integer>
          </dict>
          <key>transformation</key>
          <dict>
            <key>rotation</key>
            <integer>0</integer>
            <key>scaleX</key>
            <integer>1</integer>
            <key>scaleY</key>
            <integer>1</integer>
            <key>skewX</key>
            <integer>0</integer>
            <key>skewY</key>
            <integer>0</integer>
            <key>tCenterX</key>
            <integer>0</integer>
            <key>tCenterY</key>
            <integer>0</integer>
            <key>translateX</key>
            <integer>460</integer>
            <key>translateY</key>
            <integer>310</integer>
          </dict>
        </dict>
        <dict>
          <key>base</key>
          <string>VariableGlyph</string>
          <key>location</key>
          <dict>
            <key>height</key>
            <integer>80</integer>
            <key>width</key>
            <integer>500</integer>
          </dict>
          <key>transformation</key>
          <dict>
            <key>rotation</key>
            <integer>0</integer>
            <key>scaleX</key>
            <integer>1</integer>
            <key>scaleY</key>
            <integer>1</integer>
            <key>skewX</key>
            <integer>0</integer>
            <key>skewY</key>
            <integer>0</integer>
            <key>tCenterX</key>
            <integer>0</integer>
            <key>tCenterY</key>
            <integer>0</integer>
            <key>translateX</key>
            <integer>250</integer>
            <key>translateY</key>
            <integer>0</integer>
          </dict>
        </dict>
        <dict>
          <key>base</key>
          <string>VariableGlyph</string>
          <key>location</key>
          <dict>
            <key>height</key>
            <integer>80</integer>
            <key>width</key>
            <integer>500</integer>
          </dict>
          <key>transformation</key>
          <dict>
            <key>rotation</key>
            <integer>0</integer>
            <key>scaleX</key>
            <integer>1</integer>
            <key>scaleY</key>
            <integer>1</integer>
            <key>skewX</key>
            <integer>0</integer>
            <key>skewY</key>
            <integer>0</integer>
            <key>tCenterX</key>
            <integer>0</integer>
            <key>tCenterY</key>
            <integer>0</integer>
            <key>translateX</key>
            <integer>250</integer>
            <key>translateY</key>
            <integer>620</integer>
          </dict>
        </dict>
      </array>
    </dict>
  </lib>
</glyph>

source filename: remove or restrict?

Currently, the source filename is allowed to point at any nearby UFO (if omitted, the default UFO is meant).

Consider:

  • Require that the UFO is one of the sources in the .designspace file
    Or:
  • Remove the filename key, and require all variable component sources be layers in the default UFO

I'm strongly inclined to remove the "filename" key, and reconsider once a use case comes up.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.