Re: Freetype API for current hint info in variable fonts

[Werner LEMBERG]

>  I was able to get the current outline information of a selected
>  character from an OpenType variable font (CFF2) with the help of
>  Freetype.

OK.

> I would also like to get the current hinting information for a
> character which of course depends on the current coordinates in
> design space.  Is there an API to retrieve this information ?

No, there isn't.  I think, however, that this is an XY problem.  What
do you actually want to achieve?


Werner

Freetype API for current hint info in variable fonts

[Axel Stoltenberg]

Good morning,
 
I was able to get the current outline information of a selected character from an OpenType variable font (CFF2) with the help of Freetype.


I would also like to get the current hinting information for a character which 
of course depends on the current coordinates in design space. Is there an API 
to retrieve this information ?
Thanks a lot,
Axel

Re: Variable Fonts

[Werner LEMBERG]

> Now that I researched more, I cannot cache glyphs of different
> variations inside the cache manager unless I provide a different
> face_id for each variation and only then my system works correctly.
> To be honest this is a flaw in the cache subsystem of the freetype
> library.

Please open an issue in the FreeType tracker at
https://gitlab.freedesktop.org/freetype/freetype/-/issues

And of course, patches are welcomed :-)


Werner

Re: Variable Fonts

[Tulsi Amin]

Hello,
Now that I researched more, I cannot cache glyphs of different variations
inside the cache manager unless I provide a different face_id for each
variation and only then my system works correctly. To be honest this is a
flaw in the cache subsystem of the freetype library. You need to provide a
way to cache the glyphs of different variations and identify them uniquely
as well. Please let me know your thoughts on this. The caching system
should work well with variable fonts. Currently what I have done seems like
a hack make it work.

Thank You,
Tulsi Amin

On Mon, Jan 9, 2023 at 10:04 AM Tulsi Amin  wrote:

> Hello,
>
> I have another question related to variable fonts.
> My current implementation maps a face_id with a font variation defined by
> me.
> For example,
> Bold is a variation with weight axis value 1.0 and SemiBold is a variation
> with weight axis value 0.8 and I input a different face_id for each of the
> variation when I call  FTC_Manager_LookupFace() function so that it can
> cache glyphs of both the variations but I also think that a face_id should
> be different only when we are loading a different font file and not when we
> are applying different variations. I am a bit confused if my implementation
> should cache glyphs of both the variations in the freetype cache manager
> without changing the face_id. Please let me know.
>
> FTC_Manager_LookupFace() - here I send different face_id for different
> variations though they belong to the same font resource file(I mean the
> same .ttf)
>
> Thank You,
> Tulsi Amin
>

Variable Fonts

[Tulsi Amin]

Hello,

I have another question related to variable fonts.
My current implementation maps a face_id with a font variation defined by
me.
For example,
Bold is a variation with weight axis value 1.0 and SemiBold is a variation
with weight axis value 0.8 and I input a different face_id for each of the
variation when I call  FTC_Manager_LookupFace() function so that it can
cache glyphs of both the variations but I also think that a face_id should
be different only when we are loading a different font file and not when we
are applying different variations. I am a bit confused if my implementation
should cache glyphs of both the variations in the freetype cache manager
without changing the face_id. Please let me know.

FTC_Manager_LookupFace() - here I send different face_id for different
variations though they belong to the same font resource file(I mean the
same .ttf)

Thank You,
Tulsi Amin

Re: Variable fonts

[Tulsi Amin]

Hello,

I agree with you and thanks for the clarification.

Thank You,
Tulsi Amin

On Mon, 9 Jan, 2023, 09:06 Werner LEMBERG,  wrote:

>
> > I am currently using the multiple master feature of freetype library
> > to support the variable fonts.  There is an issue that I am facing
> > currently.  For an example, consider that I am making letter "A"
> > bold using the weight axis but in my system I want to be able to
> > uniquely identify the default normal "A" and the bold "A" but since
> > the unicode id will be same for both normal "A" and bold "A", Is
> > freetype library providing any other identifier which can uniquely
> > identify them?
>
> No.  How should FreeType do that?  You input a glyph index, and the
> library returns a rasterized image of the glyph, nothing more.  All
> information FreeType can give is in the `FT_Face` structure and its
> related sub-structures and siblings.
>
> Such 'tagging' must be done at a higher library level: essentially,
> it's you who specifies the parameters for the variable font, so it's
> you who has to track them, too.
>
>
> Werner
>

Re: Variable fonts

[Werner LEMBERG]

> I am currently using the multiple master feature of freetype library
> to support the variable fonts.  There is an issue that I am facing
> currently.  For an example, consider that I am making letter "A"
> bold using the weight axis but in my system I want to be able to
> uniquely identify the default normal "A" and the bold "A" but since
> the unicode id will be same for both normal "A" and bold "A", Is
> freetype library providing any other identifier which can uniquely
> identify them?

No.  How should FreeType do that?  You input a glyph index, and the
library returns a rasterized image of the glyph, nothing more.  All
information FreeType can give is in the `FT_Face` structure and its
related sub-structures and siblings.

Such 'tagging' must be done at a higher library level: essentially,
it's you who specifies the parameters for the variable font, so it's
you who has to track them, too.


Werner

Variable fonts

[Tulsi Amin]

Hello,
I am currently using the multiple master feature of freetype library to
support the variable fonts. There is an issue that I am facing currently.
For an example, consider that I am making letter "A" bold using the weight
axis but in my system I want to be able to uniquely identify the default
normal "A" and the bold "A" but since the unicode id will be same for both
normal "A" and bold "A", Is freetype library providing any other identifier
which can uniquely identify them?

Thank You,
Tulsi Amin

Re: Recalculate glyph metrics for variable fonts

[David Colson]

I upgraded to latest free type and it works fine now, so presumably a bug
of some kind in 2.10. No issues updating so as far as I’m concerned the
issue is resolved now.

Thanks

On Wed, 5 Jan 2022 at 06:53, Werner LEMBERG  wrote:

>
> > I am trying to adjust the weight of a variable font, Source Code Pro
> > in particular (https://fonts.google.com/specimen/Source+Code+Pro).
> >
> > I simply call FT_Set_Var_Design_Coordinates with the appropriate
> > parameters, and it basically works, however, it seems to break all
> > the glyph metrics and the whole line of text is displayed with
> > overlapping glyphs, like the advance has become incorrect.
> >
> > This only happens when setting a design coordinate.  Do I need to
> > recalculate the metrics or something after changing a variable?  I
> > had a look around the docs but could not figure out what I'm doing
> > wrong.  Currently using FreeType 2.10.1.
>
> Please check the `ftmulti` FreeType demo program; maybe it gives the
> answer you need – If I compile it from current git, the metrics stay
> the same for Source Code Pro.
>
> Otherwise please post a small, *compilable* example (preferably to be
> executed on the command line) that shows your problem.
>
>
> Werner
>

Re: Recalculate glyph metrics for variable fonts

[Werner LEMBERG]

> I am trying to adjust the weight of a variable font, Source Code Pro
> in particular (https://fonts.google.com/specimen/Source+Code+Pro).
> 
> I simply call FT_Set_Var_Design_Coordinates with the appropriate
> parameters, and it basically works, however, it seems to break all
> the glyph metrics and the whole line of text is displayed with
> overlapping glyphs, like the advance has become incorrect.
> 
> This only happens when setting a design coordinate.  Do I need to
> recalculate the metrics or something after changing a variable?  I
> had a look around the docs but could not figure out what I'm doing
> wrong.  Currently using FreeType 2.10.1.

Please check the `ftmulti` FreeType demo program; maybe it gives the
answer you need – If I compile it from current git, the metrics stay
the same for Source Code Pro.

Otherwise please post a small, *compilable* example (preferably to be
executed on the command line) that shows your problem.


Werner

Recalculate glyph metrics for variable fonts

[David Colson]

I am trying to adjust the weight of a variable font, Source Code Pro in
particular (https://fonts.google.com/specimen/Source+Code+Pro).

I simply call FT_Set_Var_Design_Coordinates with the appropriate
parameters, and it basically works, however, it seems to break all the
glyph metrics and the whole line of text is displayed with overlapping
glyphs, like the advance has become incorrect.

This only happens when setting a design coordinate. Do I need to
recalculate the metrics or something after changing a variable? I had a
look around the docs but could not figure out what I'm doing wrong.
Currently using FreeType 2.10.1.

Thanks

Re: [ft-devel] Glitchy rendering of overlapping outlines in variable fonts

[Alexei Podtelezhnikov]

> https://i.postimg.cc/VLLmQqV2/Bildschirmfoto-vom-2019-09-25-21-22-01.png
>
> Same thing in the variable TTF. Is this a known limitation in the
> renderer?

Yes, but I m not convinced that this is a limitation. An overlap is an
overlap, it does not matter if it within a glyph or between glyphs.
Suppose each contour has non-trivial opacity. What should be the
combined opacity for the overlaps within and between the glyphs? Some
will say that within a glyph overlapping contours are meant to be
merged by removing overlaps. Be my guest then, do that first before
rendering.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Glitchy rendering of overlapping outlines in variable fonts

[Behdad Esfahbod]

Yes.

On Wed, Sep 25, 2019 at 1:38 PM Nikolaus Waxweiler 
wrote:

> Hi list,
> I was just looking at SourceSerifVariable-Roman.otf from
> https://github.com/adobe-fonts/source-serif-pro/releases/tag/3.000R and
> found this discrepancy between the variable instance of Black and the
> static one with overlaps removed:
>
> https://i.postimg.cc/VLLmQqV2/Bildschirmfoto-vom-2019-09-25-21-22-01.png
>
> Same thing in the variable TTF. Is this a known limitation in the
> renderer?
>
>
>
> ___
> 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

[ft-devel] Glitchy rendering of overlapping outlines in variable fonts

[Nikolaus Waxweiler]

Hi list,
I was just looking at SourceSerifVariable-Roman.otf from 
https://github.com/adobe-fonts/source-serif-pro/releases/tag/3.000R and 
found this discrepancy between the variable instance of Black and the 
static one with overlaps removed:


https://i.postimg.cc/VLLmQqV2/Bildschirmfoto-vom-2019-09-25-21-22-01.png

Same thing in the variable TTF. Is this a known limitation in the 
renderer?




___
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 LEMBERG]

> 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?

[Behdad Esfahbod]

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?

[Ben Wagner]

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?

[Werner LEMBERG]

> 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?

[Nikolaus Waxweiler]

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?

[Werner LEMBERG]

> 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?

[Nikolaus Waxweiler]

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?

[Ben Wagner]

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?

[Nikolaus Waxweiler]

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?

[Behdad Esfahbod]

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?

[Nikolaus Waxweiler]

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?

[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.

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?

[Nikolaus Waxweiler]

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?

[Nikolaus Waxweiler]

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?

[Werner LEMBERG]

> 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?

[Nikolaus Waxweiler]

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?

[Nikolaus Waxweiler]

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?

[Nikolaus Waxweiler]

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?

[Werner LEMBERG]

> 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?

[Nikolaus Waxweiler]

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?

[Behdad Esfahbod]

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?

[Nikolaus Waxweiler]

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?

[Nikolaus Waxweiler]

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?

[Behdad Esfahbod]

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?

[Nikolaus Waxweiler]

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?

[Behdad Esfahbod]

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?

[Behdad Esfahbod]

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?

[Nikolaus Waxweiler]

> 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?

[Werner LEMBERG]

> 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?

[Nikolaus Waxweiler]

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?

[Nikolaus Waxweiler]

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?

[Nikolaus Waxweiler]

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?

[Behdad Esfahbod]

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?

[Nikolaus Waxweiler]

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

[ft-devel] Variable fonts: hhea/typo/win metrics interpreted differently for instances compared to static fonts?

[Nikolaus Waxweiler]

Hi list,
I'm trying to turn Cantarell into a VF and am hitting a hhea/typo/win 
metrics issue: the metrics seem to be interpreted differently for the 
VF instances compared to the static fonts an I'm not sure if I'm doing 
something wrong. The instances look as if their baseline was shifted 
upwards relative to the static fonts. Equalizing hhea and typo metrics 
makes the difference go away.


Here's a screenshot of the baseline difference: 
https://github.com/googlei18n/fontmake/issues/492#issuecomment-447760311


Here are the three static masters and the resulting VF: 
https://github.com/googlei18n/fontmake/issues/492#issuecomment-448005088


(Note that the Regular serves as the master for various fields, e.g. 
the "Use Typo Metrics" bit. Toggling it does not help.)


This happens on master and on 2.9.1. Am I overlooking something?


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Fwd: Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

[Werner LEMBERG]

> I meant exactly what Dave said.  While I agree that the data is
> there, a convenience method would help.  Not as a strict necessity,
> but as a convenience :-)

OK, so I ask you again to provide a suggestion for an API.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Fwd: Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

[Felipe Sanches]

I meant exactly what Dave said. While I agree that the data is there, a
convenience method would help. Not as a strict necessity, but as a
convenience :-)

2017-06-14 9:21 GMT-03:00 Werner LEMBERG :

>
> > > what API do you suggest?  Given that normally an application wants
> > > to control *all* axes, it is not obvious to me where the benefits
> > > are, so please elaborate.
> >
> > In fontview or axis-praxis the ui is an array of sliders, and it is
> > unusual for a user to have two or more pointers and adjust 2 or more
> > sliders at once.
> >
> > I'm guessing Felipe wants to pass a designspace coordinate delta,
> > based only on the user input for the single axis typically adjusted
> > by the user.
>
> Well, yes, but as you say the application has already to maintain the
> array of sliders – this exactly corresponds to an array of designspace
> coordinates.  It should be straightforward to update the new value
> *within the array*, then passing a pointer to array to FreeType.
>
> Maybe Felipe means something else.
>
>
> Werner
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Fwd: Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

[Werner LEMBERG]

> > what API do you suggest?  Given that normally an application wants
> > to control *all* axes, it is not obvious to me where the benefits
> > are, so please elaborate.
> 
> In fontview or axis-praxis the ui is an array of sliders, and it is
> unusual for a user to have two or more pointers and adjust 2 or more
> sliders at once.
> 
> I'm guessing Felipe wants to pass a designspace coordinate delta,
> based only on the user input for the single axis typically adjusted
> by the user.

Well, yes, but as you say the application has already to maintain the
array of sliders – this exactly corresponds to an array of designspace
coordinates.  It should be straightforward to update the new value
*within the array*, then passing a pointer to array to FreeType.

Maybe Felipe means something else.


Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Fwd: Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

[Dave Crossland]

On Jun 14, 2017 1:59 AM, "Werner LEMBERG"  wrote:


Felipe,


> (I really miss a Freetype method to alter a single design-space
> coordinate, instead of having to pass the full array, by the way)

what API do you suggest?  Given that normally an application wants to
control *all* axes, it is not obvious to me where the benefits are, so
please elaborate.


In fontview or axis-praxis the ui is an array of sliders, and it is unusual
for a user to have two or more pointers and adjust 2 or more sliders at
once.

I'm guessing Felipe wants to pass a designspace coordinate delta, based
only on the user input for the single axis typically adjusted by the user.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Fwd: Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

[Werner LEMBERG]

Felipe,


> (I really miss a Freetype method to alter a single design-space
> coordinate, instead of having to pass the full array, by the way)

what API do you suggest?  Given that normally an application wants to
control *all* axes, it is not obvious to me where the benefits are, so
please elaborate.


 Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [googlefonts-discuss] Re: Variable Fonts support in Inkscape

[Felipe Sanches]

Thanks, Dave!

2017-06-13 9:11 GMT-03:00 Dave Crossland <d.crossl...@gmail.com>:

> Hi
>
> I thought I would forward on Felipe's request for a convenience method
> below :)
> -- Forwarded message --
> From: "Felipe Sanches" <j...@members.fsf.org>
> Date: Jun 2, 2017 9:35 PM
> Subject: Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape
> To: "googlefonts-discuss" <googlefonts-disc...@googlegroups.com>,
> "Inkscape Devel List" <inkscape-de...@lists.sourceforge.net>
> Cc:
>
> Hi there,
>
> These past days I've been adding an experimental UI to Inkscape for
> tweaking parameters in OpenType variable fonts. One major roadblock I
> stumbled upon is requiring me to think more carefully about some
> potentially deeper architectural changes. In the screenshot attached to
> this message you can see some text written with the Decovar variable font.
> The slider labeled "Testing" in the "Text & Font" dialog is wired to invoke
> a callback upon value-change. This callback detects the currently selected
> font based on the canvas text-tool cursor position, retrieves the
> corresponding font_instance object and invokes Freetype's
> FT_Set_Var_Design_Coordinates method with the updated design-space
> coordinates (the slider in this experiment is hardwired to adjust the
> weight axis of Decovar).
>
> (I really miss a Freetype method to alter a single design-space
> coordinate, instead of having to pass the full array, by the way)
>
> The way things work right now, unfortunately, leads to the glyphs not
> changing on-canvas because once they are loaded, they seem to be kept in a
> cache. As you can see in the screenshot, each glyph has a different weigth,
> based on the slider setting when the glyph was loaded for the first time.
> It seems quite obvious that I should do something to invalidate the cache
> upon dragging the slider. But that, on the other hand, should not alter
> glyphs in other places where the same variable font is being used in the
> same document.
>
> Based on all that, I think that the proper implementation would involve
> creating individual font_instance objects for each text chunk where a
> variable-font is used with non-default design-space coordinates so that
> they can be tweaked independently. Achieving that, though, will surely
> involve a bit deeper fiddling with Inkscape's text internals, which is what
> I expect to do in my next few days of work on this.
>
> cheers,
> Felipe Sanches
>
> PS:
> I'm crossposting this to the Inkscape-devel mailing list as the rest of
> the development community may be interested in receiving updates on this
> topic. I may as well move all future updates to the Inkscape mailing list
> directly.
>
> PS2: I heard that there's a GSoC student this year who's going to work on
> Inkscape's text implementation (fixing compliance issues to the SVG spec, I
> think...) It would be really great to keep in contact with him/her and the
> mentor to coordinate efforts.
>
>
> 2017-05-30 7:48 GMT-03:00 Khaled Hosny <khaledho...@eglug.org>:
>
>> On Tue, May 30, 2017 at 12:35:24AM -0300, Felipe Sanches wrote:
>> > The relationship between pango and harfbuzz is still not very clear to
>> me,
>> > as I have the impression that even pango_shape() invokes hb_shape()
>> under
>> > the hood nowadays.
>>
>> It will eventually call HarfBuzz on Linux, but in Windows and Mac it
>> will call Uniscribe and Core Text, respectively. Switching to HarfBuzz
>> on all platforms is kinda on Pango’s TODO list, but I don’t think anyone
>> is working on it currently.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google Fonts Discussions" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to googlefonts-discuss+unsubscr...@googlegroups.com.
>> To post to this group, send email to googlefonts-disc...@googlegroups.com
>> .
>> Visit this group at https://groups.google.com/group/googlefonts-discuss.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/googlefonts-discuss/20170530104838.GC24994%40macbook.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Fonts Discussions" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to googlefonts-discuss+unsubscr...@googlegroups.com.
> To post to this group, send email to googlefonts-disc...@googlegroups.com.
> V