Re: [ft-devel] Contribution to freetype

[Parth Wazurkar]

Hi,
Sir I have submitted a draft proposal on the GSoC platform, please tell me
for the required changes.
Apologies for the delay.

Thank You

Regards
Parth

On Mon, Mar 19, 2018 at 2:57 PM, Parth Wazurkar 
wrote:

> Hi,
> Due to my college exams I will have to delay my draft proposal submission.
> I will do that as soon as the exam gets over. I will send it by 22nd so
> that we can discuss further.
>
> Thank You
>
> Regards
> Parth
>
> On Sun, Mar 18, 2018 at 12:04 PM, Parth Wazurkar 
> wrote:
>
>>
>> There's nothing to implement during GSoC!  Composite outline font
>>> support is something completely different.
>>>
>>>
>>> OK!
>> Thank You
>>
>> Regards
>> Parth
>>
>>
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Contribution to freetype

[Parth Wazurkar]

Hi,
Due to my college exams I will have to delay my draft proposal submission.
I will do that as soon as the exam gets over. I will send it by 22nd so
that we can discuss further.

Thank You

Regards
Parth

On Sun, Mar 18, 2018 at 12:04 PM, Parth Wazurkar 
wrote:

>
> There's nothing to implement during GSoC!  Composite outline font
>> support is something completely different.
>>
>>
>> OK!
> Thank You
>
> Regards
> Parth
>
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Contribution to freetype

[Werner LEMBERG]

> Maybe Werner already knows, it could be regarded as one of the
> ancestors of ISO/IEC 14496-28:
> https://blogs.adobe.com/CCJKType/2012/04/cfr.html

Thanks for the remainder!


Werner

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

Re: [ft-devel] Contribution to freetype

[suzuki toshiya]

Maybe Werner already knows, it could be regarded as one of
the ancestors of ISO/IEC 14496-28:
https://blogs.adobe.com/CCJKType/2012/04/cfr.html

Regards,
mpsuzuki

Khaled Hosny wrote:
> On Sun, Mar 18, 2018 at 12:13:03PM +0100, Werner LEMBERG wrote:
>>> In the namespace definition of XML, such strings looking like as URL
>>> are required as the identifiers, and often unreachable URL causing
>>> 404 error.  But it is not broken in the conformance of XML spec.
>> OK, thanks.  I was just curious and tried to get more information :-)
> 
> See the “Composite Fonts” section in:
> https://msdn.microsoft.com/en-us/library/system.windows.media.fontfamily(v=vs.110).aspx
> 
> Regards,
> Khaled
> 


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

Re: [ft-devel] Contribution to freetype

[Werner LEMBERG]

> See the “Composite Fonts” section in:
> https://msdn.microsoft.com/en-us/library/system.windows.media.fontfamily(v=vs.110).aspx

Thanks a lot!


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

Re: [ft-devel] Contribution to freetype

[Khaled Hosny]

On Sun, Mar 18, 2018 at 12:13:03PM +0100, Werner LEMBERG wrote:
> > In the namespace definition of XML, such strings looking like as URL
> > are required as the identifiers, and often unreachable URL causing
> > 404 error.  But it is not broken in the conformance of XML spec.
> 
> OK, thanks.  I was just curious and tried to get more information :-)

See the “Composite Fonts” section in:
https://msdn.microsoft.com/en-us/library/system.windows.media.fontfamily(v=vs.110).aspx

Regards,
Khaled

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

Re: [ft-devel] Contribution to freetype

[Werner LEMBERG]

> In the namespace definition of XML, such strings looking like as URL
> are required as the identifiers, and often unreachable URL causing
> 404 error.  But it is not broken in the conformance of XML spec.

OK, thanks.  I was just curious and tried to get more information :-)


Werner

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

Re: [ft-devel] Contribution to freetype

[suzuki toshiya]

Hi,

slightly off-topic discussion...

> Maybe I'm mistaken.  Note that the `xmlns' link in those XML files,
> 
>   http://schemas.microsoft.com/winfx/2006/xaml/composite-font
> 
> is broken.  However, it contains the string `winfx', which is (or

In the namespace definition of XML, such strings looking like as URL
are required as the identifiers, and often unreachable URL causing
404 error. But it is not broken in the conformance of XML spec.

Regards,
mpsuzuki

Werner LEMBERG wrote:
>>> If I understand you correctly, an application that uses DirectWrite
>>> doesn't need `.compositeFont' files at all, right?  What happens
>>> with applications that don't use DirectWrite?
>> No, I don't think they have any value for DirectWrite.  If
>> application is not using DirectWrite the only option left is GDI
>> paired with Uniscribe, or .NET (WPF is also working through
>> DirectWrite in modern versions).
> 
> OK.
> 
>>> AFAIK, Windows offers composite fonts in its font selection menu
>>> like normal fonts...
>> Where do you see this, and under what names are they listed?
> 
> I concluded this from a comment in `GlobalSerif.compositeFont':
> 
>   
>   
> [...]
> 
> Maybe I'm mistaken.  Note that the `xmlns' link in those XML files,
> 
>   http://schemas.microsoft.com/winfx/2006/xaml/composite-font
> 
> is broken.  However, it contains the string `winfx', which is (or
> was?) a .NET thing.
> 
>>> We are miscommunicating, I think.  I talk about taking a
>>> `.compositeFont' file and use it as a font.  You are talking about
>>> configurability of `.compositeFont' files, effectively overriding
>>> its contents.
>> I'm talking about data such files provide.  Assuming the idea was
>> for freetype to read them directly, and interpret one way or
>> another.
> 
> Yes, FreeType should be able read this sort of data.
> 
> 
> Werner
> 
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
> 


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

Re: [ft-devel] Contribution to freetype

[Werner LEMBERG]

>> If I understand you correctly, an application that uses DirectWrite
>> doesn't need `.compositeFont' files at all, right?  What happens
>> with applications that don't use DirectWrite?
> 
> No, I don't think they have any value for DirectWrite.  If
> application is not using DirectWrite the only option left is GDI
> paired with Uniscribe, or .NET (WPF is also working through
> DirectWrite in modern versions).

OK.

>> AFAIK, Windows offers composite fonts in its font selection menu
>> like normal fonts...
> 
> Where do you see this, and under what names are they listed?

I concluded this from a comment in `GlobalSerif.compositeFont':

  
  
[...]

Maybe I'm mistaken.  Note that the `xmlns' link in those XML files,

  http://schemas.microsoft.com/winfx/2006/xaml/composite-font

is broken.  However, it contains the string `winfx', which is (or
was?) a .NET thing.

>> We are miscommunicating, I think.  I talk about taking a
>> `.compositeFont' file and use it as a font.  You are talking about
>> configurability of `.compositeFont' files, effectively overriding
>> its contents.
> 
> I'm talking about data such files provide.  Assuming the idea was
> for freetype to read them directly, and interpret one way or
> another.

Yes, FreeType should be able read this sort of data.


Werner

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

Re: [ft-devel] Contribution to freetype

[Nikolay Sivov]

On 3/18/2018 12:05 PM, Werner LEMBERG wrote:
> 
>> Higher level would make use of ranges/language mapping for fallback.
>> DirectWrite fallback is modeled very close if not identical to how
>> this data is defined in .compositefont xml format.  When using
>> DirectWrite layout API, application can rely on implicit fonts being
>> selected for different script ranges, and you can set specific
>> language per range to get more accurate results.  Newer versions
>> allow user-defined fallback data, and API-wise it's very close to
>> what those files provide.
> 
> If I understand you correctly, an application that uses DirectWrite
> doesn't need `.compositeFont' files at all, right?  What happens with
> applications that don't use DirectWrite?

No, I don't think they have any value for DirectWrite. If application is
not using DirectWrite the only option left is GDI paired with Uniscribe,
or .NET (WPF is also working through DirectWrite in modern versions).

>  AFAIK, Windows offers
> composite fonts in its font selection menu like normal fonts...

Where do you see this, and under what names are they listed? Standard
Win32 font selection dialog is GDI-based, Wordpad does not list anything
called "Global User Interface" or "Global Sans Serif", DirectWrite
system font enumeration does not include anything obscure like that
either. It's possible those files are for WPF/.NET stuff that I'm not
familiar with.

> 
>> You can certainly parse and discard information irrelevant to
>> freetype, but that will create ambiguity because same script ranges
>> could be mapped to different fonts, and only differ in language.
> 
> We are miscommunicating, I think.  I talk about taking a
> `.compositeFont' file and use it as a font.  You are talking about
> configurability of `.compositeFont' files, effectively overriding its
> contents.

I'm talking about data such files provide. Assuming the idea was for
freetype to read them directly, and interpret one way or another.

> 
> 
> Werner
> 


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

Re: [ft-devel] Contribution to freetype

[Werner LEMBERG]

> Higher level would make use of ranges/language mapping for fallback.
> DirectWrite fallback is modeled very close if not identical to how
> this data is defined in .compositefont xml format.  When using
> DirectWrite layout API, application can rely on implicit fonts being
> selected for different script ranges, and you can set specific
> language per range to get more accurate results.  Newer versions
> allow user-defined fallback data, and API-wise it's very close to
> what those files provide.

If I understand you correctly, an application that uses DirectWrite
doesn't need `.compositeFont' files at all, right?  What happens with
applications that don't use DirectWrite?  AFAIK, Windows offers
composite fonts in its font selection menu like normal fonts...

> You can certainly parse and discard information irrelevant to
> freetype, but that will create ambiguity because same script ranges
> could be mapped to different fonts, and only differ in language.

We are miscommunicating, I think.  I talk about taking a
`.compositeFont' file and use it as a font.  You are talking about
configurability of `.compositeFont' files, effectively overriding its
contents.


Werner

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

Re: [ft-devel] Contribution to freetype

[Nikolay Sivov]

On 3/18/2018 11:17 AM, Werner LEMBERG wrote:
> 
> Adding support to FreeType would immediately enable *all* applications
> to handle them without changes.  What should a higher level do in your
> opinion?

Higher level would make use of ranges/language mapping for fallback.
DirectWrite fallback is modeled very close if not identical to how this
data is defined in .compositefont xml format. When using DirectWrite
layout API, application can rely on implicit fonts being selected for
different script ranges, and you can set specific language per range to
get more accurate results. Newer versions allow user-defined fallback
data, and API-wise it's very close to what those files provide.

You can certainly parse and discard information irrelevant to freetype,
but that will create ambiguity because same script ranges could be
mapped to different fonts, and only differ in language.

> 
> 
> Werner
> 


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

Re: [ft-devel] Contribution to freetype

[Werner LEMBERG]

>> Technically, they are not fonts, but practically they are.  It's
>> not much different to, say, a CFF that consists of a bunch of
>> subfonts.
> 
> Okay, I guess I'll have to wait and see when this is implemented.
> My understanding is that it's a way to define mapping for existing
> fonts, so you still need all referenced font data (which is
> referenced by NAME names by the way).

Yes.

> If e.g. you filter all duplicate entries out, and use resulting font
> array, it will have no additional information comparing to
> individual font files.

Yes.

> If freetype decided to do a "smarter" mapping, or a fallback rather,
> using language/codepoint pairs, that's a different thing that sounds
> higher level, and not fitting to existing API.

Well, the idea is that such composite fonts *behave* like a single
font!  On an MS or Android box, such composite fonts are predefined,
using the system fonts.  On a GNU/Linux box, a small application or
script could set up composite fonts using the information delivered by
FontConfig.

Adding support to FreeType would immediately enable *all* applications
to handle them without changes.  What should a higher level do in your
opinion?


Werner

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

Re: [ft-devel] Contribution to freetype

[Nikolay Sivov]

On 3/18/2018 10:25 AM, Werner LEMBERG wrote:
> 
>>> The difficulty is not adding support for the VF format itself but
>>> to find a good API that is generic enough for other purposes, too.
>>> I'm thinking of handling files like Microsoft's
>>> `GlobalSerif.CompositeFont'.  Apple and Android provide similar
>>> concepts.  It's probably not the job of FreeType to digest such
>>> composite fonts by itself (you'll need an external XML
>>> interpreter); however, it would be very helpful if we have a
>>> foundation to provide easy support for such composite fonts.
>>
>> Could you elaborate?  I don't see how .CompositeFont files are
>> related to FreeType mission.  They are not fonts, and have no font
>> data, but only define {range, locale} -> {family} mapping.
> 
> Technically, they are not fonts, but practically they are.  It's not
> much different to, say, a CFF that consists of a bunch of subfonts.

Okay, I guess I'll have to wait and see when this is implemented. My
understanding is that it's a way to define mapping for existing fonts,
so you still need all referenced font data (which is referenced by NAME
names by the way). If e.g. you filter all duplicate entries out, and use
resulting font array, it will have no additional information comparing
to individual font files. If freetype decided to do a "smarter" mapping,
or a fallback rather, using language/codepoint pairs, that's a different
thing that sounds higher level, and not fitting to existing API. But
again, I'm just curious that's all.

> 
> 
> Werner
> 


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

Re: [ft-devel] Contribution to freetype

[Werner LEMBERG]

>> The difficulty is not adding support for the VF format itself but
>> to find a good API that is generic enough for other purposes, too.
>> I'm thinking of handling files like Microsoft's
>> `GlobalSerif.CompositeFont'.  Apple and Android provide similar
>> concepts.  It's probably not the job of FreeType to digest such
>> composite fonts by itself (you'll need an external XML
>> interpreter); however, it would be very helpful if we have a
>> foundation to provide easy support for such composite fonts.
> 
> Could you elaborate?  I don't see how .CompositeFont files are
> related to FreeType mission.  They are not fonts, and have no font
> data, but only define {range, locale} -> {family} mapping.

Technically, they are not fonts, but practically they are.  It's not
much different to, say, a CFF that consists of a bunch of subfonts.


Werner

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

Re: [ft-devel] Contribution to freetype

[Nikolay Sivov]

On 3/18/2018 6:19 AM, Werner LEMBERG wrote:

> 
> The difficulty is not adding support for the VF format itself but to
> find a good API that is generic enough for other purposes, too.  I'm
> thinking of handling files like Microsoft's
> `GlobalSerif.CompositeFont'.  Apple and Android provide similar
> concepts.  It's probably not the job of FreeType to digest such
> composite fonts by itself (you'll need an external XML interpreter);
> however, it would be very helpful if we have a foundation to
> provide easy support for such composite fonts.

Could you elaborate? I don't see how .CompositeFont files are related to
FreeType mission. They are not fonts, and have no font data, but only
define {range, locale} -> {family} mapping.

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


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

Re: [ft-devel] Contribution to freetype

[Parth Wazurkar]

> There's nothing to implement during GSoC!  Composite outline font
> support is something completely different.
>
>
> OK!
Thank You

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

Re: [ft-devel] Contribution to freetype

[Werner LEMBERG]

>> >I'm thinking of handling files like Microsoft's
>> >`GlobalSerif.CompositeFont'.  Apple and Android provide similar
>> >concepts.
>> >
>> >It's probably not the job of FreeType to digest such composite
>> >fonts by itself (you'll need an external XML interpreter);
>> >however, it would be very helpful if we have a foundation to
>> >provide easy support for such composite fonts.
>
> Can you please provide me some resources so that I can study this
> part

I don't have one, I only know that those XML composite font files
exist.  It shouldn't be too difficult for you to get them from your
(or a friend's) Windows 10 installation.

>  and allot a time slot for its implementation in the GSoC timeline.

There's nothing to implement during GSoC!  Composite outline font
support is something completely different.


Werner

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

Re: [ft-devel] Contribution to freetype

[Parth Wazurkar]

>Well, most of the time it will be rather `add new header files'.
> >Modifications to other header files will (hopefully!) be minor only.
>
 Yes!


> >I'm thinking of handling files like Microsoft's
> >`GlobalSerif.CompositeFont'.  Apple and Android provide similar
> >concepts.

>It's probably not the job of FreeType to digest such
> >composite fonts by itself (you'll need an external XML interpreter);
> >however, it would be very helpful if we have a foundation to
> >provide easy support for such composite fonts.
>
Can you please provide me some resources so that I can study this part and
allot a time slot for its implementation in the GSoC timeline.

Thank You

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

Re: [ft-devel] Contribution to freetype

[Werner LEMBERG]

> For the project, I am thinking of the following approach: I will
> have to modify the internal freetype files which provide the support
> to the new font format drivers.

Well, most of the time it will be rather `add new header files'.
Modifications to other header files will (hopefully!) be minor only.

> Further, I will have to implement new drivers for gf, pk, tfm and vf
> font formats for freetype.

Yep.

> For the drivers I will take reference from the available drivers in
> VFlib and implement them for freetype on the lines of already
> available bdf font format driver.

Exactly.  The BDF, PCF, and Winfnt modules can serve as examples how
bitmap drivers work, and the Type1 module shows how to `attach' a
metric file to a font.

> I recognize that for the `vf` font format support it is tagged as
> 'hard' and I fear I may have missed things that might make it more
> difficult than I imagined.

The difficulty is not adding support for the VF format itself but to
find a good API that is generic enough for other purposes, too.  I'm
thinking of handling files like Microsoft's
`GlobalSerif.CompositeFont'.  Apple and Android provide similar
concepts.  It's probably not the job of FreeType to digest such
composite fonts by itself (you'll need an external XML interpreter);
however, it would be very helpful if we have a foundation to
provide easy support for such composite fonts.


Werner

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

Re: [ft-devel] Contribution to freetype

[Parth Wazurkar]

Hi,
For the project, I am thinking of the following approach:
I will have to modify the internal freetype files which provide the support
to the new font format drivers. Further, I will have to implement new
drivers for gf, pk, tfm and vf font formats for freetype. For the drivers I
will take reference from the available drivers in VFlib and implement them
for freetype on the lines of already available bdf font format driver.
I have an idea on how to progress for the coding part. I want to ask if
this approach is correct? and do you suggest any modifications so that I
can come up with a detailed proposal asap which we can discuss further.
I recognize that for the `vf` font format support it is tagged as 'hard'
and I fear I may have missed things that might make it more difficult than
I imagined. I would really appreciate any guidance or comments.

Regards
Parth

On Fri, Mar 16, 2018 at 9:31 AM, Parth Wazurkar 
wrote:

> Thank you so much Ewald.
> I'll check that out.
>
> Regards
> Parth
>
>
> On Fri, Mar 16, 2018 at 9:13 AM, Ewald Hew  wrote:
>
>> Hi Parth,
>>
>> > I am unable to figure out the working of `FT_Face_InitFunc` in the
>> `ftdrv.h`
>> > file.
>> > particularly, how does the call to `init_face` function invokes the
>> > particular font format's driver.
>> > Please help.
>>
>> I suggest you read the article here
>> , which
>> goes into some detail about how interfaces are being implemented in
>> FreeType.
>>
>> Basically, `FT_Face_InitFunc' is a function pointer type (with its
>> signature), through which the driver-specific implementation of
>> `init_face' can be set, per module. Look up the `FT_DEFINE_DRIVER'
>> macro and where it's being used.
>>
>> Ewald
>>
>
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Contribution to freetype

[Parth Wazurkar]

Thank you so much Ewald.
I'll check that out.

Regards
Parth

On Fri, Mar 16, 2018 at 9:13 AM, Ewald Hew  wrote:

> Hi Parth,
>
> > I am unable to figure out the working of `FT_Face_InitFunc` in the
> `ftdrv.h`
> > file.
> > particularly, how does the call to `init_face` function invokes the
> > particular font format's driver.
> > Please help.
>
> I suggest you read the article here
> , which
> goes into some detail about how interfaces are being implemented in
> FreeType.
>
> Basically, `FT_Face_InitFunc' is a function pointer type (with its
> signature), through which the driver-specific implementation of
> `init_face' can be set, per module. Look up the `FT_DEFINE_DRIVER'
> macro and where it's being used.
>
> Ewald
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Contribution to freetype

[Ewald Hew]

Hi Parth,

> I am unable to figure out the working of `FT_Face_InitFunc` in the `ftdrv.h`
> file.
> particularly, how does the call to `init_face` function invokes the
> particular font format's driver.
> Please help.

I suggest you read the article here
, which
goes into some detail about how interfaces are being implemented in
FreeType.

Basically, `FT_Face_InitFunc' is a function pointer type (with its
signature), through which the driver-specific implementation of
`init_face' can be set, per module. Look up the `FT_DEFINE_DRIVER'
macro and where it's being used.

Ewald

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

Re: [ft-devel] Contribution to freetype

[Parth Wazurkar]

Hi all,
I am unable to figure out the working of `FT_Face_InitFunc` in the
`ftdrv.h` file.
particularly, how does the call to `init_face` function invokes the
particular font format's driver.
Please help.

Regards
Parth

On Wed, Mar 7, 2018 at 9:23 PM, Parth Wazurkar 
wrote:

> Ok
> Seems like I messed up some things.
> Thank you for the reply, now I have understood where I was going wrong.
> I will work on that and get back soon.
>
> Thank You
> Regards
> Parth
>
>
> On Wed, Mar 7, 2018 at 9:01 PM, Werner LEMBERG  wrote:
>
>>
>> > I am thinking of some possible ways in providing multiple font
>> > support,
>>
>> What exactly do you mean with `multiple font support'?
>>
>> > first one can be to use the available converters for conversion of
>> > font formats, the second one can be to use the Freetype approach by
>> > modifying `FT_DRIVER_H`, `FT_OPEN_DRIVER` to support the tex font
>> > drivers as well, another can be the VFlib approach i.e to define a
>> > new font database file on the lines of vflibcap and then using the
>> > Kpathsea library for searching TEX fonts.
>> >
>> > I ruled out the first one as we must convert many font files in
>> > advance and also we don't have converters available for all types of
>> > fonts.
>>
>> OK (but I don't know exactly to what it refers).
>>
>> > I am currently more inclined towards the VFlib approach.
>>
>> You mean something like `vflibcap'?  I think this is the wrong
>> approach.  Please bear in mind that FreeType is a font rendering
>> engine, working at the lowest level – actually, there is no other
>> font-related library on a lower level (in a font stack that uses
>> FreeType, that is).
>>
>> `vflibcap', for example, provides a much higher-level access to fonts;
>> it handles kpathsea issues, encoding conversion files, etc., etc.  All
>> this stuff doesn't belong to FreeType.
>>
>> FreeType takes a font file, opens it, selects a glyph, and rasterizes
>> it.  That's it!  And such low-level functions the GSoC project should
>> provide.  The exception is VF files, which probably needs a new
>> interface: For example, a new function could return a list of the
>> necessary `raw' fonts (in TeX speak).  An alternative could be a
>> callback function that receives a font name and returns a handle to
>> FreeType.  This is what a GSoC student should research.
>>
>>
>> Werner
>>
>
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Contribution to freetype

[Parth Wazurkar]

Ok
Seems like I messed up some things.
Thank you for the reply, now I have understood where I was going wrong.
I will work on that and get back soon.

Thank You
Regards
Parth

On Wed, Mar 7, 2018 at 9:01 PM, Werner LEMBERG  wrote:

>
> > I am thinking of some possible ways in providing multiple font
> > support,
>
> What exactly do you mean with `multiple font support'?
>
> > first one can be to use the available converters for conversion of
> > font formats, the second one can be to use the Freetype approach by
> > modifying `FT_DRIVER_H`, `FT_OPEN_DRIVER` to support the tex font
> > drivers as well, another can be the VFlib approach i.e to define a
> > new font database file on the lines of vflibcap and then using the
> > Kpathsea library for searching TEX fonts.
> >
> > I ruled out the first one as we must convert many font files in
> > advance and also we don't have converters available for all types of
> > fonts.
>
> OK (but I don't know exactly to what it refers).
>
> > I am currently more inclined towards the VFlib approach.
>
> You mean something like `vflibcap'?  I think this is the wrong
> approach.  Please bear in mind that FreeType is a font rendering
> engine, working at the lowest level – actually, there is no other
> font-related library on a lower level (in a font stack that uses
> FreeType, that is).
>
> `vflibcap', for example, provides a much higher-level access to fonts;
> it handles kpathsea issues, encoding conversion files, etc., etc.  All
> this stuff doesn't belong to FreeType.
>
> FreeType takes a font file, opens it, selects a glyph, and rasterizes
> it.  That's it!  And such low-level functions the GSoC project should
> provide.  The exception is VF files, which probably needs a new
> interface: For example, a new function could return a list of the
> necessary `raw' fonts (in TeX speak).  An alternative could be a
> callback function that receives a font name and returns a handle to
> FreeType.  This is what a GSoC student should research.
>
>
> Werner
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Contribution to freetype

[Werner LEMBERG]

> I am thinking of some possible ways in providing multiple font
> support,

What exactly do you mean with `multiple font support'?

> first one can be to use the available converters for conversion of
> font formats, the second one can be to use the Freetype approach by
> modifying `FT_DRIVER_H`, `FT_OPEN_DRIVER` to support the tex font
> drivers as well, another can be the VFlib approach i.e to define a
> new font database file on the lines of vflibcap and then using the
> Kpathsea library for searching TEX fonts.
>
> I ruled out the first one as we must convert many font files in
> advance and also we don't have converters available for all types of
> fonts.

OK (but I don't know exactly to what it refers).

> I am currently more inclined towards the VFlib approach.

You mean something like `vflibcap'?  I think this is the wrong
approach.  Please bear in mind that FreeType is a font rendering
engine, working at the lowest level – actually, there is no other
font-related library on a lower level (in a font stack that uses
FreeType, that is).

`vflibcap', for example, provides a much higher-level access to fonts;
it handles kpathsea issues, encoding conversion files, etc., etc.  All
this stuff doesn't belong to FreeType.

FreeType takes a font file, opens it, selects a glyph, and rasterizes
it.  That's it!  And such low-level functions the GSoC project should
provide.  The exception is VF files, which probably needs a new
interface: For example, a new function could return a list of the
necessary `raw' fonts (in TeX speak).  An alternative could be a
callback function that receives a font name and returns a handle to
FreeType.  This is what a GSoC student should research.


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

Re: [ft-devel] Contribution to freetype

[Parth Wazurkar]

Hi,
Now I am getting a rough idea of how things are connected in the working of
Freetype.
I am thinking of some possible ways in providing multiple font support,
first one can be to use the available converters for conversion of font
formats, the second one can be to use the Freetype approach by modifying
`FT_DRIVER_H` , `FT_OPEN_DRIVER` to support the tex font drivers as well,
another can be the VFlib approach i.e to define a new font database file on
the lines of vflibcap and then using the Kpathsea library for searching TEX
fonts.
I ruled out the first one as we must convert many font files in advance and
also we don't have converters available for all types of fonts. I am
currently more inclined towards the VFlib approach.
I am still trying to figure out the approaches and I wonder if I am going
in the right direction?
I am excited to work with Freetype, it's really fascinating how much work
is required to render fonts.
Thank You

Regards
Parth


On Sat, Feb 24, 2018 at 10:19 AM, Werner LEMBERG  wrote:

>
> > I don't have any no ideas :-)
>
> This should be: I don't have any new ideas.
>
>
> Werner
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Contribution to freetype

[Werner LEMBERG]

> I don't have any no ideas :-)

This should be: I don't have any new ideas.


Werner

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

Re: [ft-devel] Contribution to freetype

[Werner LEMBERG]

> I have worked with tex in some of my documentations, but I think I
> can work upon the tex document production system.

Well, it is sufficient if you know the basic facts how TeX uses .pk,
.tfm, and .vf files.

> Are there any other recommendations which I should follow?

I don't have any no ideas :-) So please prepare a proposal that we can
discuss.


Werner

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

Re: [ft-devel] Contribution to freetype

[Werner LEMBERG]

> Now after some time now after working on FreeType I am getting
> familiar with the code base.

Good.

> After studying the proposed projects I would like to work upon 'the
> integration of VFlib's TeX format drivers into FreeType' as my the
> GSOC project.  I am currently studying VFlib and trying to figure
> out its working.  Can you please help me how should I proceed
> further with the project.

Do you have any experience with TeX?  I forgot to mention in the GSoC
description that this is a strong recommendation.

I've just updated the information on

  https://www.freetype.org/gsoc.html

regarding the canonic references of the PK, GF, and VF font formats.
Please check again.

Regarding the implementation, you should have a look at bitmap drivers
already present in FreeType (`winfonts', `pcf', `bdf'; `winfonts' is
the simplest one).  Essentially, you have to implement the necessary
methods of the module's `FT_Driver_ClassRec' structure.


Werner

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

Re: [ft-devel] Contribution to freetype

[Parth Wazurkar]

Now after some time now after working on FreeType I am getting familiar
with the code base.
After studying the proposed projects I would like to work upon 'the
integration of VFlib's TeX format drivers into FreeType' as my the GSOC
project. I am currently studying VFlib and trying to figure out its
working. Can you please help me how should I proceed further with the
project.

Thank You

Regards
Parth

On Fri, Feb 16, 2018 at 1:02 PM, Parth Wazurkar 
wrote:

> OK I will do that.
> Actually I thought if there was any error in my installation or not.
> Thank You
>
> Regards,
> Parth
>
>
> On Fri, Feb 16, 2018 at 11:51 AM, Werner LEMBERG  wrote:
>
>>
>> > I successfully compiled the example in this way:
>> > $gcc example1.c -I/home/parth/anaconda3/include/freetype2 \
>> >  -L/home/parth/anaconda3/lib -lfreetype -lm
>> >
>> > But, when I run $./a.out font sample-text for checking output it
>> > shows Segmentation fault (core dumped).  Please help.
>>
>> The demo programs leave out all error checking for simplicity.  You
>> have to take care of that by yourself.
>>
>> I strongly suggest that you get acquainted with (a) compiling and
>> linking in general, and (b) how to use a debugger like `gdb' or a GUI
>> front-end to it to identify the source code location where the program
>> crashed.
>>
>> However, this mailing list is not the right place to do that, sorry.
>>
>>
>> Werner
>>
>
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Contribution to freetype

[Werner LEMBERG]

> I successfully compiled the example in this way:
> $gcc example1.c -I/home/parth/anaconda3/include/freetype2 \
>  -L/home/parth/anaconda3/lib -lfreetype -lm
>
> But, when I run $./a.out font sample-text for checking output it
> shows Segmentation fault (core dumped).  Please help.

The demo programs leave out all error checking for simplicity.  You
have to take care of that by yourself.

I strongly suggest that you get acquainted with (a) compiling and
linking in general, and (b) how to use a debugger like `gdb' or a GUI
front-end to it to identify the source code location where the program
crashed.

However, this mailing list is not the right place to do that, sorry.


Werner

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

Re: [ft-devel] Contribution to freetype

[Parth Wazurkar]

I successfully compiled the example in this way:
$gcc example1.c -I/home/parth/anaconda3/include/freetype2
-L/home/parth/anaconda3/lib -lfreetype -lm
But,
when I run $./a.out font sample-text
for checking output it shows Segmentation fault (core dumped).
Please help.


On Fri, Feb 16, 2018 at 3:28 AM, Werner LEMBERG  wrote:

>
> > When I try to compile the example given on the website after
> > installing the library like this:
> >
> > $gcc example1.c -I/home/parth/anaconda3/include/freetype2 -lm -lfreetype
> >
> > I get the following error
> >
> > *:*
> > /usr/bin/ld: cannot find -lfreetype
> > collect2: error: ld returned 1 exit status
> >
> > I searched on the internet and also the mail archives but could not
> > find a solution.  Please help.
>
> You are missing an -L flag to specify the directory where libfreetype
> is located.
>
>
> Werner
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Contribution to freetype

[Werner LEMBERG]

> When I try to compile the example given on the website after
> installing the library like this:
> 
> $gcc example1.c -I/home/parth/anaconda3/include/freetype2 -lm -lfreetype
>
> I get the following error
> 
> *:*
> /usr/bin/ld: cannot find -lfreetype
> collect2: error: ld returned 1 exit status
> 
> I searched on the internet and also the mail archives but could not
> find a solution.  Please help.

You are missing an -L flag to specify the directory where libfreetype
is located.


Werner

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

Re: [ft-devel] Contribution to freetype

[Parth Wazurkar]

When I try to compile the example given on the website after installing the
library like this:

$gcc example1.c -I/home/parth/anaconda3/include/freetype2 -lm -lfreetype
I get the following error

*:*
/usr/bin/ld: cannot find -lfreetype
collect2: error: ld returned 1 exit status

I searched on the internet and also the mail archives but could not find a
solution. Please help.

Regards
Parth

On Wed, Feb 14, 2018 at 3:14 AM, Werner LEMBERG  wrote:

>
> > My name is Parth Wazurkar. I am a sophomore student at Indian
> > Institute Of Information Technology Nagpur, India studying Computer
> > Science and Engineering.  I am interested in working for
> > freetype.  How should I start contributing?  Please help.
>
> Parth,
>
>
> please look at FreeType's GSoC page
>
>   https://www.freetype.org/gsoc.html
>
>
> Werner
>
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Contribution to freetype

[Werner LEMBERG]

> My name is Parth Wazurkar. I am a sophomore student at Indian
> Institute Of Information Technology Nagpur, India studying Computer
> Science and Engineering.  I am interested in working for
> freetype.  How should I start contributing?  Please help.

Parth,


please look at FreeType's GSoC page

  https://www.freetype.org/gsoc.html


Werner

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

[ft-devel] Contribution to freetype

[Parth Wazurkar]

Sir,
My name is Parth Wazurkar. I am a sophomore student at Indian
Institute Of Information Technology Nagpur, India studying Computer
Science and Engineering.
I am interested in working for freetype. How should I start
contributing? Please help.

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