Re: [ft-devel] Some PDF embedded CFF fonts loading broken
Werner, The CFF fonts in question have been generated with FontForge. One of the fonts that exhibits these errors is: http://mupdf.com/repos/mupdf/fonts/NimbusSanL-Regu.cff If there is a flaw in the font file, I'd be more than happy to regenerate them with a different version of fontforge. On Sun, Jul 4, 2010 at 11:53 PM, Werner LEMBERG w...@gnu.org wrote: However, the constant `3' is probably wrong. Please try this line instead: if ( ( ip + 1 + ( ( decoder-num_hints + 7 ) 3 ) ) = limit ) Yes that works.. (FWIW the ip + 3... is exactly limit in this case) Thanks for testing. As a final check, could you determine the next instruction after `hintmask' (or `cntrmask') and its data bytes? Theoretically, it must be `return'. Otherwise, it's getting hairy. FreeType always assumes that operators are atomic. This holds for `hintmask' and `ctrlmask' also; however, both instructions can have a variable number of bytes *following* the instruction (contrary to normal instructions which expect its arguments already on the stack). Adobe's Type 2 technical note doesn't mention whether it is possible to have, say, in subroutine: ctrlmask return after returning: data byte 1 for ctrlmask data byte 2 for ctrlmask ... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft] Font rasterization
Victor, On 5/11/10, Victor loonyphoe...@gmail.com wrote: Hello! I apologize in advance if this is not the place to ask this question, but freetype doesn't seem to have a forum anywhere, so... I have recently come across a great article about font rendering, http://www.antigrain.com/research/font_rasterization/ It basically states (and very convincingly illustrates) that the secret to very good font rendering is to use only vertical pixel alignment, which I take means to apply hinting only vertically. Horizontally, the article suggests to use subpixel rendering -- that would mean very good scalability and shapes. I have tried many configurations in an attempt to produce the same result ( http://www.antigrain.com/research/font_rasterization/text_ft_antigrain.pngis a handcrafted example of what that would achieve), but horizontal pixel alignment seems to kick in even when disabling hinting completely. This is evidenced by characters having the same width with diffrent sizes. For example, if you scale the line l, its length will increase unevenly: at first it would change very little and then suddenly make a great leap. Either that, or that line would seem to have unevenly distributed spaces between the characters. I'm wondering if I just can't figure out how to configure it all correctly, or if the pixel alignment is built in without the ability to turn it off somehow. Or if maybe it's the creators of web browsers, office suites or desktops environments don't know how to achieve such an effect. So, let me reiterate my main inquiry: is it possible (with freetype) to use vertical hinting and pixel alignment only, leaving subpixel rendering to take care of the horizontal aspect? With regard to pixel alignment, it is certainly possible to render glyphs with a fractional offset with Freetype. This is set with the vector argument to FT_Set_Transform(). Sadly most UI toolkits and all web browsers that I have seen make the assumption that all fonts will be hinted horizontally and as such only calculate the glyph metrics and positioning using integers. -Tor ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft-devel] loading fonts with signature 'OTTO'
On Fri, Mar 5, 2010 at 2:40 PM, Graham Asher graham.as...@btinternet.com wrote: Does anyone know whether FreeType supports fonts with the signature (first 4 bytes) 'OTTO', and if so, which drivers are needed, and in which version was support added for this format? I have googled for some time, and experimented with various drivers, but without success, so forgive me for asking: the answer isn't obvious to me. Thanks in advance, FreeType2 has supported OpenType fonts with CFF outlines for a long time (several years now) without needing to do anything special. You'll need to compile it with both the TrueType and CFF PostScript font drivers. The default configuration works well for me in MuPDF. -Tor ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft] anti-aliasing question
Dave, On Sun, Feb 7, 2010 at 2:39 PM, Dave Calkins d...@kinematics.com wrote: I changed the flags as you suggested, rebuilt, and tested it again. I've attached a screenshot. I'm not sure how much of a difference it made though. That looks a lot more like it should. Compare the shape of the 5 and the amount of gray to the left of the 0. This is what GDI used to look like with the old pre-ClearType font smoothing, around the time of Windows 98. To match even closer, you'll need the ClearType colorization. As Werner has explained, you'll need to render 3x as wide, apply a filter (triangle filter is good) and store the resulting samples as an RGB texture. Then you need to find a way to make OpenGL composite the text taking the alpha value for each color channel separately from the texture. As others have mentioned, you can also tweak the grayscale values by applying a gamma function on the bitmap. I've found a gamma value of 0.7 and 1.4 to be good for text rendering, depending on whether you're rendering black on white or white on black. lookup[i] = pow(i / 255.0, gamma) * 255.0; -Tor ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] anti-aliasing question
On 2/5/10, Dave Calkins d...@kinematics.com wrote: On 2/5/2010 11:50 AM, Tor Andersson wrote: On Fri, Feb 5, 2010 at 2:19 PM, Dave Calkinsd...@kinematics.com wrote: I switched to using the default load flags (as opposed to the no hinting flag which was being passed by FreeTypeGL), but this doesn't seem to have made a difference. The text is still blurry. You get less blurrier output if you don't do subpixel position of glyphs. How do I control whether or not subpixel positioning of the glyphs occurs? What is the translation component of the transform? If it is non-zero then the grid fitting won't help against blurriness (since the pixel-aligned outline will then be shifted to between pixels, making the rendering all blurry). Where would the transform be specified? Are you referring to a transform provided to FreeType when it renders the glyphs? I took a look through the FreeTypeGL source and they're calling FT_RenderGlyph and then accessing glyph-bitmap to get the gray-scale image and loading this into an OpenGL 2D texture. This texture is used as the alpha channel to render a rectangle to the screen of the desired color. I'm not certain which transform you're referring to though. I'm referring to the third parameter of FT_Set_Transform, but you should also check your OpenGL transform matrices and the texture sampling mode. If that fails, could you perhaps attach some sample renderings in png format? ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] anti-aliasing question
On Sun, Jan 31, 2010 at 10:23 PM, Dave Calkins d...@kinematics.com wrote: I checked the FreeTypeGL source and it looks like its passing in the below values. For FT_Load_Glyph, FT_LOAD_NO_HINTING | FT_LOAD_NO_BITMAP For FT_Render_Glyph, FT_RENDER_MODE_NORMAL Experimenting with these hasn't seemed to have any effect on the amount of smoothing (whether anti-aliasing or a result of hinting). Basically I guess I'd like fewer gray pixels :) Not sure how to get that result. Still haven't found the answer to this. However, if I'm correct in saying that FreeType is generating a grayscale rendering of the glyph using anti-aliasing, then is there some way to control how much anti-aliasing FreeType applies when its rendering the glyph? No. It's either anti-aliased or it isn't (FT_RENDER_MODE_MONO). Removing the FT_LOAD_NO_HINTING flag should affect the rendering in the way you have been asking. ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] anti-aliasing question
On Sun, Jan 31, 2010 at 11:58 PM, Dave Calkins d...@kinematics.com wrote: Still haven't found the answer to this. However, if I'm correct in saying that FreeType is generating a grayscale rendering of the glyph using anti-aliasing, then is there some way to control how much anti-aliasing FreeType applies when its rendering the glyph? No. It's either anti-aliased or it isn't (FT_RENDER_MODE_MONO). Do you mean no there isn't a public interface to control the degree of anti-aliasing or no there is no way in the code the anti-aliasing can be controlled? I'm confused on this because somehow FreeType is creating white pixels and shades of gray pixels to render the glyph so I'm guessing there's some sort of determination internally which must affect how many gray pixels you end up getting. The gray value depends on how much the shape of the glyph covers the area of the pixel. Fully covered pixels become black, uncovered pixels white, and a 50% covered pixel will be 50% gray. To get the result you want, the shape of the glyph has to be changed so that fewer pixels will be partially covered. This is what hinting does: deform the outline to align with the pixel grid. Removing the FT_LOAD_NO_HINTING flag should affect the rendering in the way you have been asking. I tried removing that flag before and saw no difference in the anti-aliasing. Perhaps I missed something or my test was incorrect. I'll try that again and see if I can get it to have any effect. Try it again, the difference between hinted and unhinted should be pretty drastic. Which font are you using by the way? Some fonts have better hinting instructions than others. You should also make sure that your freetype library is compiled with the bytecode interpreter enabled if you want to match windows' rendering (look at ftoption.h). -Tor ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Applying Styles to text using a font
On Wed, Jan 27, 2010 at 1:16 PM, harshagomes harsha.sh...@gmail.com wrote: Hi, Can somebody please help me in applying styles to text using a ttf font ? Eg: consider the string 'sample', and am using 'verdana' font The verdana font exists in four variants -- regular, bold, italic and bold italic. Load the appropriate font file for the style you want. verdana.ttf verdanab.ttf verdanai.ttf verdanaz.ttf I want to apply bold or italic style to this string so that it becomes In Bold sample In Italic sample Thank you, harshagomes -- View this message in context: http://old.nabble.com/Applying-Styles-to-text-using-a-font-tp27338110p27338110.html Sent from the Freetype - User mailing list archive at Nabble.com. ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] anti-aliasing question
On Tue, Jan 26, 2010 at 5:14 PM, Dave Calkins d...@kinematics.com wrote: When comparing FreeType text rendering (in OpenGL via FreeTypeGL) with Windows GDI text rendering, it appears that FreeType is applying more aggressive anti-aliasing effects. The GDI text is anti-aliased, just not as much. The FreeType text looks much smoother. I'm curious, are there parameters to fine-tune how much anti-aliasing is applied? I believe you are looking for how much hinting, also known as grid fitting, is applied rather than anti aliasing. Windows font rendering deforms the font outlines very aggressively to align to the pixel grid, resulting in very few gray pixels when rendered. You'll have to look at the FreeTypeGL source to see what options it passes to freetype for rendering. If you want to get results close to what Windows does by default you'll need to use the bytecode interpreter hinting. You can also use this freetype + opengl code I wrote a while back if you want high quality smooth text with even spacing (like on Mac OS X), or experiment with different freetype rendering options in an opengl environment: http://ccxvii.net/repos/mio/font.c -Tor ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] How to compile universal freetype on MacOS X 10.4?
I'm trying to build a universal (ppc and i386) libfreetype 2.1.12 (or any reasonably recent version) on my PPC Mac (10.4.7 with XCode 2.4). I can built something, but it's always PPC-only. I believe that you need to compile twice, once with each -arch flag, to separate files. Then you merge together the two resulting (i386 and ppc) dylib files with lipo. At least that's how Xcode does it. I do not believe that gcc can compile to both architectures in the same command, which it looks like you're trying to do. Tor ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] How to compile universal freetype on MacOS X 10.4?
On 9/22/06, Russell E Owen [EMAIL PROTECTED] wrote: At 12:01 AM +0200 2006-09-22, Tor Andersson wrote: I'm trying to build a universal (ppc and i386) libfreetype 2.1.12 (or any reasonably recent version) on my PPC Mac (10.4.7 with XCode 2.4). I can built something, but it's always PPC-only. I believe that you need to compile twice, once with each -arch flag, to separate files. Then you merge together the two resulting (i386 and ppc) dylib files with lipo. At least that's how Xcode does it. I do not believe that gcc can compile to both architectures in the same command, which it looks like you're trying to do. I suppose that may be necessary for freetype. I hope not, because I don't have easy access to an Intel Mac. However, if you are making a blanket assertion that having gcc build for both i386 and ppc at the same time doesn't work...that's wrong. The tech note I reference shows how to do it, and it works just fine for libpng. That's what I meant, so I guess I am wrong. I've built universal apps on ppc macs, but I've always used Xcode (which compiles the architectures separately) and/or lipo to stitch the architectures together into a fat binary. Also, I know somebody who built a universal libfreetype on his Intel Mac. He claims to have used a similar incantation (and doing it all at once, not building separately and combining) but he doesn't remember the exact details. ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Tweaking/Improving FreeType Antialiasing
On 8/27/06, Roman Shaposhnik [EMAIL PROTECTED] wrote: On Sun, 2006-08-27 at 14:24 +0200, Tor Andersson wrote: It still won't be perfect, since all Linux toolkits snap metrics to pixel integer coordinates which gives somewhat uneven spacing. Don't even think about CoolType or ClearType in Linux; the Xft code does not do filtering across pixel borders so it's a *lot* worse than it could be. Thanks for the info, but let me ask you this -- is there somebody working on Xft to make it possible ? Are they pursuing a different route ? I'm not sure. If I remember correctly, Keith Packard explicitly decided that he didn't want the filtering to cross pixel borders because that might possibly confuse xterm and other character cell based software. Stupid reason, if you ask me. Fixing it to the same filter as Gargoyle is a trivial hack. The filter I use is a simple [ 1 2 3 2 1 ] / 9 as illustrated here: http://www.grc.com/cttech.htm It's not FreeType's fault that Linux text looks bad. For reference, with FreeType 2 it is possible to get the kind of text quality displayed in the screenshots on this web page: http://ccxvii.net/gargoyle/screenshots.html Here I use FreeType2 to render text unhinted, taking in account the fractional position of each glyph within the pixel (ie, the render of a character is different depending on whether it starts at pixel coordinate 0.0 or 0.2 or 0.7, for example). I also apply a 5-component wide LCD coloring filter. Tor, what kind of software did you use to achieve such a result ? Can it be leveraged for Xft (at least the filtering part)? I used pure freetype. The filtering can be done with a minor patch to Xft; the hard part is not the code, it's the convincing the right people. Also, if you don't mind -- can you elaborate a bit on how did you do fractional positioning (I mean it doesn't seem to be possible with FT APIs so you must have done something else here). Use the offset from integer coordinates as the translation part of the transform matrix, then render unhinted. (Hinting assumes that the translation is zero, if I recall correctly) float x, y = ... coordinates of glyph in screen space ... float xpart = x - floor(x); float ypart = y - floor(y); FT_Vector v; v.x = xpart * 64; v.y = ypart * 64; FT_Set_Transform(face, ctm, v); FT_Load_Glyph(face, gid, FT_LOAD_NO_BITMAP, FT_LOAD_NO_HINTING); FT_Render_Glyph(face-glyph, FT_RENDER_MODE_LIGHT); /* or _LCD */ Tor ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Tweaking/Improving FreeType Antialiasing
On 8/27/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'd be very happy with just a custom browser build - say something KHTML based maybe - that has great font rendering and kerning. It would make Linux so much nicer to use. OpenOffice, Gnome and a PDF viewer would be next up on my list for improved font handling. I don't think it's going to be perfect system-wide, however, if I'm understanding the limitations properly - but maybe there's at least room for improvement? off topic, shameless plug You may want to look into MuPDF. It does not do subpixel color filtering, but has unhinted, fractionally positioned text rendering, in a very light package. http://ccxvii.net/apparition/ Only windows binaries for now (but portable source). Make sure to get the stable version if you check out the source. / ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Tweaking/Improving FreeType Antialiasing
On 8/27/06, Keith Packard [EMAIL PROTECTED] wrote: On Sun, 2006-08-27 at 22:48 +0200, Tor Andersson wrote: On 8/27/06, Roman Shaposhnik [EMAIL PROTECTED] wrote: On Sun, 2006-08-27 at 14:24 +0200, Tor Andersson wrote: It still won't be perfect, since all Linux toolkits snap metrics to pixel integer coordinates which gives somewhat uneven spacing. Don't even think about CoolType or ClearType in Linux; the Xft code does not do filtering across pixel borders so it's a *lot* worse than it could be. Thanks for the info, but let me ask you this -- is there somebody working on Xft to make it possible ? Are they pursuing a different route ? I'm not sure. If I remember correctly, Keith Packard explicitly decided that he didn't want the filtering to cross pixel borders because that might possibly confuse xterm and other character cell based software. Stupid reason, if you ask me. Lame, perhaps, but still important -- filtering that extends beyond the pixel changes all character metrics, which is relevant for applications which cannot handle overlapping glyphs. As Xft was designed largely as a migration API for existing applications, trying to preserve as much of the semantic environment as possible seemed important. We can certainly change how this works in new rendering APIs like cairo where applications are moving beyond pixel-oriented drawing. I'm not sure I understand this. What's your definition of character metrics here? I'm grounded in the postscript world where the only metrics that matter are the origin and advance width. How does it change metrics? The resulting bitmap will be of a different size and have different lsb/top offsets, but apps have to cope with varying bitmap sizes anyway (as returned by FT_Render_Glyph), or am I totally ignorant about how xterm co draw their text? You can also cheat and do the interpixel filtering without changing the bitmap size. The slight error at the edge is not visible; and is still a lot better than what Xft does now. Yes, yes, I know you and Carl Worth are obsessed with precision, as evidenced by the aa discussions on the Xrender mailing list. That is, before all the X11 lists changed and killed off the discussion :( That was a sad day, I really enjoyed reading that list... Sub-pixel positioning is another important area; you can explore this with cairo today by converting glyphs to paths and filling them rather than using the simple text filling APIs. Making this 'go fast' is somewhat tricky as you need to cache rendered glyphs for acceptable performance these days, which means picking a sub-pixel grid for positioning. Would a separate set of Xft functions to get fonts that does a subpixel grid be too much to ask for? I know there's nothing in the RENDER protocol to prohibit it, and if it's an easily accessible piece of functionality it might be more likely to be used. Tor ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
[ft] detecting font format from ft_face
Hi!
I am updating my MuPDF PDF viewer to use freetype 2.2 and I have hit a snag.
Because of the way PDF treats encodings, I need to know the format of a
loaded font face.
Previously I have used the following hack to switch on the driver used:
enum { UNKNOWN, TYPE1, CFF, TRUETYPE, CID };
static int ftkind(FT_Face face)
{
const char *kind = face-driver-clazz-root.module_name;
if (!strcmp(kind, type1))
return TYPE1;
if (!strcmp(kind, cff))
return CFF;
if (!strcmp(kind, truetype))
return TRUETYPE;
if (!strcmp(kind, t1cid))
return CID;
return UNKNOWN;
}
How do I achieve the same results without using the internal header files?
Tor
___
Freetype mailing list
Freetype@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype
