Re: Revised SVG stuff
>> 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 `cff_slot_load` and `TT_Load_Glyph` so that they > return errors if an SVG table is found but a glyph isn't, then how > am I going to make sure that the rendering resorts to other color > tables or the b/w outline when an SVG glyph is not found? I've already written code to handle that, don't worry :-) Werner
Re: Revised SVG stuff
> > > 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 `cff_slot_load` and `TT_Load_Glyph` so that they return errors if an SVG table is found but a glyph isn't, then how am I going to make sure that the rendering resorts to other color tables or the b/w outline when an SVG glyph is not found?
Re: Revised SVG stuff
>> 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 auto-hinting the glyph from the `glyf` table. > > The load_glyph call won't fail even if an OT-SVG glyph is not found, > I think. Hmm. > 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. Werner
Re: Revised SVG stuff
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 > auto-hinting the glyph from the `glyf` table. > The load_glyph call won't fail even if an OT-SVG glyph is not found, I think. Instead, it'll resort to whatever type of glyph is found. That's the current behavior of cff_slot_load and TT_Load_Glyph. > If necessary, `tt_face_load_svg_doc` should be modified to exit > quickly if there is no SVG corresponding glyph. >
Re: Revised SVG stuff
>> > I'm not sure how to add a check that can prevent hinting to be >> > run for OT-SVG glyphs. Whether or not a glyph index has a >> > corresponding SVG glyph in the table is determined later on >> > inside cff_slot_load or TT_Load_Glyph. Any ideas on how to >> > prevent autohinting from being run on an OT-SVG glyph? >> >> It seems to me that you could try to add another special case for >> SVG. > > Yea, that's what I had in mind, but given this situation, I think > what can be done is, check if an SVG table exists in the font and > FT_LOAD_COLOR has been passed, if the two are true, don't run the > auto-hinter. > > Is that what you mean? Yes. However, you write Whether or not a glyph index has a corresponding SVG glyph in the table is determined later on inside cff_slot_load or TT_Load_Glyph. 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 auto-hinting the glyph from the `glyf` table. If necessary, `tt_face_load_svg_doc` should be modified to exit quickly if there is no SVG corresponding glyph. Werner
Re: Revised SVG stuff
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 all other fonts that I had in my test > > collection. > > In other words, all fonts that you've tested so far were `.otf` fonts > (with third-order Bézier curves), and not `.ttf`, right? > True, as far as I can see. > > I'm not sure how to add a check that can prevent hinting to be run > > for OT-SVG glyphs. Whether or not a glyph index has a corresponding > > SVG glyph in the table is determined later on inside cff_slot_load > > or TT_Load_Glyph. Any ideas on how to prevent autohinting from > > being run on an OT-SVG glyph? > > Look at the clause > > It seems to me that you could try to add another special case for SVG. > Yea, that's what I had in mind, but given this situation, I think what can be done is, check if an SVG table exists in the font and FT_LOAD_COLOR has been passed, if the two are true, don't run the auto-hinter. Is that what you mean? Moazin
Re: Revised SVG stuff
> 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.
> for this font while it's 0 for all other fonts that I had in my test
> collection.
In other words, all fonts that you've tested so far were `.otf` fonts
(with third-order Bézier curves), and not `.ttf`, right?
> This check happens in FT_Load_Glyph in `ftobjs.c` on line number 999
> in my branch where autohint is set to true, there's a comment about
> `num_locations` over there. I'm under the impression that that
> value will not be set to `0` in the case of OTF fonts with TTF
> glyphs.
Correct.
> I'm not sure how to add a check that can prevent hinting to be run
> for OT-SVG glyphs. Whether or not a glyph index has a corresponding
> SVG glyph in the table is determined later on inside cff_slot_load
> or TT_Load_Glyph. Any ideas on how to prevent autohinting from
> being run on an OT-SVG glyph?
Look at the clause
```
if ( autohint )
{
FT_AutoHinter_Interface hinting;
/* try to load embedded bitmaps first if available*/
/**/
/* XXX: This is really a temporary hack that should disappear */
/* promptly with FreeType 2.1! */
/**/
if ( FT_HAS_FIXED_SIZES( face ) &&
( load_flags & FT_LOAD_NO_BITMAP ) == 0 )
{
error = driver->clazz->load_glyph( slot, face->size,
glyph_index,
load_flags | FT_LOAD_SBITS_ONLY );
if ( !error && slot->format == FT_GLYPH_FORMAT_BITMAP )
goto Load_Ok;
}
...
```
It seems to me that you could try to add another special case for SVG.
Werner
Re: Revised SVG stuff
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 `ftobjs.c` on line number 999 in my branch where autohint is set to true, there's a comment about `num_locations` over there. I'm under the impression that that value will not be set to `0` in the case of OTF fonts with TTF glyphs. I'm not sure how to add a check that can prevent hinting to be run for OT-SVG glyphs. Whether or not a glyph index has a corresponding SVG glyph in the table is determined later on inside cff_slot_load or TT_Load_Glyph. Any ideas on how to prevent autohinting from being run on an OT-SVG glyph? Thanks, Moazin On Mon, Jan 3, 2022 at 10:48 AM Werner LEMBERG wrote: > > Hello Moazin, > > > just now I've pushed new branches to the FreeType and FreeType Demo > repositories with my changes. > > > https://gitlab.freedesktop.org/freetype/freetype/-/tree/wl/freetype-ot-svg-from-scratch-new > > https://gitlab.freedesktop.org/freetype/freetype-demos/-/tree/wl/freetype-demos-support-ot-svg-glyphs-new > > While the library stuff is thoroughly checked and modified[*], the > demo stuff is not yet; to the latter code I've only applied the > necessary fixes to make it compile. > > The reason why I've stopped is that I wasn't able to render this SVG > font: > > > https://get.fontspace.co/download/family/gep41/ffdec6d38cd94d51803685fec480ef08/bigpartyo2-green-font.zip > > Funnily, it was the first SVG that I downloaded, and I was quite > surprised to see no SVG rendering at all :-) > > AFAICS, the error 'Unimplemented Feature' is returned in line 502 of > file `afloader.c`. Please check. It doesn't make any sense for SVG > glyphs to run the auto-hinter. > > > Werner > > > [*] I did `git rebase -i HEAD^`, then walking over the code commit > by commit, adding my changes with `git commit --amend`. If I > found new things I did rebasing again so that the changes get > added to the right commit. >
