Hi all,
The Chrome, Skia and Google Fonts teams are collaborating on
open-source memory-safe font libraries
(https://docs.rs/skrifa/latest/skrifa/) for parsing, reading metadata
and paths and producing and writing fonts. The goal is to create an
additional backend for the SkTypeface Skia API
Hi Werner,
On Tue, Jan 25, 2022 at 9:48 AM Werner LEMBERG wrote:
>
> > While working on the new SVG support in FreeType three questions
> > came to my mind.
>
> After some working on the documentation I believe I can now answer two
> questions by myself :-) The thing is that for serious
Hi Werner,
On Fri, Jun 11, 2021 at 5:44 PM Werner LEMBERG wrote:
> > These are not implemented on the FreeType side yet. I plan to
> > implement them soon. I need to decide whether it would make sense
> > to consolidate the API and only return transformation matrices
> > instead of the
Hi Werner and others,
On Sun, May 16, 2021 at 11:37 AM Werner LEMBERG wrote:
>
> Hello Alexei,
>
>
> > You used to release a new version around this time of year. What are
> > your plans this time around? Are you waiting for some official
> > specs for COLRv1?
>
> Not really for the official
On Tue, Jun 8, 2021 at 6:45 PM Werner LEMBERG wrote:
>
> Dominik,
>
>
> while comparing the current git with the last release to check
> differences, I noticed that the COLR stuff is quite large. IMHO, it
> deserves to be moved into a separate file. What do you think? If you
> agree, can you
Congrats on the move, and a big thank you to Anurag, Werner and others
helping with this migration. I am very happy the project is moving to this
more modern infrastructure!
On Sat, Jan 16, 2021 at 1:11 AM Nikolaus Waxweiler
wrote:
> Cool! Thanks for moving ahead with this and thanks to Anurag
Hi Werner,
Once COLRv1 is merged, in Chromium (and Skia test bots) we are most
probably going to roll to FreeType tip-of-tree as usual. When building
support for COLRv1 rasterization into Skia, we would need a way to
determine whether the FreeType library headers that we are building
against
Hi Alexei,
On Wed, Jan 13, 2021 at 7:45 PM Alexei Podtelezhnikov
wrote:
>
> Hi Dominik,
>
> On Wed, Jan 13, 2021 at 12:15 PM Dominik Röttsches wrote:
> > Currently we have a test pipeline as part of
> > https://github.com/googlefonts/nanoemoji that builds a COLRv1
Hi Werner,
On Mon, Jan 11, 2021 at 6:32 PM Werner LEMBERG wrote:
>
>
> Some questions.
>
> (1) How can your code be tested? It should be eventually fuzzed, too.
Currently we have a test pipeline as part of
https://github.com/googlefonts/nanoemoji that builds a COLRv1 font
from SVG images,
Hello Werner,
I really appreciate that you took the time and put all the effort into
working through this larger set of patches with reviews and fixups.
Thank you very much!
On Sat, Jan 2, 2021 at 11:38 AM Werner LEMBERG wrote:
> > With your agreement — and I am happy to hear feedback and
Hi all,
in previous posts to this list, I have sent updates regarding our work
on COLRv1:
https://lists.gnu.org/archive/html/freetype-devel/2020-07/msg00041.html
Under the keyword COLRv1 we subsume a set of proposed specification
extensions which add support for linear and radial gradients,
Hei all,
We're considering running some of the FreeType fuzzers as part of the
internal Chromium fuzzing as well. In that setup, we have a different
environment than for oss-fuzz and we can't have a Boost dependency.
To that end, I filed a PR in
Hi Alexei,
On Sat, Aug 1, 2020 at 5:42 PM Alexei Podtelezhnikov
wrote:
> Hi Werner et al.,
>
> Please review the patch if you agree with the placement of the flag
> retention code.
>
> Hi Dominik.
>
> Last time you wanted to be warned about expected pixel differences.
> Once applied this will
for providing feedback.
Thank you very much in advance for taking a look. I'll be
out-of-office for two weeks but I'll respond to any feedback as soon
as possible when getting back.
Dominik
On Tue, Jun 30, 2020 at 11:46 AM Dominik Röttsches wrote:
>
> Hi Werner,
>
> thanks for the e
Hi,
my 2 cents regarding the discussion on commit messages and
clang-format on the [patch] Simplify ftconfig.h thread, breaking out
into a separate thread.
1) While working on COLRv1 I also wanted to relieve myself from
manually formatting the code, so I've tried to step-by-step tweak a
Hi Werner,
thanks for the encouragement.
On Tue, Jun 30, 2020 at 10:40 AM Werner LEMBERG wrote:
> > In a team effort with Roderick Sheeter & Cosimo Lupo & Dave Crossland
> > (Google Fonts) and myself (Blink/Chrome)
>
> ... and Behdad Esfahbod ...
Yes!
> Thanks. Are there fundamental
Hi,
In a team effort with Roderick Sheeter & Cosimo Lupo & Dave Crossland
(Google Fonts) and myself (Blink/Chrome) we have proposed and
published an OpenType extension to the COLR table to bring color
gradients to color vector fonts.
You can find the proposal here:
Hi Alexei,
On Tue, May 21, 2019 at 6:49 AM Alexei Podtelezhnikov
wrote:
>
>
> On Thu, May 16, 2019 at 2:11 PM Dominik Röttsches
> wrote:
> b) I would prefer 7a81b63abc2b3da0d7f0950f69377d2b3f54b0fb to be reworked
> so it doesn't cause pixel differences if possible, or r
Hello Werner and Alexei,
*From: *Werner LEMBERG
*Date: *Wed, May 15, 2019 at 9:33 AM
*To: *
*Cc: *
> > in Chrome, I am encountering issues rolling to latest FreeType ToT, see
> > details in
> > https://bugs.chromium.org/p/chromium/issues/detail?id=962932
>
> Assuming that you are testing
Hi Werner, Alexei,
in Chrome, I am encountering issues rolling to latest FreeType ToT, see
details in https://bugs.chromium.org/p/chromium/issues/detail?id=962932
In particular, these two CLs
*(1)*
Hi,
When instantiating FT_Face's from sbix or cbdt/cblc color fonts, the
units_per_EM value on FT_Face is 0, which currently seems to be intentional
behaviour.
What would be the recommended way using FreeType of still getting the units
per em value from the OpenType head table of such fonts?
21 matches
Mail list logo
