> 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
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
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.
> Done, pushed and fingers crossed.
Thanks!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Done, pushed and fingers crossed.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
> 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
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
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
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
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
>
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.
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
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
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
> 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
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
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
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
> 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
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
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
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
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?
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
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
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
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
> 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
> 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
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
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
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
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.
> >
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.
>
>
34 matches
Mail list logo
