Re: [ft-devel] ttdebug works again

Very nice! That will be quite helpful to use for debugging. I'll see what I can do. Thanks, Erik ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Enhancements for Subpixel Rendering

Thanks for the feedback, guys. My next commit will have these modifications. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Subpixel Hinting is Broken

Alexei's latest commit seems to have fixed the issue. On 01/25/2013 10:36 PM, Infinality wrote: Hi all, I've spent the last few hours trying to figure out what was wrong with my code (because I naturally assume that something is messed up with *it*. :D ) Well, it turns out

[ft-devel] Subpixel Hinting is Broken

Hi all, I've spent the last few hours trying to figure out what was wrong with my code (because I naturally assume that something is messed up with *it*. :D ) Well, it turns out that some recent change to Freetype has broken subpixel hinting. Compile the last release with subpixel hinting

[ft-devel] Enhancements for Subpixel Rendering

Here are the latest updates I've been working on for the subpixel hinting stuff. This removes a few hard-coded tweaks in favor of automatic detection. In addition it attempts to follow the MS whitepaper more by restricting the conditions of the FDEFs to those specified instead of "everything"

Re: [ft-devel] heads-up: TrueType height computation has been fixed

I wonder whether we should do the same for non-TrueType fonts. I think yes, but please comment! Are there any known TTF fonts where the hinting is impacted (positively or negatively) by this change? No, this change is not related to hinting at all. It affects *all* TrueType fonts regardless

Re: [ft-devel] heads-up: TrueType height computation has been fixed

I wonder whether we should do the same for non-TrueType fonts. I think yes, but please comment! Are there any known TTF fonts where the hinting is impacted (positively or negatively) by this change? I had a version of Inconsolata Bold that looked like crap after this change, but it turns o

Re: [ft-devel] severe problems with subpixel hinting

I've verified with debug messages that for TNR Regular, subpixel hinting and ignore_x_mode are successfully being set TRUE in tt_loader_init(). However, the execution context in ttinterp.c has them set to FALSE at the beginning of TT_RunIns(). I'm wondering if in some cases the execution conte

Re: [ft-devel] severe problems with subpixel hinting

Ok, after more experimentation, it *does* detect and store compatibility_mode correctly when I store it in the TT_Face object. I am running into an odd issue with Firefox and TNR however. For some reason, the patterns are not detected with Times New Roman Regular. And I know that Ins_FDEF is be

Re: [ft-devel] Patch to fix the ttsubpix implementation

If you have some time to read, this is a good place to start: http://www.akkadia.org/drepper/dsohowto.pdf Thanks Behdad, I'll check it out. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/free

Re: [ft-devel] severe problems with subpixel hinting

It *must* be TRUE in the FT_Face object which holds Times New Roman. Ok, after more experimentation, it *does* detect and store compatibility_mode correctly when I store it in the TT_Face object. I am running into an odd issue with Firefox and TNR however. For some reason, the patterns are

Re: [ft-devel] severe problems with subpixel hinting

I'm trying to detect when functions match a certain criteria at FDEF time, setting a variable in the execution context, and reading it later during hinting, but it seems like it's not set to what I expect it to be once the hinting process starts. What's the problem? Well, I'm trying to set a

Re: [ft-devel] Patch to fix the ttsubpix implementation

Was just looking at the source base today and found some rather sad things added recently. Here's a first patch to properly define all the sub-pixel handling tables in ttsubpix.h to the appropriate location (in ttsubpix.c, defined as constants). This saves about 55 KB of private RAM per proce

Re: [ft-devel] severe problems with subpixel hinting

This looks OK. As soon as you have a patch (or maybe you want to create a branch so that others can test it also) I can give better comments. I'm looking forward to seeing this new code! Yep, once I'm satisfied that it's working OK, I'll clean it up and send out a patch for testing. I have

Re: [ft-devel] severe problems with subpixel hinting

Hi Werner, As far as this specific Verdana issue goes, I've narrowed it down (strangely enough) to the NO_DELTAP_AFTER_IUP_Rules tweak. Interesting. In case you can nail down a precise example, I can contact Greg, asking for clarification. Don't worry about bothering him, especially given that

Re: [ft-devel] severe problems with subpixel hinting

Ah, I forgot to tell you how to build. For a build with subpixel hinting, simply I say make devel make from a clean (unmodified) repository. For a build without subpixel hinting, modify `devel/ftoption.h' (*not* `include/freetype/config/ftoption.h!) and comment out TT_CONFIG_OPTION_SU

Re: [ft-devel] severe problems with subpixel hinting

Reason is, AFAIK, that my host checks the existence of `infinality.net' only once (while trying to send), while a mailing list retries many times until it gives up. Any idea whether I can improve this on my side? Or is this only Erik's problem? I think I know what is causing this. A

Re: [ft-devel] severe problems with subpixel hinting

I'm unable to duplicate the first issue you mentioned, regarding the B/W text. When I run ftview as you stated, and hit 'a', the result is the same as your first picture, with the well-hinted monochrome characters. So, something must be different between our builds. I imagine that fontconfig

Re: [ft-devel] New Infinality Release

You can do this: { "DejaVu Sans", 12, "Regular Class", 'm', 0.95 * 0x1L }, I think the compiler will get it. See for example src/cff/cffload.c:1362: priv->expansion_factor = (FT_Fixed)( 0.06 * 0x1L ); src/type1/t1load.c:2091:priv->expansion_factor = (FT_Fixed)( 0.06 * 0x1

Re: [ft-devel] New Infinality Release

Essentially, it's just a question of representation, not changing the values themselves. Good comments help :-) Yep, it's not a huge deal, and it makes sense for consistency. I likely won't be able to get to this for a few days, so don't let it hold anything up!

Re: [ft-devel] New Infinality Release

I had originally been using floating point to handle stretching and emboldening of glyphs, which for obvious reasons Werner didn't want. So, I used 1000 because it was easier to convert to and from percentage. I'm OK converting all this over to FT_Fixed, however I think it will make maintaini

Re: [ft-devel] New Infinality Release

but the latter is rather unlikely, so this needs more investigation and pattern searching in real fonts. If you provide me a script or whatever to do such a search, I can use my collection of old fonts as a testbed to search for hits. BTW, what do you think of replacing SPH_DEBUG with FT_TR

Re: [ft-devel] New Infinality Release

Ah, I see that I've done a mistake, below is a corrected patch (untested). However, I think that the current method is flawed in general since arguments to opcodes are completely ignored by `SKIP_Code'. For example, it is not possible to decide whether the bytecode is SVTCA_x PUSHB_1

Re: [ft-devel] New Infinality Release

Have you actually done binary searches in TTFs to find signatures? Well, only using the code here, not with a hex editor. I have seen hits in some TTF files where I would not have expected them. May speak to the issues you mentioned below. Given that the new ttfautohint bytecode signatu

Re: [ft-devel] first auto-hinter infinality patch added to git

Very nice! I will take a look at implementing other extensions. On 09/19/2012 12:02 AM, Werner LEMBERG wrote: Along these lines it should be possible to add other auto-hinter extensions. Erik? Werner ___ Freetype-devel mailing list Freetyp

Re: [ft-devel] [ttfautohint] stem width handling is now selectable

For the record, I prefer 1/64. :) (Coincidentally I am also American) My favourites are screws with a head size of 39/64 or 7/16 inch, say. http://www.wlfuller.com/html/wood_screw_chart.html This sounds *so* natural :-) You sound just like my friend from Switzerland! Maybe Freetype shou

Re: [ft-devel] [ttfautohint] stem width handling is now selectable

Personally, I think that the value 1% is easier to comprehend than the value 1.5625% (to which a division by 64 is equivalent), so in this case I prefer the human to the computer. Tell this to any American who would prefer 1/32th of an inch to a millimetre before you finish your sentence. You d

Re: [ft-devel] [ttfautohint] stem width handling is now selectable

My understanding is that it was not possible to bring any dll over into WINE to get the MS rasterizer. It's built directly into the Windows kernel (or something else that isn't a dll). I would be *really* happy if I were wrong however! Please share if you find a way! On 07/02/2012 11:56 AM,

Re: [ft-devel] New Infinality Release

I think the patch is actually pretty clean and well separated from the rest of the code with #ifdef's. The patch only intrudes into the rounding routines to effectively disable them in x-direction. So I suggest that you use "if (y-direction)" OUTSIDE the rounding functions effectively skipping t

Re: [ft-devel] New Infinality Release

On 06/18/2012 03:50 PM, Alexei Podtelezhnikov wrote: On Mon, Jun 18, 2012 at 9:52 AM, Infinality wrote: On 06/18/2012 08:40 AM, Werner LEMBERG wrote: I really dislike how you disabled hinting in the x-direction. [...] Thanks for your reviews, and please continue. I'm sure Erik

Re: [ft-devel] New Infinality Release

Ok, I have access now. I had a newline in my public key. Doh! On 06/18/2012 08:40 AM, Werner LEMBERG wrote: I really dislike how you disabled hinting in the x-direction. [...] Thanks for your reviews, and please continue. I'm sure Erik will collect them all :-) Note that I won't do any cha

Re: [ft-devel] New Infinality Release

Yep, I welcome reviews and suggestions for improvement. Be gentle; I never claimed to be a C coder and I'm still learning best-practice for these things. On 06/18/2012 08:40 AM, Werner LEMBERG wrote: I really dislike how you disabled hinting in the x-direction. [...] Thanks for your review

Re: [ft-devel] New Infinality Release

Yep, I have done some google searching as well about ssh and savannah, but nothing helped. I'm going through the setup document again to see if I missed something. If I am unable to connect in the next hour or two, I can send you the patch. Thanks, Erik On 06/17/2012 11:39 AM, Werner LEMBE

Re: [ft-devel] New Infinality Release

, the latest release is available here: http://www.infinality.net/blog/infinality-freetype-patches/ Very nice! Some remarks regarding freetype-add-subpixel-hinting-infinality-20120615-01.patch: ___ Freetype-devel mailing list Freetype-devel

Re: [ft-devel] FT_Outline_Embolden() is Blurry

31 PM, Infinality wrote: Sorry to resurrect an old thread here, but I think I have a solution that preserves the addition of Y-weight at larger font sizes, while still keeping the blur to a minimum: In FT_Outline_Embolden (which is now FT_Outline_Embolden_XY), do this to ystrength: ystr

Re: [ft-devel] New Infinality Release

ilable here: http://www.infinality.net/blog/infinality-freetype-patches/ Very nice! Some remarks regarding freetype-add-subpixel-hinting-infinality-20120615-01.patch: . In line 1440 I see this: +#endif /* TT_CONFIG_OPTION_SUBPIXEL_HINTING */ +#ifdef TT_CONFIG_OPTION_SUBPIXEL_HINTING

[ft-devel] New Infinality Release

For those interested, the latest release is available here: http://www.infinality.net/blog/infinality-freetype-patches/ Changes for 2012-06-15: Infinality autohint patches: * Fix the forced slight hinting logic * Enhance artificial emboldening at larger ppems Infinality subpixel patches

Re: [ft-devel] FT_Outline_Embolden() is Blurry

Sorry to resurrect an old thread here, but I think I have a solution that preserves the addition of Y-weight at larger font sizes, while still keeping the blur to a minimum: In FT_Outline_Embolden (which is now FT_Outline_Embolden_XY), do this to ystrength: ystrength = FT_PIX_FLOOR ( ystr

Re: [ft-devel] Horizontal Stem Snapping in Autohinter

The only reason I bring up the horizontal stem snapping (outside the context of a new autohint API) is that it could be implemented without needing to add any new variables, and without using the warper. (The vertical stem alignment in the infinality patches relates more to the warper

[ft-devel] Horizontal Stem Snapping in Autohinter

Freetype font rendering. Currently, the infinality autohint patches have code inside af_latin_compute_stem_width() which accomplishes this. The only issue I notice is on a small subset of faces at certain ppems, on "s" and "a" sometimes. The middle stem tends to get under or o

Re: [ft-devel] ttfautohint / Oxygen / infinality

I've only been using browsers for these, but AFAIK it *should* be the same. :) On 04/21/2012 12:03 PM, vern adams wrote: Erik, Are you testing the rendering via web browsers only? Or do you get same results with e.g. ftview? -vern On 21 Apr 2012, at 16:51, Infinality wrote: Hi V

Re: [ft-devel] ttfautohint / Oxygen / infinality

Thanks Werner. I'd definitely be curious to know how the MS rasterizer determines when to/not use backwards compatibility mode. As of right now, my patches have no way of automatically determining this, and I'd like to go from using a hard-coded list of font names to something more dynamic!

Re: [ft-devel] ttfautohint / Oxygen / infinality

using here are: Infinality patches, native TT hinting. (I also have a custom FIR filter value set on the LCD filter for all of these images) http://www.infinality.net/files/oxygen-infinality-problems.png 2. This is what it renders like with native TT hinting if I disable all Infinality TT instru

[ft-devel] ttfautohint / Oxygen / infinality

Hi guys, Today I tested out the TT-instructed Oxygen font from the KDE repo with my TT subpixel hinting patches. This is the result: http://www.infinality.net/files/oxygen-infinality-problems.png Yikes!!! After examining the TT instructions in the instructed version of the Oxygen fonts, it

Re: [ft-devel] A review of ttfauthint by designer of Siri

I'm pretty sure that (at least some of) the issues with the main body of i and j touching the dot will go away if the x-height can be made lower, in cases where this happens. Erik / Infinality ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] FT_Outline_Embolden() is Blurry

Another thought I had just after sending the last email... Consider any font that has a bold face available: Arial, DejaVu, Lucida Grande, etc.. Their bold faces do not end up being any taller than the regular, non-bold faces. So, the fact that FT_Outline_Embolden() is making the glyphs tal

[ft-devel] FT_Outline_Embolden() is Blurry

In ftoutln.c there is a function called FT_Outline_Embolden(). This is used to create artificial emboldening, and is used when fontconfig requests emboldening for fonts that don't have a bold face available. Near the end of this function are these two lines, which actually perform the embolde

Re: [ft-devel] Severe rendering bug

Yes, if this were rendered with the subpixel hinting patch, this artifact wouldn't be present, because x-moves are ignored. In standard TT/monochrome hinting it would still be present though, as that isn't modified by the patches. Still, if it's an issue with the instructions in the font it

[ft-devel] Inconsolata Issue with 14px g

One of the users of my patchset noticed an issue with Inconsolata. See this post for details: http://www.infinality.net/forum/viewtopic.php?f=2&t=149&p=988#p988 I checked it out in an unpatched Freetype and the glitch appears

Re: [ft-devel] [RFC] FT_LCD_FILTER_HEAVY

I'll ask the fontconfig ML what they think of this, and if they OK it, I'll send you the fontconfig patch as I work on it. Sounds good. The question here is how to pass an arbitrary set of parameters to freetype from fontconfig. I'm not sure what will be the most natural on the fontconfig s

Re: [ft-devel] [RFC] FT_LCD_FILTER_HEAVY

Yes, I think that alternative is totally acceptable (and better, even), and the fontconfig syntax makes a lot more sense than the example I gave. I'd certainly be willing to figure out the changes needed to make Freetype accommodate this, however this is a new area for me. Based on the link t

Re: [ft-devel] [RFC] FT_LCD_FILTER_HEAVY

After re-reading the message from quanta, and your response to it, I see what you mean about needing a separate library to do this stuff. I'm envisioning something that would get the outline from freetype, and handle the rasterization, AA, filtering, etc. and return back to the client. That

Re: [ft-devel] [RFC] FT_LCD_FILTER_HEAVY

Well, given the fact that Freetype already has filters (LCD filters) in it, it made sense to me to allow other arbitrary filters too. It also has the advantage that you can get consistent rendering across different tools like Qt and GTK/cairo, assuming they hook into it. I guess I prefer a ce

Re: [ft-devel] Ttfautohint and light stem weights

I'm not sure how much control you get with GDI, but the only way I've found very thing fonts to render nicely is to use a technically accurate hinting (i.e. essentially Freetype slight hinting, which will make light horizontal stems be gray when less than 1px tall), and then run post-filters on

Re: [ft-devel] [RFC] FT_LCD_FILTER_HEAVY

One thing to keep in mind is that behind the scences, the Freetype FIR filter is implemented as an array of 5 FT_Bytes, which means the values are only 0 through 255 for each FIR component. So, the floats could ultimately be getting rounded somewhat, belying their precision. But, I think we'd

Re: [ft-devel] Ttfautohint and light stem weights

I'm assuming this screenshot is a Windows Cleartype rendering using ttfautohint? If so, it's possible that the filtering that Cleartype applies post-hinting is reducing very thin vertical stems to almost nothing. I ran into this same issue as I was playing around with different filters for my

Re: [ft-devel] [RFC] FT_LCD_FILTER_HEAVY

I second the idea of adding configurable LCD filter settings to fontconfig! On 11/20/2011 01:03 PM, Werner LEMBERG wrote: Given that we already have a function to set LCD filter weights, it would be natural to allow setting of the weights individually. I suggest that you discuss this on the fo

[ft-devel] Infinality Patchset Release

I've just released my latest Freetype patchset for anyone interested: http://www.infinality.net/blog/infinality-freetype-patches/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] 2.4.7 Copyright Years

happening with it, but figured I would mention it. Thanks, Erik (Infinality) ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [ft] ttfautohint 0.4 has been released

talking about. There is also other stuff going on here though too, including stem-alignment and adjustments to FIR filtering. This is newer code, but the existing infinality patchset does almost the same thing. If you'd like to play with it, it's here: http://www.infinality.net/blo

Re: [ft-devel] [ft] ttfautohint 0.4 has been released

my patchset. Currently I use a combination of emboldening, gamma correction, alignment and "dist" manipulation to make thinner fonts render in a more readable way. It would be nice to have one way to do it! Thanks, Erik (Infinality) On 10/27/2011 11:05 AM, vern adams wrote: Than