[ft-devel] Downscaling of rendered bitmaps?

So Werner and me have been discussing a possible TARGET_MEDIUM in secret and he pointed out that the often fitted-to-full-pixels TrueType fonts could simply be rendered as overscaled bitmaps and scaled down to get a "slight" to "medium" look. ft_smooth_render_generic() can produce bitmaps 3x

Re: [ft-devel] Experimental: v38 interpreter with minimal backwards compatibility mode and linear advance widths

The whitepaper gives the rules when and how to apply DELTAP instructions. Yes, but the placement of the blocking within Ins_DELTAP appears to be critical ;) Returning from the function straight away blows stuff up. I think I nailed it in my new patch.

Re: [ft-devel] Experimental: v38 interpreter with minimal backwards compatibility mode and linear advance widths

Another one. - Fixed rendering of DejaVu: the hinting code stumbled over ALIGNRP erroring out after IUP[x] which turned off hinting for many glyphs. Only error out from ALIGNRP after *both* IUP[x] and IUP[y] were called. - Don't stop execution of instructions after IUP[x] and IUP[y], instead

Re: [ft-devel] Experimental: v38 interpreter with minimal backwards compatibility mode and linear advance widths

> Blocking DELTAPs after IUP breaks several glyphs in the core web > fonts (e.g. completely displaces Arial Bold 'm'). The whitepaper gives the rules when and how to apply DELTAP instructions. > I can't debug them because FontForge renders them normally. Grrr. Try ttdebug. Werner

Re: [ft-devel] Experimental: v38 interpreter with minimal backwards compatibility mode and linear advance widths

Mhmm. This is too hars harsh. I would rather simply stop interpretation of delta instructions but let everything else work. For example, IUP[xy] could be called within conditionals, and it would be bad if the following `EIF' doesn't get interpreted, causing unwarranted execution failures. :(

Re: [ft-devel] light advance rounding

So it is possible. Correct use of rsb_delta and lsb_delta limits the positioning error to half a pixel. But those are only available when the autohinter is active? I found another implementation of subpixel positioning, Qt5:

Re: [ft-devel] Experimental: v38 interpreter with minimal backwards compatibility mode and linear advance widths

> So I stop execution after IUP[xy] in my newest iteration. So far I > couldn't find grave adverse effects. Will continue to test. Mhmm. This is too hars harsh. I would rather simply stop interpretation of delta instructions but let everything else work. For example, IUP[xy] could be called

Re: [ft-devel] Experimental: v38 interpreter with minimal backwards compatibility mode and linear advance widths

Hitchcock discusses this in his whitepaper, using the terms `pre-IUP' and `post-IUP' deltas. More discussion here: http://www.beatstamm.com/typography/RTRCh4.htm#Sec12 So I stop execution after IUP[xy] in my newest iteration. So far I couldn't find grave adverse effects. Will continue to

Re: [ft-devel] Experimental: v38 interpreter with minimal backwards compatibility mode and linear advance widths

The next iteration. - Execution of glyph instructions is stopped after IUP[x] and IUP[y] are called. This saves some backwards compatibility hack work. - SHPIX now denies execution under the same circumstances as DELTAP. Before, this blew up Rokkitt, but the freshly released v1.2 in Google's

Re: [ft] Accessing localized chars in a font for slash char.

*" withnative (TrueType) hinting enabled."* How do I enable it? Also,do I have to use FT_FACE_FLAG_TRICKY ? Checked by Avast Antivirus. www.avast.com

Re: [ft] Accessing localized chars in a font for slash char.

>> FreeType doesn't take care of localization in any way. You need a >> higher-level library like Pango or ICU to activate locale handling >> (i.e., selecting script and language for OpenType features). > > Thanks for that info. Though I see in the docs glyph-to-script-map (a) This is for the

Re: [ft] Accessing localized chars in a font for slash char.

> I was using "slash" char (code 47) but then notices that the one > which uses Adobe aftereffects is a little bit different. (typing > hebrew). Then I inspected the font in the FontCreator program and > found that it is possible to use default char (47) or localized one > which is located at