Re: [ft-devel] State of TrueType interpreter v38 and up?
> I'm interested in adding native ClearType to the definition `Native' ClearType is implemented. > If I remember correctly, that is what Infinality set out to do and > Behdad mentioned that it's slow. Yes, it's slow. Improvements welcome. > How far did the integration go? What work remains? There are a whole bunch of improvements for the auto-hinter not yet integrated, but this doesn't affect the TT engine. > I reckon my stem darkening work will have to wait until the TrueType > driver can do native Y-only-hinting.. There is a misunderstanding, see above. `Native' ClearType doesn't do y-only hinting! It's simply that advance width modifications are ignored in Windows at a later stage, namely in the rasterizer. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] State of TrueType interpreter v38 and up?
Infinality patches are integrated. See in ttinterp.c under |#ifdef TT_CONFIG_OPTION_SUBPIXEL_HINTING Ah, okay, so ClearType support is theoretically complete? What about v39 and v40? I personally do not like how this is done. Also the truth remains that ClearType patents will prevent this from wide acceptance in the near future. By then you will upgrade to a 4k monitor and forget this. I what way do you not like it? And Werner said something like leaving half the hints out is not covered by patents? I thought only subpixel rendering is covered by patents? I also fear that crappy LoDPI screens will be with us for quite a while... ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] State of TrueType interpreter v38 and up?
>> Infinality patches are integrated. See in ttinterp.c under |#ifdef >> TT_CONFIG_OPTION_SUBPIXEL_HINTING > > Ah, okay, so ClearType support is theoretically complete? What about > v39 and v40? ClearType consists of multiple parts. The first one is the interpretation of the hints, which is complete (more or less). The second one consists how the hinted outlines are converted to raster images. There are big differences between the MS engine and FreeType, which can't be `fixed' without completely redesigning FreeType. >> I personally do not like how this is done. Also the truth remains >> that ClearType patents will prevent this from wide acceptance in >> the near future. By then you will upgrade to a 4k monitor and >> forget this. > > In what way do you not like it? And Werner said something like > leaving half the hints out is not covered by patents? The ClearType rendering *filter* is patented, not the ClearType compatibility mode for hinting instructions. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] State of TrueType interpreter v38 and up?
On 03.12.2015 21:38, Werner LEMBERG wrote: There is a misunderstanding, see above. `Native' ClearType doesn't do y-only hinting! It's simply that advance width modifications are ignored in Windows at a later stage, namely in the rasterizer. I'm confused. Is this "native ClearType" actually called "Natural ClearType" or "natural advance widths"? MS created too many buzzwords :-( `Native ClearType ' means `no ClearType backwards-compatibility mode' `natural ClearType mode' is DWrite talk for subpixel positioning `natural ClearType widths' is GDI talk for integer pixel positioning with subpixel rendering. Mostly as note to my future self, to summarize those rendering modes in DWrite terms, please correct me if I got anything wrong: DWRITE_RENDERING_MODE_ALIASED No antialiasing (still hinted I think) DWRITE_RENDERING_MODE_GDI_CLASSIC Horizontal direction AA, advances are adjusted. DWRITE_RENDERING_MODE_GDI_NATURAL Horizontal direction AA, advances are not adjusted, but still rounded. DWRITE_RENDERING_MODE_NATURAL Horizontal axis AA, with subpixel positioning, i.e. no snapping to pixel boundaries. DWRITE_RENDERING_MODE_NATURAL_SYMMETRIC Both axis AA, with subpixel positioning DWRITE_RENDERING_MODE_OUTLINE Raw design outlines, irrelevant in this context. In all cases that offer AA, it could be either cleartype or grayscale, it's specified separately from rendering mode. Could it mean that in grayscale mode DWrite NATURAL mode is the same as GDI_NATURAL? I remember that symmetric mode is not supported in freetype yet, so we can forget about it. So the question is what does freetype support from this list, and how can I switch between different modes? I know that one option is a per-library engine version setting, but what does it change in terms of those listed modes (also is there any reason to never switch it back and forth between render operations, performance penalty for example?). ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] State of TrueType interpreter v38 and up?
MS created too many buzzwords :-( `Native ClearType ' means `no ClearType backwards-compatibility mode' `natural ClearType mode' is DWrite talk for subpixel positioning `natural ClearType widths' is GDI talk for integer pixel positioning with subpixel rendering. Now I'm more confused :B MS Windows doesn't support that, and FreeType doesn't support it either. Uh, wait. I thought one of the core ideas of ClearType is that glyphs are snapped to the pixel grid only on the Y-axis? By Y-only hinting I mean what the slight autohinter and the CFF engine do. Are you telling me I'm even more confused? :B And if so, why didn't you say so when I posted my documentation update? :O So what exactly must the TT driver support or imitate so that it fits the description of “Use native vertical-grid-only-snapping if driver and font supports it [...]”? If I understand correctly, FT already does subpixel positioning and natural advance widths in light mode (autohinter, CFF)? The latter: MS uses super-sampling, which *virtually* increases the device resolution by a factor of 10 or so, while FreeType does *really* increase the resolution. Ah. I take it those differences don't matter? Any known advantages and disadvantages to either approach? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] State of TrueType interpreter v38 and up?
There are a whole bunch of improvements for the auto-hinter not yet integrated, but this doesn't affect the TT engine. Mhm, sounds like a job for me. I'll put it somewhere on my todo list :P There is a misunderstanding, see above. `Native' ClearType doesn't do y-only hinting! It's simply that advance width modifications are ignored in Windows at a later stage, namely in the rasterizer. I'm confused. Is this "native ClearType" actually called "Natural ClearType" or "natural advance widths"? I guess that's something FT already does? What I meant to say is I want the part of ClearType that does Y-only hinting. ClearType consists of multiple parts. The first one is the interpretation of the hints, which is complete (more or less). This, I guess? I don't fully understand the description of the interpreter versions. Does GETINFO == 39 (v2.0) and 40 (v2.1) bring anything to the table that would be relevant to FT? A quick search didn't turn up any specifications except that one guide for how ClearType tries to be backwards compatible... The second one consists how the hinted outlines are converted to raster images. There are big differences between the MS engine and FreeType, which can't be `fixed' without completely redesigning FreeType. Could you provide some specifics? Do you mean how the rasterizer handles anti-aliasing and subpixel-rendering? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] State of TrueType interpreter v38 and up?
>> There is a misunderstanding, see above. `Native' ClearType doesn't do >> y-only hinting! It's simply that advance width modifications are >> ignored in Windows at a later stage, namely in the rasterizer. > > I'm confused. Is this "native ClearType" actually called "Natural > ClearType" or "natural advance widths"? MS created too many buzzwords :-( `Native ClearType ' means `no ClearType backwards-compatibility mode' `natural ClearType mode' is DWrite talk for subpixel positioning `natural ClearType widths' is GDI talk for integer pixel positioning with subpixel rendering. > What I meant to say is I want the part of ClearType that does Y-only > hinting. MS Windows doesn't support that, and FreeType doesn't support it either. > Does GETINFO == 39 (v2.0) and 40 (v2.1) bring anything to the table > that would be relevant to FT? Versions 39 and 40 essentially add different rendering modes only, which isn't directly relevant to FreeType. >> The second one consists how the hinted outlines are converted to >> raster images. There are big differences between the MS engine and >> FreeType, which can't be `fixed' without completely redesigning >> FreeType. > > Could you provide some specifics? Do you mean how the rasterizer > handles anti-aliasing and subpixel-rendering? The latter: MS uses super-sampling, which *virtually* increases the device resolution by a factor of 10 or so, while FreeType does *really* increase the resolution. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
