Re: [ft-devel] [GSoC] Draft proposal of project "Integrate VFlib's TeX format drivers into FreeType"

[Werner LEMBERG]

> 1. Should I send the proposal in the mailing list (open to all) or,
> 2. Should I send to the mentors listed in the idea list page only
> (keep it private)?

This is up to you.


Werner

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

Re: [ft-devel] [GSoC] Develop a test framework for checking FreeType's rendering output

[Werner LEMBERG]

> Is a link to a Google document appreciated for such purposes?

This is OK.


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] [GSoC] Develop a test framework for checking FreeType's rendering output

[Armin Hasitzka]

Oh, what a coincidence, that sounds great! :D

Thanks also for this very positive feedback, I will have a look at the other 
GSoC student's work and prepare a proper draft of a blueprint to implement such 
a framework then. Is a link to a Google document appreciated for such purposes?

Thanks again,
Armin
On 07/03/2018 14:31:35, Werner LEMBERG  wrote:

Hello Armin!


> I am a student at TU Wien (Vienna, Austria)...

Aah, ich unterrichte zweimal die Woche in der Mühlgasse :-)

> ... [I] found the idea of developing a testing framework - this
> sounds like an amazing way for me to explore a new topic!

Great!

> Apart from that I pick up things and ideas very quickly and would,
> should you accept my proposal in April, read into the concepts and
> ideas of font rendering until May; I know a professor to ask about
> this already.

Good – and of course we could also meet face to face...

> I would really love to be part of FreeType this summer but, due to
> my lack of experience with font rendering in general, I wonder if
> you think that I am a good fit to you?

Lack of experience with fonts is not a problem, since you can
essentially consider FreeType as a black box that you feed with test
fonts on the one side, and comparing its output with a baseline on the
other side. What we need is a comfortable tool that helps us quickly
find rendering differences for various rendering and hinting modes.

Last year, a GSoC student already started with preliminary support
(which is far from finished) – see the `GSoC-2017-kushal' branch of
FreeType's git repository. I think you could extend it further.

Awaiting your draft proposal :-)


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] [GSoC] Develop a test framework for checking FreeType's rendering output

[Werner LEMBERG]

Hello Armin!


> I am a student at TU Wien (Vienna, Austria)...

Aah, ich unterrichte zweimal die Woche in der Mühlgasse :-)

> ... [I] found the idea of developing a testing framework - this
> sounds like an amazing way for me to explore a new topic!

Great!

> Apart from that I pick up things and ideas very quickly and would,
> should you accept my proposal in April, read into the concepts and
> ideas of font rendering until May; I know a professor to ask about
> this already.

Good – and of course we could also meet face to face...

> I would really love to be part of FreeType this summer but, due to
> my lack of experience with font rendering in general, I wonder if
> you think that I am a good fit to you?

Lack of experience with fonts is not a problem, since you can
essentially consider FreeType as a black box that you feed with test
fonts on the one side, and comparing its output with a baseline on the
other side.  What we need is a comfortable tool that helps us quickly
find rendering differences for various rendering and hinting modes.

Last year, a GSoC student already started with preliminary support
(which is far from finished) – see the `GSoC-2017-kushal' branch of
FreeType's git repository.  I think you could extend it further.

Awaiting your draft proposal :-)


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

[ft-devel] [GSoC] Develop a test framework for checking FreeType's rendering output

[Armin Hasitzka]

Hi,

I am a student at TU Wien (Vienna, Austria) and currently writing my Bachelor 
Thesis. I love low-level programming (esp. using C on Unix) and I also 
specialised on automated code validation as much as possible (which is part of 
my Bachelor Thesis).

While I am new to working on font rendering, I do have a high appreciation for 
this topic due to a professional background in web design. Naturally, lots of 
things came together, when I browsed your list of project ideas and found the 
idea of developing a testing framework - this sounds like an amazing way for me 
to explore a new topic!

Apart from that I pick up things and ideas very quickly and would, should you 
accept my proposal in April, read into the concepts and ideas of font rendering 
until May; I know a professor to ask about this already. I faced a similar 
situation with GSoC last year where I worked on Mono and got accustomed to a 
large and previously unknown code base with many new ideas/concepts extremely 
quickly.

I would really love to be part of FreeType this summer but, due to my lack of 
experience with font rendering in general, I wonder if you think that I am a 
good fit to you?

Thanks for all your thoughts in advance! :)

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

Re: [ft-devel] [GSoC] Draft proposal of project "Integrate VFlib's TeX format drivers into FreeType"

[Jie Weng]

Sorry to bother but I have some more questions about sending the proposal:

1. Should I send the proposal in the mailing list (open to all) or,

2. Should I send to the mentors listed in the idea list page only
(keep it private)?

Best Regards,

Jie Weng

On Wed, Mar 7, 2018 at 12:21 PM, Jie Weng  wrote:
> Thanks for your reply! I will use the modern way then.
>
> Best Regards,
>
> Jie Weng
>
> On Tue, Mar 6, 2018 at 11:46 PM, suzuki toshiya
>  wrote:
>> Dear Jie Weng,
>>
>> My suggestion: if modern way #2 does not work well, please try
>> conventional way #1.
>>
>> Regards,
>> mpsuzuki
>>
>> Jie Weng wrote:
>>> Hi everyone,
>>>
>>> I am Jie Weng, a graduate student in Computer Science and Technology.
>>> I'd like to participate in GSoC with FreeType on project "Integrate
>>> VFlib's TeX format drivers into FreeType".
>>>
>>> I've read some documentations and articles to get familiar with Tex's
>>> fonts, VFlib, and FreeType. I also browsed the sources of these two
>>> libraries to find the starting point of coding work. Recently I
>>> finished the draft of my proposal, and I really appreciated if you
>>> could review it and give me some advice. By the way I drafted my
>>> proposal in Google Docs, I'd like to know which way is preferred to
>>> send my proposal: 1. download the file first and send it, 2. send
>>> through the shared link?
>>>
>>> Best Regards,
>>>
>>> Jie Weng
>>>
>>> ___
>>> 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