Re: [ft-devel] GSoC status update.

[Parth Wazurkar]

>
> >> 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?
>
> FreeType already does that for some formats: The glyph with index 0
> must be the equivalent to the `.notdef' glyph (also known as the
> `undefined glyph' or `default glyph') – cf. the WINFNT or BDF driver.
>

Oh, I always wondered what was this `notdef' glyph in the WINFNT driver.
I thought this was something format specific. I get that now. Thanks :-)

BTW, it seems this feature is still missing in the GF driver, so
> please add it.  The actual shape of the glyph with index zero doesn't
> matter; for example, you could construct it on the fly (i.e., while
> loading the GF file), say, a bitmap that contains a hollow box as with
> most TrueType fonts, scaled to the proper font size.
>
>X
>X   X
>X   X
>X   X
>X
>
> Similarly to the above you should construct a second artificial
> character to hold the space glyph (i.e., an empty bitmap which only
> has an advance width); for convenience, I suggest this glyph gets
> index 1.  As a consequence, you would have to shift all (native) glyph
> indices by two; a GF font with 128 glyphs becomes a font with 130
> glyphs, etc., etc.
>
> In case no TFM file is attached to the GF file, please use the font
> size to derive a heuristic width for both the `.notdef' and the
> `space' glyphs.
>

Ok. I will do it.

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.

[Werner LEMBERG]

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

FreeType already does that for some formats: The glyph with index 0
must be the equivalent to the `.notdef' glyph (also known as the
`undefined glyph' or `default glyph') – cf. the WINFNT or BDF driver.
BTW, it seems this feature is still missing in the GF driver, so
please add it.  The actual shape of the glyph with index zero doesn't
matter; for example, you could construct it on the fly (i.e., while
loading the GF file), say, a bitmap that contains a hollow box as with
most TrueType fonts, scaled to the proper font size.

   X
   X   X
   X   X
   X   X
   X

Similarly to the above you should construct a second artificial
character to hold the space glyph (i.e., an empty bitmap which only
has an advance width); for convenience, I suggest this glyph gets
index 1.  As a consequence, you would have to shift all (native) glyph
indices by two; a GF font with 128 glyphs becomes a font with 130
glyphs, etc., etc.

In case no TFM file is attached to the GF file, please use the font
size to derive a heuristic width for both the `.notdef' and the
`space' glyphs.


Werner

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

Re: [ft-devel] GSoC status update.

[Parth Wazurkar]

>
> Now `ftview' displays the gf glyphs too!
> I am attaching a screenshot of the output from `ftview' and `ftstring'!
> [...]
>

I have cleaned up the code for `gf driver' in the branch `parthw-cleaned',
removed all unnecessary typedefs and comments.
I have currently tested for many `gf' files, like cmr1, cmr2, cmr10, with
different options in `ftview' and `ftgrid' and it is working fine.
Can you please once test the driver so that if there are any further changes
required, I can complete that.

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.

[Parth Wazurkar]

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

[Parth Wazurkar]

>
> >>> 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] GSoC status update.

[Werner LEMBERG]

>> 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] GSoC status update.

[Werner LEMBERG]

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

[Werner LEMBERG]

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

[Parth Wazurkar]

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

Re: [ft-devel] GSoC status update.

[Parth Wazurkar]

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

[Werner LEMBERG]

>>> 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] GSoC status update.

[Parth Wazurkar]

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

Ok.


> What about trying `ftstring' instead?  IIRC, it doesn't use the
> caching code; debugging it should thus be simpler.
>

Yes! I'll do that. Thanks.

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

Re: [ft-devel] GSoC status update.

[Werner LEMBERG]

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

What about trying `ftstring' instead?  IIRC, it doesn't use the
caching code; debugging it should thus be simpler.


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

Re: [ft-devel] GSoC status update.

[Parth Wazurkar]

>
> > * GF Driver: I have added support for parsing the `xxx' and `yyy'
> > commands.  Now the gf driver supports all the `gf' font files!  I am
> > working on the possibilities of parsing information from these
> > commands.
>
> Good.  Does `ftview' amd friends already work?


No not yet.


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


> > * PK Driver: The `pk' driver is almost similar to the `gf' driver.
> > I have added all the code for the pk driver in the branch
> > `parthw-pk-vf'.  The driver is running properly and allocating
> > bitmap values like the gf driver!
>
> Good, too :-)  Still waiting for an image from `ftview'...
>

Will get it running soon! :-)

> Please let me know if there are any instructions for me :-)
>
> I suggest that you get rid of `UINT' and friends, replacing it with
> `FT_UInt' and similar FreeType entities.  This should (a) make the
> source code appearance more uniform, and (b) it should make debugging
> easier since you have to remember less typedefs.
>

Ok.

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.

[Werner LEMBERG]

> * GF Driver: I have added support for parsing the `xxx' and `yyy'
> commands.  Now the gf driver supports all the `gf' font files!  I am
> working on the possibilities of parsing information from these
> commands.

Good.  Does `ftview' amd friends already work?  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...

> * PK Driver: The `pk' driver is almost similar to the `gf' driver.
> I have added all the code for the pk driver in the branch
> `parthw-pk-vf'.  The driver is running properly and allocating
> bitmap values like the gf driver!

Good, too :-)  Still waiting for an image from `ftview'...

> Please let me know if there are any instructions for me :-)

I suggest that you get rid of `UINT' and friends, replacing it with
`FT_UInt' and similar FreeType entities.  This should (a) make the
source code appearance more uniform, and (b) it should make debugging
easier since you have to remember less typedefs.


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

[ft-devel] GSoC status update.

[Parth Wazurkar]

Hi all,
Here are some quick updates,

* GF Driver: I have added support for parsing the
`xxx' and `yyy' commands. Now the gf driver supports
all the `gf' font files! I am working on the possibilities
of parsing information from these commands.

* PK Driver: The `pk' driver is almost similar to the `gf'
driver. I have added all the code for the pk driver in the
branch `parthw-pk-vf'. The driver is running properly and
allocating bitmap values like the gf driver!

* TFM Driver: Some changes are remaining and it will be
working soon!

* VF Driver: I have started working on the code, and
will get it running soon!

Please let me know if there are any instructions for me :-)

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

[Werner LEMBERG]

> I have cleaned up the code and now gf driver has all the code
> required to run the driver, the driver is now properly extracting
> the information correctly from the font file.  All the
> `gf_driver_class' functions are also complete now.

Excellent.  Will test soon.

> But, when I run `ftview' it is giving errors somewhere, it loads the
> display but after a while gives a segmentation fault.  After some
> debugging I found out that the error is in the
> `FTC_Manager_LookupFace' function.  I am unable to figure out the
> error here.  Please help me with this.

I suggest that you use `valgrind'.  To get meaningful results you
should have debugging symbols in the binary (i.e., compile the library
with `make devel; make'.

valgrind ftview ...

An additional help is to use clang's sanitize functionality: Add
`-fsanitize=undefined' and `-fsanitize=address' while compiling and
linking with clang (or a recent gcc version), then run the binary.
Note that valgrind can't digest a binary with sanitize functionality
since it essentially does the same.

If this doesn't help I need an example to reproduce the problem,
together with instructions how to trigger the segfault.


Werner

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

Re: [ft-devel] GSoC Status update

[Parth Wazurkar]

>
> > * About the testing of the gf driver, there are still some issues
>> >   left to be sorted out.  I am working on them.
>>
>> What I want to have is code in your `gf' module so that `ftview' can
>> display GF fonts.
>>
>
> I have cleaned up the code and now gf driver has all the code required
> to run the driver, the driver is now properly extracting the information
> correctly from the font file. All the `gf_driver_class' functions are also
> complete now.
> But, when I run `ftview' it is giving errors somewhere, it loads the
> display
> but after a while gives a segmentation fault. [...]
>
> When will you reach that point?
>
After this issue is resolved,  the gf driver will be up and running.

Thank you.

--
Parth

On Thu, Jun 28, 2018 at 3:30 PM, Parth Wazurkar 
wrote:

> > * About the testing of the gf driver, there are still some issues
>> >   left to be sorted out.  I am working on them.
>>
>> What I want to have is code in your `gf' module so that `ftview' can
>> display GF fonts.  When will you reach that point?
>>
>
> I have cleaned up the code and now gf driver has all the code required
> to run the driver, the driver is now properly extracting the information
> correctly from the font file. All the `gf_driver_class' functions are also
> complete now.
> But, when I run `ftview' it is giving errors somewhere, it loads the
> display
> but after a while gives a segmentation fault. After some debugging I found
> out that the error is in the `FTC_Manager_LookupFace' function. I am
> unable
> to figure out the error here. Please help me with this.
> I have added final code with printf flags to the branch `parthw-wip'. This
> code is
> unclean, please ignore that.
>
> 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

[Parth Wazurkar]

>
> > * About the testing of the gf driver, there are still some issues
> >   left to be sorted out.  I am working on them.
>
> What I want to have is code in your `gf' module so that `ftview' can
> display GF fonts.  When will you reach that point?
>

I have cleaned up the code and now gf driver has all the code required
to run the driver, the driver is now properly extracting the information
correctly from the font file. All the `gf_driver_class' functions are also
complete now.
But, when I run `ftview' it is giving errors somewhere, it loads the display
but after a while gives a segmentation fault. After some debugging I found
out that the error is in the `FTC_Manager_LookupFace' function. I am unable
to figure out the error here. Please help me with this.
I have added final code with printf flags to the branch `parthw-wip'. This
code is
unclean, please ignore that.

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

[Werner LEMBERG]

> * I had been working on the stream support for the gf driver for
>   quite a while now, and I have completed it.

Good!

> * About the testing of the gf driver, there are still some issues
>   left to be sorted out.  I am working on them.

What I want to have is code in your `gf' module so that `ftview' can
display GF fonts.  When will you reach that point?

> * I have already started working on the tfm driver. I intend to work
>   on it as I move ahead with the testing of gf driver.

OK.

> * There still remains the error checking and tracing part of the gf
>   driver, which I will eventually add.

OK.


Werner

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

Re: [ft-devel] GSoC Status update and complete API reference website

[Nikhil Ramakrishnan]

> > See the attached screenshots, for an idea of how this will work.
>
> Looks good!
>

Great, changes implemented and wiki updated! I have removed the
original tilde method.


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

[ft-devel] GSoC Status update

[Parth Wazurkar]

Hi all,
* I had been working on the stream support for the gf driver
for quite a while now, and I have completed it.

* About the testing of the gf driver, there are still some issues
left to be sorted out. I am working on them.

* I have already started working on the tfm driver. I intend to work
on it as I move ahead with the testing of gf driver.

* There still remains the error checking and tracing part of the gf driver,
which I will eventually add.

Please let me know if there are any instructions or feedback you wish to
give me.

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 and complete API reference website

[Werner LEMBERG]

> I just realized that this would cause a problem with nested lists.
> A solution here is to indent multi-paragraph lists to 4 spaces in
> the docs itself, so that docwriter is freed from the responsibility
> of keeping track of the spaces.

Yes.

> See the attached screenshots, for an idea of how this will work.

Looks good!


Werner

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

Re: [ft-devel] GSoC Status update and complete API reference website

[Nikhil Ramakrishnan]

> Hmm.  What about making DocPara strip leading and trailing spaces
> *except* for the first leading space in a paragraph?


This seems reasonable. This will be implemented as follows:

* DocPara will have a new property 'indent' which will store the
  indentation of the first line of the paragraph.

* The previous paragraph's indent value will be stored as the 'margin'
  in the caller (DocField).

* 'margin' will be sent while creating DocPara for the next paragraph.

* DocPara will compare this value (previous para's indent) with the
  current indentation. If indent > margin + 2, it will add 4 spaces
  to the first line (see below for why I'm adding 4 spaces).


>   We can enforce
> the assumption that the indentation of a paragraph is determined by
> the number of spaces starting the first line.  If we do that, the
> markdown parser sees the correct indentation.  Am I missing something?
>

Have a look at https://daringfireball.net/projects/markdown/syntax#list
Continuing paragraphs in lists require at least 4-space indentation.

I found an example in 'ftdriver.h
'.
Changing the '1)' to '1.' and indenting the
2nd paragraph still won't work directly with markdown because there will
be only 3 spaces.

Therefore for convenience, I'm keeping the required indentation at 3
spaces, and adding 4 wherever there are 3 or more.

Also, the 3 space minimum indent is because URLs are indented with
2 spaces currently, and I don't want to touch them in the output.

Does this seem to be OK?


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

Re: [ft-devel] GSoC Status update and complete API reference website

[Werner LEMBERG]

>> * I'm not happy with
>>
>> To continue a list over multiple paragraphs, start the paragraphs
>> with a tilde (~) character.
>>
>>   I would rather prefer that a continuation is indented as before.
> 
> The problem with this is, DocPara objects strip leading and trailing
> spaces in the string before storing the words in an array.  Doing
> this will involve analysis of the lines before indentation data is
> removed, and creating another object to store lists.  This is not
> good, because we're essentially doing work that the markdown parser
> is supposed to do.

Hmm.  What about making DocPara strip leading and trailing spaces
*except* for the first leading space in a paragraph?  We can enforce
the assumption that the indentation of a paragraph is determined by
the number of spaces starting the first line.  If we do that, the
markdown parser sees the correct indentation.  Am I missing something?

>> * Shall we mention that we prefer two spaces after a full stop
>>   ending a sentence?  Ditto for details on uppercasing in section
>>   titles (US style, for example `This and That'), how to cite a C
>>   function (without trailing parentheses), etc., etc.
> 
> You know a lot more about these small details, and I think these
> should be added to make the file a nice guide to always refer to.  I
> have added you as a collaborator, please add the necessary
> information!

OK.


Werner

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

Re: [ft-devel] GSoC Status update and complete API reference website

[Nikhil Ramakrishnan]

> Very nice, thanks!
>

:-)

Some issues.
>
> * s/comfig/config/.


Oops, fixed!


> * I'm not happy with
>
> To continue a list over multiple paragraphs, start the paragraphs
> with a tilde (~) character.
>
>   I would rather prefer that a continuation is indented as before.
>   Example:
>
> 1. Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
>Aliquam hendrerit mi posuere lectus.  Vestibulum enim wisi,
>viverra nec, fringilla in, laoreet vitae, risus.
>
>Donec sit amet nisl.  Aliquam semper ipsum sit amet velit.
>Suspendisse id sem consectetuer libero luctus adipiscing.
>
>   [IIRC, Pandoc supports this style.]  Is this possible?  What do you
>   think?
>

The problem with this is, DocPara objects strip leading and trailing
spaces in the string before storing the words in an array. Doing this will
involve analysis of the lines before indentation data is removed, and
creating another object to store lists. This is not good, because we're
essentially doing work that the markdown parser is supposed to do.

This may actually require a complete restructuring of the docs making
all content WYSIWYG, and ensuring all indentation is exactly how we
want it to be in the markdown output.

Or do you think there's another way?


> * Shall we mention that we prefer two spaces after a full stop ending
>   a sentence?  Ditto for details on uppercasing in section titles (US
>   style, for example `This and That'), how to cite a C function
>   (without trailing parentheses), etc., etc.
>

You know a lot more about these small details, and I think these should
be added to make the file a nice guide to always refer to. I have added
you as a collaborator, please add the necessary information!


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

Re: [ft-devel] GSoC Status update and complete API reference website

[Werner LEMBERG]

> I have written a draft for this document, available at
> 
> https://github.com/nikramakrishnan/freetype-docs/wiki/Documentation-Guidelines-for-The-FreeType-Project

Very nice, thanks!

Some issues.

* s/comfig/config/.

* I'm not happy with

To continue a list over multiple paragraphs, start the paragraphs
with a tilde (~) character.

  I would rather prefer that a continuation is indented as before.
  Example:

1. Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
   Aliquam hendrerit mi posuere lectus.  Vestibulum enim wisi,
   viverra nec, fringilla in, laoreet vitae, risus.

   Donec sit amet nisl.  Aliquam semper ipsum sit amet velit.
   Suspendisse id sem consectetuer libero luctus adipiscing.

  [IIRC, Pandoc supports this style.]  Is this possible?  What do you
  think?

* Shall we mention that we prefer two spaces after a full stop ending
  a sentence?  Ditto for details on uppercasing in section titles (US
  style, for example `This and That'), how to cite a C function
  (without trailing parentheses), etc., etc.


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

Re: [ft-devel] GSoC Status update and complete API reference website

[Nikhil Ramakrishnan]

> > Because we will now switch to markdown, we may have to be careful
>> > with the usage of asterisks.  They are used to begin points in
>> > unordered lists and wrap italics text.
>>
>> OK.  This is something to be added to a forthcoming
>> `docs/DOCUMENTATION' file.  I invite you to write this while doing the
>> conversion process :-)
>
>
> Sure! I will write this after I fix minor issues and get docwriter working
> on the FreeType repository tree :-)
>

I have written a draft for this document, available at


https://github.com/nikramakrishnan/freetype-docs/wiki/Documentation-Guidelines-for-The-FreeType-Project

This covers most details from the structure of the docs, to guidelines
on writing them in Markdown. I feel that reading this should be enough
for most developers to understand the documentation process.

Please have a look at it, and let me know if I missed something, and
suggest changes and additions!

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

Re: [ft-devel] GSoC Status update and complete API reference website

[Nikhil Ramakrishnan]

> Indeed.  Essentially, everything that can be used within C code should
> be tagged with `...`, for example `FT_Glyph`, `FT_GLYPH_H`, etc.
>
> Maybe it makes sense to convert everything starting with `FT_...' to
> `...`?
>

These cases are covered by the regex I added, so stuff with underscores,
arrow operators, and such will be converted to `...` by markify.


> > Because we will now switch to markdown, we may have to be careful
> > with the usage of asterisks.  They are used to begin points in
> > unordered lists and wrap italics text.
>
> OK.  This is something to be added to a forthcoming
> `docs/DOCUMENTATION' file.  I invite you to write this while doing the
> conversion process :-)


Sure! I will write this after I fix minor issues and get docwriter working
on the FreeType repository tree :-)


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

Re: [ft-devel] GSoC Status update and complete API reference website

[Werner LEMBERG]

 
> OK, I came up with 2 regex expressions to try and find inline code
> sequences, and was able to replace 394 `...' quotes to `...`. All
> other quotes will be converted to '...' (these changes were done in
> markify.py).
> 
> However, this is *not* fool-proof, and many variable names would
> have been left out (stuff like 'face', 'source'...)

Indeed.  Essentially, everything that can be used within C code should
be tagged with `...`, for example `FT_Glyph`, `FT_GLYPH_H`, etc.

Maybe it makes sense to convert everything starting with `FT_...' to
`...`?

> Because we will now switch to markdown, we may have to be careful
> with the usage of asterisks.  They are used to begin points in
> unordered lists and wrap italics text.

OK.  This is something to be added to a forthcoming
`docs/DOCUMENTATION' file.  I invite you to write this while doing the
conversion process :-)


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

Re: [ft-devel] GSoC Status update and complete API reference website

[Nikhil Ramakrishnan]

> Well, `...' should be eventually resolved into `...` and '...'.
>

OK, I came up with 2 regex expressions to try and find inline code
sequences,
and was able to replace 394 `...' quotes to `...`. All other quotes will be
converted to '...' (these changes were done in markify.py).

However, this is *not* fool-proof, and many variable names would have been
left out (stuff like 'face', 'source'...)

(Regex available at
https://github.com/nikramakrishnan/freetype-docs/blob/markdown/markdown_utils.py#L96
,
if anyone is interested).

The changes have been pushed to the preview site.


> I prefer `lsquo' and `rsquo'.
>

OK, I have retained this.

BTW, the problem with the note section in
https://nikramakrishnan.github.io/freetype-site/ft2-glyph_management/#ft_get_glyph
is now fixed because those are now inline code blocks :-)
I'm not sure if there are more of these, but eventually we have to figure
out a way for this to not happen.

Because we will now switch to markdown, we may have to be careful with
the usage of asterisks. They are used to begin points in unordered lists and
wrap italics text.

Asterisks, although should be used directly in inline code blocks (`...`),
should always be escaped (\*) in normal text.

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

Re: [ft-devel] GSoC Status update and complete API reference website

[Werner LEMBERG]

>> Do you mean in the input or in the output?  Right now, `...' in the
>> input has two purposes.
>>
>> (1) It is used as a poor-man's substitute for inline code snippets
>> – the thing Nikhil is talking.
>>
>> (2) It is *really* used for quotations, i.e., `foo' should be
>> converted to ‘foo’.  Note that I prefer ‘foo’ over “foo”, since
>> it is less intrusive to my eyes.
>>

>> This should be disentangled.  However, I don't want to throw away
>> (2) completely.
> 
> Should I look at only changing inline code blocks, or all quotes (in
> input), then?

Well, `...' should be eventually resolved into `...` and '...'.

> Also, in the output, should we retain  and  (‘... ’)
> or should I change those to just single quotes ('..')?

I prefer `lsquo' and `rsquo'.

>> While the majority of `...' is case (1), we have a lot of (2) also.
>> In other words, a fully automated conversion is not possible IMHO.
> 
> It seems like there are 981 instances of quoted text in the docs.  I
> will try to come up with a method to automate this, if possible.
> 
> We can always do a manual cleanup later.

OK.


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

Re: [ft-devel] GSoC Status update and complete API reference website

[Nikhil Ramakrishnan]

> Do you mean in the input or in the output?  Right now, `...' in the
> input has two purposes.
>
> (1) It is used as a poor-man's substitute for inline code snippets –
> the thing Nikhil is talking.
>
> (2) It is *really* used for quotations, i.e., `foo' should be
> converted to ‘foo’.  Note that I prefer ‘foo’ over “foo”, since it
> is less intrusive to my eyes.
>
> This should be disentangled.  However, I don't want to throw away (2)
> completely.
>

Should I look at only changing inline code blocks, or all quotes (in input),
then?

If you want to retain (2) in the input, that will not be a problem because
we can change it in the output. Further, using 'foo' directly in input
should
also not cause any problems.

Also, in the output, should we retain  and  (‘... ’ ) or
should
I change those to just single quotes ('..')?

> Do we have to change the quote style or your scripts can do it?
>
> While the majority of `...' is case (1), we have a lot of (2) also.
> In other words, a fully automated conversion is not possible IMHO.
>

It seems like there are 981 instances of quoted text in the docs.
I will try to come up with a method to automate this, if possible.

We can always do a manual cleanup later.


> BTW, there is a buglet in the conversion script: Have a look at the
> `note' section of
>
>
> https://nikramakrishnan.github.io/freetype-site/ft2-glyph_management/#ft_get_glyph
>
> The current code in the header file starts with
>
>   Because `*aglyph->advance.x' and '*aglyph->advance.y' are 16.16 ...
>
> Note how the stuff between the two `*' gets incorrectly converted to
> italics in the HTML output.
>

Will fix this, thanks.


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

Re: [ft-devel] GSoC Status update and complete API reference website

[Werner LEMBERG]

>>> I do not like `quoted' text.

Do you mean in the input or in the output?  Right now, `...' in the
input has two purposes.

(1) It is used as a poor-man's substitute for inline code snippets –
the thing Nikhil is talking.

(2) It is *really* used for quotations, i.e., `foo' should be
converted to ‘foo’.  Note that I prefer ‘foo’ over “foo”, since it
is less intrusive to my eyes.

This should be disentangled.  However, I don't want to throw away (2)
completely.

>> I do have a suggestion - Changing variable names and inline code
>> snippets to `foobar` instead of `foobar'.  Markdown will add an
>> inline code block around the text (see attached image).
> 
> Yes, I would prefer this.

Me too.

> There was a reason to use different quotes, which I do not remember.

See (2).  `foo' is good old TeX tradition for quotation input.  It's
OK with me to change the `foo' style to 'foo' for (2) in the source
code, as used by markdown.

> Do we have to change the quote style or your scripts can do it?

While the majority of `...' is case (1), we have a lot of (2) also.
In other words, a fully automated conversion is not possible IMHO.

BTW, there is a buglet in the conversion script: Have a look at the
`note' section of

  
https://nikramakrishnan.github.io/freetype-site/ft2-glyph_management/#ft_get_glyph

The current code in the header file starts with

  Because `*aglyph->advance.x' and '*aglyph->advance.y' are 16.16 ...

Note how the stuff between the two `*' gets incorrectly converted to
italics in the HTML output.


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

Re: [ft-devel] GSoC Status update and complete API reference website

[Alexei Podtelezhnikov]

>> I do not like `quoted' text.

> I do have a suggestion - Changing variable names and inline code snippets
> to `foobar` instead of `foobar'. Markdown will add an inline code block
> around the text (see attached image).

Yes, I would prefer this. There was a reason to use different quotes,
which I do not remember. Do we have to change the quote style or your
scripts can do it?

Thanks!
Alexei

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

Re: [ft-devel] GSoC Status update and complete API reference website

[Nikhil Ramakrishnan]

> It is nice that most ordered and unordered lists are picked up. Is it
> described somewhere what is recognized as a list?


For now any list style supported by markdown should work except in
field tables (there is a problem with ordered lists right now, but I am
working to fix this). You can expect any format given in this
handy cheatsheet to work:
https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#lists


> I do not like
> `quoted' text. Can we use italics instead of quotes?
>

This depends on how we want to handle quoted text. There is already a
format for italics (underscore), and things like variable names would
look weird in italics.
I do have a suggestion - Changing variable names and inline code snippets
to `foobar` instead of `foobar'. Markdown will add an inline code block
around the text (see attached image).

Any thoughts?

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

Re: [ft-devel] GSoC Status update and complete API reference website

[Werner LEMBERG]

>> * In the `fields' subsection of each element, please reduce the
>>   space between the elements.  In most cases, the descriptions are
>>   only a single line, and (at least with my Chrome browser) this
>>   takes too much vertical space IMHO, see attached image.
> 
> I have reduced the space. Please check!

Better, thanks!


Werner

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

Re: [ft-devel] GSoC Status update and complete API reference website

[Nikhil Ramakrishnan]

> Right now I've noticed only two issues.
>
> * Looking at
>
> https://nikramakrishnan.github.io/freetype-site/ft2-toc/
>
>   I wonder why the `Docs' link in
>
> Docs » Table of Contents
>
>   points to the index.  Is this intentional?  I assume this is a
>   temporary decision, since later on we mount the whole reference into
>   the FreeType tree so that `Docs' links to
>
> https://www.freetype.org/freetype2/docs/documentation.html
>
>   or something similar, right?
>

This is temporary. I wanted a valid internal link for now, and I will
point this to the documentation link later.


> * In the `fields' subsection of each element, please reduce the space
>   between the elements.  In most cases, the descriptions are only a
>   single line, and (at least with my Chrome browser) this takes too
>   much vertical space IMHO, see attached image.
>

I have reduced the space. Please check!


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

Re: [ft-devel] GSoC Status update and complete API reference website

[Alexei Podtelezhnikov]

On Tue, Jun 12, 2018 at 8:26 AM, Nikhil Ramakrishnan
 wrote:
> * The complete API documentation site is now available on
> https://nikramakrishnan.github.io/freetype-site/ft2-toc/
> This was generated using docwriter with the header files
> updated to commit b18f5e7c62c0aa6f8d17cbb9a8fe687ed402569a.

This looks really nice. I can see all my errors in
https://nikramakrishnan.github.io/freetype-site/ft2-lcd_rendering/,
which I actually want to move from Support API to Controlling FreeType
Modules.

It is nice that most ordered and unordered lists are picked up. Is it
described somewhere what is recognized as a list? I do not like
`quoted' text. Can we use italics instead of quotes?

Thanks,
Alexei

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

Re: [ft-devel] GSoC Status update and complete API reference website

[Werner LEMBERG]

Hello Nikhil!


> * Also, docwriter
>   (https://github.com/nikramakrishnan/freetype-docwriter) can now
>   output Markdown, and I am in the process of writing code to
>   automatically generate the `yml' configuration file required by
>   MkDocs.

Great!  Will check that within the next few days.

> Please also let me know of any problems you notice with the
> website, and any other comments.

Right now I've noticed only two issues.

* Looking at

https://nikramakrishnan.github.io/freetype-site/ft2-toc/

  I wonder why the `Docs' link in

Docs » Table of Contents

  points to the index.  Is this intentional?  I assume this is a
  temporary decision, since later on we mount the whole reference into
  the FreeType tree so that `Docs' links to

https://www.freetype.org/freetype2/docs/documentation.html

  or something similar, right?

* In the `fields' subsection of each element, please reduce the space
  between the elements.  In most cases, the descriptions are only a
  single line, and (at least with my Chrome browser) this takes too
  much vertical space IMHO, see attached image.


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

[ft-devel] GSoC Status update and complete API reference website

[Nikhil Ramakrishnan]

Hi all,

* It's been 4 weeks since the coding period for GSoC began and
I have written another status update for weeks 3 & 4:
https://github.com/nikramakrishnan/freetype-docs/wiki/GSoC-Status-Update:-Week-3-&-4

* Also, docwriter (https://github.com/nikramakrishnan/freetype-docwriter)
can now output Markdown, and I am in the process of writing
code to automatically generate the `yml' configuration file
required by MkDocs.

* The complete API documentation site is now available on
https://nikramakrishnan.github.io/freetype-site/ft2-toc/
This was generated using docwriter with the header files
updated to commit b18f5e7c62c0aa6f8d17cbb9a8fe687ed402569a

.

I am in the process of implementing changes and fixing
bugs suggested/reported on the mailing list previously.

Please also let me know of any problems you notice with the
website, and any other comments.

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

Re: [ft-devel] [GSoC] Status Update after community bonding period

[Werner LEMBERG]

> I have written a blog post about the community bonding period here
> .

Nice!

> Please let me know if there are any other instructions which you
> wish to give me.

Nothing specific comes to my mind.  Have fun with coding!


Werner

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

[ft-devel] [GSoC] Status Update after community bonding period

[Parth Wazurkar]

Hi all,
I have written a blog post about the community bonding period here
.
I am currently going through the VFlib's codebase and have started gaining
insights for the GF driver, I have also started coding for the driver and
will come up with initial code soon!
Please let me know if there are any other instructions which you wish to
give me.

Thank you!

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