Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/googlefonts/ufo2ft

A bridge from UFOs to FontTools objects (and therefore, OTFs and TTFs).
https://github.com/googlefonts/ufo2ft

Last synced: about 23 hours ago
JSON representation

A bridge from UFOs to FontTools objects (and therefore, OTFs and TTFs).

Awesome Lists containing this project

README 

        
|GitHub Actions status| |PyPI Version| |Codecov| |Gitter Chat|



ufo2ft

======



ufo2ft ("UFO to FontTools") is a fork of

`ufo2fdk `__ whose goal is to

generate OpenType font binaries from UFOs without the FDK dependency.



The library provides two functions, ``compileOTF`` and ``compileTTF``,

which work exactly the same way:



.. code:: python



    from defcon import Font

    from ufo2ft import compileOTF

    ufo = Font('MyFont-Regular.ufo')

    otf = compileOTF(ufo)

    otf.save('MyFont-Regular.otf')



In most cases, the behavior of ufo2ft should match that of ufo2fdk,

whose documentation is retained below (and hopefully is still accurate).



Naming Data

~~~~~~~~~~~



As with any OpenType compiler, you have to set the font naming data to a

particular standard for your naming to be set correctly. In ufo2fdk, you

can get away with setting *two* naming attributes in your font.info

object for simple fonts:



-  familyName: The name for your family. For example, "My Garamond".

-  styleName: The style name for this particular font. For example,

   "Display Light Italic"



ufo2fdk will create all of the other naming data based on thse two

fields. If you want to use the fully automatic naming system, all of the

other name attributes should be set to ``None`` in your font. However,

if you want to override the automated system at any level, you can

specify particular naming attributes and ufo2fdk will honor your

settings. You don't have to set *all* of the attributes, just the ones

you don't want to be automated. For example, in the family "My Garamond"

you have eight weights. It would be nice to style map the italics to the

romans for each weight. To do this, in the individual romans and

italics, you need to set the style mapping data. This is done through

the ``styleMapFamilyName`` and ``styleMapStyleName`` attributes. In each

of your roman and italic pairs you would do this:



**My Garamond-Light.ufo**



-  familyName = "My Garamond"

-  styleName = "Light"

-  styleMapFamilyName = "My Garamond Display Light"

-  styleMapStyleName = "regular"



**My Garamond-Light Italic.ufo**



-  familyName = "My Garamond"

-  styleName = "Display Light Italic"

-  styleMapFamilyName = "My Garamond Display Light"

-  styleMapStyleName = "italic"



**My Garamond-Book.ufo**



-  familyName = "My Garamond"

-  styleName = "Book"

-  styleMapFamilyName = "My Garamond Display Book"

-  styleMapStyleName = "regular"



**My Garamond-Book Italic.ufo**



-  familyName = "My Garamond"

-  styleName = "Display Book Italic"

-  styleMapFamilyName = "My Garamond Display Book"

-  styleMapStyleName = "italic"



**etc.**



Additionally, if you have defined any naming data, or any data for that

matter, in table definitions within your font's features that data will

be honored.



Feature generation

~~~~~~~~~~~~~~~~~~



If your font's features do not contain kerning/mark/mkmk features,

ufo2ft will create them based on your font's kerning/anchor data.



In addition to

`Adobe OpenType feature files `__,

ufo2ft also supports the

`MTI/Monotype format `__.

For example, a GPOS table in this format would be stored within the UFO at

``data/com.github.googlei18n.ufo2ft.mtiFeatures/GPOS.mti``.



Fallbacks

~~~~~~~~~



Most of the fallbacks have static values. To see what is set for these,

look at ``fontInfoData.py`` in the source code.



In some cases, the fallback values are dynamically generated from other

data in the info object. These are handled internally with functions.



Merging TTX

~~~~~~~~~~~



If the UFO data directory has a ``com.github.fonttools.ttx`` folder with TTX

files ending with ``.ttx``, these will be merged in the generated font.

The index TTX (generated when using using ``ttx -s``) is not required.



.. |GitHub Actions status| image:: https://github.com/googlefonts/ufo2ft/workflows/Test%20+%20Deploy/badge.svg

.. |PyPI Version| image:: https://img.shields.io/pypi/v/ufo2ft.svg

   :target: https://pypi.org/project/ufo2ft/

.. |Codecov| image:: https://codecov.io/gh/googlefonts/ufo2ft/branch/master/graph/badge.svg

   :target: https://codecov.io/gh/googlefonts/ufo2ft

.. |Gitter Chat| image:: https://badges.gitter.im/fonttools-dev/ufo2ft.svg

   :alt: Join the chat at https://gitter.im/fonttools-dev/ufo2ft

   :target: https://gitter.im/fonttools-dev/ufo2ft?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge



Color fonts

~~~~~~~~~~~



ufo2ft supports building ``COLR`` and ``CPAL`` tables.



If there is ``com.github.googlei18n.ufo2ft.colorPalettes`` key in font lib, and

``com.github.googlei18n.ufo2ft.colorLayerMapping`` key in the font or

in any of the glyphs lib, then ufo2ft will build ``CPAL`` table from the color

palettes, and ``COLR`` table from the color layers.



``colorPalettes`` is a array of palettes, each palette is a array of colors and

each color is a array of floats representing RGBA colors. For example:



.. code:: xml



    com.github.googlei18n.ufo2ft.colorPalettes

    

      

        

          0.26

          0.0

          0.23

          1.0

        

        

          0.86

          0.73

          0.28

          1.0

        

      

    



``colorLayerMapping`` is a array of color layers, each color layer is a array of

layer name and palette color index. It is a per-glyph key, but if present in

the font lib then it will be used for all glyphs that lack it. For example:



.. code:: xml



      com.github.googlei18n.ufo2ft.colorLayerMapping

      

        

          color.1

          1

        

        

          color.2

          0

        

      



With these this key present, ufo2ft will copy the color layers into individual

glyphs and setup ``COLR`` table.



Alternatively, if the color layers are already separate UFO glyphs, the

``com.github.googlei18n.ufo2ft.colorLayers`` font lib key can be used. It uses

a table keyed by base glyph, and the value is an array of color layers, each

color layer is an array of glyph name and palette color index. For example:



.. code:: xml



    com.github.googlei18n.ufo2ft.colorLayers

    

      alef-ar

      

        

          alef-ar.color0

          2

        

      

      alefHamzaabove-ar

      

        

          alefHamzaabove-ar.color0

          1

        

        

          alefHamzaabove-ar.color1

          2

        

      

    



Setup Notes

~~~~~~~~~~~



If you are installing ufo2ft from source, note that the strict dependency versions in `requirements.txt` are

for testing, see `setup.py`'s install_requires and extras_requires for more relaxed dependency requirements.