Re: [ft-devel] broken hinted DejaVuSans et 4
>> This means that FreeType is fine and DejaVuSans's hinting at 4ppm is >> buggy. :-) Due to the `gasp' table, this is a non-issue anyway. > > It cannot be both non-issue and buggy font. The hinting at 4ppem *is* buggy. However, the gasp table prevents hinting at this size, for exactly that reason. So it is a non-issue. > No blame for ftview and its handling of gasp? ftview intentionally doesn't handle gasp. Instead, you can manually switch on and off the various hinting and rendering modes. I've examined the issue more closely because such rendering artifacts look fishy; there was a possibility that the bug lies within FreeType. It's a relieve for me that everything is OK. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] broken hinted DejaVuSans et 4
On Tue, Sep 13, 2011 at 1:49 PM, Werner LEMBERG wrote: > > This means that FreeType is fine and DejaVuSans's hinting at 4ppm is > buggy. :-) Due to the `gasp' table, this is a non-issue anyway. It cannot be both non-issue and buggy font. No blame for ftview and its handling of gasp? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] broken hinted DejaVuSans et 4
> CVT values in a TrueType font are normally modified in the `prep' > table to adapt them to the current device resolution. If the > resolution changes, the `prep' table is executed again. > > However, what happens if there is a WCVTP or WCVTF instruction within > a glyph's bytecode to modify a CVT entry? > > I can imagine three possible solutions. Let's assume that we have > WCVTP and/or WCVTF commands in glyph A. > > 1. WCVTP and WCVTF are allowed and are applied globally. As a > consequence, rendering glyph A might influence the shape of any > other glyph. > > 2. WCVTP and WCVTF are allowed and are applied locally. All > modified CVT entries are restored after rendering of glyph A. > > 3. WCVTP and WCVTF are ignored if found outside of the `prep' table. > > IMHO, option 1 is bad, and that options 2 and 3 are OK. I favour > option 3 since it is most convenient to implement. Right now, > FreeType does option 1, and we should change that... > > I've just written an email to Greg Hitchcock, asking for > clarification. And his answer: Both Apple and MS rasterizers implement option 1! This means that FreeType is fine and DejaVuSans's hinting at 4ppm is buggy. :-) Due to the `gasp' table, this is a non-issue anyway. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] broken hinted DejaVuSans et 4
> > It seems that the execution of [glyph uni277C's] bytecode at that > > size somehow influences rendering of other glyphs, but I have no > > idea how this is possible at all. Valgrind shows nothing, BTW. I've now debugged this issue. > The bytecode for DejaVu Sans' uni277C in svn in: > > SVTCA[y-axis] > PUSHW_3 > 17 > 3 > 3 > CALL > [...] This CALL instruction invokes a subroutine which is causing the problem: MPPEM LT IF DUP PUSHB_1 253 RCVT WCVTP< EIF POP Note that the marked instruction writes to the CVT, and later glyphs use this modified value. It is not described in the OpenType specification what to do in this situation. CVT values in a TrueType font are normally modified in the `prep' table to adapt them to the current device resolution. If the resolution changes, the `prep' table is executed again. However, what happens if there is a WCVTP or WCVTF instruction within a glyph's bytecode to modify a CVT entry? I can imagine three possible solutions. Let's assume that we have WCVTP and/or WCVTF commands in glyph A. 1. WCVTP and WCVTF are allowed and are applied globally. As a consequence, rendering glyph A might influence the shape of any other glyph. 2. WCVTP and WCVTF are allowed and are applied locally. All modified CVT entries are restored after rendering of glyph A. 3. WCVTP and WCVTF are ignored if found outside of the `prep' table. IMHO, option 1 is bad, and that options 2 and 3 are OK. I favour option 3 since it is most convenient to implement. Right now, FreeType does option 1, and we should change that... I've just written an email to Greg Hitchcock, asking for clarification. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] broken hinted DejaVuSans et 4
> "WL" == Werner LEMBERG writes: WL> It seems that the execution of [glyph uni277C's] bytecode at that WL> size somehow influences rendering of other glyphs, but I have no WL> idea how this is possible at all. Valgrind shows nothing, BTW. The bytecode for DejaVu Sans' uni277C in svn in: SVTCA[y-axis] PUSHW_3 17 3 3 CALL PUSHW_1 17 SRP0 PUSHW_3 10 20 3 CALL PUSHW_1 10 SRP0 IUP[y] IUP[x] I can't tell from the code in the .sfd what sub 3 is. For my compile of DejaVu Sans, uni277C is glyph 4091. I get the bug from: :; ftview -f 4091 4 /usr/share/fonts/dejavu/DejaVuSans.ttf but not from :; ftview -f 4092 4 /usr/share/fonts/dejavu/DejaVuSans.ttf even after hitting ← to back up to glyph 4091, or F9 to back even further. The prep and fpgm tables were inherited from Bitstream Vera Sans unchanged. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] broken hinted DejaVuSans et 4
> This is NOT a recent regression and should not hold 2.4.6. > But why is the attached so ugly? A very good question! Fortunately, you shouldn't see this in real life if applications properly follow the data in the `gasp' table. > ftview 4 /usr/share/fonts/dejavu/DejaVuSans.ttf > > and toggle 'h' a couple of times. Make sure that you play at size 4. > This is DejaVu 2.33. I've tested with version 2.25, and I can get the erratic behaviour even without pressing a key by using ftview -f 3978 4 DejaVuSans.ttf (glyph index 3978 corresponds to glyph `uni277C') but not with ftview -f 3979 4 DejaVuSans.ttf It seems that the execution of this glyph's bytecode at that size somehow influences rendering of other glyphs, but I have no idea how this is possible at all. Valgrind shows nothing, BTW. This needs a detailed investigation, single stepping through the bytecode with the C debugger, and I don't have enough time currently to that. Please file a bug report. Thanks for bringing this weird behaviour to our attention. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
