Re: [ft-devel] State of TrueType interpreter v38 and up?
It must (a) ignore changes of the horizontal advance widths due to hinting instructions (not implemented yet), and (b) ensure that all instructions behave correctly even if the horizontal resolution is increased (this is ClearType compatibility mode, already implemented). Ah, okay :) is (a) so complicated or is it that simply nobody did the work yet? And regarding your other post dealing with DWRITE equivalents, I think FT then with the above only ever does DWRITE_RENDERING_MODE_NATURAL_SYMMETRIC, which is probably what we want for light mode. No. This is what *effectively* happens, due to the strongly increased horizontal resolution. However, at least in `native' mode, you can still enforce non-integer positions along the x axis. Such a mode doesn't exist in the MS engine. However, Adobe's modified TT engine essentially hints only along the y axis, if I've understood Dave Arnold correctly, replacing x axis hints with emboldening. How complicated. So I guess ClearType - without stem darkening: let font modify x-coordinates at will but ignore modifications to advance width - with stem-darkening: nop everything that deals with x-coordinates and embolden just the x-axis? Dave? The latter would make backwards compatibility irrelevant because we would only honor Y-hints anyway, right? ... the MS approach is superior IMHO. It (a) elegantly circumvents many problems due to the extreme difference between horizontal and vertical resolution – it basically makes the compatibillity mode redundant, and (b) the increased resolution is around 10 times in both horizontal and vertical direction, compared to a threefold horizontal resolution increase of FreeType. Hm. Something for a hypothetical FreeType 3 :) ClearType patents should have run out by then ;) ___ 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?
> Mostly as note to my future self, to summarize those rendering modes > in DWrite terms, please correct me if I got anything wrong: [...] All what I know is taken from information from https://msdn.microsoft.com/en-us/library/windows/desktop/dd368118(v=vs.85).aspx You certainly are aware of that link :-) > 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? The above link says something different. > I remember that symmetric mode is not supported in freetype yet, so > we can forget about it. It's exactly the opposite: FreeType *only* supports symmetric mode (this is, AA for both the horizontal and vertical axis). Note that `symmetric' is not related to subpixel rendering – this can only be applied to a single axis due to the geometry of current LCD screens. > So the question is what does freetype support from this list, It seems that FreeType supports DWRITE_RENDERING_MODE_ALIASED and DWRITE_RENDERING_MODE_NATURAL_CLASSIC. All other modes have non-AA along the vertical axis, which FreeType doesn't implement. > and how can I switch between different modes? Since the AA and non-AA rasterizers are two different modules in FreeType, you can change between these two modes simply by using the proper FT_LOAD_XXX flag. > I know that one option is a per-library engine version setting, but > what does it change in terms of those listed modes The Windows enumerations combine various aspects of both the hinting engine and the rasterizer, and those combinations are not available under FreeType. > (also is there any reason to never switch it back and forth between > render operations, performance penalty for example?). I think this question doesn't apply to FreeType. 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?
> 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
[ft-devel] State of TrueType interpreter v38 and up?
Hey, so I was wondering what work exactly is left to support TT interpreter v38 and up? I'm interested in adding native ClearType to the definition of slight and Jan says, we need v38 and up for that. If I remember correctly, that is what Infinality set out to do and Behdad mentioned that it's slow. How far did the integration go? What work remains? Are there fundamental problems? I reckon my stem darkening work will have to wait until the TrueType driver can do native Y-only-hinting.. Regards, Nikolaus :) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
