diff options
| -rw-r--r-- | .gitignore | 1 | ||||
| -rw-r--r-- | python-ufo2ft.spec | 510 | ||||
| -rw-r--r-- | sources | 1 |
3 files changed, 512 insertions, 0 deletions
@@ -0,0 +1 @@ +/ufo2ft-2.31.1.tar.gz diff --git a/python-ufo2ft.spec b/python-ufo2ft.spec new file mode 100644 index 0000000..fb451b7 --- /dev/null +++ b/python-ufo2ft.spec @@ -0,0 +1,510 @@ +%global _empty_manifest_terminate_build 0 +Name: python-ufo2ft +Version: 2.31.1 +Release: 1 +Summary: A bridge between UFOs and FontTools. +License: MIT +URL: https://github.com/googlefonts/ufo2ft +Source0: https://mirrors.nju.edu.cn/pypi/web/packages/c1/ec/1b3ba245dd452394627793a1b66dbd44c1a3c1fd52965dd5c4d6cb21503f/ufo2ft-2.31.1.tar.gz +BuildArch: noarch + +Requires: python3-fonttools[ufo] +Requires: python3-cu2qu +Requires: python3-cffsubr +Requires: python3-booleanOperations +Requires: python3-compreffor +Requires: python3-skia-pathops + +%description +ufo2ft ("UFO to FontTools") is a fork of +`ufo2fdk <https://github.com/typesupply/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: + 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 <http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html>`__, +ufo2ft also supports the +`MTI/Monotype format <http://monotype.github.io/OpenType_Table_Source/otl_source.html>`__. +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. +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: + <key>com.github.googlei18n.ufo2ft.colorPalettes</key> + <array> + <array> + <array> + <real>0.26</real> + <real>0.0</real> + <real>0.23</real> + <real>1.0</real> + </array> + <array> + <real>0.86</real> + <real>0.73</real> + <real>0.28</real> + <real>1.0</real> + </array> + </array> + </array> +``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: + <key>com.github.googlei18n.ufo2ft.colorLayerMapping</key> + <array> + <array> + <string>color.1</string> + <integer>1</integer> + </array> + <array> + <string>color.2</string> + <integer>0</integer> + </array> + </array> +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: + <key>com.github.googlei18n.ufo2ft.colorLayers</key> + <dict> + <key>alef-ar</key> + <array> + <array> + <string>alef-ar.color0</string> + <integer>2</integer> + </array> + </array> + <key>alefHamzaabove-ar</key> + <array> + <array> + <string>alefHamzaabove-ar.color0</string> + <integer>1</integer> + </array> + <array> + <string>alefHamzaabove-ar.color1</string> + <integer>2</integer> + </array> + </array> + <dict> + +%package -n python3-ufo2ft +Summary: A bridge between UFOs and FontTools. +Provides: python-ufo2ft +BuildRequires: python3-devel +BuildRequires: python3-setuptools +BuildRequires: python3-pip +%description -n python3-ufo2ft +ufo2ft ("UFO to FontTools") is a fork of +`ufo2fdk <https://github.com/typesupply/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: + 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 <http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html>`__, +ufo2ft also supports the +`MTI/Monotype format <http://monotype.github.io/OpenType_Table_Source/otl_source.html>`__. +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. +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: + <key>com.github.googlei18n.ufo2ft.colorPalettes</key> + <array> + <array> + <array> + <real>0.26</real> + <real>0.0</real> + <real>0.23</real> + <real>1.0</real> + </array> + <array> + <real>0.86</real> + <real>0.73</real> + <real>0.28</real> + <real>1.0</real> + </array> + </array> + </array> +``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: + <key>com.github.googlei18n.ufo2ft.colorLayerMapping</key> + <array> + <array> + <string>color.1</string> + <integer>1</integer> + </array> + <array> + <string>color.2</string> + <integer>0</integer> + </array> + </array> +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: + <key>com.github.googlei18n.ufo2ft.colorLayers</key> + <dict> + <key>alef-ar</key> + <array> + <array> + <string>alef-ar.color0</string> + <integer>2</integer> + </array> + </array> + <key>alefHamzaabove-ar</key> + <array> + <array> + <string>alefHamzaabove-ar.color0</string> + <integer>1</integer> + </array> + <array> + <string>alefHamzaabove-ar.color1</string> + <integer>2</integer> + </array> + </array> + <dict> + +%package help +Summary: Development documents and examples for ufo2ft +Provides: python3-ufo2ft-doc +%description help +ufo2ft ("UFO to FontTools") is a fork of +`ufo2fdk <https://github.com/typesupply/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: + 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 <http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html>`__, +ufo2ft also supports the +`MTI/Monotype format <http://monotype.github.io/OpenType_Table_Source/otl_source.html>`__. +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. +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: + <key>com.github.googlei18n.ufo2ft.colorPalettes</key> + <array> + <array> + <array> + <real>0.26</real> + <real>0.0</real> + <real>0.23</real> + <real>1.0</real> + </array> + <array> + <real>0.86</real> + <real>0.73</real> + <real>0.28</real> + <real>1.0</real> + </array> + </array> + </array> +``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: + <key>com.github.googlei18n.ufo2ft.colorLayerMapping</key> + <array> + <array> + <string>color.1</string> + <integer>1</integer> + </array> + <array> + <string>color.2</string> + <integer>0</integer> + </array> + </array> +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: + <key>com.github.googlei18n.ufo2ft.colorLayers</key> + <dict> + <key>alef-ar</key> + <array> + <array> + <string>alef-ar.color0</string> + <integer>2</integer> + </array> + </array> + <key>alefHamzaabove-ar</key> + <array> + <array> + <string>alefHamzaabove-ar.color0</string> + <integer>1</integer> + </array> + <array> + <string>alefHamzaabove-ar.color1</string> + <integer>2</integer> + </array> + </array> + <dict> + +%prep +%autosetup -n ufo2ft-2.31.1 + +%build +%py3_build + +%install +%py3_install +install -d -m755 %{buildroot}/%{_pkgdocdir} +if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi +if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi +if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi +if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi +pushd %{buildroot} +if [ -d usr/lib ]; then + find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/lib64 ]; then + find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/bin ]; then + find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/sbin ]; then + find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst +fi +touch doclist.lst +if [ -d usr/share/man ]; then + find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst +fi +popd +mv %{buildroot}/filelist.lst . +mv %{buildroot}/doclist.lst . + +%files -n python3-ufo2ft -f filelist.lst +%dir %{python3_sitelib}/* + +%files help -f doclist.lst +%{_docdir}/* + +%changelog +* Fri May 05 2023 Python_Bot <Python_Bot@openeuler.org> - 2.31.1-1 +- Package Spec generated @@ -0,0 +1 @@ +47d92abd7163a0a1adc92263e95a10e2 ufo2ft-2.31.1.tar.gz |