Figure out why our Oswald has significantly different glyphs than fontmake's #250
Comments
|
The difference in glyph names is because in python fontmake the glyph names are renamed to final, "production" name (following AGLFN conventions), this is done in the ufo2ft postProcessor based on a number of conditions (e.g. presence of public.postscriptNames, if I remember the name of the lib key correctly, typing from memory) and options. It is done as a post-processing step because the feature file is supposed to contain source glyph names. The difference in point order is because fontmake-py reverses the contour direction by default when generating TrueType outlines, because it assumes that inputs are postscript cubic outlines and as such in counterclockwise direction as PS recommends, so the result of the direction flipping is that TT outlines get clockwise direction as recommended by the respective spec. |
|
I like how the spell checker corrects fontmake as "don't make" |
|
For better comparisons you can disable glyph renaming with --no-production-names, and also --keep-direction to not reverse contour direction. |
|
The flags are very handy short-term, ty. Should we ultimatley just implement the renaming and direction shifting? |
|
fontmake fontmake-rs The different choice of default likely explains why all our glyph coordinates are different. |
|
Much better after #252. A few major sources of difference remain:
|
|
I have WIP code that I didn't push yet for removing implied oncurves, will do when I get back next week. |
Safe bet that I screwed something up :D QQ, I thought we said fontmake only went one level deep with components by default but when I build Oswald with fontmake and inspect maxp it seems to be saying otherwise? <maxp>
...
<maxComponentElements value="4"/>
<maxComponentDepth value="3"/> <!-- isn't this supposed to be 0 or 1? -->
</maxp> |
|
(apparently if you press enough keys you can accidentally close an issue) |
|
No, what we said is fontmake keeps nested composite glyphs by default, but ufo2ft has an optional filter that flattens them to depth 1, and gftools builder activates that by default |
|
Ah yes, ty, I forgot gftools runs fontmake with unique arguments. Amusingly I just ran into the same thing with Roboto Serif: gftools effectively runs |
|
Updated the instructions on the milestone to suggest building with |
I wonder if it's because you're traversing the component tree in breadth-first order (you pop from the front/left of the frontier and extend at the back, rather than at the front), whereas ufo2ft |
|
hm.. I tried to follow the instructions from the https://github.com/googlefonts/fontmake-rs/milestone/4 but when I try to build Oswald.glyphs (checked out at latest commit from upstream Oswald repo), I get this error from fontc: |
|
In case anyone else looks here, use https://github.com/googlefonts/OswaldFont at 5298dbd8f4478518940aa047b1f498225a87b9ed. The latest (at time of writing) commit, 2570e33cf0e5fbadd4781108cbbf98f57e7faec3, introduced variation incompatible glyphs that fontc chokes on. #263 tracks adding a flag to ignore such problems. |
|
A fourth source of difference, fontmake seems to avoid glyph components that are themselves components. For example: <!-- both -->
<TTGlyph name="A">...simple glyph...</TTGlyph>
<TTGlyph name="A-cy" xMin="19" yMin="0" xMax="473" yMax="810">
<component glyphName="A" x="0" y="0" flags="0x204"/>
</TTGlyph>
<!-- fontmake (python) directly references A -->
<TTGlyph name="Abreve-cy" xMin="19" yMin="0" xMax="473" yMax="1009">
<component glyphName="A" x="0" y="0" flags="0x204"/>
<component glyphName="brevecomb-cy" x="-53" y="232" flags="0x4"/>
</TTGlyph>
<!-- fontc indirectly references A by way of A-cy (which is A with a 0 offset) -->
<TTGlyph name="Abreve-cy" xMin="19" yMin="0" xMax="473" yMax="1009">
<component glyphName="A-cy" x="0" y="0" flags="0x204"/>
<component glyphName="brevecomb-cy" x="-53" y="232" flags="0x4"/>
</TTGlyph>Guessing this is the work of one of the filters ( |
|
A fifth source of difference, there are glyphs where the bbox (xMin/Max, yMin/Max) fontc produces doesn't match that of fontmake. At a glance I think it's when an off-curve point contains the extrema; perhaps I managed to only included on-curve when computing (?) |
yeah, that's the result of --filter FlattenComponentsFilter, which un-nests components; it is not the default fontmake behavior and I am not 100% convinced it should be the default for the new fontmake-rs. I'm a bit wary to make the latter too opinionated and GF-specific. A font containing a component of a component (of a component, etc.) is perfectly valid anad up to spec. Only very ancient PS printers are reported to have issues with nested components (/cc I remember @moyogo knew more details), and gftools probalby likes to err on the side of caution. |
|
@anthrotype I don’t think this only affects "ancient" PS printers, but I have no data to prove nor disprove that. |
|
yeah, that "ancient" was my wishful thinking perhaps. BTW, this is the discussion in FontBakery that made us enable that filter by default in gftools: |
worth noting that vanilla fontmake does not enable this by default and I don't remember having received reports that this should be turned on by default from non gftools.builder users of fontmake. |
perhaps related to faulty bbox, I also noticed a sixth difference, that some of the left sidebearings (seems to be from the composite glyphs) are incorrectly set to 0 in the font built by fontc <hmtx>
<mtx name=".notdef" width="682" lsb="90"/>
<mtx name="A" width="492" lsb="19"/>
- <mtx name="A-cy" width="492" lsb="19"/>
+ <mtx name="A-cy" width="492" lsb="0"/>
<mtx name="AE" width="635" lsb="-51"/>
<mtx name="AEacute" width="635" lsb="-51"/>
<mtx name="Aacute" width="492" lsb="19"/>
@@ -1047,9 +1047,9 @@
<mtx name="Ccircumflex" width="515" lsb="48"/>
<mtx name="Cdotaccent" width="515" lsb="48"/>
<mtx name="Che-cy" width="551" lsb="50"/>
- <mtx name="Cheabkhasian-cy" width="695" lsb="15"/>
+ <mtx name="Cheabkhasian-cy" width="695" lsb="17"/>
<mtx name="Chedescender-cy" width="574" lsb="49"/>
- <mtx name="Chedescenderabkhasian-cy" width="685" lsb="15"/>
+ <mtx name="Chedescenderabkhasian-cy" width="685" lsb="17"/> |
|
the question is, do we want to keep repeating ourselves for the next thirty years that "some printer drivers do not handle nested components, or transformed components properly", or do we finally get to the bottom of this and give names and surnames to this buggy pieces of software and demand they get fixed finally? fontmake-rs is designed to be VF first, and VFs are relatively new technology, so we should be able to allow ourselves to break backward compatibility with pre-VF software. And one can always do the un-nesting and component decomposition when generating static instances that are meant to be used for non-VF-aware software like these unspecified "PS printer drivers"... |
|
Regarding the
Now, regarding the 2), unfortunately fontmake-py still does not do the right thing of decomposing components when an incompatible 2x2 transform occur in some masters -- it has been suggested several times but never implemenetedm cf. googlefonts/fontmake#595 (fontmake-rs correctly does that as of , whereas fontmake-rs does that now as of #266); however, since the optional ufo2ft DecomposeTransformedComponentsFilter was made mostly to tackle issue 1) (see googlefonts/ufo2ft#399), people who want to accomplish 2) also end up wanting to use that. But this gets rid not only of components whose 2x2 transform is different across masters, but of all transformed components everywhere, which is in my opinion too greedy and unwarranted, and I would like to insist that fontmake-rs does not do that by default. |
|
One issue with DecomposeTransformedComponentsFilter is that it filters per master instead of across all masters. So if one master doesn’t have transformed component and another does, an incompatibilty is introduced. |
So significantly so it makes me wonder if we are using the wrong master as default or something of that nature. Also the point order seems ... rotated?
The diff is huge; it will probably be helpful to start with a version of the source where most of the glyphs are deleted.
The text was updated successfully, but these errors were encountered: