Re: [ft-devel] GSoC 2017 - CFF for Type 1

> On 27 Mar 2017, at 12:28, Werner LEMBERG wrote: > > What I want is to move the (extended) CFF parser and hinter from the > `cff' module to the `psaux' module, thus replacing the Type 1 parser > and hinter. Later on, the `cid' module must also be adapted to use > the (extended)

Re: [ft-devel] GSoC 2017 - CFF for Type 1

> I think that... > > > The alternative below merges before the decoding stage, i.e. use the > > same decoder for all three types of charstrings, which I understand > > more readily and am leaning towards. > > ... this is the solution to go, yes. > We have a complaint regarding the speed of the

Re: [ft-devel] GSoC 2017 - CFF for Type 1

> Regarding modularity, the constraint is rather simple: [...] Aha, I understand now. Thanks for the informative reply! > Thanks, looks promising! Please transfer this to a proper, registered > GSoC draft proposal as soon as possible. After the transfer, please > allow comments for the

Re: [ft-devel] GSoC 2017 - CFF for Type 1

> From what I understand, we can rewrite > 't1_decoder_parse_charstrings' to do the same as > 'cf2_interpT2CharString' for calling outline builder functions, > which does not increase duplicated code over what is already > present. Then, for hinting, I believe we can do the same i.e. get > the

Re: [ft-devel] GSoC 2017 - CFF for Type 1

On Sun, Mar 26, 2017 at 1:52 AM, Werner LEMBERG wrote: > > > I need some time to cross-reference the specifications to decide if > > this is possible. The alternative is, as how CFF2 support was > > added, to write a separate interpreter for Type 1 charstrings and > > glue it to

[ft-devel] GSoC 2017 - CFF for Type 1

Hi all, I am Ewald, a Computer Science student and I am interested in working with FreeType for GSoC 2017. I am looking at the idea of adding Type 1 support to the CFF driver. I have read through some parts of the code and have a rough idea of how things connect to one another. I thought of two