Re: [ft] Include problems

[Werner LEMBERG]

 I have compiled(win32) the freetype librabry, but when I include
 FT_FREETYPE_H after ft2build.h it gives me errors at fterrdef.h.

 The errors at the following:

 fterrdef.h(35): error C2143: syntax error : missing '}' before '('
 fterrdef.h(35): error C2143: syntax error : missing ';' before
 'L_TYPE_raw'
 fterrdef.h(35): error C2059: syntax error : 'L_TYPE_raw'
 fterrors.h(164): error C2143: syntax error : missing ';' before '}'
 fterrors.h(177): error C2059: syntax error : '}'
 fterrors.h(177): error C2143: syntax error : missing ';' before '}'
 freetype.h(38): error C2143: syntax error : missing ';' before '{'
 freetype.h(38): error C2447: '{' : missing function header (old-style
 formal list?)

Never seen before.  Please try to compile a small snippet, e.g.

  http://freetype.org/freetype2/docs/tutorial/example1.c

with a different compiler.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Follow up: FreeType v2501 under DJGPP with RHIDE

[Werner LEMBERG]

 I am trying to set up FreeType v2.51 with DJGPP under RHIDE on DOS
 in order to trace through the library source code.  Particularly, I
 want to translate the anti-aliased rasterizer to another language.
 Therefore, I do not want to build the library -- I want all source
 code to be traceable.

Read this thread

  http://lists.gnu.org/archive/html/freetype-devel/2012-01/msg00037.html

and try

  https://github.com/vinniefalco/FreeTypeAmalgam.

It's not up to date, but perhaps you can ping Vinnie to fix that – it
should basically be trivial for him to run his `amalgamate' tool

  https://github.com/vinniefalco/Amalgamate

on the corresponding amalgamate template

  https://github.com/vinniefalco/Amalgams/

again.

Even if you don't use the amalgamation stuff, looking up those
templates might help you in fixing your compilation problems.


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Cache sizes

[Werner LEMBERG]

Hello Daniel!


 In short, as soon as we have more faces or sizes than the cache will
 allow, default being 2/2 as you already know, then strange things
 happens.  First of all we receive face object where the size pointer
 is NULL.  This causes our GetKerning routine to fail, since there is
 no size data to work with.  This will not occur if we increase the
 size of the cache.

Given that FreeType's cache code is still in beta, there might be
bugs.

 Q1: Are we doing something wrong?

I don't think so.  However, it would tremendously help us if you could
provide a simple demo program (to be run on the console) that exhibits
the problems you are experiencing.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Python3 Language Binding

[Werner LEMBERG]

 There seem to have been a number of attempts at implementing a Python
 binding for FreeType. Let me offer my effort:
 https://github.com/ldo/python_freetype.

Nice!  Please provide a patch for 

  http://freetype.org/developer.html#language-bindings

so that I can add it (in case you think that it is mature enough to be
mentioned there).


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] freetype

[Werner LEMBERG]

[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

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Incorrect Status Return In FT_Get_SubGlyph_Info

[Werner LEMBERG]

 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.

Fixed 2014-04-17, appearing in version 2.5.4.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] python_freetype Design: Vector Matrix Operations

[Werner LEMBERG]

 * Shearing is often used to simulate italic.

Yes.  In this special case, hinting along the vertical axis (which
happens before shearing) doesn't harm.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

[ft] Announcing ttfautohint 1.3

[Werner LEMBERG]

ttfautohint 1.3 has been released.

The source tarball, statically-linked binaries for Win32 (TTY and GUI) and
OS X (TTY only) are available from

http://savannah.nongnu.org/download/freetype/

or

http://sourceforge.net/projects/freetype/files/ttfautohint/1.3

Instructions to build the GUI version on OS X can be found at

http://freetype.org/ttfautohint/osx.html


Enjoy!


   Werner


PS: Downloads from savannah.nongnu.org will redirect to your nearest
mirror site.  Files on mirrors may be subject to a replication
delay of up to 24 hours.  In case of problems use
http://download-mirror.savannah.gnu.org/releases/


--


http://freetype.org/ttfautohint

This project provides a library that takes a TrueType font as the input,
remove its bytecode instructions (if any), and return a new font where all
glyphs are bytecode hinted using the information given by FreeType's
autohinting module.  The idea is to provide the excellent quality of the
autohinter on platforms that don't use FreeType.

The library has a single API function, `TTF_autohint'; see
`lib/ttfautohint.h' for a detailed description.  Note that the library
itself won't get installed currently.

A command-line interface to the library is the `ttfautohint' program; after
compilation and installation, say

  ttfautohint --help

for usage information, or say

  man ttfautohint

to read its manual page.

A GUI to the library is `ttfautohintGUI'; it uses the Qt4 framework.  The
compilation of this application can be disabled with the `--without-qt'
configuration option.


--


Version 1.3 (2015-Jan-06)
-

* Keywords in control instruction files can be more verbose to increase
  readability.  You can now use `left`, `right`, `nodir`, `point`, `touch`,
  `xshift`, and `yshift` for `l`, `r`, `n`, `p`, `t, `x`, and `y`,
  respectively.

* A new control instruction keyword `touch` was added to apply delta
  instructions before the final IUP bytecode commands, also `touching' the
  affected points (to use the TrueType instructions terminology).  Such
  deltas *do* work even with ClearType if applied to the non-ClearType
  direction.

* Support for the Telugu script.

* The amount of information about ttfautohint and its parameters that gets
  added to the `name` table by default has been reduced.  A new option
  `--detailed-info` restores the previous behaviour.

* ttfautohintGUI crashed if not used with a control instruction file.

* ttfautohintGUI now correctly switches to a horizontal two-column layout if
  the standard one-column layout would exceed the screen height.

* A new option `--family-suffix` makes it possible to append a suffix to a
  font's family name in the `name` table.  This can be useful during the
  development process: It helps the operating system to simultaneously
  display several instances of a font that are processed with different
  ttfautohint parameters.

* The new library option `info-post-callback` helps in processing data from
  the `name` table.

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Faster computation of text width?

[Werner LEMBERG]

 And if you have really found a bug, it is a great aid to me for
 debugging and thus very efficient also – only a failing snippet can
 *exactly* demonstrate the issue.
 
 No, I don't think I found some bugs.  My questions are about
 FreeType use.  As long as the documentation describes only the less
 efficient way of FreeType use, I have no other choice than trying
 myself and asking questions.

Unfortunately, I have difficulties to talk about efficiency if I can't
see corresponding C (or C++) code.  Maybe somebody else can give you
better advice.

 Ah, BTW, I have a library architecture observation/note:
 
 The structures FTC_ScalerRec and FTC_ImageType are in practice the
 same structure, described in some different way.  Then why not to
 join them (add a field .flags to FTC_ScalerRec)?

This is not possible since both structures are public, and for ABI
reasons they can't be changed.[*]

 The same applies for the pairs of functions
 FTC_ImageCache_Lookup/FTC_ImageCache_LookupScaler and
 FTC_SBitCache_Lookup/FTC_SBitCache_LookupScaler.

Ditto.

 And last: In the documentation, I read that We hope to also provide
 a kerning cache in the near future.  Is these plans still alive?

Not really – David Turner, the father of the caching code, no longer
works on FreeType, and my priorities are elsewhere.  However, if
someone contributes such code, I will gladly integrate it.

Werner


[*] Well, theoretically they could be changed since the FreeType's
cache interface is still tagged as beta, but I don't see a
convincing reason to do it.
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Faster computation of text width?

[Werner LEMBERG]

 If the ABI can only be introduced and never removed, every library
 early or later will become an overbloated huge monster, that no one
 wants to use.  In this moment will come some lightType library,
 that will replace the old dead one.

Correct.  There are ideas to provide a lighter interface for a
forthcoming FreeType 3, but this won't come quickly.  Additionally,
I'm bad at designing APIs...

 In fact, the cache code is so useful, that not developing it is a
 huge mistake.

Volunteers welcomed!

 On the other hand, its functions are so different than the other
 FreeType functions, that maybe it worth to make them a separate
 library...

Mhmm, probably not very useful, since it is tightly integrated to
FreeType.  If you don't need its functionality it is easy to
deactivate this module.

 BTW, if the author discarded this task, how the beta will become
 release?

`Beta' essentially means that I reserve the right to apply larger
changes if necessary.  On the other hand, the caching code is probably
widely used, and changes to it would be an unpleasant surprise to many
users.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

[ft] simplified installation of ttfautohint with Homebrew

[Werner LEMBERG]

An updated formula for installing ttfautohint *and* ttfautohintGUI has
just been committed to Homebrew.  This greatly simplifies installation
on OS X.  The updated installation instructions can be found at

  http://www.freetype.org/ttfautohint/osx.html


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Opentype support of specual characters

[Werner LEMBERG]

 is it possible to use the special characters like ö, ü, ö, ß from
 opentype (otf) fonts in PHP?

If the font contains those glyphs, and it also contains a Unicode cmap
(which is standard today), it should work.

 I used this: 
 
 ImageTTFText ($image, 30, 0, 0, 40,
   $font,tmp/AnieneNuovaEF-Regular.otf,$text);

I don't know this `ImageTTFText' function, since I'm not using PHP.
Are you sure that `$text' has the right encoding?  You should look up
the documentation.


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Faster computation of text width?

[Werner LEMBERG]

 I came across “The Little Manual of API Design” recently
 http://www4.in.tum.de/~blanchet/api-design.pdf, from one of the Qt
 developers.

Thanks.


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] use of FT_New_Library function

[Werner LEMBERG]

 Sure, [...]

Thanks for the suggestion; I've added something similar to the git
repository.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] python_freetype Design: Bitmap Objects

[Werner LEMBERG]

 One potentially misleading thing, I think, is the routine name
 “FT_Bitmap_New”: it does not allocate any storage at all (contrast
 “FT_Outline_New” and “FT_Stroker_New”), but initializes the Bitmap
 structure to indicate “zero width, zero height, no pixels”. A better
 name might have been “FT_Bitmap_Init”, or even “FT_Bitmap_Null” or
 “FT_Bitmap_Empty”.

Renamed in git to `FT_Bitmap_Init'.


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] use of FT_New_Library function

[Werner LEMBERG]

 So you see, the FT_Memory object you pass is expected to remain
 valid for the life of the FT_Library.

Shall something be added to the documentation?  If yes, can you
provide a patch?


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Correct TrueType Checksums

[Werner LEMBERG]

 The TrueType font format is full of checksums: [...]

FreeType completely ignores them except for a very special purpose,
namely to identify `tricky' (CJK) fonts that must not be auto-hinted
(cf. function `tt_synth_sfnt_checksum' in file `ttobjs.c') – and even
here we don't trust the value in the font but compute it by ourselves
for the `cvt', `fpgm', and `prep' tables only.

 Unfortunately, this field gets counted in the font checksum twice,
 so it can only adjust its value by ±2. So if you have an odd number
 of tables with odd content checksums, there seems to be no way to
 get the overall font checksum to come out right.

What do you want to achieve?

 Back when I was mucking around with Macintosh fonts, I used to come
 across a lot of ones with bad checksums--seems like font creators
 couldn’t even be bothered to get them right.

You might use the `ttx' program to check and/or fix checksums.  AFAIK,
it computes them correctly.


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Faster computation of text width?

[Werner LEMBERG]

 Indeed, working more on this issue I realized, that using
 FT_ADVANCE_FLAG_FAST_ONLY together with FT_LOAD_TARGET_LCD causes
 FT_Get_Advance to fail always.  Removing FT_ADVANCE_FLAG_FAST_ONLY,
 makes it work but very slow.
 
 On the other hand, using FT_LOAD_NO_HINTING makes it to work really
 fast, but the computed width is not the same as the width of the
 rendered string with hinting enabled.
 
 Which makes this function almost useless in the real world... :(

Well, caching is the solution.  Additionally, in case a font has a
hdmx table, and you are in non-ClearType mode, you can use the
pre-computed advance widths for a given PPEM value.

 Well I tested it with the following code (I simplified it in order
 to be more clear).  [...]

Uh, oh, please provide a C snippet, and tell us which font you are
using.  I apologize for not being able to work with ASM.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Faster computation of text width?

[Werner LEMBERG]

 Uh, oh, please provide a C snippet, and tell us which font you are
 using.  I apologize for not being able to work with ASM.

 The cited benchmarks was made using DejaVu Sans with 16px height
 (19px line spacing)

OK.  This information already excludes a potential issue with CFF
files, cf. https://savannah.nongnu.org/bugs/?43248, which I still have
to investigate in more detail.

 About the C snippets - unfortunately, I can only read C and only if
 it is not so complex.  This way I simply can't provide C code
 snippets at all.  I can write them in Pascal, but writing everything
 from scratch only for a mailing list question is IMHO not very
 efficient.

Believe it or not, it *is* efficient.  In about three of ten cases,
people who try to provide such a snippet discover a bug in their own
code while doing so.  And if you have really found a bug, it is a
great aid to me for debugging and thus very efficient also – only a
failing snippet can *exactly* demonstrate the issue.


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] python_freetype Design: Bitmap Objects

[Werner LEMBERG]

 Renamed in git to `FT_Bitmap_Init'.
 
 Cool! Presumably you provide a #define of the old name for backward
 compatibility. :)

This won't work.  For ABI compatilibity, the `FT_Bitmap_Init' symbol
must be retained in the library, so there are now two functions that
do the same.

 what about FT_Get_X11_Font_Format
 http://freetype.org/freetype2/docs/reference/ft2-font_formats.html?
 Is it time to rename that to, say, FT_Get_Font_Format?

Done.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Faster computation of text width?

[Werner LEMBERG]

 According to the FreeType documentation, the fastest way to compute
 the width of some text string is to use FT_Get_Advance function that
 returns the advance values without loading and rendering the glyphs.

See documentation of FT_ADVANCE_FLAG_FAST_ONLY for reasons why this
can take a long time.

 But working on this task, I figured out, that using the cache
 sub-system and loading the whole images with FTC_ImageCache_Lookup
 and using the advance from the loaded image is faster than the above
 function.
 
 And faster at least 5..10 times!

Hmm.  Please provide a small snippet that demonstrates the problem.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] My experiments with FreeType cache.

[Werner LEMBERG]

 Are you aware of the FreeType demo programs?  Some of them use the
 cache.
 
 No, not actually. The only demo I read was from the tutorial, but
 it does not use the cache.  Where I can download these fine demo
 sources?

At the very place where you've found FreeType itself, e.g.

  http://download.savannah.gnu.org/releases/freetype/ft2demos-2.5.5.tar.bz2

or

  
http://sourceforge.net/projects/freetype/files/freetype-demos/2.5.5/ft2demos-2.5.5.tar.bz2/download


 Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] What is FT_PIXEL_MODE_BGRA for?

[Werner LEMBERG]

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

It's supported, AFAIK.

 I suppose it is some particular font format that supports colourful
 glyphs. Is it?

Yep.

 Where I can found a sample of such font?

Look for emoji fonts, including the ones from Android and iOS.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] References Is Not Included in the Document Tarball

[Werner LEMBERG]

 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.

Thanks for the report; the right wat to get the full documentation is
to unpack both freetype-doc and freetype:

  cd foo
  tar xzvf freetype-2.5.5.tar.gz
  tar xzvf freetype-doc-2.5.5.tar.gz

I will add a README to the freetype-doc tarball to make this clear.

However, I now see that the CSS and JavaScript stuff is missing.
Oops!  I will fix that for the next tarball, together with some other
minor improvements.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] What is FT_PIXEL_MODE_BGRA for?

[Werner LEMBERG]

 I tried to find some, but all they seems to be monochrome. 
 Can you help me with some links? 

https://github.com/behdad/color-emoji/blob/master/specification/examples/FruityGirl.ttf
http://forum.xda-developers.com/showthread.php?t=2563757

 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.

Hmm.  I've just downloaded it from 

  https://github.com/google/skia/blob/master/resources/Funkster.ttf

and it works just fine with current ftview.  At 96ppem, I get color
glyphs (and after pressing `c' I see the same in B/W).  Note that you
need to link FreeType with libpng to get coloured bitmap glyphs.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Emboldening monospaced fonts

[Werner LEMBERG]

 There are some good looking programmer fonts without bold variant
 available [1].  Makes those fonts little inconvenient for code
 editors where bold is used as highlight.  I went for
 FT_GlyphSlot_Embolden, but it breaks the monospaceness of the
 font.  Is there a way to embolden the font without breaking the
 monospaced font?

Embolden the glyph but use the original advance width.  The glyph
outline should be shifted to the left to compensate for the increased
width:

  new_left_side_bearing = left_side_bearing
  - (new_advance_width - advance_width) / 2

(or something like that).


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Freetype x86

[Werner LEMBERG]

Hello Aleksandra!


 We have come across several great Android apps that are taking
 advantage of Freetype.  As far as I found out the Freetype does
 support Android x86 platforms natively, although this option is not
 set by default.

Basically, FreeType doesn't provide special support for *any*
platform.  Or to formulate it differently, FreeType should run on
*any* platform that comes with an ANSI C compiler.  The normal
configuration for compilation of our library uses the GNU autoconf
framework, which should be able to correctly derive the used platform.
If that fails, there are various means to override the incorrect
settings.

For some platforms, FreeType provides assembler routines for
time-critical functions.  One of them is for i386, and I guess that
this assembler code works on Android x86 also.

 We would like to know if there would be an interest from your side
 and opportunity to make the x86 version the default version of
 Freetype.

Please be more specific.  What exactly are the problems?  Are there
bug reports or similar things that we can analyze?


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Working around a bad ascender value?

[Werner LEMBERG]

 I’d rather just ignore font bugs, if a font is broken, it is broken,
 and whoever made the font should just fix it.

Amen.

 [...] the Win values should be big enough to fit the largest glyph
 in fonts, and even make room for combining marks since applications
 use it for clipping, [...]

Yes!  However, many popular fonts don't follow this rule, probably for
backwards compatibility reasons since usWinXXX values are originally
based on the Win ANSI character set only.  For example, the ascender
of glyph `Aringacute' in Microsoft's `arial.ttf' exceeds the
usWinAscent value by 10%.  In other words, this glyph gets always
clipped in older Windows versions, making the top acute disappear
completely.


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] A suspicious memory leak in src/truetype/ttgload.c: tt_loader_init

[Werner LEMBERG]

 I'm porting FreeType-2.5.5 to an embedded RTOS. However, I found
 memory leak in looped `FT_Load_Char(fft-face, *text_ptr,
 FT_LOAD_RENDER)` while the memory won't leak if I set the load_flags
 ORed with FT_LOAD_NO_HINTING.
 
 So I dive into the source code and found in the tt_loader_init, the
 `size-bytecode_ready` and `size-cvt_ready` are always -1, causing
 `tt_size_ready_bytecode` run on the same `size` repeatedly. So the
 previous content of size will be leaked.

Please provide a stand-alone, compilable minimum example that exhibits
the problem.  I can then do some debugging.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Installation issue

[Werner LEMBERG]

 I am trying to compile and install freetype 2.4.0 on FreeBSD v10.1
 system

Version 2.4.0 is very old.  You might try the current release, 2.5.5.

 Viewing the requirement for GNU make, I downloaded, compiled and
 installed it.  (GNU make v4.1)

OK.

 In the /usr/local/bin dir I ran make -v and got the version
 # and info.  So I know that it exists and is working.

OK.

 Now when I cd into the freetype dir and run
 GNUMAKE=/usr/local/bin/make ./configure
 
 I am greeted with the statement
  GNUMAKE=/usr/local/bin/make command not found
 
 The shell is csh.

It seems that for the csh family you have to use `setenv' or `set'.  I
strongly suggest that you use bash or sh for running FreeType's
configure script – I'm not a csh user, and scripts are tested for sh
(and bash) only.

Of course, patches are highly welcome to support csh also (in case
there is some necessary work to do)...


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Ongoing Re: Installation issue

[Werner LEMBERG]

 so the first line: MAKE=/usr/local/bin/make ./configure doesn't
 preserve the setting.

Correct.  Setting environment variables in front of a command adjusts
the environment seen by the command itself.

Please look up an introduction into command line shells.  I'm quite
sure you will find better explanations than mine :-)


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Ongoing Re: Installation issue

[Werner LEMBERG]

 MAKE=/usr/local/bin/make ./configure ran fine

OK.

 Make did not

 # make

Well, you've explicitly selected GNU make for the `configure' script
via the `MAKE' variable.  I think it is not a big surprise to conclude
that you need GNU make for running the makefiles also :-)

Call

  /usr/local/bin/make

(within a bash or sh shell) instead of `make'.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] security vulnerabilities in freetype

[Werner LEMBERG]

 The below security vulnerabilities have been reported for freetype
 package: [...]
 
 Are these already fixed in freetype-2.5.5 release?  Please kindly
 confirm.

Please kindly read :-) All those CVE messages explicitly state `before
2.5.4'.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Re running make fails

[Werner LEMBERG]

 Hmm, this looks like a non-FreeType problem.  Can you use `libz.a'
 at all with other applications or programs?
 
 I don't know. I have been compiling and installing things like zlib,
 libjpeg, libpng, and GNU make, I haven't seen and similar complaints
 I haven't seen any other error messages from software specific to
 `libz.a'.

By default, FreeType compiles both a static and dynamic library.  I
can imagine that you have installed zlib without shared libraries –
did you by chance called `./configure --static' for zlib?  This would
disable the creation of a shared library.  However, this is just a
wild guess, since BSD systems work differently compared to GNU/Linux
boxes, which I use.

Another possibility of problems is an incorrect setup of the dynamic
linker.  For example, it might completely miss the `/usr/local/lib'
directory for finding dynamic libraries.  On my GNU/Linux box, I can
control this with having a `/usr/local/lib' line in file
`/etc/ld.so.conf', together with the `ldconfig' program to set up a
location cache for the dynamic linker.

 What does recompile with -fPIC mean? Obviously, in trial, it is
 not an option to /usr/local/bin/make (unless the syntax is wrong)

It means that the compiler needs an additional option `-fPIC'.
Normally, such options can be specified by the user in the environment
variable `CFLAGS', e.g.

  make CFLAGS='-fPIC'

On the other hand, if you build zlib with shared libraries, such
details should be handled automatically...  Adding `-fPIC' is not an
option a *user* should have to specify normally!  It's the job of the
developer (or rather the build system, i.e., the `configure' script)
to set this up correctly.


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Re running make fails

[Werner LEMBERG]

 maybe I should have included the immediately preceding line:
 
 /usr/bin/ld: /usr/local/lib/libz.a(inflate.o): relocation R_X86_64_32S
 against `zcalloc' can not be used when making a shared object;
 recompile with -fPIC
 
 to
 /usr/local/lib/libz.a: could not read symbols: Bad value
 cc: error: linker command failed with exit code 1 (use -v to see
 invocation)

Hmm, this looks like a non-FreeType problem.  Can you use `libz.a' at
all with other applications or programs?


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Gamma (?) huge difference between FreeType and others (OS X, or even FreeType based MacType)

[Werner LEMBERG]

 Now I use the same fonts to compare them again.

Thanks, however...

 Compare them side by side,
 CJK:
 https://i.imgur.com/eXOpUPN.png

... the font sizes are not identical, unfortunately.  Doing a blink
comparison of the first body text line (starting with `李') I see that
the Linux version is 1ppem smaller.  This makes it very hard to
exactly compare rendering differences.

 Latin:
 https://i.imgur.com/3huCFdq.png

The same thing.

 With the comparisons, you can clearly see the color difference
 between FreeType and other two.  By my eye, it looks like OS X and
 MacType both font rendering's color have a little bit red
 inside, or just simply say that looks more red (or purple red)
 than Linux.  Only Linux font rendering's color still looks blue.
 By color, it's because I still don't know what really called is.
 I have been searching a lot of articles about font rendering in the
 past week, but none of them can helps me out with this color
 issue.  I was thought that it probably could be Subpixel rendering
 related, but still not sure.

Your guess is right, I believe, being related to the applied subpixel
color filter.  The original one developed by Microsoft is patented
(aka. ClearType), thus not enabled on various GNU/Linux distributions,
AFAIK.  The legacy color filter that FreeType provides is rather poor,
and it seems that nobody has yet come up with a better one for X11.
[List readers: In case I'm wrong, please correct me!  And I would be
really glad if I'm wrong...]

 I'm also wondering since MacType is FreeType too, which means that
 FreeType can did the right color of the font rendering.

Maybe they simply using a better color filter.


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

[ft] Announcing FreeType version 2.6

[Werner LEMBERG]

FreeType 2.6 has been released.

It is available from

http://savannah.nongnu.org/download/freetype/

or

http://sourceforge.net/projects/freetype/files/

The latter site also holds older versions of the FreeType library.

See below for the relevant snippet from the CHANGES file.

Enjoy!


   Werner


PS: Downloads from  savannah.nongnu.org  will redirect to your nearest
mirror site.   Files on  mirrors may  be subject to  a replication
delay   of   up   to   24   hours.   In   case   of  problems  use
http://download-mirror.savannah.gnu.org/releases/


--


http://www.freetype.org


FreeType 2  is a software  font engine that  is designed to  be small,
efficient,  highly   customizable,  and  portable   while  capable  of
producing high-quality output (glyph images) of most vector and bitmap
font formats.

Note that  FreeType 2 is  a font service  and doesn't provide  APIs to
perform higher-level features, like text layout or graphics processing
(e.g.,  colored  text  rendering,  `hollowing',  etc.).   However,  it
greatly simplifies these tasks by providing a simple, easy to use, and
uniform interface to access the content of font files.

FreeType  2  is  released  under  two open-source  licenses:  our  own
BSD-like FreeType  License and the  GPL.  It can  thus be used  by any
kind of projects, be they proprietary or not.


--


CHANGES BETWEEN 2.5.5 and 2.6

  I. IMPORTANT CHANGES

- Behdad  Esfahbod contributed  code  for improved  thread-safety,
  which results in the following model.

  * An `FT_Face' object can only be safely used from one thread at
a time.

  * An `FT_Library'  object can  now be used  without modification
from multiple threads at the same time.

  * `FT_Face' creation and destruction  with the same `FT_Library'
object can only be done from one thread at a time.

  One can use a single  `FT_Library' object across threads as long
  as a mutex lock is used around `FT_New_Face' and `FT_Done_Face'.
  Any calls to `FT_Load_Glyph' and similar API are safe and do not
  need the lock  to be held as  long as the same  `FT_Face' is not
  used from multiple threads at the same time.

- Thai script support has been added to the auto-hinter.

- Arabic script support has been added to the auto-hinter.

- Following OpenType version 1.7,  advance widths and side bearing
  values in  CFFs (wrapped  in an SFNT  structure) are  now always
  taken from the `hmtx' table.

- Following OpenType  version 1.7, the  PostScript font name  of a
  CFF font (wrapped in an SFNT structure) is now always taken from
  the `name'  table.  This is  also true for  OpenType Collections
  (i.e., TTCs using  CFFs subfonts instead of TTFs),  where it may
  have a significant difference.

- Fonts natively hinted for  ClearType are now supported, properly
  handling selector index 3 of the INSTCTRL bytecode instruction.

- Major improvements to the GX TrueType variation font handling.


  II. MISCELLANEOUS

- A new auto-hinter  property `warping' can switch on  and off the
  warping code  if this  experimental feature  is compiled  in (by
  defining  the AF_CONFIG_OPTION_USE_WARPER  configuration option;
  by default  this option is  now enabled but warping  is switched
  off).

  The AF_CONFIG_OPTION_USE_WARPER option itself is an old feature,
  available   since  2006.Warping   only   works  in   `light'
  auto-hinting mode.   The idea of  the code is to  slightly scale
  and  shift a  glyph  along the  non-hinted  dimension (which  is
  usually the horizontal axis) so that as much of its segments are
  aligned  (more or  less) to  the grid.   To find  out a  glyph's
  optimal   scaling   and   shifting  value,   various   parameter
  combinations are tried and scored.

  See  file  `ftautoh.h' for  more;  the  demo programs  `ftdiff',
  `ftview', and `ftgrid' can toggle warping with key `w'.

- Some  fields  in  the  `FTC_ImageTypeRec'  structure  have  been
  changed from signed to unsigned  type, which better reflects the
  actual usage.  It is also an additional means to protect against
  malformed input.

  This  change doesn't  break  the ABI;  however,  it might  cause
  compiler warnings.

- Function `FT_Bitmap_New'  has been renamed  to `FT_Bitmap_Init',
  since  this name  better reflects  its function.   For backwards
  compatibility, the old function name is still available.

- Function   `FT_Get_X11_Font_Format'   hasbeen   renamed   to
  `FT_Get_Font_Format',  since  this   name  better  reflects  its
  function.  For backwards compatibility, the old function name is
  still available.

  Additionally, the header  

Re: [ft] Tahoma rendering differently on Freetype Windows

[Werner LEMBERG]

 Simply observing the process by which this behavior can be debugged
 is elucidating in its own right.

:-) This partially explains why I'm sometimes quite slow in answering
e-mails: Preparing a response took me a few hours, both in writing a
detailed, concise replay to your questions, and at the same time
adding the necessary tracing stuff to the B/W rasterizer, which was
still missing.

 Mounting an attempt at the bytecode certainly is tempting, though it
 may be best to leave well enough alone unless I am planning a
 professional career in this sort of thing.

Well, it's not that difficult, fortunately.

  (0a) Disassemble the font with `ttx' (I recommend to install the
   current version directly from the `fonttools' git repository).

  (0b) For debugging B/W rendering issues, FontForge works quite
   nicely – you must probably build it by yourself so that the TT
   debugger actually works.  Other, commercial font editors also
   provide TrueType debugging facilities, AFAIK.

  (0c) In general, you certainly need the TrueType instructions manual
   from the Microsoft font site :-)

  (1) Use FontForge to iterate over the glyph's bytecode instructions
  until you find the spot where the point in question is moved a
  last time along the horizontal axis.  In this case, it is moved
  twice, and we are interested in the last move caused by a
  SHPIX[] operator.  It is part of a function (which you must not
  change since other glyphs use it also); consequently, you have
  to insert the new bytecode somewhere after this function call,
  but before the final IUP[] instruction.  You should also ensure
  that the freedom vector is (1,0) – along this axis SHPIX[]
  actually works.

  (2) At the very place where you want to insert the bytecode, check
  whether there are jump instructions that jump over the code
  spot; you will have to update the offsets accordingly (IIRC,
  there aren't jump instructions in this glyph).

  (3) To restrict the change to a single ppem value (16ppem in your
  case), you need to insert code like this (this is, inserting
  into the dump produced by ttx).

MPPEM[ ]
PUSH[ ]
  16
EQ[ ]
IF[ ]
  ... here comes the new code ...
EIF[ ]

  (4) The new code is most probably another SHPIX[] call, to partially
  undo the right shift of point 25.  Assuming that a shift of
  -3/64px is sufficient, the code within the IF clause is

  PUSH[ ]
25
-3
  SHPIX[ ]

  (5) Reassemble the dump with ttx.

That's it.  Note, however, that your new Tahoma font file will not by
digitally signed (this is, the DSIG table in the font will be a dummy
version only).

 Rather than fiddle with the TTF instructions, I thought I might
 first try adding a cleaned up version of Tahoma at 16ppem into the
 original TTF as an embedded bitmap.

If you are going this route, it would be sufficient to add a bitmap
strike that holds a single bitmap for this particular glyph only...


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

[ft] Fw: [ft-devel] fitting a text

[Werner LEMBERG]

[Originally sent to the wrong list.]

Please help this guy.


Werner
---BeginMessage---
Hi,

I'm trying to draw text to a bitmap. It should fit the height of the
bitmap and the width can be extended whenever required.
Getting the width right works fine but the height is a problem: a, b, c
fit nicely but g, q and _ fall below the bottom. How can I get this to
work?
My code is:

int target_height = 50; // height of bitmap

FT_Library library;
FT_Face face;
  (void)FT_Init_FreeType(library);
  (void)FT_New_Face(library, filename.c_str(), 0, face);
  
  (void)FT_Set_Char_Size(face, target_height * 64, 0, 100, 0); /* set 
character size */
FT_GlyphSlot slot = face-glyph;
  
  w = 0;
  h = target_height;

  // calculate resulting width
  for(int n = 0; n  text.size(); n++)
  {
 if (FT_Load_Char(face, text.at(n), FT_LOAD_RENDER))
  continue;
 
 w += slot-advance.x / 64;
  }
 
  // draw text to bitmap
  image = new uint8_t[w * h];
  memset(image, 0x00, w * h);
  
  double x = 0.0;
  for(int n = 0; n  text.size(); n++)
  {
if (FT_Load_Char(face, text.at(n), FT_LOAD_RENDER))
  continue;
  
draw_bitmap(w, h, slot-bitmap, slot-bitmap_left + int(x / 
64.0), target_height - slot-bitmap_top - slot-advance.y);

x += slot-advance.x;
  }
  
  FT_Done_Face(face);
  FT_Done_FreeType(library);


draw bitmap:
// x_offset is the 'x' from the code above that gets the slot-advance.x 
added to it for every character
// x,y here just iterate from 0 to slot-bitmap.width and .height

int y_offset = target_height - slot-bitmap_top - slot-advance.y;

image[(y + y_offset) * image_width + x + x_offset] = slot-bitmap.buffer[y 
* slot-bitmap.width + x];


Folkert van Heusden

___
Freetype-devel mailing list
freetype-de...@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
---End Message---
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] A suspicious memory leak in src/truetype/ttgload.c: tt_loader_init

[Werner LEMBERG]

 I got some clue. The leak is caused by this piece of code in
 ttinterp.c: [...]

Confirmed – and fixed in git repository.  Please test.


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] How can I Minimize Heap Size in Freetype 2.6?

[Werner LEMBERG]

 I was using freetype 2.4 version in my embedded application for
 rendering ttf files only.  It uses about 12 KB heap size, when I set
 FT_RENDER_POOL_SIZE to 4096 Bytes.  But in freetype 2.6 ,it takes
 around 20 KB heap size minimum.  Here I could observe ,freetype 2.6
 doesn't use raster_pool anymore.

Yes, Behdad rewrote the B/W rasterizer code to make it thread-safe.
It is possible that due to that change a larger heap size is
necessary.

 1. What is the minimum heap size needed for freetype to rasterize
ttf files as a binary image? (I don't need smoothing and gray
shades)
 
 2. How can I minimize heap size in freetype 2.6 for this purpose?

Behdad, can you answer these two questions?


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] How to use subpixel hinting in FreeType

[Werner LEMBERG]

Sorry for the late response.

 I am a beginner at using FreeType and new to the concept of subpixel
 hinting.  I've read through most API references that seemed related,
 but I am still not sure how should I use the library to attain RGB
 (or RGBA?) bitmaps with glyphs hinted on the subpixel level.  If
 there are any examples on this I did not manage to find, please
 direct me to it.

I suggest that you look at the FreeType demo programs like `ftdiff' or
`ftview'.

 So here is what I tried doing so far: I built the library with both
 the FT_CONFIG_OPTION_SUBPIXEL_RENDERING and the
 TT_CONFIG_OPTION_SUBPIXEL_HINTING definitions. Here is my program,
 that runs without errors: http://pastebin.com/YNhgwwAN
 
 With this method, I end up with a glyph bitmap which is three times
 wider than the intended size.

This looks OK to me.

 If this is the right approach, then my question is how should I use
 this information to get an RGB bitmap with the right size?  The code
 tries to directly map the values of the result bitmap to the RGB
 channels, but this doesn't seem right:
 http://postimg.org/image/gbfdyh0b9/ The colors are obviously too
 strong.

The color filter assumes that the background is white, not black, and
yes, the colour artifacts can be quite visible.

 I guess I am doing something really wrong here, because if I try different
 sizes (for example: 31) the result will be distorted:
 http://postimg.org/image/7s28scn9j/
 I am also getting distortions like that seemingly every time, if I don't
 turn on LCD filtering.

The bitmap size is not `width*rows' but rather `pitch*rows'.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Change in monochrome rendered font behaviour from 2.5.0.1 to 2.5.1

[Werner LEMBERG]

 Specifically, the change is that monochrome rendered fonts (in small
 sizes for a low resolution display) appear noticeably worse unless
 the `FT_LOAD_FORCE_AUTOHINT` option is supplied.  It's not clear to
 me if this is a bug or an intended change in behaviour.

It's intentional.

 The following demonstrates the difference in behaviour (when viewed
 with a monospace font) with a 14 pt letter 'e' from
 `DejaVuSansCondensed-Bold.ttf`: [...]

Previously, FreeType used the auto-hinter as soon a glyph doesn't have
instructions.  However, this can cause severe problems if a hinted
font intentionally contains some unhinted glyphs that render fine at
all resolutions: If the auto-hinter jumps in, the ascender or
descender values might be completely different, causing uneven lines.
Now it checks whether there are hints at all in the font, and only if
there are none it uses the auto-hinter.

Unfortunately, the DejaVu Sans Condensed Bold font (version 2.34) is
lying: It contains both an `fpgm' and `prep' table, but not a single
glyph is hinted!

The proper solution of course is to fix the font.  The second best
solution is to set up a FontConfig rule that enforces auto-hinting for
this font.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Change in monochrome rendered font behaviour from 2.5.0.1 to 2.5.1

[Werner LEMBERG]

 It's intentional.

 Thanks for clarifying that and for your explanation. Is this covered
 in the Changelog somewhere?

No.  The feature itself was announced for 2.4.5 as

- If autohinting is not explicitly disabled, FreeType now uses the
  autohinter if a TrueType based font doesn't contain native
  hints.

and it was actually a bug that FreeType did only look at the `glyf'
table, ignoring `prep' and `fpgm'.  Since it was a rather minor bug
fix, I didn't add an entry to the `CHANGES' file.

 Unfortunately, the DejaVu Sans Condensed Bold font (version 2.34)
 is lying: It contains both an `fpgm' and `prep' table, but not a
 single glyph is hinted!

 Is there an easy way to see whether those tables exist and if there's
 no hinted glyphs?

Using ttx, you might say

  ttx foo.ttf

then open the output file `foo.ttx', search for `glyf', go to this
place, then search for `[ ]'.  If you don't get a hit, there are no
hints.

 It seems like the instructions are intentionally disabled due to
 Condensed's experimental status:
 
  
 https://github.com/dejavu-fonts/dejavu-fonts/blob/master/scripts/generate.py#L37

As James mentioned, it is a bug that they didn't remove the `fpgm' and
`prep' tables also.

 The second best solution is to set up a FontConfig rule that
 enforces auto-hinting for this font.

 From looking into this and trying it, am I correct in thinking this
 won't work with PIL/Pillow because it doesn't use fontconfig?

No idea, sorry.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Possible Bug in FT_Get_FSType_Flags

[Werner LEMBERG]

 According to FreeType document, the FT_GetFSType should return one
 of the FT_FSTYPE_XXX flag.

This is not correct.  The flags are ORed, so more than a single
FT_FSTYPE_XXX flag can be returned.  I've clarified it in the
documentation.

 But I receive a 1, which is not listed as any of those flags.

Have you tried a different font?  It might be a bug in the font
itself.

  switch(flag)

This doesn't work.  Try rather something like

  if (flag  FT_FSTYPE_INSTALLABLE_EMBEDDING)
...
  if (flag  FT_FSTYPE_RESTRICTED_LICENSE_EMBEDDING)
...
  ...


 Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Freetype x86

[Werner LEMBERG]

Hello Aleksandra,
hello J,


finally I've reached your responses while wading through my pile of
e-mails :-)

 We have been looking into the use of Freetype and the compatibility
 with x86 devices, and as you noted in your first email, it should
 run on any platform, as it creates Libs/armeabi/libfreetype.so,
 libs/armeabi-v7a/libfreetype.so or libs/x86/libfreetype.so depending
 on the APP_ABI configuration of the software developer.  Therefore
 my question would be if you provide specific scripts to developers
 using Freetype to build their library or is this the main source
 that developers use:
 http://en.wikibooks.org/wiki/OpenGL_Programming/Installation/Android_NDK#FreeType
 ?

FreeType doesn't provide such scripts.  I'm sorry to say that my
knowledge of Android device programming is zero, so I can't tell you
whether this OpenGL guide works in general.

 In that case, since the wiki-resource doesn't have any mention of
 the creation of x86 libs for the developers, would it be possible
 for you to add the instructions for developers to inform them about
 the possibility of setting their APP_ABI as APP_ABI:=all or
 APP_ABI:=armeabi-v7a x86 to create applications with x86 support?

Of course I'm willing to add information to both the FreeType
documentation and the build scripts that is necessary to make
compilation work on specific targets.  The very problem is that I'm
not the right person to write it.  I've CCed Behdad Esfahbod, a Google
developer who is actively working for Android.  Maybe he can give
advice or point to proper instructions.

Note that the OpenGL recipe given in the above link is quite specific
and probably too limiting in general.  In particular, it essentially
disables FreeType's support of color Emojis, as far as I can see (due
to the `--with-png=no' configure switch).  There is also an
intertwined dependency on the HarfBuzz library if you need good
auto-hinting support of various scripts.  Today, a generic compilation
of FreeType enabling all features needs three steps, assuming that you
start from scratch.

  1. Compile FreeType.
  2. Compile HarfBuzz (which needs FreeType).
  3. Compile FreeType again – now the configure script finds the
 HarfBuzz library and uses it unconditionally.

 It looks to me that freetype is a configure based build?

Yes.  This is what we actively use.

 I guess it's primary build required Jam
 (http://www.freetype.org/jam/)

No, it was always just an alternative way to compile FreeType.  I must
admit that support for Jam in FreeType is very weak today, since none
of the core developers use it (any more).  The `support' is mainly my
try to stay in sync with the files in the repository, but it isn't
actively tested.

 Many years ago I just made a cmake code snippet to build freetype
 for my own purposes (added at end) that makes the list of sources
 that I can add to my external 3rd party library build as
 ${FREETYPE_SOURCE}; but that's certainly far from the standard.

What I've just said about Jam essentially holds for CMake support
also: The `CMakeLists.txt' control file was contributed, and I try to
hold it in sync without using it.

 For Me, building for android was a simple as setting the toolchain
 for cmake and rebuilding everything as usual;

Good to know.  Have you used FreeType's `CMakeLists.txt'?  Right now,
it contains specific support for OS X and iOS.  Is there something to
add for Android's NDK?

 [...] but looking now Freetype is kind of a legacy product and there
 is a lot of scripts under freetype/builds but none there say
 'android' or 'arm'...  and unless one assumed android would just be
 'some unix thing that supports configure' it wouldn't really be
 clear how to build it.

Yes, I consider Android to be `some unix thing' – it's essentially a
Linux kernel, right?

By the way, looking into the `config' git repository (which holds
the newest versions of `config.guess' and `config.sub'),

  http://git.savannah.gnu.org/cgit/config.git   ,

I don't see any recent commits related to the Intel architecture, so I
conclude that the necessary Intel ABI targets for Android are already
there, and the standard

  configure; make; make install

incantation should work out of the box if you provide the necessary
cross compilation switches.  In other words, generic instructions how
to use the Android NDK for Intel should apply to the FreeType library
also.

 at least Freetype sources themselves are somewhat easily gathered
 since each 'module' has a single source that includes all related
 sources for that module instead of having to enumerate absolutely
 every source in the tree somehow.

You can also go one step further and use Vinnie Falco's FreeType
amalgamation, cf.

  https://github.com/vinniefalco/FreeTypeAmalgam

Those files are for an older FreeType version, but there's a link to
the necessary scripts to recreate it.  After doing this, you have a
single file that contains the whole FreeType library!  However, I've
never used it, so 

Re: [ft] Gamma (?) huge difference between FreeType and others (OS X, or even FreeType based MacType)

[Werner LEMBERG]

 I'm fully confused. I don't know how to say properly, because I'm
 not talking about font's darken/slightly, I'm saying, they just like
 got the different colors of the results.

 Putting them together,
 https://i.imgur.com/dpDEEzO.png
 https://i.imgur.com/EJdaCQQ.png
 
 As you can see, even the MacType got the results as same as OS X.
 Only Linux is so different.

Have a closer look at the glyph `お'.  You can clearly see that OS X
and Linux use different fonts.  Before drawing any conclusions about
the `weirdness' on Linux, you should make sure to compare the
rendering of the *same* fonts – in the same font format!  Especially
the latter can be of some importance, since CFF (.otf) and TrueType
(.ttf) are technically different and thus handled separately.


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] A suspicious memory leak in src/truetype/ttgload.c: tt_loader_init

[Werner LEMBERG]

 I got some clue. The leak is caused by this piece of code in
 ttinterp.c: [...]

 Any progress?

Not yet, but soon.  Still wading through older e-mails...


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

[ft] New FreeType release soon

[Werner LEMBERG]

Folks,


right now I'm trying to fix GX support[*], then I'm going to do a new
release, which will be 2.6.0.  This should happen within a week, I
hope.  In case you feel that something urgent should be fixed also,
please raise your voice.


Werner


[*] Behdad, it is indeed necessary to interpolate after each design
tuple.  My implementation already works quite nicely, but there
are two glitches that I have to identify and correct before
committing the code to the repository.

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Possible issue in FreeType

[Werner LEMBERG]

Hello Jose!


 Since I'm not too familiar with the package yet I have a question
 about one particular piece of code that could result in an invalid
 memory segment read or stack fault.


 Version: 2.5.5
 File src/tools/apinames.c

The good news: This file is *not* part of the FreeType library itself;
it is only used to automatically generate the export definition file
of the library (mainly for Windows), needed during compilation.
Additionally, this code is only executed if you create such a file for
the Watcom C compiler.

 In the case that the process flow executes code inside the if
 statement at line 170: if ( dot != NULL ), there is a line of
 code where dll_name points to a local variable temp which
 becomes invalid outside if block.  So in the next for loop
 dll_name variable could point to an invalid memory segment.

Thanks for the analysis; this is now corrected in the git repository.

 I really appreciate if anyone can address this question and tell me
 whether is a real issue or not since you know much better the
 package and can analyze the code deeply.

As mentioned above, it's rather harmless – and fixed :-)


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Tahoma rendering differently on Freetype Windows

[Werner LEMBERG]

Hello Lewis!


Sorry for the late reply.

 I've noticed a rendering discrepancy between Freetype and the
 Windows font engine.  I'm comparing output from Freetype 2.5.5 and
 Windows XP's native rendering.
 
 The font in question is Tahoma 12pt rendered at 96 dpi.  Note the
 bowl of the lowercase 'a' differs between the two in the attached
 image.  IMHO Freetype's rendering isn't quite as nice.
 
 I'm not sure if this qualifies as a bug, but to my eyes, it does
 seem to look wrong.  It's amazing how a one-pixel difference can
 sometimes be so immediately noticeable.

This case exhibits an example of bad hinting in Tahoma's `a' glyph,
obviously taylored to the Windows rasterizer by trial and error.
Using tahoma.ttf version 3.14, as delivered with Windows XP, the
bytecode for this glyph contains a SHPIX instruction that moves point
25 from the pixel border to the right by 0.25px if the ppem value is
in the range 14-16 (and 12pt at 96dpi is 16ppem).  Due to this
movement, the outline one pixel row below doesn't cover a pixel
center, thus drop-out mode becomes active – see the attached image.

Tahoma uses drop-out mode 5; the standard writes the following for our
case:

  If a scan line between two adjacent pixel centers (either vertical
  or horizontal) is intersected by both an on-Transition contour and
  an off-Transition contour and neither of the pixels was already
  turned on by rules 1 and 2, turn on the pixel which is closer to the
  midpoint between the on-Transition contour and off-Transition
  contour.  This is “Smart” dropout control.

Let's turn to the numbers.  I've just added tracing info for the B/W
rasterizing process to the current git version of FreeType; the data
below is from the call

  FT2_DEBUG=raster:7 ftview -m a -r 96 -e unic 12 tahoma.ttf

after pressing the `a' key in ftview to activate B/W rendering (this
needs a FreeType library compiled with debugging support).

Among other lines the tracing output shows the following:

  y=1 x=[0.043212890625;0.969482421875], drop-out=5 - x=1 (drop-out)

The B/W rasterizer internally shifts the whole outline by -0.5px both
horizontally and vertically so that the pixel centers lie on the grid.
The question now is whether to use pixel center (0,1) or (1,1).  The
value

  (0.043212890625 + 0.969482421875) / 2 = 0.50634765625

is slightly nearer to the right pixel center (value 1), thus FreeType
switches on the right pixel.

Obviously, the Windows rasterizer uses a different method to get the
outline intersection values so that the left pixel is used...

Note that it is *not* a precision problem alone: Even if I
artificially activate FreeType's `low-precision' rendering mode for
this ppem value, the right pixel will be turned on.

 If this isn't a bug, is there a way for me to 'tune' the hinting to
 match the results produced by Windows XP's native rendering?

The direct answer is: Sorry, no, there is no possibility to do that.
The indirect answer is: You might privately modify Tahoma's bytecode
so that point 25 is moved by only 0.15px to the right, say, thus
avoiding a drop-out mode case.  However, this is nothing for the
faint-hearted :-)


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] virtual box

[Werner LEMBERG]

 i have a windows 8 computer but when i download virtual box it only
 allows a 32 bit option. is there a fix

Wrong list, sorry.  We are related to the FreeType library.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Freetype x86

[Werner LEMBERG]

 Have you had time to look into the changes I have mentioned in my
 last email?

Not yet, sorry.  I'm extremely busy currently with non-computer issues
(this is, having a lot of work in my other, musical life), increasing
my pile of unread e-mails far too quick.  Please give me some days to
respond.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] WOFF2 support?

[Werner LEMBERG]

 I wonder if Google's WOFF2 will be supported by freetype in future?

Most likely.  I think especially Google is interested to have support
for that in FreeType :-)


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] CMakeLists.txt patch

[Werner LEMBERG]

Hello John!


 To ensure not built shared on Windows, which does not work
 due to lack of declspec's.  Adds versioning of shared libraries.

Thanks.  This is now applied to the git repository, with slight
modifications.

 Adds creation of freetype-config on unix.

Below you can see what I currently have.  Note that one central
variable in `freetype-config.in' is still missing: %LIBSTATIC_CONFIG%.
This exposes a weakness present in most `FindXXX.cmake' modules that
come with cmake itself: There is no support for getting the static
libraries necessary for linking.

I don't know how to handle this gracefully.

Additionally, I think it would be better if cmake doesn't generate the
script `freetype-config' but rather the pkg-config module
`freetype2.pc' (from `freetype2.in').  However, this leads to exactly
the same problem, namely getting a proper substitute for
`%REQUIRES_PRIVATE%'...


Werner


==


diff --git a/CMakeLists.txt b/CMakeLists.txt
index edcb64e..b3de1cf 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -355,6 +355,34 @@ if (HARFBUZZ_FOUND)
 endif ()
 
 
+# Create the `freetype-config' file
+if (UNIX)
+  message(STATUS
+Creating directory ${PROJECT_BINARY_DIR}/builds/unix)
+  file(MAKE_DIRECTORY ${PROJECT_BINARY_DIR}/builds/unix)
+
+  message(STATUS
+Creating file ${PROJECT_BINARY_DIR}/builds/unix/freetype-config)
+
+  file(READ ${PROJECT_SOURCE_DIR}/builds/unix/freetype-config.in
+FREETYPE_CONFIG_IN)
+  string(REPLACE %ft_version% ${SHARED_LIBRARY_VERSION}
+FREETYPE_CONFIG_IN ${FREETYPE_CONFIG_IN})
+  string(REPLACE %prefix% ${CMAKE_INSTALL_PREFIX}
+FREETYPE_CONFIG_IN ${FREETYPE_CONFIG_IN})
+  string(REPLACE %exec_prefix% ${CMAKE_INSTALL_PREFIX}
+FREETYPE_CONFIG_IN ${FREETYPE_CONFIG_IN})
+  string(REPLACE %exec_prefix_set% no
+FREETYPE_CONFIG_IN ${FREETYPE_CONFIG_IN})
+  string(REPLACE %includedir% ${CMAKE_INSTALL_PREFIX}/include
+FREETYPE_CONFIG_IN ${FREETYPE_CONFIG_IN})
+  string(REPLACE %libdir% ${CMAKE_INSTALL_PREFIX}/lib
+FREETYPE_CONFIG_IN ${FREETYPE_CONFIG_IN})
+  file(WRITE ${PROJECT_BINARY_DIR}/builds/unix/freetype-config
+${FREETYPE_CONFIG_IN})
+endif ()
+
+
 # Installations
 # Note the trailing slash in the argument to the `DIRECTORY' directive
 install(DIRECTORY ${PROJECT_SOURCE_DIR}/include/
@@ -368,6 +396,12 @@ install(FILES
   ${PROJECT_BINARY_DIR}/include/freetype/config/ftoption.h
   DESTINATION include/freetype2/freetype/config
 )
+if (UNIX)
+  install(PROGRAMS
+${PROJECT_BINARY_DIR}/builds/unix/freetype-config
+DESTINATION bin
+  )
+endif ()
 install(TARGETS freetype
   RUNTIME DESTINATION bin
   LIBRARY DESTINATION lib

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] CMakeLists.txt patch

[Werner LEMBERG]

 Below you can see what I currently have.  Note that one central
 variable in `freetype-config.in' is still missing:
 %LIBSTATIC_CONFIG%.  This exposes a weakness present in most
 `FindXXX.cmake' modules that come with cmake itself: There is no
 support for getting the static libraries necessary for linking.

 What value do you expect in LIBSTATIC_CONFIG?

Ah, a typo, I've meant LIBSSTATIC_CONFIG.  This variable should hold
all libraries necessary for statically linking FreeType.  For example,
I get the following value on my GNU/Linux box.

-lz -lbz2 -lpng12 -lz -lm -L/usr/local/lib -lharfbuzz
 ^^ 
 || |  |
  from zlib   from libpngfrom harfbuzz
  |
from bzip2

In general, the static dependency values for a library `foo' are
collected using the following methods, where the first successful one
wins; see `builds/unix/configure.raw' for details.

  (1) pkg-config --static --libs foo

  On my computer, this gives the above value.  [Note that the data
  for harfbuzz is probably incorrect; I'll check that with
  Behdad.]

  (2) foo-config --static --ldflags
  (3) AC_CHECK_LIB([foo], ...)

Unfortunately, only a handful of the available cmake modules have code
to return static dependencies, e.g., `FindBoost.cmake'.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] CMakeLists.txt patch

[Werner LEMBERG]

 [...] by static dependencies, you mean everthing else one needs on
 the link line to use the main package (freetype) built static (since
 the dependency libs are not embedded in archives like they are for
 .so's).

Exactly.

 What variable is Boost returning the dependency libs in?
 (Not seeing it looking at latest FindBoost.cmake.)

Note that I have never used `FindBoost.cmake' – I guess that the
standard return variables are used.  To enforce static return values,
it seems that you have to set the `Boost_USE_STATIC_LIBS' cmake
variable.

On the other hand, `FindPkgConfig.cmake' already returns the necessary
data for static linking (see the file itself for more on this), but
most of the packages that include this file don't make use of it.
Additionally, not all libraries provide proper .pc configuration files
for PkgConfig.

Simply do

  grep -i static *

in cmake's `Modules' directory to see how seldom this keyword is
used...


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

[ft] new `freetype-commit' mailing list

[Werner LEMBERG]

A new mailing list `freetype-commit' is available.  It track commits
to the FreeType git repositories.  Subscription can be done using the
standard ways, i.e., either via e-mail or using the web interface.

See

  http://freetype.org/contact.html

for more details how to subscribe.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Freetype2 and TimesNewRoman?

[Werner LEMBERG]

> Does Freetype2 support TimesNewRoman Font?

Certainly.

> I believe this is 'Serif'?

TimesNewRoman is indeed a serif font.  However, it depends on your
system's font setup whether, say, the HTML fallback font `serif' maps
to TimesNewRoman.

> Unfortunately when searching for Glyph information using the
> FT_Get_Char_Index function I'm getting 0 which means that the char
> index has not been found.  The character 'a' is all I am searching
> for at this stage (the char index for 'a').

This should work, of course.  So I guess there's a bug somewhere in
your code.

> If this does in fact support serif fonts then it's probably
> something I'm doing wrong and I'll eventually sort it out.

Yep :-)


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Misaki Mincho metrics issues

[Werner LEMBERG]

> Looking at EBLC data, there's only one strike available, metrics are:
> 
> ---
> Horizontal Line Metrics
>Ascender:8
>   Descender:8

This is a bug in the font, making the strike's glyph height
effectively zero (or not, see below).

> What freetype does in tt_face_load_strike_metrics():
> 
> ---
> metrics->ascender  = (FT_Char)strike[16] * 64;  /* hori.ascender  */
> metrics->descender = (FT_Char)strike[17] * 64;  /* hori.descender */
> metrics->height= metrics->ascender - metrics->descender;
> ---
>
> The question is mostly if it's reasonable to have some kind of
> workaround for that in freetype itself, like ignoring descender
> entirely in such cases or something else?

This is a good question.  First of all, there is a problem with the
specification.  It doesn't tell us whether positive or negative
`descender' values in the `sbitLineMetrics' record indicate ink below
the baseline.  Looking into the corresponding Apple specification for
the `bloc' table, I see similar fuzzy wording.

I've now taken a look into some EBLC tables of (older) fonts
distributed by Microsoft (Windows 7), and even here I find strikes
with invalid ascender and descender values all set to zero
(`calibri.ttf' version 5.62), fonts where we have positive descender
values (`cour.ttf', version 5.11), and fonts where we have negative
values (`simsun.ttf', version 5.03).  In other words, it's a complete
mess, and I came to the conclusion that we must not trust those
values.

In the git repository you can now find some heuristics to change a
positive bitmap strike descender value to a negative one (this fails
for your Misaki version since the values are too broken), and to get a
non-zero height (which always works).  Please test.


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] SourceForge repo

[Werner LEMBERG]

>> Does anyone knows what is wrong with the sourceforge repo?

It's completely out of date.  Today, I'm using this site only for
distributing FreeType tarballs.

Admittedly, the entry page `freetype.sf.net' (or
`freetype.sourceforge.net') is misleading; I have now replaced it with
a redirection to `freetype.org'.

> Try here  instead.

Exactly.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Licensing

[Werner LEMBERG]

> In terms of what act can I duplicate the Apache of this software

I don't really understand this sentence :-) Please read the two
available, mutually exclusive licenses and ask specific questions if
there are still questions.

  http://freetype.org/license.html


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

[ft] RasterInfo.ttf 1.01 released

[Werner LEMBERG]

[RasterInfo.ttf lets you inspect the properties of the used TrueType
 hinting engine.]

Due to serious bugs found in version 1.00 (the font failed to work
with the MS rasterizer if subpixel hinting was active, showing only
`E' glyphs), I've just released version 1.01.

  http://freetype.org/freetype2/docs/rasterinfo/rasterinfo.html


Enjoy!

  Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

[ft] Fw: Quick Question RE FreeType 2.6.1

[Werner LEMBERG]

--- Begin Message ---

Hello Michael!


> I obtained the software “FreeType 2.6.1” just a couple of days ago
> by downloading “freetype-2.6.1.tar.bz2” from
> “http://sourceforge.net/projects/freetype/files/” onto my Mac (I’m
> using OS X “El Capitan,” along with the absolute very latest version
> of Xcode 7 developer tool package), and I moved the unpacked
> FreeType2.6.1 directory to my “/usr/local/” directory. (I should
> mention at this point that I am about as newbie as you can get about
> this command line stuff!)

OK.  So my first advice: Don't move stuff manually to `/usr/local'!
This is a directory hierarchy where local stuff gets *installed*,
usually by `make install' or something similar.  Instead, I recommend
that you build programs and libraries in a subdirectory of your home
directory or a similar location.

> “Make: ./install-sh: No such file or directory”

This is a bug fixed already in the git repository, and you can
circumvent the issue by doing

  cd freetype-2.6.1
  ln -s builds/unix/install-sh .

> [...] could you please advise me as to when you think that an
> updated version of FreeType2.6.1 will become available to fix this
> missing “install-sh” thing?

The next version, 2.6.2, will have the fix.  I don't know when I will
release this version, but I guess this will happen within a month.


Werner
--- End Message ---
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Vertical Center Justification

[Werner LEMBERG]

> Vertical Center Justification

> We can’t figure this out!  We don’t understand how the FreeType
> engine calculates vertical centering.  Can you please give me exact
> instructions on where to place the glyph Relative to the WinAscent
> and WinDescent and Baseline to achieve perfect vertical centering?
> Or do I have it all wrong and this is a calculation that uses the
> bounding box dimensions.  Whatever it is please let me know how to
> accomplish this.

You haven't told us relative to *what* you would like to center the
icon...

Assuming that you simply want to have the glyph as an image, to be
positioned without relation to surrounding text, I would definitely
use the bounding box, since many fonts don't properly set up WinAscent
and WinDescent values.


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

[ft] Announcing ttfautohint version 1.4.1

[Werner LEMBERG]

ttfautohint 1.4.1 has been released.

The source tarball, statically-linked binaries for Win32 (TTY and GUI) and
OS X (TTY only) are available from

http://savannah.nongnu.org/download/freetype/

or

http://sourceforge.net/projects/freetype/files/ttfautohint/1.4.1

Instructions to build the GUI version on OS X can be found at

http://freetype.org/ttfautohint/osx.html


Enjoy!


   Werner


PS: Downloads from savannah.nongnu.org will redirect to your nearest
mirror site.  Files on mirrors may be subject to a replication
delay of up to 24 hours.  In case of problems use
http://download-mirror.savannah.gnu.org/releases/


--


http://freetype.org/ttfautohint

This project provides a library which takes a TrueType font as the input,
remove its bytecode instructions (if any), and return a new font where all
glyphs are bytecode hinted using the information given by FreeType's
autohinting module.  The idea is to provide the excellent quality of the
autohinter on platforms which don't use FreeType.

The library has a single API function, `TTF_autohint'; see
`lib/ttfautohint.h' for a detailed description.  Note that the library
itself won't get installed currently.

A command-line interface to the library is the `ttfautohint' program; after
compilation and installation, say

  ttfautohint --help

for usage information, or say

  man ttfautohint

to read its manual page.

A GUI to the library is `ttfautohintGUI'; it uses the Qt4 framework.  The
compilation of this application can be disabled with the `--without-qt'
configuration option.


--


Version 1.4.1 (2015-Oct-17)
---

* A bug in handling control instruction files could cause severe glyph
  shape distortions of accent-like glyphs.  All users should update.


Version 1.4 (2015-Oct-04)
-

* Support for Thai and Lao scripts.

* Support for the Arabic script.

* Better support for scripts that contain superscript-like and
  subscript-like glyphs, e.g., the International Phonetic Alphabet (IPA).

* Accents and other `non-base' glyphs are now hinted without snapping to
  blue zones.

* A new control instruction syntax form was added to adjust the mapping
  between glyphs and styles.  Right now, its usage is quite limited; a
  forthcoming version will give much more flexibility.

* The `touch` keyword in a delta instructions file was buggy: If used for a
  point `P` at a ppem value `s`, it sometimes led to unwanted movements
  of `P` for ppem values unequal to `s`, thus causing outline distortions.

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

[ft] RasterInfo.ttf

[Werner LEMBERG]

I guess you might enjoy this :-)

  http://freetype.org/freetype2/docs/rasterinfo/rasterinfo.html


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

[ft] FreeType patents page updated

[Werner LEMBERG]

In another mailing list there was a reference to

  http://david.freetype.org/cleartype-patents.html

I wasn't aware that this page exists...

Consequently, I've just updated the patents page at

  http://freetype.org/patents.html


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Vertical line spacing problems with different fonts.

[Werner LEMBERG]

> I am drawing multi line text using FreeType2.  Now,I compare my text
> position with Adobe AfterEffects built-in text.  I found that using
> standard fonts like Verdana the auto spacing looks good.  But with
> some less standard fonts like Segoe UI the second line text has a
> shift of several pixels on vertical axis.

Auto spacing?  What do you mean?

> I set the line spacing using Font metrics Height property.

What formula?

> Interesting also is that if I manually set the line spacing using
> this formula:
>
>   pen.y -= verticalSpacingInPixels /
>  ( fontSizeInPixels / FontMetrics->UnitsPerEM )
>
> then both in AfterEffects and in my app the spacing looks the same.

Then simply use this formula!

> What can it be?  May be Adobe AfterEffects calculates auto spacing
> in some unique way?  But then why does it show the same results as
> in my app for standard fonts?

I'm not sure I understand.  However, there are programs like TeX that
derive the baseline-to-baseline spacing directly from a font's point
size, completely ignoring any vertical dimensions stored in a fontc.
Maybe AfterEffects is using a similar strategy.


 Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Debian Stable Still Has Old FreeType

[Werner LEMBERG]

> I’ve just been getting to the bottom of a mysterious discrepancy in
> the metrics of a .otf font between machines running Ubuntu 14.04 and
> those running Debian (Stable 8.1 and also Unstable).

Well, I hope that the `new' behaviour is the right one :-)


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

[ft] Announcing FreeType version 2.6.1

[Werner LEMBERG]

FreeType 2.6.1 has been released.

It is available from

http://savannah.nongnu.org/download/freetype/

or

http://sourceforge.net/projects/freetype/files/

The latter site also holds older versions of the FreeType library.

See below for the relevant snippet from the CHANGES file.

Enjoy!


   Werner


PS: Downloads from  savannah.nongnu.org  will redirect to your nearest
mirror site.   Files on  mirrors may  be subject to  a replication
delay   of   up   to   24   hours.   In   case   of  problems  use
http://download-mirror.savannah.gnu.org/releases/


--


http://www.freetype.org


FreeType 2  is a software  font engine that  is designed to  be small,
efficient,  highly   customizable,  and  portable   while  capable  of
producing high-quality output (glyph images) of most vector and bitmap
font formats.

Note that  FreeType 2 is  a font service  and doesn't provide  APIs to
perform higher-level features, like text layout or graphics processing
(e.g.,  colored  text  rendering,  `hollowing',  etc.).   However,  it
greatly simplifies these tasks by providing a simple, easy to use, and
uniform interface to access the content of font files.

FreeType  2  is  released  under  two open-source  licenses:  our  own
BSD-like FreeType  License and the  GPL.  It can  thus be used  by any
kind of projects, be they proprietary or not.


--


CHANGES BETWEEN 2.6 and 2.6.1

  I. IMPORTANT BUG FIXES

- It turned  out that for CFFs  only the advance widths  should be
  taken from the  `htmx' table, not the side  bearings.  This bug,
  introduced in  version 2.6.0, makes  it necessary to  upgrade if
  you are using  CFFs; otherwise, you get cropped  glyphs with GUI
  interfaces like GTK or Qt.

- Accessing Type 42 fonts returned  incorrect results if the glyph
  order of the embedded TrueType font differs from the glyph order
  of the Type 42 charstrings table.


  II. IMPORTANT CHANGES

- The header  file layout  has been  changed (again),  moving  all
  header files except `ft2build.h' into a subdirectory tree.

  Doing so  reduces the  possibility of  header file  name clashes
  (e.g., FTGL's  `FTGlyph.h' with FreeType's `ftglyph.h')  on case
  insensitive file systems like Mac OS X or Windows.

  Applications  that  use  (a)  the  `freetype-config'  script  or
  FreeType's `freetype2.pc' file for pkg-config to get the include
  directory  for the  compiler,  and (b)  the  documented way  for
  header inclusion like

#include 
#include FT_FREETYPE_H
...

  don't need any change to the source code.

- Simple access  to named instances  in GX variation fonts  is now
  available (in addition to the  previous method via FreeType's MM
  interface).   In  the `FT_Face'  structure,  bits  16-30 of  the
  `face_index' field hold the current named instance index for the
  given face  index, and bits  16-30 of `style_flags'  contain the
  number of  instances for  the given face  index.  `FT_Open_Face'
  and friends also understand the  extended bits of the face index
  parameter.

  You need to enable  TT_CONFIG_OPTION_GX_VAR_SUPPORT for this new
  feature.  Otherwise, bits  16-30 of the two fields  are zero (or
  are ignored).

- Lao script support has been added to the auto-hinter.


  III. MISCELLANEOUS

- The auto-hinter's Arabic script support has been enhanced.

- Superscript-like and  subscript-like glyphs  as used  by various
  phonetic alphabets like the IPA  are now better supported by the
  auto-hinter.

- The TrueType bytecode interpreter now runs slightly faster.

- Improved support for builds with cmake.

- The  function  `FT_CeilFix'  now   always  rounds  towards  plus
  infinity.

- The  function  `FT_FloorFix'  now always  rounds  towards  minus
  infinity.

- A  new load  flag `FT_LOAD_COMPUTE_METRICS'  has been  added; it
  makes FreeType  ignore pre-computed  metrics, as needed  by font
  validating  or  font  editing  programs.  Right  now,  only  the
  TrueType  module supports  it  to ignore  data  from the  `hdmx'
  table.

- Another round of bug fixes  to better handle broken fonts, found
  by Kostya Serebryany .

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

[ft] Announcing ttfautohint version 1.4

[Werner LEMBERG]

ttfautohint 1.4 has been released.

The source tarball, statically-linked binaries for Win32 (TTY and GUI) and
OS X (TTY only) are available from

http://savannah.nongnu.org/download/freetype/

or

http://sourceforge.net/projects/freetype/files/ttfautohint/1.4

Instructions to build the GUI version on OS X can be found at

http://freetype.org/ttfautohint/osx.html


Enjoy!


   Werner


PS: Downloads from savannah.nongnu.org will redirect to your nearest
mirror site.  Files on mirrors may be subject to a replication
delay of up to 24 hours.  In case of problems use
http://download-mirror.savannah.gnu.org/releases/


--


http://freetype.org/ttfautohint

This project provides a library which takes a TrueType font as the input,
remove its bytecode instructions (if any), and return a new font where all
glyphs are bytecode hinted using the information given by FreeType's
autohinting module.  The idea is to provide the excellent quality of the
autohinter on platforms which don't use FreeType.

The library has a single API function, `TTF_autohint'; see
`lib/ttfautohint.h' for a detailed description.  Note that the library
itself won't get installed currently.

A command-line interface to the library is the `ttfautohint' program; after
compilation and installation, say

  ttfautohint --help

for usage information, or say

  man ttfautohint

to read its manual page.

A GUI to the library is `ttfautohintGUI'; it uses the Qt4 framework.  The
compilation of this application can be disabled with the `--without-qt'
configuration option.


--


Version 1.4 (2015-Oct-04)
-

* Support for Thai and Lao scripts.

* Support for the Arabic script.

* Better support for scripts that contain superscript-like and
  subscript-like glyphs, e.g., the International Phonetic Alphabet (IPA).

* Accents and other `non-base' glyphs are now hinted without snapping to
  blue zones.

* A new control instruction syntax form was added to adjust the mapping
  between glyphs and styles.  Right now, its usage is quite limited; a
  forthcoming version will give much more flexibility.

* The `touch` keyword in a delta instructions file was buggy: If used for a
  point `P` at a ppem value `s`, it sometimes led to unwanted movements
  of `P` for ppem values unequal to `s`, thus causing outline distortions.

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Building freetype under cygwin

[Werner LEMBERG]

> Running into some problem building freetype for Windows under
> cygwin, using mingw compiler. The problem seems to be with build
> process launching an Win32 executable, and passing Cygwin paths to
> it, resulting in:
> 
> 
> /home/alex/freetype-2.6/objs/apinames.exe \
> -o/home/alex/freetype-2.6/objs/ftexport.sym \
> /home/alex/freetype-2.6/include/freetype/ttnameid.h \
> [...]
>
> could not open '/home/alex/freetype-2.6/include/freetype/ttnameid.h'
> for writing

This is *very* strange!  Why does the `ftexport.sym' argument gets
ignored, making apinames try to write to `ttnameid.h'?

On my GNU/Linux box, this works just fine, and we've never got a error
report, and the corresponding source and Makefile code is essentially
unchanged since years...

Please try to manually call

  /home/alex/freetype-2.6/objs/apinames.exe \
  -o/home/alex/freetype-2.6/objs/ftexport.sym \
  /home/alex/freetype-2.6/include/freetype/ttnameid.h \
  /home/alex/freetype-2.6/include/freetype/freetype.h

and check whether `ftexport.sym' contains identifiers.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Building freetype under cygwin

[Werner LEMBERG]

> alex@ALEXANDERAG6A39 ~/freetype-2.6
> $ ./objs/apinames.exe \
>   -o `cygpath -w /home/alex/freetype-2.6/objs/ftexport.sym` \
>   `cygpath -w /home/alex/freetype-2.6/include/freetype/ttnameid.h` \
>   `cygpath -w /home/alex/freetype-2.6/include/freetype/freetype.h`

Aah, OK.  I've never used cygwin, so the problem isn't with `apinames'
per se, but the conversion of UNIX style file names to Windows style.

Could you work on a patch that fixes that?  The idea is to use GNU
make's powerful string substitution routines to massage the recipe in
the rule for generating $(EXPORTS_LIST) in file `exports.mk', that is,
having the following replacement.

  if we have cygwin + mingw (or whatever triggers the problem):
U2W := `cygpath -w %`
  otherwise:
U2W := %

  $(EXPORTS_LIST): $(APINAMES_EXE) $(PUBLIC_HEADERS)
  $(subst /,$(SEP),$(APINAMES_EXE)) \
  -o$(patsubst %,$(U2W),$@ $(APINAMES_OPTIONS) $(PUBLIC_HEADERS))
  @echo TT_New_Context >> $(EXPORTS_LIST)
  @echo TT_RunIns >> $(EXPORTS_LIST)

> Not to change the topic, but I’ve tried some alternative methods of
> building.  Under the same environment as above (cygwin with mingw
> toolchain), cmake seems to go further, but doesn’t seem to offer
> disabling zlib.

I've just applied some cmake patches that should take care of this.
Please test the git repository.

> Switching to msys2 shell with mingw toolchain, the build is
> finishing, but the binary ends up requiring libgcc_s_dw2-1.dll —
> passing --static-libgcc in LDFLAGS doesn’t seem to have any effect.

Hmm.  AFAIK, a user-defined LDFLAGS is passed on to libtool...  Does
libtool pass `--static-libgcc' to the gcc command line?


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Building freetype under cygwin

[Werner LEMBERG]

> Unfortunately this was the last straw, and I’m trying to get things
> going on msys2 now.  I’ll try and look at this sometime next week,
> once I’m done with my current task, if I have a moment, though.

Thanks!

> I’m attaching the output from complete ft build. It seems that while
> the flag is passed to most every command, it’s missing on [...]
 
It seems that the problem with `-static-libgcc' has an `official'
solution:

  http://www.mingw.org/wiki/HOWTO_Sneak_GCC_Switches_Past_Libtool


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] [ft-devel] [ft-announce] Announcing FreeType version 2.6.1

[Werner LEMBERG]

> When do you expect to release 2.6.2?

This weekend.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] FreeType Rasterizer/Renderer and Dropouts

[Werner LEMBERG]

Sorry for the late reply.

> The code I used to generate the image is part of a much larger
> project, but here's the general procedure I'm following.

In case you haven't yet solved the issue, please create a stand-alone,
command-line program (in C) that outputs its ASCII data to stdout, and
that demonstrates the problem.

Note that the smooth rendering engine computes correct pixel coverages
of the outlines, thus pixel dropouts can't happen.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Rendering of GD symbols

[Werner LEMBERG]

> Can FreeType font engine be used to render Geometric dimensioning
> and tolerancing symbols(wiki link:
> https://en.wikipedia.org/wiki/Geometric_dimensioning_and_tolerancing).

FreeType renders glyphs from a font, nothing else.  You have to do the
layout by yourself (or let a suitable library do that).


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

[ft] Announcing ttfautohint version 1.5

[Werner LEMBERG]

ttfautohint 1.5 has been released.

The source tarball, statically-linked binaries for Win32 (TTY and GUI) and
OS X (TTY only) are available from

http://savannah.nongnu.org/download/freetype/

or

http://sourceforge.net/projects/freetype/files/ttfautohint/1.5

Instructions to build the GUI version on OS X can be found at

http://freetype.org/ttfautohint/osx.html


Enjoy!


   Werner


PS: Downloads from savannah.nongnu.org will redirect to your nearest
mirror site.  Files on mirrors may be subject to a replication
delay of up to 24 hours.  In case of problems use
http://download-mirror.savannah.gnu.org/releases/


--


http://freetype.org/ttfautohint

This project provides a library which takes a TrueType font as the input,
remove its bytecode instructions (if any), and return a new font where all
glyphs are bytecode hinted using the information given by FreeType's
autohinting module.  The idea is to provide the excellent quality of the
autohinter on platforms which don't use FreeType.

The library has a single API function, `TTF_autohint'; see
`lib/ttfautohint.h' for a detailed description.  Note that the library
itself won't get installed currently.

A command-line interface to the library is the `ttfautohint' program; after
compilation and installation, say

  ttfautohint --help

for usage information, or say

  man ttfautohint

to read its manual page.

A GUI to the library is `ttfautohintGUI'; it uses the Qt4 framework.  The
compilation of this application can be disabled with the `--without-qt'
configuration option.


--


Version 1.5 (2016-Jan-24)
-

* Support for Khmer, Myanmar, and Bengali scripts.

* Improved Devanagari hinting.

* ttfautohintGUI can now be compiled with Qt5.

* Bug fix: Too many delta control instructions for a single glyph caused
  a bytecode stack overflow, making the MS rasterizer ignore all hinting
  instructions for this glyph.

* Bug fix: Don't create multiple `TTFA` tables in font.

* Bug fix: Under certain circumstances, glyph indices used in Indic features
  were incorrectly assigned to the default script.

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

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

[Werner LEMBERG]

>> 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 auto-hinter only.

(b) Unfortunately, it is currently unmaintained.  It's also out of
date, since I have added a large bunch of scripts.

> I have another question regarding Chinese CJK glyph maps.  When I
> try to read outlines of such a glyph the coordiantes looks weird and
> when I render the shapes (triangulating it before that) it looks
> screwed.  [...]

It seems that you are looking at a composite fonts where the subglyphs
are scaled and shifted with bytecode instructions.

> Is there a way to handle this type of maps with Freetype to get
> correct path?

Please don't use the word `map'.  It's rather called `outline data'.

We call such fonts `tricky', which you can test with the
`FT_IS_TRICKY' macro.  To get outlines of such a font that can be
processed further, you should render the glyphs with calls to
FT_Load_Glyph at the font's ppem resolution (e.g., 1024 or 2048), with
native (TrueType) hinting enabled.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Failure in loading U+033F in DejaVu fonts

[Werner LEMBERG]

> Oh, I slipped to mention a change from my patch in previous post and
> committed one.  In previous post in this list, I added a public
> function FT_List_GetNodeAt().  But, now I moved it into ttgload.c,
> as a private function.  It is just because once we publish some
> function, we cannot withdraw it.  If there is a better place to
> include the internal utility functions, I will do so.

This is just fine, thanks a lot!  In case we need the function again,
we could certainly export it.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Failure in loading U+033F in DejaVu fonts

[Werner LEMBERG]

> I updated the simplest fix in my hand.  I was going to commit it to
> head of git repository, but savannah is in some network trouble.
> Attached is the patch, but if anybody wants, I will make a "make
> dist" tarball which is ready to "./configure && make".  please let
> me know.

Savannah seems to be back, so please proceed!

> Also I have more complex patch using same strategy but do not rely
> on arbitrary usage of GID.  I think the current patch would work on
> the platforms whose default pointer is 32-bit.  For the platform
> whose default pointer is 16-bit or shorter, some fonts having 64k
> glyphs can confuse the simplest fix.

I haven't tested 16bit support since years, given that you can't
create 16bit code with gcc.[*] However, I've just found in the
internet that recent clang versions support an `-m16' option that
apparently produces valid 16bit code!  So you might test compilation
of FreeType with this option, but I guess that you will find zillions
of problems...

Today, I'm no longer sure whether 16bit support makes sense at all, so
maybe you shouldn't spend time on this.


Werner


[*] Option `-m16' introduced in gcc 4.9.0 doesn't provide a real 16bit
environment; it has a special usage for bootloader code and the
like.

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Glyph 0xBB does not load from TTF-FreeFont FreeSerif.ttf since 6.12.2

[Werner LEMBERG]

> As of version 6.12.2, a single glyph from FreeSerif.ttf (from
> http://www.nongnu.org/freefont/) cannot be loaded any more, namely
> code point 0xBB (">>", guillemotright).  [...]
>
> The error code is 0x15, "invalid composite glyph".

Thanks for the report.  Accidentally, Suzuki-san is working on a patch
that fixes this, I think.  Please stay tuned a few days, then try the
current git version.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Failure in loading U+033F in DejaVu fonts

[Werner LEMBERG]

> It seems that the changeset 758d55e522eb426dad2f15adc1d945f7896d7b29
> (between 2.6.1 and 2.6.2) is the point that FT2 starts the complain
> against DejaVu. The changset was introduced to detected looped
> reference. [...]

Thanks for your analysis.  It seems that the test to protect against
recursion is a bit too simple.

> I guess the composite glyphs referring same component twice or more
> can cause this warning. I will try to fix it...

Great! 


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Help needed

[Werner LEMBERG]

> I need to do anti aliasing in a smartwatch prototype but iam not
> able to install freetype in my computer.
> 
> Could you please tell me a way to install and use your product in
> the most simplest way since I am not a programmer.
> 
> I use windows 7. Please advice asap.

Well, FreeType *is* a programming library, and you thus have to have
some programming skills to use it.  For Windows users, there are
project files in the archive you can use for compilation with MSVC,
cf. directory `builds/windows/vc2010'.

> DISCLAIMER : The information contained in this email is confidential
> and intended only for the addressee.  [...]

Uh, oh, are you aware that you've just written to a public e-mail list
with a public e-mail archive?  I strongly suggest that you remove such
crap from your e-mails in that case.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

[ft] Announcing FreeType version 2.6.5

[Werner LEMBERG]

FreeType 2.6.5 has been released.

It is available from

http://savannah.nongnu.org/download/freetype/

or

http://sourceforge.net/projects/freetype/files/

The latter site also holds older versions of the FreeType library.

See below for the relevant snippet from the CHANGES file.

Enjoy!


   Werner


PS: Downloads from  savannah.nongnu.org  will redirect to your nearest
mirror site.   Files on  mirrors may  be subject to  a replication
delay   of   up   to   24   hours.   In   case   of  problems  use
http://download-mirror.savannah.gnu.org/releases/


--


http://www.freetype.org


FreeType 2  is a software  font engine that  is designed to  be small,
efficient,  highly   customizable,  and  portable   while  capable  of
producing high-quality output (glyph images) of most vector and bitmap
font formats.

Note that  FreeType 2 is  a font service  and doesn't provide  APIs to
perform higher-level features, like text layout or graphics processing
(e.g.,  colored  text  rendering,  `hollowing',  etc.).   However,  it
greatly simplifies these tasks by providing a simple, easy to use, and
uniform interface to access the content of font files.

FreeType  2  is  released  under  two open-source  licenses:  our  own
BSD-like FreeType  License and the  GPL.  It can  thus be used  by any
kind of projects, be they proprietary or not.


--


  I. IMPORTANT BUG FIXES

- Compilation works again  on Mac OS X (bug introduced  in version
  2.6.4).


  II. IMPORTANT CHANGES

- The new  subpixel hinting  mode is now  disabled by  default; it
  will  be enabled  by default  in the  forthcoming 2.7.x  series.
  Main reason for reverting this feature is the principle of least
  surprise: a  sudden change in  appearance of all fonts  (even if
  the rendering improves  for almost all recent  fonts) should not
  be expected in a new micro version of a series.

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Permission to use FreeType logo

[Werner LEMBERG]

> May I have permission to use the libfreetype logo in the credits of
> my project as part of a larger open source acknowledments section?

Certainly!


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

[ft] Announcing FreeType version 2.6.4

[Werner LEMBERG]

FreeType 2.6.4 has been released.

It is available from

http://savannah.nongnu.org/download/freetype/

or

http://sourceforge.net/projects/freetype/files/

The latter site also holds older versions of the FreeType library.

See below for the relevant snippet from the CHANGES file.

Enjoy!


   Werner


PS: Downloads from  savannah.nongnu.org  will redirect to your nearest
mirror site.   Files on  mirrors may  be subject to  a replication
delay   of   up   to   24   hours.   In   case   of  problems  use
http://download-mirror.savannah.gnu.org/releases/


--


http://www.freetype.org


FreeType 2  is a software  font engine that  is designed to  be small,
efficient,  highly   customizable,  and  portable   while  capable  of
producing high-quality output (glyph images) of most vector and bitmap
font formats.

Note that  FreeType 2 is  a font service  and doesn't provide  APIs to
perform higher-level features, like text layout or graphics processing
(e.g.,  colored  text  rendering,  `hollowing',  etc.).   However,  it
greatly simplifies these tasks by providing a simple, easy to use, and
uniform interface to access the content of font files.

FreeType  2  is  released  under  two open-source  licenses:  our  own
BSD-like FreeType  License and the  GPL.  It can  thus be used  by any
kind of projects, be they proprietary or not.


--


CHANGES BETWEEN 2.6.3 and 2.6.4

  I. IMPORTANT CHANGES

- A new  subpixel hinting  mode has  been contributed  by Nikolaus
  Waxweiler, which is now the  default rendering mode for TrueType
  fonts.  It implements  (almost everything of) version  40 of the
  bytecode engine.

  The existing code  base in FreeType (the  `Infinality code') was
  stripped to the bare minimum  and all configurability removed in
  the  name  of speed  and  simplicity.   The configurability  was
  mainly aimed  at legacy  fonts like Arial,  Times New  Roman, or
  Courier.  [Legacy fonts are fonts  that modify vertical stems to
  achieve clean black-and-white bitmaps.]  The new mode focuses on
  applying a minimal set of rules to all fonts indiscriminately so
  that modern and web fonts  render well while legacy fonts render
  okay.

  Activation  of the  subpixel hinting  support can  be controlled
  with   the   `TT_CONFIG_OPTION_SUBPIXEL_HINTING'   configuration
  option  at compile  time: If  set to  value 1,  you get  the old
  Infinality  mode  (which  was  never  the  default  due  to  its
  slowness).  Value 2 activates the new subpixel hinting mode, and
  value 3 activates both.  The default is value 2.

  At run time,  you can select the subpixel hinting  mode with the
  `interpreter-version'  property (provided  you have  compiled in
  the corresponding hinting mode); see `ftttdrv.h' for more.

- Support  for  the  following  scripts  has  been  added  to  the
  auto-hinter.

Armenian, Cherokee, Ethiopic, Georgian, Gujarati, Gurmukhi,
Malayalam, Sinhala, Tamil


  II. MISCELLANEOUS

- Type 42 fonts as created by LilyPond are now supported.

- Minor rendering improvments in the auto-hinter.

- For experimental  reasons, the old  CFF engine now  supports all
  CFF operators except `random', including the deprecated Multiple
  Masters  instructions.  This  allows the  display of  fonts like
  `ITCGaramondMM-It.otf' (without font variations, though).

- Another round of fixes to improve handling of invalid fonts.

- The `ftgrid' demo program now displays the rendered pixels also;
  this can be switched off with the `b' key.  Selection of various
  LCD filtering modes can be done with the `L' key.

- The demo programs  have been extended to allow  selection of all
  available TrueType bytecode engines.

- A very early beta version of a new, Qt based demo program called
  `ftinspect'  is  part  of  the   source  code  bundle;  it  will
  eventually supersede  the other  demo programs.   Currently, you
  have to compile  it manually with `qmake; make';  note that many
  features are still missing.

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Freetype Usage

[Werner LEMBERG]

>> Can you send me an HTML patch for
>> 
>>   https://www.freetype.org/developer.html
>> 
>> so that your bindings are listed also (and probably updating the
>> references to the other Python stuff)?
> 
> Sure. How’s this?

Applied, thanks!


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Freetype Usage

[Werner LEMBERG]

> I would like to know how to I use freetype in my application code,

The documentation is available online.

  https://www.freetype.org/freetype2/docs/documentation.html

> I want to render chinese characters on display.  Please can you
> guide me how do I use this freetype library.

Please read the above documentation carefully; there's also a tutorial
with some code samples.  If you still have questions, please come
back.  Note that we *don't* write code for you.


Werner


PS: You might probably want to use a higher-level library like
HarfBuzz or ICU in case you are going to handle more complicated
scripts like Indic ones.

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Freetype Usage

[Werner LEMBERG]

> [...] have a look at my set of Python bindings for the main parts of
> the Linux typography stack:

Can you send me an HTML patch for

  https://www.freetype.org/developer.html

so that your bindings are listed also (and probably updating the
references to the other Python stuff)?


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

[ft] FreeType & GSoC

[Werner LEMBERG]

This year, FreeType wants to participate GSoC (Google Summer of Code).

Here is our idea list.

  https://www.freetype.org/gsoc.html

Please comment!  And please spread the news :-)


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] BWIP-JS and Ionic 2

[Werner LEMBERG]

> Is there any sort of support for Ionic 2 and Angular 2 with this
> library?

Not here on this list, sorry.  I hear those terms the first time.

Are you sure that you are using the FreeType library in its original
form?  Maybe you are using the output of emscripten...


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Troubleshoot while running configure script on freetype-2.4.12.tar.bz2 and freetype-2.7.tar.gz

[Werner LEMBERG]

> When I run the configure script after extracting the files of the
> .tar.gz file, I have the next messages:
> 
>   awk: symbol lookup error: awk: undefined symbol: mpfr_z_sub
>   awk: symbol lookup error: awk: undefined symbol: mpfr_z_sub

This message doesn't come from FreeType!  It's probably related to the
GNU MPFR library, which FreeType doesn't use.

> Generating `Makefile'
>   /home/user/Downloads/Altera/freetype-2.7/Makefile:7: *** Too many open
> files.  Stop.

This is not sufficient information.  The normal way to build FreeType
on GNU/Linux systems like Ubuntu is

  cd freetype-2.7
  ./configure [options]
  make

where `[options]' should be added as needed.  All configuration
options can be seen by calling

  ./configure --help

After running `configure' (and before executing `make'), you should
closely inspect the console output and/or the file
`builds/unix/config.log' for problems.

Somehow you aren't following the normal setup, I guess.  You need GNU
make, BTW, but this should be the default on Ubuntu anyway, I guess.

> I need a file named ".libs" that should appear in the ."../objs/"
> directory after running the configure and making scripts.

`.libs' is not a file, it's a directory!


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Emboldening and then hinting a glyph with FreeType

[Werner LEMBERG]

> I'm a one of the developers of free open source CoolReader3 branch
> for E-Ink reader devices and I have a question.  CR3 is based on
> FreeType2 lib.  I have added emboldening font functionality to CR3,
> since E-Ink devices seem to need some font emboldening due to the
> low contrast of E-Ink screens.

The current release of FreeType supports stem darkening for the
auto-hinter.  Have you tried it?

> So, my question is: is there a way to embolden a glyph first and
> then "hint" it with FT_LOAD_TARGET_NORMAL, HINTING_MODE_AUTOHINT or
> FT_LOAD_TARGET_LIGHT, so that I could get an emboldened and THEN
> hinted glyph before using FT_Render_Glyph()? I have searched the
> Documentation and forums, but was not able to find the answer.

This is not possible (yet).  Stem darkening (this is what you really
want, I guess) is available for CFF and the auto-hinter, but not for
TrueType.


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Emboldening and then hinting a glyph with FreeType

[Werner LEMBERG]

> Is there any other possibility to "hint" transformed glyphs? For
> example, by calling hinting function directly or something like
> that?

Well, the TrueType hinting mechanism is tightly bound to the outline
and its rasterization to the grid depending on the selected PPEM.
Basically, it is *not* possible to apply TrueType hints after a
transformation while yielding sensible results.  Nikolaus tries to
replace the horizontal hinting with horizontal emboldening (note the
word `replace'), but even this is quite a complicated issue; right
now, he is stuck.

> Also I have noticed that proper scaling could help to improve font
> displaying dramatically. If x-height is aligned to pixel grid, the
> result looks much like "light hinting" even without hinting at all.

Indeed, this is what the light hinter mainly does: it scales the
glyphs vertically so that the x height gets aligned to the grid, then
it shifts the outlines so that horizontal tangents lie on the grid
also (if possible and sensible).

> I appreciate any thoughts and advice on this.

I fear that I can't give much advice here.[*]


Werner


[*] I assume that you know that FreeType produces *coverage* bitmaps,
this is, you have apply proper alpha blending and gamma
correction.

  
https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_Render_Glyph
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

[ft] FreeType is part of GSoC 2017

[Werner LEMBERG]

FreeType is part of Google Summer of Code 2017!

  https://www.freetype.org/gsoc.html


Werner

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] mactype and vac bann

[Werner LEMBERG]

> can this softtware cause VAC bann?

I don't think so.  FreeType is a library to render fonts...

> ..im reading in some article that this software is using "hook to
> the program" method, and usually VAC detects this method as a
> attempt for cheating @.@...so can you guys confirm this?

This is the first time I hear the term `VAC', so: no.  No idea what
`hook to the program' means in this context.  There are no CVEs for
the current release of FreeType, AFAIK – such a vulnerability might be
the only possibility to inject code into steam (besides bad
programming on the steam side, of course).


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] not work

[Werner LEMBERG]

> Good afternoon, colleagues!  Do not display correctly insert
> elements in TextMaker rev.757; In Microsoft offices displayed
> correctly.

Maksim,


there is a long way from a PDF to its rasterization on screen.  If I
open your MS Office document with LibreOffice on my GNU/Linux box, the
acronym `TIC' is displayed just fine (LibreOffice 5.1.3.2, current git
version of FreeType).

It thus seems that there is a problem with TextMaker, so I suggest
that you contact its authors and report the problem there.  If you are
*sure* that it is a font issue, please come back and show us the
offending font – and tell us the FreeType version you are using.


Werner
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

[ft] Announcing FreeType version 2.7

[Werner LEMBERG]

FreeType 2.7 has been released.

It is available from

http://savannah.nongnu.org/download/freetype/

or

http://sourceforge.net/projects/freetype/files/

The latter site also holds older versions of the FreeType library.

See below for the relevant snippet from the CHANGES file.

Enjoy!


   Werner


PS: Downloads from  savannah.nongnu.org  will redirect to your nearest
mirror site.   Files on  mirrors may  be subject to  a replication
delay   of   up   to   24   hours.   In   case   of  problems  use
http://download-mirror.savannah.gnu.org/releases/


--


http://www.freetype.org


FreeType 2  is a software  font engine that  is designed to  be small,
efficient,  highly   customizable,  and  portable   while  capable  of
producing high-quality output (glyph images) of most vector and bitmap
font formats.

Note that  FreeType 2 is  a font service  and doesn't provide  APIs to
perform higher-level features, like text layout or graphics processing
(e.g.,  colored  text  rendering,  `hollowing',  etc.).   However,  it
greatly simplifies these tasks by providing a simple, easy to use, and
uniform interface to access the content of font files.

FreeType  2  is  released  under  two open-source  licenses:  our  own
BSD-like FreeType  License and the  GPL.  It can  thus be used  by any
kind of projects, be they proprietary or not.


--



CHANGES BETWEEN 2.6.5 and 2.7

  I. IMPORTANT CHANGES

- As announced earlier, the 2.7.x series now uses the new subpixel
  hinting  mode as  the  default, emulating  a  modern version  of
  ClearType.

  This change inevitably leads to different rendering results, and
  you   might   change   the   `TT_CONFIG_OPTION_SUBPIXEL_HINTING'
  configuration option to  adapt it to your taste (or  use the new
  `FREETYPE_PROPERTIES'environmentvariable).

- A new option  `FT_CONFIG_OPTION_ENVIRONMENT_PROPERTIES' has been
  introduced.   If  set (which  is  the  default), an  environment
  variable  `FREETYPE_PROPERTIES' can  be used  to control  driver
  properties.  Example:

FREETYPE_PROPERTIES=truetype:interpreter-version=35 \
cff:no-stem-darkening=1 \
autofitter:warping=1

  This allows to select, say, the subpixel hinting mode at runtime
  for a given application.  See file `ftoption.h' for more.


  II. IMPORTANT BUG FIXES

- After  loading a  named instance  of  a GX  variation font,  the
  `face_index'  value  in  the returned  `FT_Face'  structure  now
  correctly holds the named instance  index in the upper 16bits as
  documented.


  III. MISCELLANEOUS

- A new macro `FT_IS_NAMED_INSTANCE' to  test whether a given face
  is a named instance.

- More fixes to GX font handling.

- Apple's   `GETVARIATION'  bytecode   operator  (needed   for  GX
  variation font support) has been implemented.

- Another round  of fuzzer fixes,  mainly to reject  invalid fonts
  faster.

- Handling of raw CID fonts  was broken (bug introduced in version
  2.6.4).

- The smooth rasterizer has been streamlined  to make it faster by
  approx. 20%.

- The `ftgrid'  demo program now  understands command  line option
  `-d' to give start-up design coordinates.

- The `ftdump' demo program has  a new command line option `-p' to
  dump TrueType bytecode instructions.

___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype