freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ft-devel] sbix originOffsetX/Y interpretation.


From: Ben Wagner
Subject: [ft-devel] sbix originOffsetX/Y interpretation.
Date: Wed, 13 Mar 2019 15:11:54 -0400

I was making a test sbix font where I wanted the image not to have its lower left corner at 0,0 (which seems to be what most sbix fonts do). I ended up with different results from FreeType, CoreGraphics, and DirectWrite/Edge. The specification is difficult to interpret so I opened an issue for clarification at [1] where I summarize what seems to be the current state of sbix image placement and how the various implementations end up drawing the image where they do.

Of direct interest to FreeType is that CoreGraphics and DirectWrite/Edge interpret positive values of originOffsetY to move the image visually up. It appears the FreeType is currently using this to move the image visually down (which is what the specification seems to currently imply). With a sign reversal, FreeType would use this value in the same direction as the other implementations and fully match DirectWrite/Edge. 

Unfortunately, it turns out that CoreGraphics uses a different origin. It appears that if there is a entry for the glyph in the 'glyf' table, the lower left of the bbox of that glyph is used as the origin. This seems a strange offset, but CoreGraphics is probably the one to follow for what 'sbix' does, especially since some authoring tools document this so some fonts probably depend on this behavior. However, there don't appear to be that many fonts which depend on this behavior (possibly because all implementations are currently different), at least not yet.

That being said, convincing CoreGraphics to change when it is the de facto specification for sbix would be difficult. As a result, my current suggestion is just to document the current CoreGraphics behavior and clarify the specification. If there are objections, better proposals, or other comments, please see [1].

[1] https://github.com/MicrosoftDocs/typography-issues/issues/191

reply via email to

[Prev in Thread] Current Thread [Next in Thread]