Hi all,
I'm free for a few months and I'd like to finalize the OT-SVG project. I'd
be sending more emails to this list discussing things soon however there's
one thing on which I want to hear your opinion first.
I'm relatively new to fonts, FreeType, and the whole font stack, so I don't
know
Hi Werner,
I think the main benefit is simplifying the interface, this is,
> letting FreeType handle all fonts, regardless of its format.
>
In its current state, the hooks should be set by default depending
on the how `configure` was called and if they are set, only the flag
`FT_LOAD_COLOR` is
Hi Manish,
What do you mean by Community Platform?
Best,
Moazin
On Sat, Apr 3, 2021 at 1:10 AM Manish Kumar Barnwal <
manishbarnwal...@gmail.com> wrote:
> Hello Freetype Team,
>
> I am Manish Kumar Barnwal, a web development enthusiast, having experience
> with Backend Development. I went
Hi Werner,
Thanks a lot for reviewing the MR.
https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/68
As you can see in the TODO list in the MR, one of the items is having
official hooks and documentation on how to create them. I'm trying to write
them in the repo below. Maybe
> I had a quick look at the code, and I've immediately found a
> fundamental problem: You are directly accessing
> `library->svg_renderer_state`. This is a no-go for applications since
> `FT_Library` is an opaque pointer that must not be dereferenced.
>
> Is it actually necessary that
Hi all,
I've just submitted a draft MR that brings OT-SVG functionality to
FreeType. The code added allows client applications to grab the SVG
document given a glyph ID as well as allows rendering it to a bitmap if
renderer hooks are plugged-in externally.
The code is two years old, I originally
> > It's not really necessary to store it in FT_Library, if there's any
> > other location that all the hooks can access, it'd work fine. Do you
> > have other candidates to store the structure?
>
> ...why must this be in FreeType at all? It's user data, so what about
> letting the application
Hi Werner,
I want to talk about two minor things about the OT-SVG implementation.
1. `FT_LOAD_NO_SCALE`: For CFF/TTF outlines, this flag loads the outlines,
but in font units, if you directly render it by `FT_Render_Glyph`, the
render functions just assume that the points are in 26.6 point
Hi Werner,
Sorry for the late reply.
> > 1. `FT_LOAD_NO_SCALE`: For CFF/TTF outlines, this flag loads the
> >outlines, but in font units, if you directly render it by
> >`FT_Render_Glyph`, the render functions just assume that the
> >points are in 26.6 point format, which isn't the
Hi Werner,
I just got some time to quickly check this bug. The reason why the
autohinting code seems to get triggered for that font is because
`ttface->num_locations` is 1 for this font while it's 0 for all other fonts
that I had in my test collection. This check happens in FT_Load_Glyph in
Hi Werner,
> > The reason why the autohinting code seems to get triggered for that
> > font is because `ttface->num_locations` is 1
>
> The actual value is 321, the number of normal (i.e., non-SVG) glyphs
> in the TrueType font.
>
Yea, sorry, that's correct.
> > for this font while it's 0 for
Hi Werner,
If I understand this correctly it means that a test for the SVG table
> is not sufficient. Instead, you have to actually do the call to
> `driver->clazz->load_glyph`, and if this fails, FreeType should try to
> load a bitmap font, and if this fails, it should proceed with
>
>
> > Instead, it'll resort to whatever type of glyph is found. That's
> > the current behavior of cff_slot_load and TT_Load_Glyph.
>
> OK. If necessary, please modify the code! I think the code spoty in
> question is the right place to avoid auto-hinting for OT-SVG glyphs.
>
Umm, if I change
13 matches
Mail list logo
