Re: [ft-devel] [freetype2] parthw-cleaned 42890cf 2/2: [gf] Register gf services.
> +#define FT_SERVICE_GF_H Do you think there will be a new service special to GF? Otherwise a file `svgf.h' is not needed. To answer my own question: Probably yes, namely to make the `xxx' and `yyy' data publicly available. If you are going to do that, do you already have an idea how such an API should look like? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] GSoC status update.
> > >> Now `ftview' displays the gf glyphs too! I am attaching a > >> screenshot of the output from `ftview' and `ftstring'! [...] > > Looks good, thanks! > > I wonder whether it makes sense to add an artificial space glyph to > the GF + TFM combo – most font formats have a space glyph for simple > string support... What do you think? The width of such a space glyph > could be derived from TFM's `param[2]' value. > I don't really know how to work that out. Can you suggest any format which does this? Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] GSoC status update.
> > >>> Perhaps there is some missing documentation or a missing > >>> explanatory comment in the code... > > > > Hmm, maybe a note on this could go into `FreeType Design / IV', as a > > list of services all drivers are required to implement. > > Good idea! Parth, please file a bug report (with item group > `wishlist') so that it won't be forgotten. > Yes sure. Parth ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] COLR/CPAL
After a minor cairo patch, I can now see Segoe UI Emoji rendered with hb-view (and I suppose rest of GNOME). On Mon, Jul 16, 2018 at 1:56 PM, Behdad Esfahbod wrote: > On Mon, Jul 16, 2018 at 1:51 PM, Werner LEMBERG wrote: > >> >> > Why does builds/unix/ftoption.h not have >> > TT_CONFIG_OPTION_COLOR_LAYERS? >> >> There is no such file in the git repository; it's a generated file... >> > > Ok, then the build system is broken and not updating that one... > > >> > I also never understood why there are three ftoption.h files... >> >> We have only two :-) It's mainly laziness that this doesn't get >> changed. > > > Glad to hear that :). > > -- > behdad > http://behdad.org/ > -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] COLR/CPAL
On Mon, Jul 16, 2018 at 1:51 PM, Werner LEMBERG wrote: > > > Why does builds/unix/ftoption.h not have > > TT_CONFIG_OPTION_COLOR_LAYERS? > > There is no such file in the git repository; it's a generated file... > Ok, then the build system is broken and not updating that one... > > I also never understood why there are three ftoption.h files... > > We have only two :-) It's mainly laziness that this doesn't get > changed. Glad to hear that :). -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] COLR/CPAL
> Why does builds/unix/ftoption.h not have > TT_CONFIG_OPTION_COLOR_LAYERS? There is no such file in the git repository; it's a generated file... > I also never understood why there are three ftoption.h files... We have only two :-) It's mainly laziness that this doesn't get changed. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] COLR/CPAL
Why does builds/unix/ftoption.h not have TT_CONFIG_OPTION_COLOR_LAYERS? I also never understood why there are three ftoption.h files... On Mon, Jul 16, 2018 at 12:37 PM, Behdad Esfahbod wrote: > Looks like my config thinks TT_CONFIG_OPTION_COLOR_LAYERS is disabled... > > On Mon, Jul 16, 2018 at 12:31 PM, Behdad Esfahbod > wrote: > >> On Sat, Jul 14, 2018 at 9:15 PM, Werner LEMBERG wrote: >> >>> >>> > Looks to me like FT_HAS_COLOR still returns false for COLR/CPAL >>> > fonts. Any idea? >>> >>> How do you come to this impression? There is the following code in >>> `sfobjs.c' around line 1405: >>> >>> if ( face->sbit_table_type == TT_SBIT_TABLE_TYPE_CBLC || >>>face->sbit_table_type == TT_SBIT_TABLE_TYPE_SBIX || >>>face->colr ) >>> flags |= FT_FACE_FLAG_COLOR; /* color glyphs */ >>> >>> For me it seems to work. Do you have a counterexample? >> >> >> Running fc-query on seguiemj.ttf returns color=false. The code is: >> >> >> ↦ has_color = !!(face->face_flags & FT_FACE_FLAG_COLOR); >> ↦ if (!FcPatternAddBool (pat, FC_COLOR, has_color)) >> ↦ goto bail1; >> >> I need to debug. >> >> -- >> behdad >> http://behdad.org/ >> > > > > -- > behdad > http://behdad.org/ > -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] COLR/CPAL
Looks like my config thinks TT_CONFIG_OPTION_COLOR_LAYERS is disabled... On Mon, Jul 16, 2018 at 12:31 PM, Behdad Esfahbod wrote: > On Sat, Jul 14, 2018 at 9:15 PM, Werner LEMBERG wrote: > >> >> > Looks to me like FT_HAS_COLOR still returns false for COLR/CPAL >> > fonts. Any idea? >> >> How do you come to this impression? There is the following code in >> `sfobjs.c' around line 1405: >> >> if ( face->sbit_table_type == TT_SBIT_TABLE_TYPE_CBLC || >>face->sbit_table_type == TT_SBIT_TABLE_TYPE_SBIX || >>face->colr ) >> flags |= FT_FACE_FLAG_COLOR; /* color glyphs */ >> >> For me it seems to work. Do you have a counterexample? > > > Running fc-query on seguiemj.ttf returns color=false. The code is: > > > ↦ has_color = !!(face->face_flags & FT_FACE_FLAG_COLOR); > ↦ if (!FcPatternAddBool (pat, FC_COLOR, has_color)) > ↦ goto bail1; > > I need to debug. > > -- > behdad > http://behdad.org/ > -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] COLR/CPAL
On Sat, Jul 14, 2018 at 9:15 PM, Werner LEMBERG wrote: > > > Looks to me like FT_HAS_COLOR still returns false for COLR/CPAL > > fonts. Any idea? > > How do you come to this impression? There is the following code in > `sfobjs.c' around line 1405: > > if ( face->sbit_table_type == TT_SBIT_TABLE_TYPE_CBLC || >face->sbit_table_type == TT_SBIT_TABLE_TYPE_SBIX || >face->colr ) > flags |= FT_FACE_FLAG_COLOR; /* color glyphs */ > > For me it seems to work. Do you have a counterexample? Running fc-query on seguiemj.ttf returns color=false. The code is: ↦ has_color = !!(face->face_flags & FT_FACE_FLAG_COLOR); ↦ if (!FcPatternAddBool (pat, FC_COLOR, has_color)) ↦ goto bail1; I need to debug. -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] GSoC status update.
>> Now `ftview' displays the gf glyphs too! I am attaching a >> screenshot of the output from `ftview' and `ftstring'! [...] Looks good, thanks! I wonder whether it makes sense to add an artificial space glyph to the GF + TFM combo – most font formats have a space glyph for simple string support... What do you think? The width of such a space glyph could be derived from TFM's `param[2]' value. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] External link modified
> There is a link to [1] in the last section on [2] (labeled "dropout > control") which is no longer available. > This might be the new link: https://docs.microsoft.com/en-us/typography/opentype/spec/ttch01#the-scan-converter I've also noticed 404's on some other links to Microsoft docs. Here's a few I came across: * In https://www.freetype.org/freetype2/docs/reference/ft2-truetype_tables.html#TT_MS_LANGID_XXX (possible new link: https://msdn.microsoft.com/en-us/library/cc233982.aspx). * In https://www.freetype.org/freetype2/docs/reference/ft2-winfnt_fonts.html#FT_WinFNT_ID_OEM (not sure where this got shifted to). -- Nikhil ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] GSoC status update.
>>> Perhaps there is some missing documentation or a missing >>> explanatory comment in the code... > > Hmm, maybe a note on this could go into `FreeType Design / IV', as a > list of services all drivers are required to implement. Good idea! Parth, please file a bug report (with item group `wishlist') so that it won't be forgotten. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] GSoC status update.
>> Please tell me why you wasn't able to identify the problem by >> yourself! > > > Actually, I thought that these services are not a regular part of > the module and are defined only if there are functions of the driver > required outside the driver, so I did not define them. Ah, ok. > But, I was unaware that the services are used by the demo program. It doesn't directly use a service since services are always internal to FreeType. Instead, it uses a high-level API function that delegates all of its work to a service. > As I was first debugging with `ftview' and I was going function by > function to debug it and I was stuck at the `FTC' functions. Then > when you told to debug through `ftstring', I thought to do it later > as I was in middle of learning about the `vf' fonts. BTW, `ftview' crashes in *exactly* the same way... And I was wrong since my memory failed me: `ftstring' also uses some caching code, provided by routines in `ftcommon.c'. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] GSoC status update.
> >>> I've still not found time to have a closer look at the issue, sorry
>>> >>> (still on vacation more or less). Please try to debug it by
>>> >>> yourself also – I can only assist, since it's actually your job to
>>> >>> find the bug...
>>> >>
>>> >> Yes, I am working on it. If you could just give me a lead like
>>> >> where should I look upon and like possible sources of errors, it
>>> >> will be great help.
>>> >
>>> > I'm quite sure this is not a problem of `ftview'. Similarly, I'm
>>> > quite sure it is not a problem of FreeType's caching code either.
>>>
>>> I've now done some debugging:
>>>
>>> gdb --args /home/wl/git/freetype/freetype2-demos.parth/bin/ftstring
>>> 20 cmr10.600gf
>>> (gdb) r
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x76817ea6 in __strcmp_ssse3 () from /lib64/libc.so.6
>>> (gdb) up
>>> #1 0x004088af in my_face_requester (face_id=0x762110,
>>> lib=0x747df0, request_data=0x0, aface=0x770118) at
>>> src/ftcommon.c:239
>>> 239 if ( !strcmp( format, "Type 1" ) )
>>> (gdb) p format
>>> $1 = 0x0
>>> (gdb) l
>>> 234 if ( !error )
>>> 235 {
>>> 236 const char* format = FT_Get_Font_Format( *aface );
>>> 237
>>> 238
>>> 239 if ( !strcmp( format, "Type 1" ) )
>>> 240 {
>>> 241 char orig[5];
>>> 242 char* suffix= (char*)strrchr(
>>> font->filepathname, '.' );
>>> 243 inthas_extension = suffix
>>> &&
>>>
>>> This clearly shows that the problem is in `FT_Get_Font_Format'; this
>>> function returns zero which looks very fishy according to its
>>> documentation.
>>>
>>> (gdb) b FT_Get_Font_Format
>>> (gdb) r
>>> Breakpoint 1, FT_Get_Font_Format (face=0x7703c0) at
>>> /home/wl/git/freetype/freetype2.parth/src/base/ftfntfmt.c:30
>>> 30 const char* result = NULL;
>>> (gdb) n
>>> 33 if ( face )
>>> (gdb)
>>> 34FT_FACE_FIND_SERVICE( face, result, FONT_FORMAT );
>>> (gdb)
>>> 36 return result;
>>> (gdb) p result
>>> $2 = 0x0
>>>
>>> Obviously, there is a problem with the `FONT_FORMAT' service in the GF
>>> driver; let's check the winfnt driver for comparison.
>>>
>>> cd winfonts
>>> git grep FONT_FORMAT
>>> winfnt.c:#include FT_SERVICE_FONT_FORMAT_H
>>> winfnt.c:{ FT_SERVICE_ID_FONT_FORMAT, FT_FONT_FORMAT_WINFNT },
>>>
>>> cd gf
>>> git grep FONT_FORMAT
>>> gfdrivr.c:#include FT_SERVICE_FONT_FORMAT_H
>>>
>>> Ouch, the service is completely missing...
>>>
>>> Tadaa!
>>>
>>> Have a look into `include/freetype/internal/services/svfntfmt.h'.
>>>
>>
>> Yes! indeed! Thank you so much for that.
>>
>>
>>> Please tell me why you wasn't able to identify the problem by
>>> yourself!
>>
>>
>> Actually, I thought that these services are not a regular part of the
>> module
>> and are defined only if there are functions of the driver required
>> outside the
>> driver, so I did not define them. But, I was unaware that the services
>> are
>> used by the demo program. As I was first debugging with `ftview' and I
>> was
>> going function by function to debug it and I was stuck at the `FTC'
>> functions.
>> Then when you told to debug through `ftstring', I thought to do it later
>> as I was in middle of learning about the `vf' fonts.
>>
>>
>>> Perhaps there is some missing documentation or a missing
>>> explanatory comment in the code...
>>>
>>
> Now `ftview' displays the gf glyphs too!
> I am attaching a screenshot of the output from `ftview' and `ftstring'!
> [...]
>
Attaching a cropped image.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] External link modified
There is a link to [1] in the last section on [2] (labeled "dropout control") which is no longer available. Ankit [1] https://www.microsoft.com/typography/TrueTypeScanConversion.mspx [2] https://www.freetype.org/freetype2/docs/tutorial/step2.html ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] GSoC status update.
>
> >>> I've still not found time to have a closer look at the issue, sorry
> >>> (still on vacation more or less). Please try to debug it by
> >>> yourself also – I can only assist, since it's actually your job to
> >>> find the bug...
> >>
> >> Yes, I am working on it. If you could just give me a lead like
> >> where should I look upon and like possible sources of errors, it
> >> will be great help.
> >
> > I'm quite sure this is not a problem of `ftview'. Similarly, I'm
> > quite sure it is not a problem of FreeType's caching code either.
>
> I've now done some debugging:
>
> gdb --args /home/wl/git/freetype/freetype2-demos.parth/bin/ftstring 20
> cmr10.600gf
> (gdb) r
> Program received signal SIGSEGV, Segmentation fault.
> 0x76817ea6 in __strcmp_ssse3 () from /lib64/libc.so.6
> (gdb) up
> #1 0x004088af in my_face_requester (face_id=0x762110,
> lib=0x747df0, request_data=0x0, aface=0x770118) at src/ftcommon.c:239
> 239 if ( !strcmp( format, "Type 1" ) )
> (gdb) p format
> $1 = 0x0
> (gdb) l
> 234 if ( !error )
> 235 {
> 236 const char* format = FT_Get_Font_Format( *aface );
> 237
> 238
> 239 if ( !strcmp( format, "Type 1" ) )
> 240 {
> 241 char orig[5];
> 242 char* suffix= (char*)strrchr(
> font->filepathname, '.' );
> 243 inthas_extension = suffix
> &&
>
> This clearly shows that the problem is in `FT_Get_Font_Format'; this
> function returns zero which looks very fishy according to its
> documentation.
>
> (gdb) b FT_Get_Font_Format
> (gdb) r
> Breakpoint 1, FT_Get_Font_Format (face=0x7703c0) at
> /home/wl/git/freetype/freetype2.parth/src/base/ftfntfmt.c:30
> 30 const char* result = NULL;
> (gdb) n
> 33 if ( face )
> (gdb)
> 34FT_FACE_FIND_SERVICE( face, result, FONT_FORMAT );
> (gdb)
> 36 return result;
> (gdb) p result
> $2 = 0x0
>
> Obviously, there is a problem with the `FONT_FORMAT' service in the GF
> driver; let's check the winfnt driver for comparison.
>
> cd winfonts
> git grep FONT_FORMAT
> winfnt.c:#include FT_SERVICE_FONT_FORMAT_H
> winfnt.c:{ FT_SERVICE_ID_FONT_FORMAT, FT_FONT_FORMAT_WINFNT },
>
> cd gf
> git grep FONT_FORMAT
> gfdrivr.c:#include FT_SERVICE_FONT_FORMAT_H
>
> Ouch, the service is completely missing...
>
> Tadaa!
>
> Have a look into `include/freetype/internal/services/svfntfmt.h'.
>
Yes! indeed! Thank you so much for that.
> Please tell me why you wasn't able to identify the problem by
> yourself!
Actually, I thought that these services are not a regular part of the module
and are defined only if there are functions of the driver required outside
the
driver, so I did not define them. But, I was unaware that the services are
used by the demo program. As I was first debugging with `ftview' and I was
going function by function to debug it and I was stuck at the `FTC'
functions.
Then when you told to debug through `ftstring', I thought to do it later
as I was in middle of learning about the `vf' fonts.
> Perhaps there is some missing documentation or a missing
> explanatory comment in the code...
>
Yes. I think so too.
Thank you
Parth
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] GSoC status update.
>>> I've still not found time to have a closer look at the issue, sorry
>>> (still on vacation more or less). Please try to debug it by
>>> yourself also – I can only assist, since it's actually your job to
>>> find the bug...
>>
>> Yes, I am working on it. If you could just give me a lead like
>> where should I look upon and like possible sources of errors, it
>> will be great help.
>
> I'm quite sure this is not a problem of `ftview'. Similarly, I'm
> quite sure it is not a problem of FreeType's caching code either.
I've now done some debugging:
gdb --args /home/wl/git/freetype/freetype2-demos.parth/bin/ftstring 20
cmr10.600gf
(gdb) r
Program received signal SIGSEGV, Segmentation fault.
0x76817ea6 in __strcmp_ssse3 () from /lib64/libc.so.6
(gdb) up
#1 0x004088af in my_face_requester (face_id=0x762110,
lib=0x747df0, request_data=0x0, aface=0x770118) at src/ftcommon.c:239
239 if ( !strcmp( format, "Type 1" ) )
(gdb) p format
$1 = 0x0
(gdb) l
234 if ( !error )
235 {
236 const char* format = FT_Get_Font_Format( *aface );
237
238
239 if ( !strcmp( format, "Type 1" ) )
240 {
241 char orig[5];
242 char* suffix= (char*)strrchr( font->filepathname,
'.' );
243 inthas_extension = suffix
&&
This clearly shows that the problem is in `FT_Get_Font_Format'; this
function returns zero which looks very fishy according to its
documentation.
(gdb) b FT_Get_Font_Format
(gdb) r
Breakpoint 1, FT_Get_Font_Format (face=0x7703c0) at
/home/wl/git/freetype/freetype2.parth/src/base/ftfntfmt.c:30
30 const char* result = NULL;
(gdb) n
33 if ( face )
(gdb)
34FT_FACE_FIND_SERVICE( face, result, FONT_FORMAT );
(gdb)
36 return result;
(gdb) p result
$2 = 0x0
Obviously, there is a problem with the `FONT_FORMAT' service in the GF
driver; let's check the winfnt driver for comparison.
cd winfonts
git grep FONT_FORMAT
winfnt.c:#include FT_SERVICE_FONT_FORMAT_H
winfnt.c:{ FT_SERVICE_ID_FONT_FORMAT, FT_FONT_FORMAT_WINFNT },
cd gf
git grep FONT_FORMAT
gfdrivr.c:#include FT_SERVICE_FONT_FORMAT_H
Ouch, the service is completely missing...
Tadaa!
Have a look into `include/freetype/internal/services/svfntfmt.h'.
Please tell me why you wasn't able to identify the problem by
yourself! Perhaps there is some missing documentation or a missing
explanatory comment in the code...
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Updates to Docwriter: Logging, testing, linting
It's funny Python often trades performance for elegance ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
