Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
> So, to summarize, the new behavior is sTypo (if UseTypoMetrics), > then hhea (if not 0), then sTypo (if not 0), then usWin. This is > now consistent across all fonts; variable fonts do not have a > different fallback order. Variable fonts will apply the MVAR deltas > to whichever metrics were picked. Thanks for this summary! I added something along your lines to FreeType's `CHANGES' file. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
Fully agree. Thanks Nikolaus and Ben. On Mon, Feb 4, 2019, 3:06 PM Ben Wagner wrote: > So, to summarize, the new behavior is sTypo (if UseTypoMetrics), then hhea > (if not 0), then sTypo (if not 0), then usWin. This is now consistent > across all fonts; variable fonts do not have a different fallback order. > Variable fonts will apply the MVAR deltas to whichever metrics were picked. > > This explains the behavior change seen when rolling this into Chromium ( > https://chromium-review.googlesource.com/c/chromium/src/+/1452712 ) and > the change to the cff2 font ( > https://test-results.appspot.com/data/layout_results/linux-blink-rel/6261/webkit_layout_tests%20%28with%20patch%29/layout-test-results/results.html > ). This is AdobeVFPrototype.otf (checked into blink's test resources) and > it does not set the UseTypoMetrics bit, so we're using the FreeType > computed metrics. The MVAR for this font only has 'stro' and 'xhgt', so no > variable adjustments. What has changed is that FreeType now provides the > hhea metrics instead of the sTypo metrics since UseTypoMetrics isn't set. > > Overall I like this change, this behavior is easier to reason about. This > particular font didn't ask nicely to use the sTypo metrics, and it's > probably a good thing to keep it that way to keep testing this case. > > > > Le lun. 4 févr. 2019 à 01:46, Werner LEMBERG a écrit : > >> > Done, pushed and fingers crossed. >> >> Thanks! >> >> >> Werner >> > ___ > Freetype-devel mailing list > Freetype-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/freetype-devel > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
So, to summarize, the new behavior is sTypo (if UseTypoMetrics), then hhea (if not 0), then sTypo (if not 0), then usWin. This is now consistent across all fonts; variable fonts do not have a different fallback order. Variable fonts will apply the MVAR deltas to whichever metrics were picked. This explains the behavior change seen when rolling this into Chromium ( https://chromium-review.googlesource.com/c/chromium/src/+/1452712 ) and the change to the cff2 font ( https://test-results.appspot.com/data/layout_results/linux-blink-rel/6261/webkit_layout_tests%20%28with%20patch%29/layout-test-results/results.html ). This is AdobeVFPrototype.otf (checked into blink's test resources) and it does not set the UseTypoMetrics bit, so we're using the FreeType computed metrics. The MVAR for this font only has 'stro' and 'xhgt', so no variable adjustments. What has changed is that FreeType now provides the hhea metrics instead of the sTypo metrics since UseTypoMetrics isn't set. Overall I like this change, this behavior is easier to reason about. This particular font didn't ask nicely to use the sTypo metrics, and it's probably a good thing to keep it that way to keep testing this case. Le lun. 4 févr. 2019 à 01:46, Werner LEMBERG a écrit : > > Done, pushed and fingers crossed. > > Thanks! > > > Werner > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
> Done, pushed and fingers crossed. Thanks! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
Done, pushed and fingers crossed. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
> Thanks for chiming in. Well, the patch works and at least two people > say it's the right thing to do, so I'd say let's merge it. Werner, > is that ok? OK with me, thanks. Please check the code formatting to be in sync with the remaining parts of FreeType! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
Thanks for chiming in. Well, the patch works and at least two people say it's the right thing to do, so I'd say let's merge it. Werner, is that ok? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
I believe that Chromium is using Skia's reported font metrics which are currently calculated at https://skia.googlesource.com/skia/+/00dcf668659ab26b8691c64a977fdd19e9e8df09/src/ports/SkFontHost_FreeType.cpp#1411 . The biggest issue is that historically (and as noted above) FT_Face would always use HHEA metrics if they weren't 0, and then fallback to usWin or typo and UseTypoMetrics wasn't looked at to change the priority. As a result Skia has code to look at the UseTypoMetrics bit and if set reads the values from the (FreeType generated) OS/2 table if available instead of using the FT_Face values. So if FreeType interpolates the TT_OS2.sTypo* values in the table it creates for an FT_Face then that should get picked up by any font which sets UseTypoMetrics. Any font which doesn't set UseTypoMetrics will get whatever the FT_Face says to do (except bitmap only fonts use FT_Face.size.metrics values). I think it would be great for FreeType to look at the UseTypoMetrics bit. This would allow for the (eventual) simplification of the Skia code. Le mer. 30 janv. 2019 à 20:21, Nikolaus Waxweiler a écrit : > The short version is that Firefox and Chromium seem to directly access > hhea and typo themselves. The patches seem to have no effect except that > Chromium seems to react to freetype not blindly setting typo values in VF > instances anymore, but only with small metrics changes. > > GTK and Qt let text and UI elements compress if bit 7 is set and typo > ascender plus descender < hhea ascender plus descender. I have no idea how > much this is the result of theming in either toolkit and if it is what is > supposed to happen. > > So. > > Still not sure we want mvar typo deltas to modify currently active metrics? > > ... Merge and break out asbestos pants? > ___ > Freetype-devel mailing list > Freetype-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/freetype-devel > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
The short version is that Firefox and Chromium seem to directly access hhea and typo themselves. The patches seem to have no effect except that Chromium seems to react to freetype not blindly setting typo values in VF instances anymore, but only with small metrics changes. GTK and Qt let text and UI elements compress if bit 7 is set and typo ascender plus descender < hhea ascender plus descender. I have no idea how much this is the result of theming in either toolkit and if it is what is supposed to happen. So. Still not sure we want mvar typo deltas to modify currently active metrics? ... Merge and break out asbestos pants? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
I must confess I haven't fully followed your reports. On Wed, Jan 30, 2019 at 4:49 PM Nikolaus Waxweiler wrote: > Then what should happen is that everything is just shifted, no? E.g. Qt > does this: > > https://i.postimg.cc/ZR3x17mw/Bildschirmfoto-vom-2019-01-31-00-09-31.png > https://i.postimg.cc/PJjQhWrT/Bildschirmfoto-vom-2019-01-31-00-09-56.png > > Text becomes compressed. > Am Do, 31. Jan, 2019 um 12:38 A. M. schrieb Behdad Esfahbod > : > > That's what line-gap is: gap between consecutive lines. There is no > > line before the first line, and as such, no gap. > > -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
Then what should happen is that everything is just shifted, no? E.g. Qt does this: https://i.postimg.cc/ZR3x17mw/Bildschirmfoto-vom-2019-01-31-00-09-31.png https://i.postimg.cc/PJjQhWrT/Bildschirmfoto-vom-2019-01-31-00-09-56.png Text becomes compressed. Am Do, 31. Jan, 2019 um 12:38 A. M. schrieb Behdad Esfahbod : That's what line-gap is: gap between consecutive lines. There is no line before the first line, and as such, no gap. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
That's what line-gap is: gap between consecutive lines. There is no line before the first line, and as such, no gap. On Wed, Jan 30, 2019 at 4:37 PM Nikolaus Waxweiler wrote: > Even more testing. > > ftview and Qt actually do the same GTK does: they don't add the line > gap to the top, so text fields look compressed when the > USE_TYPO_METRICS bit is set and typo asc+desc is smaller than hhea > asc+desc. I'm not sure this is supposed to happen?! Didn't test MVAR > modification. > > Firefox and Chromium disregard FT_Face's ascender, descender and height > attributes and use either hhea (I think; no USE_TYPO_METRICS) or typo > metrics (USE_TYPO_METRICS), modifying typo metrics and the FT_Face > attributes through the MVAR table therefore has no effect unless the > USE_TYPO_METRICS bit is set. > > The document body of a new text file in LibreOffice Writer 6.1.4.2 > stays the same regardless of bit so I think LO Writer is doing it > right. It doesn't support VFs though so I can't test MVAR modifications. > > Behdad, I'm not completely sure of typo deltas in MVAR modifying the > currently active metrics. Given that the hhea set is basically a legacy > value and is probably taller spaced than the typo metrics, so we might > end up doing things the designer didn't intend? What FF/Chromium do > strikes me as saner, i.e. writing typo metrics to FT_Face > ascender/descender/height when USE_TYPO_METRICS is set :/ > > Otherwise, I'd say unless anyone has objections, I think we can merge > the branch. > > -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
Even more testing. ftview and Qt actually do the same GTK does: they don't add the line gap to the top, so text fields look compressed when the USE_TYPO_METRICS bit is set and typo asc+desc is smaller than hhea asc+desc. I'm not sure this is supposed to happen?! Didn't test MVAR modification. Firefox and Chromium disregard FT_Face's ascender, descender and height attributes and use either hhea (I think; no USE_TYPO_METRICS) or typo metrics (USE_TYPO_METRICS), modifying typo metrics and the FT_Face attributes through the MVAR table therefore has no effect unless the USE_TYPO_METRICS bit is set. The document body of a new text file in LibreOffice Writer 6.1.4.2 stays the same regardless of bit so I think LO Writer is doing it right. It doesn't support VFs though so I can't test MVAR modifications. Behdad, I'm not completely sure of typo deltas in MVAR modifying the currently active metrics. Given that the hhea set is basically a legacy value and is probably taller spaced than the typo metrics, so we might end up doing things the designer didn't intend? What FF/Chromium do strikes me as saner, i.e. writing typo metrics to FT_Face ascender/descender/height when USE_TYPO_METRICS is set :/ Otherwise, I'd say unless anyone has objections, I think we can merge the branch. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
Some more testing today. Turns out that if have just the MVAR apply patch active, Chromium still changes the line-height when switching between the same Cantarell VF (one with bit 7, one without). As there actually are no metric field values in the MVAR table, the FT_Face ascender, descender and height values stay the same between both. Bizarre. As if Chromium actually depends on the current behavior and fixes it itself. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
> So after some weeks of testing, I can say that fonts that set the > USE_TYPO_METRICS bit and have a sTypoLineHeight set to non-zero > consistently look shifted up in GNOME, so this patch seems to > work ;) No eye-catching change in Qt UI, Chromium or Firefox. Will > test some more as time allows, but want to get this in before 2.10. OK. Please drop a not as soon as you think that the patch is ready for integration. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
After doing some vanilla/patch switching of FreeType and testing, I found that Chromium is indeed impacted by the patch. Without it, switching between the VFs I attached to https://gitlab.gnome.org/GNOME/gtk/issues/1626 makes no difference on http://www.cyreal.org/Font-Testing-Page/index.php makes no difference. With the patch, I can see changes. Firefox stays the same with and without the patch. Hm. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
Actually, Behdad, just so I understand correctly: In the case of Cantarell, assuming the line gap is put at the top, toggling USE_TYPO_METRICS should _in theory_ not make any difference because each of hhea, typo and win sums up to a total height of 1200 font units (1000 upM font + 20% line spacing as recommended by the OpenType spec), no? I'm asking because that's what I think should happen but does neither in Frefox nor in Chromium. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
Oh, right, sorry :D So after some weeks of testing, I can say that fonts that set the USE_TYPO_METRICS bit and have a sTypoLineHeight set to non-zero consistently look shifted up in GNOME, so this patch seems to work ;) No eye-catching change in Qt UI, Chromium or Firefox. Will test some more as time allows, but want to get this in before 2.10. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
> what do you think about the patch? Any objections to merging it? :) Well, you told us then that you want to test and report whether it works... So: does it work as expected? If yes, it's OK with me to merge. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
Werner, what do you think about the patch? Any objections to merging it? :) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
On Sat, Dec 22, 2018 at 11:23 AM Nikolaus Waxweiler wrote: > > > The thinking within the working group was that no one uses win > > metrics, so we didn't encode their variations. Indeed, the only time > > one uses them these days is if typo and hhea metrics are not set... > > > > But MVAR tags for win metrics exist? > > https://docs.microsoft.com/en-us/typography/opentype/spec/mvar#value-tags > > 'hcla' horizontal clipping ascent OS/2.usWinAscent > 'hcld' horizontal clipping descent OS/2.usWinDescent > > Or are they specifically for clipping avoidance and should never modify > line metrics? You are right. Those are for clipping on older Windows systems. Only if there's no usable line size in hhea or typo ones should one use win. > Then the code should be removed anyway from the MVAR > apply function. I see in the HB code you linked that you use the typo > metrics if the typo bit is set and hhea metrics otherwise. I can find > no mention of win* metrics in the codebase. Should FreeType behave > similarly? I.e. > > 1. If OS/2 table exists and typo bit is on, use typo metrics > 2. Otherwise, use hhea metrics > 3. Unless they are zero, then use typo metrics. If they are zero as > well, so be it. > (4. Always ignore win metrics) > > The comment given in sfobjs.c:1662 says that some ARIALNB.ttf has typo > metrics set to zero. So, not sure about 4., maybe only for static fonts? > > I'm in a bit of a bind with Cantarell, as I already released a version > that ships with GNOME and does not have the typo bit set. Grr. I guess > I need to look into how to make GTK or whatever add line gap somewhere > or change the metrics around... > > -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
I implemented something at http://git.savannah.gnu.org/cgit/freetype/freetype2.git/log/?h=use-typo-metrics http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?h=use-typo-metrics=1250af7acecb22b2f5080efeb8dd14ab28779f6a http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?h=use-typo-metrics=7c379c466107a17e30155995a85a74cfa8f536bd I installed this on my machine, let's see what happens. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
The thinking within the working group was that no one uses win metrics, so we didn't encode their variations. Indeed, the only time one uses them these days is if typo and hhea metrics are not set... But MVAR tags for win metrics exist? https://docs.microsoft.com/en-us/typography/opentype/spec/mvar#value-tags 'hcla' horizontal clipping ascent OS/2.usWinAscent 'hcld' horizontal clipping descent OS/2.usWinDescent Or are they specifically for clipping avoidance and should never modify line metrics? Then the code should be removed anyway from the MVAR apply function. I see in the HB code you linked that you use the typo metrics if the typo bit is set and hhea metrics otherwise. I can find no mention of win* metrics in the codebase. Should FreeType behave similarly? I.e. 1. If OS/2 table exists and typo bit is on, use typo metrics 2. Otherwise, use hhea metrics 3. Unless they are zero, then use typo metrics. If they are zero as well, so be it. (4. Always ignore win metrics) The comment given in sfobjs.c:1662 says that some ARIALNB.ttf has typo metrics set to zero. So, not sure about 4., maybe only for static fonts? I'm in a bit of a bind with Cantarell, as I already released a version that ships with GNOME and does not have the typo bit set. Grr. I guess I need to look into how to make GTK or whatever add line gap somewhere or change the metrics around... ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
On Sat, Dec 22, 2018 at 8:43 AM Nikolaus Waxweiler wrote: > > There's also the question of whether MVAR tags should apply to > > whatever was used for ascent/descent. I think yes. And I'll > > implement that in HB. > > What would you do when > > 1. the typo metrics are modified by the MVAR table > If Typo exists, that's what MVAR tags are applied to. > 2. win metrics are modified > 3. both are modified > The thinking within the working group was that no one uses win metrics, so we didn't encode their variations. Indeed, the only time one uses them these days is if typo and hhea metrics are not set... -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
I suggest FreeType be changed to respect OS/2 useTypoMetrics bit. I'm gonna experiment with that. GTK/Pango/Cairo just call into FreeType for metrics. I'm confused. What does "default outline" vs "default instance" mean? By default outline I mean the outline that is displayed by ftview when you open a VF, before pressing `n` to cycle through the instances. I noticed that GTK apps display Cantarell-Regular using the default outlines but use e.g. the bold instance for -Bold. That's how I noticed the metrics difference. There's also the question of whether MVAR tags should apply to whatever was used for ascent/descent. I think yes. And I'll implement that in HB. What would you do when 1. the typo metrics are modified by the MVAR table 2. win metrics are modified 3. both are modified ? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
On Thu, Dec 20, 2018 at 5:32 AM Werner LEMBERG wrote: > > > I just tested the static and variable fonts in macOS 10.14 TextEdit. > > For the static instances, it presumably takes the hhea metrics, for > > the VF, it always takes typo metrics. (It also adds the line gap at > > the bottom, making text look weird, but maybe that's because the > > layout logic is broken.) > > Thanks for testing! > > > So that would speak in favor of always using either typo or win > > metrics for variable fonts, even for the default outlines? > > Behdad? > Umm. I suggest FreeType be changed to respect OS/2 useTypoMetrics bit. This is my attempt in HB: https://github.com/harfbuzz/harfbuzz/blob/master/src/hb-ot-hmtx-table.hh#L194 and then use same logic for VF and non-VF. There's also the question of whether MVAR tags should apply to whatever was used for ascent/descent. I think yes. And I'll implement that in HB. > > Or maybe this is really the fault of GTK/Pango/something because it > > loads the default outline instead of the default instance, which > > would yield the correct metrics? > > This is certainly the most convenient solution for me since I have > nothing to do on the FreeType side :-) > GTK/Pango/Cairo just call into FreeType for metrics. I'm confused. What does "default outline" vs "default instance" mean? > Your question, however, is a fundamental one: Shall a VF font be > always treated as VF, or is the `VFness' an optional feature? > > > Werner > -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
On Thu, Dec 20, 2018 at 6:02 AM Nikolaus Waxweiler wrote: > > This is certainly the most convenient solution for me since I have > > nothing to do on the FreeType side :-) > > (As an aside, GTK/Pango seem to make the same mistake as TextEdit then, > putting the line gap at the bottom instead of on both sides or something, > so this would still look wrong even if FT would default to typo metrics for > VFs) > lineGap should be put in between two neighboring lines only. > > Your question, however, is a fundamental one: Shall a VF font be > > always treated as VF, or is the `VFness' an optional feature? > > I'd say the primary purpose of a VF is to be a VF, it is only optionally > so for applications that don't know what a VF is. You'd think that using > the hhea metrics for the default outlines would make sense in that case, > but this still presents a corner case if the applications increases in > smartness and suddenly the same font has different metrics 樂 > -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
> This is certainly the most convenient solution for me since I have > nothing to do on the FreeType side :-) (As an aside, GTK/Pango seem to make the same mistake as TextEdit then, putting the line gap at the bottom instead of on both sides or something, so this would still look wrong even if FT would default to typo metrics for VFs) > Your question, however, is a fundamental one: Shall a VF font be > always treated as VF, or is the `VFness' an optional feature? I'd say the primary purpose of a VF is to be a VF, it is only optionally so for applications that don't know what a VF is. You'd think that using the hhea metrics for the default outlines would make sense in that case, but this still presents a corner case if the applications increases in smartness and suddenly the same font has different metrics 樂 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
> I just tested the static and variable fonts in macOS 10.14 TextEdit. > For the static instances, it presumably takes the hhea metrics, for > the VF, it always takes typo metrics. (It also adds the line gap at > the bottom, making text look weird, but maybe that's because the > layout logic is broken.) Thanks for testing! > So that would speak in favor of always using either typo or win > metrics for variable fonts, even for the default outlines? Behdad? > Or maybe this is really the fault of GTK/Pango/something because it > loads the default outline instead of the default instance, which > would yield the correct metrics? This is certainly the most convenient solution for me since I have nothing to do on the FreeType side :-) Your question, however, is a fundamental one: Shall a VF font be always treated as VF, or is the `VFness' an optional feature? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
I just tested the static and variable fonts in macOS 10.14 TextEdit. For the static instances, it presumably takes the hhea metrics, for the VF, it always takes typo metrics. (It also adds the line gap at the bottom, making text look weird, but maybe that's because the layout logic is broken.) So that would speak in favor of always using either typo or win metrics for variable fonts, even for the default outlines? Or maybe this is really the fault of GTK/Pango/something because it loads the default outline instead of the default instance, which would yield the correct metrics? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
OR MAYBEE if we detect a variable font, the default/static outlines gets typo or win metrics instead of hhea metrics? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
Actually, maybe the "patch" is wrong. Should the decision making between static faces and instances be harmonized instead? I.e. should static faces default to typo metrics instead of hhea metrics? Should ascender/descender in tt_apply_mvar only be changed if hhea metrics are zero, like for static fonts? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
On Tue, Dec 18, 2018 at 11:43 AM Nikolaus Waxweiler wrote: > Thanks Alexei for chiming in at > https://github.com/googlei18n/fontmake/issues/492#issuecomment-448249543. > > > The following seems to be different: hhea does not seem to be used in > VF. Compare and decide which one is correct. > > > > > https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/truetype/ttgxvar.c#n1365 > > > https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/sfnt/sfobjs.c#n1670 > > The OpenType spec says nothing variation specific about hhea/typo/win > metrics, except that hhea vmetrics don't seem to be supported by the > `MVAR` in that only win and typo metrics have `MVAR` tags: > The reasoning for that was that varfonts should set OS/2 useTypoMetrics bit on and as such only one set of values need variation. I would say if that bit is off then the respective MVAR tags should be applied to hhea values. > - > https://docs.microsoft.com/en-us/typography/opentype/spec/hhea#39hhea39-table-and-opentype-font-variations > - > https://docs.microsoft.com/en-us/typography/opentype/spec/mvar#value-tags > - > https://docs.microsoft.com/en-us/typography/opentype/spec/os2#stypoascender > - > https://docs.microsoft.com/en-us/typography/opentype/spec/os2#uswinascent > > Regarding ascender, descender and height calculation in sfobjs.c and > ttgxvar.c: the math seems to be the same: > > - hhea: ascender 983, descender -217, line gap 0 -> total height 1200 fU > - typo: ascender 739, descender -217, line gap 244 -> total height 1200 fU > - win: ascender 983, descender 217, line gap 0 -> total height 1200 fU > > For static fonts, FT uses hhea metrics: `root->height = root->ascender > - root->descender + face->horizontal.Line_Gap;` or `983 - (- 217) + 0 > = 1200` > For instances, it uses typo metrics: `root->height = root->ascender - > root->descender + face->os2.sTypoLineGap;` or `739 - (-217) + 244 = > 1200` > > Will look into this deeper later. > > ___ > Freetype-devel mailing list > Freetype-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/freetype-devel > -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?
Thanks Alexei for chiming in at https://github.com/googlei18n/fontmake/issues/492#issuecomment-448249543. > The following seems to be different: hhea does not seem to be used in VF. > Compare and decide which one is correct. > > https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/truetype/ttgxvar.c#n1365 > https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/sfnt/sfobjs.c#n1670 The OpenType spec says nothing variation specific about hhea/typo/win metrics, except that hhea vmetrics don't seem to be supported by the `MVAR` in that only win and typo metrics have `MVAR` tags: - https://docs.microsoft.com/en-us/typography/opentype/spec/hhea#39hhea39-table-and-opentype-font-variations - https://docs.microsoft.com/en-us/typography/opentype/spec/mvar#value-tags - https://docs.microsoft.com/en-us/typography/opentype/spec/os2#stypoascender - https://docs.microsoft.com/en-us/typography/opentype/spec/os2#uswinascent Regarding ascender, descender and height calculation in sfobjs.c and ttgxvar.c: the math seems to be the same: - hhea: ascender 983, descender -217, line gap 0 -> total height 1200 fU - typo: ascender 739, descender -217, line gap 244 -> total height 1200 fU - win: ascender 983, descender 217, line gap 0 -> total height 1200 fU For static fonts, FT uses hhea metrics: `root->height = root->ascender - root->descender + face->horizontal.Line_Gap;` or `983 - (- 217) + 0 = 1200` For instances, it uses typo metrics: `root->height = root->ascender - root->descender + face->os2.sTypoLineGap;` or `739 - (-217) + 244 = 1200` Will look into this deeper later. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
