>> I have to increase the glyph style array from 8bit to 16bit.
>
> Will that effect filesize of ttfautohinted files?
No. But it will increase the memory footprint of FreeType. Assuming
a font has 1000 glyphs, FreeType will need 1000 byte more.
Werner
___
On 28 August 2015 at 18:07, Werner LEMBERG wrote:
> I have to increase the glyph style array from
> 8bit to 16bit.
>
Will that effect filesize of ttfautohinted files?
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/ma
Right now, I'm working on slightly extending the auto-hinter to make a
distinction between `base characters' and everything else. The idea
is that only base characters will use blue zones. This should give
more consistent vertical positions of e.g. diacritics since they won't
be snapped to (inco
On 8/28/2015 7:10 AM, Nikolaus Waxweiler wrote:
You want a *global* stem width for all scripts within a font? I'm not
sure whether this is a good idea.
Uh, I thought that's how it works for Postscript and OpenType/CFF fonts? I'm
only aware of the (face-)global dict with a face-wide stdVW.
If
>> You want a *global* stem width for all scripts within a font? I'm
>> not sure whether this is a good idea.
>
> Uh, I thought that's how it works for Postscript and OpenType/CFF
> fonts? I'm only aware of the (face-)global dict with a face-wide
> stdVW.
Normal Type1 fonts work like that. CFF
> I'm only aware of the (face-)global dict with a face-wide
> stdVW.
I forgot to mention that the subfonts of HiraKakuPro *roughly* fit
auto-hinter scripts; in other words, the idea of determining separate
standard width values for different scripts is not far-fetched.
Werner
_
On 15-08-28 03:10 PM, Nikolaus Waxweiler wrote:
>> You want a *global* stem width for all scripts within a font? I'm not
>> sure whether this is a good idea.
>
> Uh, I thought that's how it works for Postscript and OpenType/CFF fonts? I'm
> only aware of the (face-)global dict with a face-wide st
You want a *global* stem width for all scripts within a font? I'm not
sure whether this is a good idea.
Uh, I thought that's how it works for Postscript and OpenType/CFF fonts?
I'm only aware of the (face-)global dict with a face-wide stdVW.
If not, I will need to rethink my approach ;)
___
>> The auto-hinter computes the standard widths in *font units*, this
>> is, the values are unscaled!
>
> Ah, yes, thinko. I meant once as opposed to several times due to
> lazy evaluation.
You want a *global* stem width for all scripts within a font? I'm not
sure whether this is a good idea.
On 15-08-28 02:43 PM, Werner LEMBERG wrote:
>
> But we are now constrained by compatibility.
>>
>> We actually aren't!
>
> Please explain.
The rendering of CFF fonts changed drastically from one FreeType version to
another. The effect of FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH changed from one
But we are now constrained by compatibility.
>
> We actually aren't!
Please explain.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
I'm awaiting your patches :-)
Heh ;)
Why `once per size'? The auto-hinter computes the standard widths in
*font units*, this is, the values are unscaled!
Ah, yes, thinko. I meant once as opposed to several times due to lazy
evaluation.
___
Free
Here's a piece of Python code for whoever wants to compare curves...
On 15-08-27 04:44 PM, Alexei Podtelezhnikov wrote:
> On Thu, Aug 27, 2015 at 10:46 AM, Nikolaus Waxweiler
> wrote:
>>> The look of the function is documented and it blows my mind. I want to
>>> know what they smoked. You simply
On 15-08-27 11:06 PM, Werner LEMBERG wrote:
>>> But we are now constrained by compatibility.
We actually aren't!
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
> Thanks for the explanation. The source code needs comments like
> that :)
I'm awaiting your patches :-)
> In my first prototype, I tried to get a face-wide stdVW and modified
> af_latin_metrics_init_widths to upload whatever is computed to
> AF_FaceGlobals. Then I found that when displaying a
Where's the problem? The auto-hinter provides different standard
width values depending on the script. It tries up to three characters
(cf. the last three arguments to the `SCRIPT' macro in file
`afscript.h') in function `af_latin_metrics_init_widths' for finding a
standard width. As soon as we
> I changed the strategy to get the standard_width of a face. Instead
> of relying on the hard-to-follow workings of the style analyzers,
> [...]
Where's the problem? The auto-hinter provides different standard
width values depending on the script. It tries up to three characters
(cf. the last
17 matches
Mail list logo
