> BTW, BDF driver too does the same, this might have to be changed
> too.
Yes :-) A recent bug report also complains about long loading times
for PCF.
As you can see, working on FreeType is a never-ending story...
Werner
___
Freetype-devel
>
> >> >> Yes, it has been already done.
> >>
> >> Hmm. Which commit is this? I don't see anything recent change in
> >> the `parthw-cleanup' branch related to this issue.
> >
> > Actually this was done from the start itself, I misunderstood
> > somethings and got confused myself and then I
>> >> Yes, it has been already done.
>>
>> Hmm. Which commit is this? I don't see anything recent change in
>> the `parthw-cleanup' branch related to this issue.
>
> Actually this was done from the start itself, I misunderstood
> somethings and got confused myself and then I figured out that it
>> [...] and don't break URLs in the ChangeLog. [...]
>
> Even if it breaks the rule of 78? ;P
Yes. No reason to be more catholic than the Pope :-)
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
> [...] and don't break URLs in the ChangeLog. [...]
Even if it breaks the rule of 78? ;P
(anyways, sure + consider it done :))
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,12 @@
> +2018-07-20 Armin Hasitzka
> +
> + Move the legacy fuzz target to the `freetype-testing' repository:
> + it can now be found at https://github.com/freetype/freetype2-testing \
> + /tree/master/fuzzing/src/legacy
> +
> + *
As discussed earlier this week I would like to move the sources of the
legacy fuzz target to the testing repository. I have already copied it to
the new repository:
https://github.com/freetype/freetype2-testing/tree/master/fuzzing/src/legacy
. It would now be time to remove it from the freetype2
>> What exactly do you mean with `wrongly filled'? Please give an
>> example that I can look at with the debugger.
>
> I mean that the which metric data is wrongly allotted in the
> `GF_Glyph_Load' function which is causing these errors in the gf
> output. Is it only ascender and descender
>
> >>> And what about making GF loading the bitmaps on demand only?
> >>
> >> Yes, it has been already done.
>
> Hmm. Which commit is this? I don't see anything recent change in the
> `parthw-cleanup' branch related to this issue.
>
Actually this was done from the start itself, I misunderstood
>>> And what about making GF loading the bitmaps on demand only?
>>
>> Yes, it has been already done.
Hmm. Which commit is this? I don't see anything recent change in the
`parthw-cleanup' branch related to this issue.
Werner
___
>
> >> Please finish the GF + TFM combo first.
> >>
> >
> > Ok, then I have a pretty clear idea about how to accomplish it, I
> > will create some API functions in the `tfm' driver's service code
> > which will be used in the `gf', `pk' and `vf' drivers to extract the
> > tfm data.
>
> Please have
>> Please finish the GF + TFM combo first.
>>
>
> Ok, then I have a pretty clear idea about how to accomplish it, I
> will create some API functions in the `tfm' driver's service code
> which will be used in the `gf', `pk' and `vf' drivers to extract the
> tfm data.
Please have a look how AFM
>
> >> the next step is `attaching' a TFM file to GF (and later on to PK),
> >> i.e., providing the internal code for `FT_Attach_File' and
> >> `FT_Attach_Stream' so that GF's metric data gets completed. Any
> >> estimate when you are done with this?
> >
> > I don't think that would be necessary,
> In particular, a glyph normally has a height, a depth, [...]
Ah, this is TeX speak. In FreeType speak, this is called ascender and
descender:
ascender = height;
descender = -depth;
Werner
___
Freetype-devel mailing list
14 matches
Mail list logo
