qlb1234 | 26 Feb 04:09 2015
Picon

[ft] References Is Not Included in the Document Tarball

Dear sir,

I found out that this file, http://gnu.mirrors.pair.com/savannah/savannah//freetype/freetype-doc-2.5.5.tar.bz2, does not have reference (API) pages in it. However, there are hyperlinks which points to them in the tutorial. I think the reference is meant to be there. For now, one need to copy them from the source tarball manually to make the hyperlinks work.

Regards,
Wesley
_______________________________________________
Freetype mailing list
Freetype <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype
John Found | 25 Feb 10:13 2015

Re: [ft] What is FT_PIXEL_MODE_BGRA for?

Thanks for the help! (And all others on the thread). Actually I just realized, that these fonts have fixed
size and for any other size requested FreeType returns "Invalid pixel size" (in ftview as well). When
started ftview with the proper size, the fonts are visible. Knowing this, I was able to test the colourful
fonts in my application and everything seems to be fine. ;)

On Wed, 25 Feb 2015 09:07:43 +0100
"Toresson, Alexander (EXT)" <Alexander.Toresson <at> sonymobile.com> wrote:

> Here's Noto Color Emoji from Android Kitkat.
> 
> BR, Alexander
> 
> -----Original Message-----
> From: freetype-bounces+alexander.toresson=sonymobile.com <at> nongnu.org
[mailto:freetype-bounces+alexander.toresson=sonymobile.com <at> nongnu.org] On Behalf Of John Found
> Sent: den 25 februari 2015 08:20
> To: freetype <at> nongnu.org
> Subject: Re: [ft] What is FT_PIXEL_MODE_BGRA for?
> 
> On Tue, 24 Feb 2015 20:50:39 +0100 (CET) Werner LEMBERG <wl <at> gnu.org> wrote:
> 
> > Look for emoji fonts, including the ones from Android and iOS.
> 
> I tried to find some, but all they seems to be monochrome. 
> Can you help me with some links? 
> 
> P.S. Actually, I found one font named "Funkster.ttf", that seems to be at least grayscale, but when trying
to use it FreeType fails on FT_Set_Pixel_Sizes. Also, it can't be installed on my Linux OS.
> 
> 
> -- 
> John Found <johnfound <at> asm32.info>
> 
> _______________________________________________
> Freetype mailing list
> Freetype <at> nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype

--

-- 
John Found <johnfound <at> asm32.info>
John Found | 24 Feb 18:50 2015

[ft] What is FT_PIXEL_MODE_BGRA for?

Is it supported actually or is just reserved for future use?

I suppose it is some particular font format that supports colourful glyphs. Is it?
Where I can found a sample of such font?

--

-- 
John Found <johnfound <at> asm32.info>
John Found | 20 Feb 21:15 2015

[ft] My experiments with FreeType cache.

After some experiments with the FreeType cache sub-system, I was able to produce some working code. 
Well, I think is it "working", only because the text rendering speed raised more than five times.

But is it really OK?

What I am doing is:

At first, I defined my own structure "TFont" to keep the string with the font name in format for FontConfig
and the needed font height. The address of this structure will be the Face_ID for the cache manager.

The FT_Face_Requester procedure using the from the Face_ID calls the FontConfig functions in the
following order:

1. FcNameParse
2. FcConfigSubstitute
3. FcDefaultSubstitute
4. FcFontMatch
5. FcPatternGetString, ..., FC_FILE,...
5. FcPatternGetInteger, ..., FC_INDEX,...

After obtaining the font filename and the face index, the requester creates the face object calling:

7. FT_New_Face ...
8. FT_Set_Pixel_Sizes - from the passed Face_ID structure.

Thus created face is returned to the caller.

In the procedure that renders the text the string loop looks following way:

1. Decode one UTF-8 character.
2. FT_Get_Char_Index
3. FTC_ImageCache_Lookup (with FT_LOAD_RENDER in the FT_Image_type.flags and the height of the font in
the .height arguments)
4. DrawGlyph the returned FT_BitmapGlyphRec.bitmap image (it is my custom procedure, that draws the
bitmap in color)
5. goto 1

What I am doing wrong?

The full source (x86 assembly language) can be seen here: 

http://fresh.flatassembler.net/fossil/repo/fresh/info/812dc7?ln=17-169

Notice, that it is still a draft and misses any error checking.

I hope I didn't miss something important.

Best Regards.
--

-- 
John Found <johnfound <at> asm32.info>
Raimund Steger | 19 Feb 00:53 2015
Picon

[ft] Suggestion/Inquiry: keeping metrics.horiAdvance for emboldened fixed-width fonts

Hi,

there has been a discussion on the fontconfig mailing list about 
artificially emboldened fixed-width fonts (this one: 
http://thread.gmane.org/gmane.comp.fonts.fontconfig/5372).

The issue that has been brought up -- not for the first time -- is that 
some text editors use bold face for syntax highlighting, and if said 
editors happen to use a font that has no native bold variant (Droid Sans 
Mono, Inconsolata, Lucida Console) the characters will not align between 
the lines as FreeType adds emboldening strength to the horizontal 
advance width which many toolkits use without modification (not terminal 
emulators though! as I've found, but... the rest).

I don't at all disagree with the current implementation in terms of 
aesthetics, but I suppose one could say that keeping monospace text in 
its proper grid (in the face of users who don't want to configure a lot) 
constitutes something like a higher cause...

Anyway. We found that older Infinality patches implemented a change to 
this exact advance width calculation that just disabled it if 
FT_FACE_FLAG_FIXED_WIDTH was set. Newer versions then started disabling 
it unconditionally, but I think that would be taking it a little too far.

Attached is a patch that's about what I have in mind.

Now I have little experience what weight such a change would carry in 
the FreeType world, whether the patch even addresses the right spot in 
the code, and if it's something you would consider acceptable in terms 
of looks (in particular, I haven't tested emboldened bitmap fonts), and 
... let's say rendering stability (I mean creating reproducible images 
across FreeType versions. I've spotted a discussion in the mailing list 
archive that suggests that some people are very serious about this). 
Still I thought it'd be worth a suggestion before some distributions 
started disabling the feature for monospace fonts through their 
fontconfig setup...

-Raimund

-- 
Worringer Str 31 Duesseldorf 40211 DE  home: <rs <at> mytum.de>
+49-179-2981632 icq 16845346           work: <rs <at> interface-ag.de>
diff --git a/include/ftsynth.h b/include/ftsynth.h
index ca7f2c7..4b13807 100644
--- a/include/ftsynth.h
+++ b/include/ftsynth.h
 <at>  <at>  -62,8 +62,10  <at>  <at>  FT_BEGIN_HEADER
   /* a wrapper for  <at> FT_Outline_Embolden and  <at> FT_Bitmap_Embolden.           */
   /*                                                                       */
   /* For emboldened outlines the height, width, and advance metrics are    */
-  /* increased by the strength of the emboldening.  You can also call      */
-  /*  <at> FT_Outline_Get_CBox to get precise values.                           */
+  /* increased by the strength of the emboldening.  (An exception to this  */
+  /* are mono-width fonts, where the horizontal advance metrics are left   */
+  /* unchanged.)  You can also call  <at> FT_Outline_Get_CBox to get precise    */
+  /* values.                                                               */
   FT_EXPORT( void )
   FT_GlyphSlot_Embolden( FT_GlyphSlot  slot );

diff --git a/src/base/ftsynth.c b/src/base/ftsynth.c
index cd68533..cab2bb0 100644
--- a/src/base/ftsynth.c
+++ b/src/base/ftsynth.c
 <at>  <at>  -150,7 +150,10  <at>  <at> 

     slot->metrics.width        += xstr;
     slot->metrics.height       += ystr;
-    slot->metrics.horiAdvance  += xstr;
+    /* for mono-width fonts (like Andale, Courier, etc.) we need */
+    /* to keep the original advance width                        */
+    if ( !FT_IS_FIXED_WIDTH( face ) )
+      slot->metrics.horiAdvance  += xstr;
     slot->metrics.vertAdvance  += ystr;
     slot->metrics.horiBearingY += ystr;

_______________________________________________
Freetype mailing list
Freetype <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype
Jan Engelhardt | 18 Feb 23:54 2015
Picon

[ft] Different font appearance depending on matrix


Depending on how one chooses font scaling, the result looks different.
As a baseline, I am using

[1] xterm -fa 'DejaVu Sans Mono:size=26:matrix=0.85 0 0 1'

this can be rewritten to

[2] xterm -fa 'DejaVu Sans Mono:size=13:matrix=1.7 0 0 2'
[3] xterm -fa 'DejaVu Sans Mono:size=7.5:matrix=3.4 0 0 4'
[4] xterm -fa 'DejaVu Sans Mono:size=52:matrix=0.425 0 0 0.5'

[5] xterm -fa 'DejaVu Sans Mono:size=22.1:matrix=1 0 0 1.17647'

The font looks slightly different for these four configurations (and
in case of [3] even causes a different window size) - screenshot at
http://inai.de/files/ftmatrix.png .

What may be the reason behind the different renderings?
There might be rounding erros in cases like [5], but [1]/[2]?
John Found | 17 Feb 19:37 2015

[ft] How to use FreeType with FontConfig?

Recently I am working on text rendering with FreeType.

The FreeType function FT_New_Face uses the filename of the font, but I want more flexible approach with
font substitution and suggesting fonts by some pattern, for example "serif", "monospaced", "bold", etc.

I know that such functionality is provided by Fontconfig library. 

But how I can interface Fontconfig with FreeType? 

I tried to read the Fontconfig documentation, but didn't find a solution. The FreeType documentation also
does not mention Fontconfig.

--

-- 
John Found <johnfound <at> asm32.info>
Lawrence D'Oliveiro | 17 Feb 08:37 2015
Picon

[ft] python_freetype Design: Bitmap Objects

It seems like the APIs for FT_Bitmap objects are not entirely public.
FT_Bitmap_New sets a Bitmap to null (zero dimensions, no pixel buffer
allocated). FT_Bitmap_Copy can allocate storage for the pixels, but
only to copy an existing non-null Bitmap. So there is no public API
call to allocate a user-specified amount storage for a Bitmap--not
storage that will be correctly disposed by FT_Bitmap_Done, at any rate.

However, FreeType will correctly copy pixels _from_ a user-supplied
Bitmap object without worrying where the storage is allocated. So my
Bitmap wrapper class allows the option of using a Python buffer array
<https://docs.python.org/3/library/array.html> for the pixel storage. I
provide methods “new_with_array” to allocate a Bitmap of specified
dimensions, and “copy_with_array” which will make a copy of a Bitmap
such that the storage is in an array. (The “copy” method wraps
FreeType’s FT_Bitmap_Copy routine to go the other way.) Since all access
(and disposal!) is managed through methods of my wrapper class, I can
handle all details of the difference between such Bitmaps and those with
storage managed by FreeType itself.

_______________________________________________
Freetype mailing list
Freetype <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype
Werner LEMBERG | 15 Feb 16:46 2015
Picon

Re: [ft] freetype


[Forwarding to the FreeType user mailing list.]

Please help this guy.

> I am writing to you to ask for your help with freetype2. I intend to
> use freetype2 for embedded arm cortex m4 controller with ram 160 K
> and flash 1M.
>
> I wish to use truetype.
>
> Could you please give me some hints about how to tailor it to a
> minimum? Be it a book or a link?
>
> Thank you in advance
>
> Mr. Jinlong Shen
Lawrence D'Oliveiro | 15 Feb 07:29 2015
Picon

[ft] Incorrect Status Return In FT_Get_SubGlyph_Info

Looks like FT_Get_SubGlyph_Info forgets to set its error return to
FT_Err_Ok if the conditions are right for it to return its info.
Lawrence D'Oliveiro | 13 Feb 02:07 2015
Picon

[ft] python_freetype Design: Outline Objects

FT_Outline objects seem to have some tricky aspects to them: they have
“n_contours” and “n_points” fields to indicate the _used_ sizes of the
“points”, “tags” and “contours” arrays, but no explicit way of
indicating the actual _allocated_ sizes of these arrays. It looks like
the caller has to keep track of that.

For example, FT_Stroker_Export and FT_Stroker_ExportBorder blithely
assume they can append data onto these arrays, and increment n_contours
and n_points accordingly. So a basic technique for calling these would
be to call FT_Stroker_GetCounts or FT_Stroker_GetBorderCounts to find
out how much space the export will use, call FT_Outline_New to allocate
a new FT_Outline with sufficient space, then _set its n_contours and
n_points to zero_ before passing it to the export routine to fill it in.

In Python, I wanted to avoid all this messing about. So I implemented
an “append” method for my Outline wrapper class, which allocates a new
FT_Outline, big enough to hold both the existing and the additional
sets of outline data, copies all the data into it, and replaces the
Outline’s internal FT_Outline object with the new one.

To go with this, my Outline class implements a “new” method which
creates a new Outline with room for 0 contours and 0 curve points. And
in my Stroker class, the export methods do an append to the Outline you
pass to them, so you never have to worry about overrunning the arrays.

_______________________________________________
Freetype mailing list
Freetype <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Gmane