Decompose scaled or rotated components

[moyogo]

This adds a filter to decomposed rotated or scaled components. Some TrueType implementations don’t deal well with those.

[madig]

Some TrueType implementations don’t deal well with those.

Which ones? :O

[anthrotype]

Shouldn't this filter class live in its own separate module?

I think that's what is expectated for the getFilterClass function used by loadFilters to load the filters from the lib.plist:

ufo2ft/Lib/ufo2ft/filters/__init__.py

Lines 14 to 26 in e1c08f6

	def getFilterClass(filterName, pkg="ufo2ft.filters"):
	"""Given a filter name, import and return the filter class.
	By default, filter modules are searched within the ``ufo2ft.filters``
	package.
	"""
	# TODO add support for third-party plugin discovery?
	# if filter name is 'Foo Bar', the module should be called 'fooBar'
	filterName = filterName.replace(" ", "")
	moduleName = filterName[0].lower() + filterName[1:]
	module = importlib.import_module(".".join([pkg, moduleName]))
	# if filter name is 'Foo Bar', the class should be called 'FooBarFilter'
	className = filterName[0].upper() + filterName[1:] + "Filter"
	return getattr(module, className)

[anthrotype]

I believe Denis is referring to those transformations (like flipping horizontally/vertically) that reverse the component's contour direction, and thus may create white gaps if such transformed components overlap with other components. Am I right?

There's code in ufo2ft.util.deepCopyContours that checks for those transforms (a negative determinant is the trigger):

ufo2ft/Lib/ufo2ft/util.py

Lines 192 to 197 in e1c08f6

	pen = TransformPen(parent.getPen(), transformation)
	# if the transformation has a negative determinant, it will
	# reverse the contour direction of the component
	xx, xy, yx, yy = transformation[:4]
	if xx * yy - xy * yx < 0:
	pen = ReverseContourPen(pen)

Perhaps the issue is that by default we only decomposing glyphs that are "mixed" with both contour and components; whereas Denis would like to trigger this for such problematic composite glyphs as well.

There's also a related fontmake issue: googlefonts/fontmake#253 (comment)

[anthrotype]

I don't think there's anything wrong with merely having a component scaled or rotated, I've never come across an implementation that doesn't render such components properly. It's when they overlap other components and have transforms that flip their direction that you get rendering issues (as exemplified in the linked fontmake issue)

[moyogo]

Some TrueType implementations don’t deal well with those.

Which ones? :O

Any implementation of the TrueType implementation that doesn’t understand the component flags SCALED_COMPONENT_OFFSET or UNSCALED_COMPONENT_OFFSET for example, or any implementation that expects the component flag WE_HAVE_A_SCALE to apply scaling.

We probably should set more flags from https://docs.microsoft.com/en-us/typography/opentype/spec/glyf#composite-glyph-description.
But even then, there’s still the issue of implementations that are not aware of the SCALED_COMPONENT_OFFSET or UNSCALED_COMPONENT_OFFSET flags, for example if they follow only https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6glyf.html which doesn’t mention those flags.

[moyogo]

Shouldn't this filter class live in its own separate module?

I moved the filter to its own module.

http://pfaedit.sourceforge.net/Composites/ (pfaedit is the super old name of Fontforge) also documents the issue about how Apple’s and Microsoft’s understanding of scaled components differs.

[khaledhosny]

I have been using scaled and rotated components for almost 10 years, if there is a problem I would have known by now.

The only issue I had with components was Mac OS X not liking nested components (they get displaced), so for a long time I had code to de-nest them, but I dropped this recently because I can no longer reproduce it, no complaints so far.

[khaledhosny]

(nested and transformed components, that is it)

[moyogo]

There are several printers that have issues with nested components. See for example JulietaUla/Montserrat#108 which I suspect is the issue, since Udieresis has a nested component.
Dalton Maag had clients that had the issue a couple of times ; in fact one of the printers from this decade at their office even has the nested component issue (or at least when I was there).
The flattenComponentsFilter can be used to flatten nested components to basic components.

For scaled components, this merge request is for a module that is optional, like the flattenComponentsFilter one is. I have no intention in making fontmake/ufo2ft using it be default.
There are a few workflows where it can be useful:

• VF with components scaled by different 2x2 transforms in different masters, see should decompose components with different 2x2 transforms when building VF fontmake#595 (comment)
• When working with VTT Components: Rotated or scaled components davelab6/opensans-1#36 (comment) (which is probably the same issue as the first)
• When working with ttfautohint Check glyphs are not constructed from transformed components fonttools/fontbakery#2011

[anthrotype]

Yes, makes sense to have such an optional filter available.
Can we name it "Decompose Transformed Components" instead of just "Scaled"?

Note that Glyphs.app has a custom parameter "Keep Transformed Components" which off by default; so by default Glyphs.app will decompose "distorted and mirrored components", unless that parameter is set. See https://glyphsapp.com/blog/new-features-in-glyphs-2-5

[moyogo]

I’ve renamed it "Decompose Transformed Components".