Re: [Inquiry] Auto-fit on monochrome output

[Lawrence D'Oliveiro]

On Wed, 8 Nov 2023 16:27:03 +0800, Jm Moon wrote:

> ahh it's on the very legacy display, which is monochrome at 72dpi
> we have no choice but to find out what can be done to improve the
> appearance

Hand-tuned bitmap fonts.

Re: Font Rendering: Multiple FT_Faces and baselines

[Lawrence D'Oliveiro]

On Thu, 20 Jul 2023 01:03:54 +, takase1121 via FreeType users wrote:

> ... calculate an "average" baseline and align to that ...

Or align to the midpoints of the overall font glyph boxes (including
font ascent and font descent). That may be a suitable compromise.

Re: Freetype Linux problem with 64 bit program.

[Lawrence D'Oliveiro]

On Mon, 10 Jul 2023 14:04:19 +, Jain, Ankit wrote:

> The information contained in this message is proprietary and/or
> confidential.

Just a note that, no it isn’t.

Re: [FT_Get_Postscript_Name] Get the corresponding platform ID and language ID

[Lawrence D'Oliveiro]

On Fri, 16 Jun 2023 18:47:45 -0400, Moi15 Moi wrote:

> Is there a way to know what is the platform ID and the language ID of
> the postscript name given by FT_Get_Postscript_Name
> 
>  ?

I didn’t think PostScript font names had any dependency on platform and
language. They have to be used in PostScript code, after all.

Re: Variable Font and FT_Load_Sfnt_Table

[Lawrence D'Oliveiro]

On Wed, 10 May 2023 01:58:24 +, Rajeev Pahuja via FreeType users
wrote:

> If variable font is set using FT_Set_Var_Design_Coordinates(ftFace,
> ... ) or FT_Set_Named_Instance(ftFace, ...) and then call to
> FT_Load_Sfnt_Table(ftFace,...) is made, does it return table data
> specific to variation set on ftFace or whole data of variable font ?

As I understand it, table contents don’t change because of changes in
variation/MM settings.

Re: Need Help!!Getting Different glyph_locations in freetype 2.0.9 and 2.10.0

[Lawrence D'Oliveiro]

On Wed, 26 Apr 2023 15:36:38 +, Jain, Ankit wrote:

> Can somebody help me in getting those old values with new freetype
> or some other suggestion.

I think your life would be a lot easier if you stopped making
assumptions about the internal implementation of FreeType.

> The information contained in this message is proprietary and/or
> confidential.

No it isn’t.

Re: Need Help!!Getting Different glyph_locations in freetype 2.0.9 and 2.10.0

[Lawrence D'Oliveiro]

On Wed, 26 Apr 2023 13:15:39 +, Jain, Ankit wrote:

> ... we are using these location
> to write the data in post script file as post script has limitation
> in writing the number of bytes ...

Do you have to write PostScript files? How are these being consumed? By
a printer? By another graphics app? There may be a way to avoid
PostScript.

Re: [External] Re: Halo Glyphs generation query

[Lawrence D'Oliveiro]

On Fri, 18 Nov 2022 02:25:45 +, Boppe, Balakrishna (D COE) wrote:

> I am not able to access "
> https://www.deviantart.com/default-cube/art/Text-Effect-566875799;
> 
> I get this error!
> 403 ERROR
> The request could not be satisfied.

Maybe try it from a regular Internet connection?

Re: Halo Glyphs generation query

[Lawrence D'Oliveiro]

On Thu, 17 Nov 2022 15:27:45 +, Boppe, Balakrishna (D COE) wrote:

> Can someone please help or provide any guidance on how to get halo
> effect around each glyph generated by Freetype .

Something like this
,
perhaps?

Re: Error in make process

[Lawrence D'Oliveiro]

On Fri, 8 Jul 2022 19:16:25 +0800, 贾慧阳 wrote:

> cannot find -lpng15

libpng-dev not installed?

Re: [External] Re: Query on Generation of halo around glyphs.

[Lawrence D'Oliveiro]

On Thu, 23 Jun 2022 04:45:16 +, Boppe, Balakrishna (D COE) wrote:

> I am looking for something where I can generate the halo at run time
> and not at the design time(offline).

Run the code at your “run time” (whatever that means), it’s your choice.

Re: Query on Generation of halo around glyphs.

[Lawrence D'Oliveiro]

On Thu, 23 Jun 2022 03:29:27 +, Boppe, Balakrishna (D COE) wrote:

> Using freetype APIs, any recommendation on how to generate halo, of a
> given width, around each glyph, using Freetype APIs ?

Use Pixman, perhaps
.

Re: [External] Re: Kerning information related query.

[Lawrence D'Oliveiro]

On Wed, 15 Jun 2022 03:49:36 +, Boppe, Balakrishna (D COE) wrote:

> For some reason, the link provided below is not opening for me.
> 
> HarfBuzz
> 

Re: Kerning information related query.

[Lawrence D'Oliveiro]

On Tue, 14 Jun 2022 13:10:50 +, Boppe, Balakrishna (D COE) wrote:

> I would like to use the kerning information(offline) to perform the
> rendering of text(run time)

HarfBuzz  does all
this for you, and more.

Re: How does freetype get the "right" family name

[Lawrence D'Oliveiro]

On Thu, 26 May 2022 15:53:13 -0400, Moi15 Moi wrote:

> I am trying to understand how does freetype determine what is the
> "right" family name.

Is this code helpful? (From the routine sfnt_load_face in
src/sfnt/sfobjs.c):

face->root.family_name = NULL;
face->root.style_name  = NULL;
if ( face->os2.version != 0xU && face->os2.fsSelection & 256 )
{
  if ( !ignore_typographic_family )
GET_NAME( TYPOGRAPHIC_FAMILY, >root.family_name );
  if ( !face->root.family_name )
GET_NAME( FONT_FAMILY, >root.family_name );

  if ( !ignore_typographic_subfamily )
GET_NAME( TYPOGRAPHIC_SUBFAMILY, >root.style_name );
  if ( !face->root.style_name )
GET_NAME( FONT_SUBFAMILY, >root.style_name );
}
else
{
  GET_NAME( WWS_FAMILY, >root.family_name );
  if ( !face->root.family_name && !ignore_typographic_family )
GET_NAME( TYPOGRAPHIC_FAMILY, >root.family_name );
  if ( !face->root.family_name )
GET_NAME( FONT_FAMILY, >root.family_name );

  GET_NAME( WWS_SUBFAMILY, >root.style_name );
  if ( !face->root.style_name && !ignore_typographic_subfamily )
GET_NAME( TYPOGRAPHIC_SUBFAMILY, >root.style_name );
  if ( !face->root.style_name )
GET_NAME( FONT_SUBFAMILY, >root.style_name );
}

Re: Proper way of rotating glyphs

[Lawrence D'Oliveiro]

On Fri, 06 May 2022 13:37:01 +0300, Василий Троцкий via FreeType users
wrote:

> Now i am using FreeType library to fill texture atlas with font
> glyphs in order to render strings as a sprites with texture from
> atlas.

Easier to use a proper graphics library, like Cairo, to manage all this.

Re: glyph diagram

[Lawrence D'Oliveiro]

On Fri, 29 Apr 2022 15:47:17 + (UTC), Werner LEMBERG wrote:

> Could you contribute SVG images of the two graphics to
> FreeType?

OK, I have changed the output format of my script to SVG (Cairo seems
to do a good job of SVG output, at least in this case), and split out
the two diagrams into separate files. Output and script enclosed.

Let me know if this is suitable or not.
<>

Re: glyph diagram

[Lawrence D'Oliveiro]

On Thu, 28 Apr 2022 22:24:32 +0200, Dave via FreeType users wrote:

> Do you know where I might find a 600 dpi version of the freetype
> glyph metrics?

Presumably you mean the diagrams here
.

How does the enclosed look? It was generated with a Python script I
threw together this afternoon. Currently it exactly mimics the layout of
the original diagrams (using the Noto Serif font), which may not be the
best ;). I can generate it at any resolution you like.

Re: Trouble installing with make on Ubuntu 20.04 (WSL 2), /bin/sh: 2: ./configure: not found

[Lawrence D'Oliveiro]

On Wed, 24 Nov 2021 20:28:45 +, Naphat Amundsen wrote:

> cd builds/unix; \
> ./configure
> /bin/sh: 2: ./configure: not found
> make: *** [builds/unix/detect.mk:91: setup] Error 127

If you look at the development tree
,
builds/unix/configure does not exist, looks like it must be generated
from configure.raw. This needs to be done by autogen.sh
.

Normally I think you are supposed to build a production installation
from a distribution tarball, not the original development tree (leave
that for the FreeType developers themselves).

Re: Glyph bitmap is 3x too big?

[Lawrence D'Oliveiro]

On Mon, 25 Oct 2021 22:52:54 +0200, Andy wrote:

> I do example from madig's tutorial.
> Both metod, first FT_Get_Char_Index/FT_Load_Glyph/FT_Render_Glyph
> second: FT_Load_Char
> next I FT_Bitmap draw on wxWidgets image and next wxWidgets DC/
> GIve me bitmap for wisth 3 letters instead one and below thrashed
> letters, like
> https://i.imgur.com/eJQwx9c.png

Bitmap depth mismatch?

Re: [External] Aw: Re: Re: Re: Re: Native TTF name sometimes contains crap

[Lawrence D'Oliveiro]

On Mon, 25 Oct 2021 07:32:07 +, Boppe, Balakrishna (D COE) wrote:

> We want to create fonts using  pixelsize of the order of 14, which
> would eventually be displayed on DPI 114 display device.

If you want a font hand-tuned to look good at just one size, make it a
bitmap font.

Re: Incompatible versions of libfreetype.6.dylib

[Lawrence D'Oliveiro]

On Tue, 19 Oct 2021 00:56:01 -0400, Samuel Dupree wrote:

> I'm running Python 3.8.8 under the Anaconda distribution ver.
> custom on a Mac Pro (2019) desktop running Mac OSX ver. 11.6.
> 
> I'm getting the following error message:
> 
> ...
>    Reason: Incompatible library version:
> ft2font.cpython-38-darwin.so 
> requires version 24.0.0 or later, but libfreetype.6.dylib provides
> version 23.0.0

Looks like you are mixing incompatible third-party versions of software
with vendor-provided ones? Not a recipe for happiness...

Re: render 3 glyphes into the one buffer

[Lawrence D'Oliveiro]

On Tue, 03 Aug 2021 17:02:36 +0700, Vitaliy Fadeev wrote:

> Lawrence D'Oliveiro, say, please: Cairo preallocate one big bitmap,
> then render each char into the one preallocated bitmap, or Cairo
> render each glyph and then do copy bitmap into the surface ?

It has a built-in caching system, so you don’t have to worry about
details like this.

> Lawrence D'Oliveiro, say, please, how Cairo render text when available
> OpenGL/GPU ?

I believe it has a rendering back-end to take advantage of that.

Re: render 3 glyphes into the one buffer

[Lawrence D'Oliveiro]

On Tue, 03 Aug 2021 15:15:39 +0700, Vitaliy Fadeev wrote:

> Question 1: Possible to render glyphs directly into te one big bitmap
> ?

This is what higher-level graphics libraries like Cairo
 do for you. Using such a library is
easier than trying to figure it out how to reinvent it for yourself.

Re: Compiling freetype without make and cmake

[Lawrence D'Oliveiro]

On Tue, 29 Jun 2021 06:36:43 -0700, honey wrote:

>However, PlatformIO uses its own build system, which won’t play
> nice with make and cmake.

Note that CMake isn’t actually a build system, it’s a wrapper around
other build systems. Think of it more as a “meta-build” system. It
generates GNU Makefiles on Linux-type systems, and Visual Studio and
XCode IDE projects on Microsoft and Apple platforms.

In short, it should in principle be possible to create a CMake backend
that drives whatever platform-specific build system you have here.

Re: FreeType ANDROID ndk installation

[Lawrence D'Oliveiro]

On Fri, 21 May 2021 15:36:01 +0200, GoldSpark wrote:

> For 2 days now I am trying to get your library to work with android
> ndk project. I absolutely have no idea how to make it work.

Maybe you are better off sticking with Android’s built-in
text/graphics-rendering APIs.

Re: how update the website for the complex layout

[Lawrence D'Oliveiro]

On Wed, 19 May 2021 14:04:34 -0700, Harold Hallikainen wrote:

> And in my application (cinema subtitles) a UTF-8 string is passed in
> with an output of horizontal or vertical text. There are XML
> attributes to the Text element that indicate the direction (left to
> right, top down, right to left, or bidirectional (using the Unicode
> Bidirectional Algorithm). Each Text element includes one line (or
> column) of text, so line breaks are handled during authoring
> (creation of the XML subtitle file).

That should be a piece of cake to lay out with HarfBuzz.

Re: how update the website for the complex layout

[Lawrence D'Oliveiro]

On Wed, 19 May 2021 04:58:08 + (UTC), Werner LEMBERG wrote:

> HarfBuzz is a text shaping library; it is not meant to actually do
> text layout.

Do you mean it is lacking things like recognizing word breaks and line
breaks? Because it can lay out a line of text pretty well.

Re: Font files and vertical text

[Lawrence D'Oliveiro]

On Sun, 16 May 2021 11:05:46 -0700, Harold Hallikainen wrote:

> 1. On most systems, the vertical position of the column of text is
> based on the top, bottom, or center of the bounding box for the
> rendered column of text. I think it SHOULD be based on the vertical
> origin of the first character, vertical origin + advance height of
> the bottom character, or the center of these two points.

I remember, a long time ago, back in about the time of Aldus (not yet
Adobe) PageMaker, a comment I read somewhere that CJK text rendering is
best thought of as happening on a grid of character cells, not in terms
of font metrics, fixed-width or otherwise.

Not sure if that helps ...

Re: how update the website for the complex layout

[Lawrence D'Oliveiro]

On Sun, 16 May 2021 21:30:25 +0900, suzuki toshiya wrote:

> BTW, I wonder whether current last answer referring Pango should be
> improved by referring HarfBuzz. Yes, Pango is still essential part of
> GTK+, but HarfBuzz is becoming more general framework broader than
> GTK+. How do you feel?

Myself, I’ve never used Pango. I managed to do Python wrappers
for FreeType, Cairo, HarfBuzz and FriBidi, but never got as far as
Pango ;). In other words, I don’t feel qualified to offer any opinion
on it.

By the way, following up Werner’s suggestion about mentioning ICU, and
idly looking through packages in the standard Debian repo, I came
across libicu-le-hb , where Behdad
has stripped out the shaping engine from libicu and replaced it with
HarfBuzz.

Re: [Freetype] Font files and vertical text

[Lawrence D'Oliveiro]

OK, how about this as a starting point:

Q: How do I render a line of text in FreeType?
A: FreeType is a very low-level rendering engine. All it knows how to
do is render individual glyphs and return metrics for them.

Arranging glyphs into words and lines is best left to a more complete
2D graphics rendering library, like Cairo
. Cairo also does very basic
translation of Unicode character codes to glyphs; for a more general
solution, add HarfBuzz
, which implements
the full OpenType rules for glyph substitution and placement (Cairo
still handles the actual text drawing). To deal with right-to-left
(Arabic, Hebrew) text layout, you will also need FriBidi
, which handles the details of the
Unicode bidirectional layout algorithm.

And finally, to cope with additional niceties like dealing with
writing-system-specific rules for word breaks and line breaks, you
might like to look at ICU , which includes
a whole range of internationalization and localization facilities.

[Is it worth mentioning Fontconfig
 as well, do you
think? As a solution for font matching?]

Re: how update the website for the complex layout

[Lawrence D'Oliveiro]

On Sun, 16 May 2021 17:31:17 +0900, suzuki toshiya wrote:

> Yet I don't have a good answer to a person saying "I don't care
> the right-to-left scripts, or the complex glyph shaping like various
> Indic scripts, I understand they need very complicated technology.
> But I just want the support for CJK vertical writing mode, it should
> be possible that raw FT2 supports it?

The kind of people who need to ask this sort of question are precisely
the sort who would not be able to figure out the details that layers
like HarfBuzz and Cairo already deal with for them.

> The dependency chain before
> HarfBuzz, like X11, pixman, cairo, glib, C++, etc etc are too long
> for me!"

Reimplementing these functions for themselves would take even longer.

Re: [Freetype] Font files and vertical text

[Lawrence D'Oliveiro]

On Sun, 16 May 2021 08:06:23 + (UTC), Werner LEMBERG wrote:

> On Sun, 16 May 2021 20:00:20 +1200, Lawrence D'Oliveiro wrote:
>> 
>> You want me to submit an item for the FAQ along the lines of “How do
>> I do advanced/language-specific text layout?”?
> 
> Mhmm, this too, but I have thought of something quite at the top level
> to really, really scare people away from inventing the wheel again,
> underestimating the many difficulties that come with good typesetting.

Yeah, but that’s a bit beyond my level of expertise. I’m the kind of
person who thinks HarfBuzz already does a pretty good job ;).

>> I can mention Fribidi for bidirectional arrangement, HarfBuzz for
>> shaping/placement/substitution, and Cairo for actual rendering.
>> Anything else along those lines anybody wants to see covered?  
> 
> This looks very promising, thanks!  Maybe it makes sense to mention
> ICU also.

I’ve never used that, though. The ones I mentioned are the ones I’ve
used.

Re: [Freetype] Font files and vertical text

[Lawrence D'Oliveiro]

On Sun, 16 May 2021 07:35:04 + (UTC), Werner LEMBERG wrote:

> On Sat, 15 May 2021 18:45:55 +1200, Lawrence D'Oliveiro wrote:
>> 
>> Too many times I see questions on this list from people trying to do
>> complicated font rendering directly in FreeType, when they should be
>> using higher-level rendering/shaping engines like Cairo, HarfBuzz
>> and Fribidi. They should be saving themselves some work.  
> 
> Can you suggest or provide a documentation fix for the web page that
> guides people into the right direction?

You want me to submit an item for the FAQ along the lines of “How do I
do advanced/language-specific text layout?”? Sure, I can do that.

I can mention Fribidi for bidirectional arrangement, HarfBuzz for
shaping/placement/substitution, and Cairo for actual rendering.
Anything else along those lines anybody wants to see covered?

Re: [Freetype] Font files and vertical text

[Lawrence D'Oliveiro]

On Sat, 15 May 2021 15:16:25 +0900, suzuki toshiya wrote:

> The modern applications trying to support the
> CJK vertical writing mode use more complicated frameworks, like
> HarfBuzz.

Too many times I see questions on this list from people trying to do
complicated font rendering directly in FreeType, when they should be
using higher-level rendering/shaping engines like Cairo, HarfBuzz and
Fribidi. They should be saving themselves some work.

Re: Does Freetype work best with gamma 2.2, and how does it interact with KDE gamma setting?

[Lawrence D'Oliveiro]

On Tue, 04 May 2021 10:00:05 +0200, Allan Sandfeld Jensen wrote:

> Freetype doesn't interact with gamma on its own.

I would hope that would be true of all rendering engines, e.g.
FreeType, Cairo, Blender Cycles etc. Gamma and colour profiling are
issues for on-screen display, image input and image storage/interchange
formats. And in the latter, one would expect that this information can
be stored non-destructively, i.e. without having to alter stored pixel
values.

Rendering calculations are easiest if pixels are considered to be in
a linear colour space.

Re: OTF font containing multiple faces

[Lawrence D'Oliveiro]

On Thu, 15 Apr 2021 09:57:18 +0200 (CEST), Werner LEMBERG wrote:

> > FT_Open_Face takes a face_index value, can anyone point me to an OTF
> > font that contains more than one face  
> 
> Look at the Noto CJK fonts, for example
> 
>   NotoSerifCJK-Regular.ttc
> 
> Inspite of having the extension `.ttc`, those fonts are CFF
> collections.  The above font has four faces:
> 
>   Noto Serif CJK JP   (Japanese)
>   Noto Serif CJK KR   (Korean)
>   Noto Serif CJK SC   (Simplified Chinese)
>   Noto Serif CJK TC   (Traditional Chinese)

ldo@theon:~> file /usr/share/fonts/opentype/noto/NotoSerifCJK-Regular.ttc
/usr/share/fonts/opentype/noto/NotoSerifCJK-Regular.ttc: OpenType font 
collection data, 1.0, 4 fonts, at 0x1c OpenType Font data, 15 tables, 1st "BASE"
ldo@theon:~> file /usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc
/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc: OpenType font 
collection data, 1.0, 10 fonts, at 0x34 OpenType Font data, 16 tables, 1st 
"BASE"

Re: emoji colorized gyphs

[Lawrence D'Oliveiro]

On Tue, 6 Apr 2021 09:03:08 +0200, Anthony Rouaux wrote:

> 1\ Can you point me to a public font file that you used to do your 
> implementation of that feature?

Google’s Noto Color Emoji font is one I have used.

> 2\ Do you have an simple example of code that I could use as a
> starting point.

Here’s one
,
which produced this output:
.

> I am probably not 
> using the correct FT_xxx function and this leads to a segmentation
> fault when I tried to decode the font file.

It is really easier to use higher-level libraries like HarfBuzz and
Cairo, which is what I did.

Re: How can use freetype to render Mongolia font?

[Lawrence D'Oliveiro]

On Sun, 17 Jan 2021 11:21:35 +0800, Xuefeng Mu wrote:

> can't render Mongolia font, or where is my fault?

Let me suggest that you make things easier for yourself by using a
text-shaping library like HarfBuzz
.

Re: Is font rendering sharper under Wayland?

[Lawrence D'Oliveiro]

On Thu, 31 Dec 2020 23:22:38 +0100, Allan Sandfeld Jensen wrote:

> On Donnerstag, 31. Dezember 2020 05:23:53 CET Lawrence D'Oliveiro
> wrote:
>
>> That sharpness comes at the expense of distortion. Hinting is all
>> about hacking the shapes of glyphs to fit the pixel grid -- for
>> example, getting rid of subtle curves and slants. Anti-aliasing
>> gives you a way of representing these.
>
> Yeah, but one pixel at 100% opacity looks a whole lot better than 2
> pixel at 50% opacity (or whatever opacity you get after gamma
> correction).

“Better” may not be better if you lose the original artist’s design.
Typography is an art, after all.

It’s all a tradeoff. Which is why it doesn’t make sense to use both
together.

Re: Is font rendering sharper under Wayland?

[Lawrence D'Oliveiro]

On Thu, 31 Dec 2020 12:18:27 +0900, Tatsuyuki Ishi wrote:

>> On Thu, 31 Dec 2020 15:26:43 +1300, Lawrence D'Oliveiro wrote:
>
>> Surely antialiasing makes hinting unnecessary.
> 
> It doesn't. "Antialiasing makes hinting unnecessary" is simply wrong
> as a general statement: hinting definitely makes a difference and
> improves clarity at lower scaling factors like 125%. Try comparing a
> 1px stem snapped to pixel grid and another centered on the boundary
> of a pixel; there's no way the latter would look as sharp as the
> former.

That sharpness comes at the expense of distortion. Hinting is all about
hacking the shapes of glyphs to fit the pixel grid -- for example,
getting rid of subtle curves and slants. Anti-aliasing gives you a way
of representing these.

Re: Is font rendering sharper under Wayland?

[Lawrence D'Oliveiro]

On Thu, 31 Dec 2020 10:28:07 +0900, Tatsuyuki Ishi wrote:

> Wayland fractional scaling works by asking applications to
> render at a larger, integer scaling factor (e.g. 200% when asking for
> 150%), and then scaling that down by the compositor. It breaks hinting
> and introduces even more antialiasing artifacts, so I've found it
> practically unusable.

Surely antialiasing makes hinting unnecessary.

Re: Is font rendering sharper under Wayland?

[Lawrence D'Oliveiro]

On Wed, 30 Dec 2020 23:31:26 +, Richard L wrote:

> I have recently switched to Wayland on my desktop (KDE Plasma) and
> think I have noticed that text is rendered sharper under Wayland.

As I understand it, Wayland basically does as little as possible. While
X11 implements a whole graphics protocol (even including a font server
at one point), Wayland leaves all that up to the client. All it wants is
buffers of pixels for it to composite together to make up the screen
display.

Re: Issue rendering fonts with fixed sizes

[Lawrence D'Oliveiro]

On Wed, 25 Nov 2020 17:05:38 -0800, step...@unity3d.com wrote:

> I am currently testing with the NotoColorEmoji.ttf font.

I just did some rendering with this exact same font.

> // Setting the pixel size returns no error since 109 is a size
> supported by this font.
> 
> m_Error = FT_Set_Pixel_Sizes(m_Face, 109, 109);

Try FT_Select_Size with an index into the available-sizes table
instead. Since Noto Color Emoji only comes in one size, an index of 0
should work.

In my example
, I
found it easier to use a graphics engine like Cairo to take care of the
font-sizing headaches for me.

The output from that program can be seen here
.

Re: Getting victory hands symbol from Wingdings

[Lawrence D'Oliveiro]

On Wed, 19 Aug 2020 12:16:06 +0200, Andreas Falkenhahn wrote:

> But I guess then I don't even have to look for a fix because it's
> impossible to synthesize a Unicode charmap for Wingdings/Webdings
> because, as you said, it's not really possible because the codepoints
> in MS Symbol don't seem to be unique.

If you are only dealing with that one specific font, you don’t need to
depend on any charmap, you could load the glyph by its index directly.

Re: Initial pen position in freetype?

[Lawrence D'Oliveiro]

On Mon, 20 Jul 2020 19:22:01 +1000, Andrew Tomazos wrote:

> What I mean by "pen" is the FT_Vector translation vector that is
> passed to FT_Set_Transform before each call to FT_Load_Glyph as each
> glyph is rendered.

That’s not meant to be used as a “pen”.

Re: Initial pen position in freetype?

[Lawrence D'Oliveiro]

On Mon, 20 Jul 2020 17:31:25 +1000, Andrew Tomazos wrote:

> But my question is, how do you set the initial pen position of the
> first character, relative to the upper left bound of the drawing
> surface?

FreeType has no pen. That is a function of the graphics engine that
uses FreeType for text rendering.

Re: looking for support

[Lawrence D'Oliveiro]

On Thu, 26 Mar 2020 17:31:42 +0800, 羡世 wrote:

> Can you tell me libfreetype how to make fonts bold, slanted,
> underlined.

Better to use a full 2D graphics library that makes use of FreeType,
e.g. Cairo .

Re: [ft] Linking against freetype in Linux

[Lawrence D'Oliveiro]

On Thu, 27 Jun 2019 16:36:26 +0100, Kris wrote:

> On 26/06/2019 22:59, Lawrence D'Oliveiro wrote:
>> 
>> Just for fun, would you like to try a simple Python script?
>> 
>>  import ctypes as ct
>>  ft = ct.cdll.LoadLibrary("libfreetype.so.6")
>>  hasattr(ft, "FT_Init_FreeType")
>> 
>> prints out
>> 
>>  True
>> 
>> on my system.  
> 
> Doesn't print anything on mine.

Sorry, make that last line

print(hasattr(ft, "FT_Init_FreeType"))

That’s what happens when you only test things in Jupyter notebooks. ;)

> These lines DON'T report "ENOENT (No such file or directory)", so
> with that plus the results of the Python script, suggest that the
> linker is opening the libfreetype.so file OK, but then failing to
> find the symbol within it!

Except the ENOENT meant it wasn’t opening the library file OK, because
the path was wrong.

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

Re: [ft] Linking against freetype in Linux

[Lawrence D'Oliveiro]

On Wed, 26 Jun 2019 22:28:19 +0100, Kris wrote:

> 16892 stat("/usr/lib/gcc/x86_64-linux-gnu/8/libfreetype.so", 
> 0x7ffeecb07830) = -1 ENOENT (No such file or directory)

Why is that "/8/” in the path? That’s not where it is on my Debian
Unstable system:

ldo@theon:~> ls -l /usr/lib/x86_64-linux-gnu/libfreetype.* 
-rw-r--r-- 1 root root 1055516 Nov 22 2018 
/usr/lib/x86_64-linux-gnu/libfreetype.a
lrwxrwxrwx 1 root root  21 Nov 22 2018 
/usr/lib/x86_64-linux-gnu/libfreetype.so -> libfreetype.so.6.16.1
lrwxrwxrwx 1 root root  21 Nov 22 2018 
/usr/lib/x86_64-linux-gnu/libfreetype.so.6 -> libfreetype.so.6.16.1
-rw-r--r-- 1 root root  763816 Nov 22 2018 
/usr/lib/x86_64-linux-gnu/libfreetype.so.6.16.1

The unversioned symlink (and .a file) comes from the -dev package, while
the actual versioned library comes from the runtime package.

Just for fun, would you like to try a simple Python script?

import ctypes as ct
ft = ct.cdll.LoadLibrary("libfreetype.so.6")
hasattr(ft, "FT_Init_FreeType")

prints out

True

on my system.

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

Re: [ft] Linking against freetype in Linux

[Lawrence D'Oliveiro]

On Wed, 26 Jun 2019 11:12:45 +0100, Kris wrote:

> g++ `pkg-config freetype2 --cflags --libs` test.cpp

This works for me (Debian Unstable). Output was

Initialised OK!

> I'm not sure what to try next. Does anyone have any suggestions?

Try compiling it as C, rather than C++ code? (Both worked for me, by
the way.)

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

Re: [ft] Arabic text (was Re: _sprintf already defined)

[Lawrence D'Oliveiro]

On Thu, 13 Jun 2019 15:19:11 +0100, Tim Orton wrote:

> How do I render Arabic text?

You need the Unicode bidirectional layout algorithm. This is
implemented in FriBidi , and that may be
enough for simple text needs -- namely, those that can be rendered
using the standard Unicode Arabic “presentation forms”.

For more high-quality work, you will need a text-shaping library that
understands OpenType glyph substitution/placement rules. Like HarfBuzz
.

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

Re: [ft] Fw: Could you help me for debugging FreeType library?

[Lawrence D'Oliveiro]

On Fri, 3 May 2019 03:00:25 +, suzuki toshiya wrote:

> BTW, does cmake have any hardwired database for
> the available flags for each compilers? I can check
> for gcc and clang, but I'm not sure about other
> proprietary compilers...

I thought most C compilers supported at least some small core of
GCC-compatible flags, including “-g” for generating debugging symbols
and “-D” for defining preprocessor symbols that can be queried in the
code. Plus of course the usual ones for specifying library and include
paths. You can do a lot with just these.

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

Re: [ft] Fw: Could you help me for debugging FreeType library?

[Lawrence D'Oliveiro]

On Fri, 3 May 2019 02:11:30 +, suzuki toshiya wrote:

> It seems that cmake experts have left FreeType, so I try to respond
> you although I'm not an expert.

I’ve done a little bit of messing about with CMake. While
CMAKE_BUILD_TYPE is a standard variable
, I
think its meaning is mostly up to the build scripts. For example, in
the Blender source tree, you see things like
:

if (NOT CMAKE_BUILD_TYPE MATCHES "Release")
... set various compiler flags ...
endif()

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

Re: [ft] freetype demos

[Lawrence D'Oliveiro]

On Sat, 13 Apr 2019 00:11:25 +, Dryden, Thomas wrote:

> Does anyone know an easy method for converting a freetype demo to use
> FT_Set_Pixel_Sizes() instead of FT_Set_Char_Size()?

I guess you have to find the nearest entry matching your desired size
in the font’s available_sizes.

The following Python code from my font_chart example
 doesn’t choose the
right size, it just picks the first available one. But it at least
shows you the right API calls:

if len(show_face.available_sizes) != 0 :
# fixme: quick hack for bitmap fonts
sys.stderr.write("available_sizes = %s\n" % 
repr(show_face.available_sizes)) # debug
use_size = show_face.available_sizes[0]
show_face.set_pixel_sizes(use_size["x_ppem"], use_size["y_ppem"])
else :
show_face.set_char_size(size = textsize, resolution = freetype.base_dpi)
#end if

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

Re: [ft] FT_Load_Glyph() slow?

[Lawrence D'Oliveiro]

On Wed, 10 Apr 2019 18:48:59 +, Dryden, Thomas wrote:

> Is there a specific caching layer that is recommended for FreeType?

This is usually left to the graphics engine. I like to use Cairo
 for 2D work.

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

Re: [ft] FT_Load_Glyph() slow?

[Lawrence D'Oliveiro]

On Tue, 9 Apr 2019 23:39:56 +, Dryden, Thomas wrote:

> ... surprised to find that FT_Load_Glyph() was taking 500ns.

FT_Load_Glyph is where the glyph rendering takes place. Does that
surprise you? This is why there needs to be a separate caching layer on
top.

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

Re: [ft] get all glyphs

[Lawrence D'Oliveiro]

On Mon, 8 Apr 2019 20:55:37 +, Dryden, Thomas wrote:

> I'm attempting to extract all glyphs from a TTF in order to create a
> table of each glyph's width.

If you want to get all glyphs, then just call FT_Load_Glyph for every
index in the range from 1 up to num_glyphs - 1 inclusive. That will
return a nonzero status for any glyph it fails to load, but that
shouldn’t happen.

On Mon, 8 Apr 2019 22:48:41 +, Dryden, Thomas wrote:

> The only problem is, I also need to
> know the character code. I don't know how to get the character code.

Unicode, you mean? You can iterate through the
character-code-to-glyph-index mapping with
FT_Get_First_Char/FT_Get_Next_Char.

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

Re: [ft] [EXTERNAL] RE: get all glyphs

[Lawrence D'Oliveiro]

On Mon, 8 Apr 2019 22:48:41 +, Dryden, Thomas wrote:

> I did try FT_Load_Glyph as well. The only problem is, I also need to
> know the character code. I don't know how to get the character code
> from the slot??

You might be interested in one or two of these examples
, such as the one that
produces a font chart.

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

Re: [ft] Why is FT_F26Dot6 defined as a signed long

[Lawrence D'Oliveiro]

On Thu, 14 Feb 2019 11:58:09 -0800, Wink Saville wrote:

> Interesting, but on a 32bit platform, with long == 32 bits, that
> wouldn't work.

There is this thing called “LP64” versus “LLP64”, for describing code
generation on 64-bit architectures. GCC (and I think all the other
compilers that work on Linux) is “LP64”, which means that “long” and
pointers are both 64 bits. On Windows, it seems “LLP64” is the norm,
where “long” is 32 bits and you need to say “long long” to get 64 bits.

C99 introduced the stdint.h include file, which gives explicit names to
you can use to request particular sizes of integers, to avoid this
discrepancy.

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

Re: [ft] What does the following mean?

[Lawrence D'Oliveiro]

On Thu, 14 Feb 2019 01:46:34 +, Dryden, Thomas wrote:

> My second question below is with regards to handling comma, and
> parenthesis. Looking at the metrics, it's not clear to me how to
> detect that they need to be pushed up 3 pixels. The comma has a
> positive horizontal bearing Y, which surprised me??

The appearance and metrics are very much up to the font designer. They
adjust and position things in order to make the overall layout look good
in lines of text. If you try to second-guess them with your own glyph
adjustments, you are just likely to make things look worse.

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

Re: [ft] What does the following mean?

[Lawrence D'Oliveiro]

On Thu, 14 Feb 2019 00:14:55 +, Dryden, Thomas wrote:

> "26.6 fractional pixel format"? How do I convert this to pixels?
> Divide by 26.6?

The meaning is that the bottom 6 bits are the fractional part. So to
convert to a float, for example, divide by 2**6 = 64.

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

Re: [ft] Problems when rendering some fonts

[Lawrence D'Oliveiro]

On Mon, 11 Feb 2019 16:15:14 -, ar...@hasitzka.com wrote:

> If you feel somewhat comfortable with C, you could try to write a tiny
> program that loads + renders the failing characters (in whatever
> order) from the font files in question, using FreeType directly.

You could use a Python FreeType binding, like
,
.

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

Re: [ft] FT layout

[Lawrence D'Oliveiro]

On Sun, 14 Oct 2018 03:12:18 +, sylvain.bertr...@gmail.com wrote:

> What's happening to the FT layout lib?

Why not just use HarfBuzz?

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

Re: [ft] Optimizing ft_adobe_glyph_list

[Lawrence D'Oliveiro]

On Fri, 12 Oct 2018 09:12:25 +0300, Povilas Kanapickas wrote:

> All of the above increase the complexity and size of the retrieval
> function.

For what it’s worth, on modern cache-intensive architectures, you can
often get a net speedup by writing more complex code that does fewer
memory accesses.

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

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

On Fri, 11 May 2018 10:03:26 +0900, suzuki toshiya wrote:

> ... the maintainer cannot introduce the change breaking
> the backward compatibility ...

Which is why I suggested a change that would *not* break backward
incompatibility. Whatever code that might actually exist that checks for
an error code can continue to do so.

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

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

On Thu, 10 May 2018 00:55:42 +0200 (CEST), Werner LEMBERG wrote:

> On Thu, 10 May 2018 10:29:11 +1200, Lawrence D'Oliveiro wrote:
>>
>> On Wed, 09 May 2018 14:11:19 +0200 (CEST), Werner LEMBERG wrote:
>>>
>>> IMHO, `FT_Done_Face' shouldn't return an error code
>>> at all.  
>> 
>> Glad you finally agree. So how to fix it?  
> 
> IMHO, there is nothing to fix.
> 
>> * For backward compability, it should continue to return
>> FT_Err_Ok.  
> 
> It should return what it already returns.

But it returns an error code. But above you said it “shouldn’t return
an error code at all”. So here you saying it *should* return an error
code.

Could you please clarify what you mean? Otherwise it’s going to be very
difficult conducting a coherent conversation with you.

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

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

On Wed, 09 May 2018 14:11:19 +0200 (CEST), Werner LEMBERG wrote:

> IMHO, `FT_Done_Face' shouldn't return an error code
> at all.

Glad you finally agree. So how to fix it?

* For backward compability, it should continue to return FT_Err_Ok.
* So what should the code do if the FT_List_Find call returns NULL?
  I think it should print a message to stderr and abort the program.

Ignoring the internal consistency failure is not really a good idea. It
is very likely an indication that memory blocks are screwed. So if the
code just tries to keep going, it could hit a segfault later on, or
otherwise behave unpredictably. And then the programmer is left
scratching their head as to what went wrong. By reporting the problem
as close as possible to the point of its discovery, you maximize the
chance that it can be found and fixed.

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

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

On Mon, 07 May 2018 09:55:51 +0200 (CEST), Werner LEMBERG wrote:

> Again, this is a hypothetical, bad example.  No need actually to discuss this
> further :-)

So what would you consider to be a GOOD example of checking for an
error from FT_Done_Face?

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

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

On Mon, 07 May 2018 09:01:34 +0200 (CEST), Werner LEMBERG wrote:

> With `trusting' I mean that the code controls `FT_New_Face'.  For
> example, a plug-in provided by the user might call `FT_New_Face',
> delegating the deallocation to the program core.  In this case the
> program core cannot trust that the user module always does the right
> thing.

You mean, the caller is expected to call FT_New_Face, then pass
ownership of the object to the intermediate layer, which then makes use
of it and has the responsibility of calling FT_Done_Face?

If the intermediate layer is not expecting a NULL pointer, then an
error on FT_Done_Face would seem to be the least of your problems.

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

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

On Mon, 07 May 2018 08:18:35 +0200 (CEST), Werner LEMBERG wrote:

> On Mon, 7 May 2018 17:48:17 +1200, Lawrence D'Oliveiro wrote:
>>
>> NULL should be perfectly valid -- it simply indicates the object was
>> never allocated.  
> 
> Well, yes – if you trust the source.

Does FreeType “trust its source”?

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

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

On Mon, 07 May 2018 07:33:16 +0200 (CEST), Werner LEMBERG wrote:

> You would only check the return value of `FT_Done_Face' if your code
> gets an `FT_Face' handle that it doesn't manage by itself (rather
> unlikely, but who knows).  In this situation it could happen that the
> handle is NULL, and this should be reported back – not because
> `FT_Done_Face' can't handle value NULL but the fact that it has
> received such a handle, which indicates a problem in the calling
> program.

NULL should be perfectly valid -- it simply indicates the object
was never allocated.

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

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

On Mon, 7 May 2018 14:34:26 +0900, suzuki toshiya wrote:

> Thus, making FreeType abort immediately by a bad
> font, it can make some environment quite inconvenient.

I’m not sure where you get such an idea from...

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

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

On Sun, 6 May 2018 23:33:16 +0200, Gregor Mückl wrote:

> On 5/6/2018 10:54 PM, Lawrence D'Oliveiro wrote:
>
>> In the process of recovering from the error in disposing of the
>> first one, do you try to dispose of the second one?  
> 
> This could potentially happen ...

I know it can “potentially happen” -- that’s why I asked.

Your wonderfully elaborate and complicated, not to say fragile,
error-recovery system cannot cope with it, can it?

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

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

On Mon, 07 May 2018 06:55:27 +0200 (CEST), Werner LEMBERG wrote:

> You only get an error code if `FT_Done_Face' is called with an
> invalid handle, something which doesn't happen in a normal FreeType
> workflow.

What are you supposed to do when it does happen?

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

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

On Sun, 6 May 2018 22:07:53 +0200, Gregor Mückl wrote:

> On 5/6/2018 9:56 PM, Lawrence D'Oliveiro wrote:
>
>> On Sun, 6 May 2018 09:47:19 +0200, Gregor Mückl wrote:
>>>
>>> Also, on the way up to the exception handler in main(), stack
>>> unwinding causes destructors of various objects to be called. That
>>> way, RAII patterns in my code get executed: resources are freed,
>>> files are closed (writing buffered file contents to disk) etc.  
>
>> What happens if you have another FT_Face to dispose of?  
> 
> Why would that matter? I cannot see the relevance to the topic.

In the process of recovering from the error in disposing of the first
one, do you try to dispose of the second one?

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

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

On Sun, 6 May 2018 09:47:19 +0200, Gregor Mückl wrote:

> The important part here is that the constructor of gltb::Error
> records the actual runtime callstack of where it was executed, that
> is, how the throw statement was reached in the exection flow of the
> program. And its asFormattedText method turns it into a readable
> string. In various cases, I have dumped this string onto the console
> (as in the example above), shown this in a Windows message box (no
> console there) and written it into a log file that a user can locate
> in the file system and send to me.
> 
> Also, on the way up to the exception handler in main(), stack
> unwinding causes destructors of various objects to be called. That
> way, RAII patterns in my code get executed: resources are freed,
> files are closed (writing buffered file contents to disk) etc.

What happens if you have another FT_Face to dispose of?

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

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

On Sun, 6 May 2018 09:47:19 +0200, Gregor Mückl wrote:

>   if(FT_Done_Face(face != 0) {

You got to be kidding me.

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

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

On Sun, 6 May 2018 00:11:12 +0200, Gregor Mückl wrote:

> Just don't assume that you know better than the creator of the host 
> program when it is okay to bail and how to do so.

As the provider of the lower-level abstraction, you guarantee certain
invariants. In this case, that every FT_Face has a driver, and the
driver has knowledge of that FT_Face as long as it exists.

If that invariant breaks, there’s nothing that the caller can
reasonably do about it, because it’s none of the caller’s business.

That’s what “abstraction” means.

> This is highly dependent on the actual purpose of the program ...

In that case, perhaps you could show us an example or two of how you
deal with error returns from FT_Done_Face?

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

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

On Sat, 05 May 2018 20:10:43 +0200 (CEST), Werner LEMBERG wrote:

> I agree with Gregor: A library should not call `exit' by itself.

What else is it supposed to do? Lots of code is already ignoring the
result from FT_Done_Face.

Exhibit A: HarfBuzz
:

static void
_hb_ft_face_destroy (FT_Face ft_face)
{
  FT_Done_Face (ft_face);
}

Exhibit B: Fontconfig
, which
also ignoring the result from FC_Done_FreeType:

static FcBool
FcFileScanFontConfig (FcFontSet *set,
  FcBlanks  *blanks,
  const FcChar8 *file,
  FcConfig  *config)
{
...
FT_Done_Face (face);
...

FT_Done_FreeType (ftLibrary);

return ret;
}

Another pair of examples from Fontconfig
:

FcPattern *
FcFreeTypeQuery(const FcChar8   *file,
int id,
FcBlanks*blanks,
int *count)
{
...

FT_Done_Face (face);
bail:
FT_Done_FreeType (ftLibrary);
return pat;
}

Exhibit C: libraqm
 (one of
3 instances):

static void
_raqm_free_text_info (raqm_t *rq)
{
  if (!rq->text_info)
return;

  for (size_t i = 0; i < rq->text_len; i++)
  {
if (rq->text_info[i].ftface)
  FT_Done_Face (rq->text_info[i].ftface);
  }

  free (rq->text_info);
  rq->text_info = NULL;
}

Is all this code wrong?

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

Re: [ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

On Sat, 5 May 2018 19:49:30 +0200, Gregor Mückl wrote:

> Please don't create another library that blindly terminates its host 
> program on a whim.

s/whim/internal consistency failure/

> Returning an error really is the right thing to do 
> here. Just make it clear that this is a bad error.

And what exactly is the caller supposed to do about it?

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

[ft] FT_Done_Face Should Not Return An Error

[Lawrence D'Oliveiro]

It is common for object-disposal routines to never return error
statuses. The archetypal example is free(3)
. If this is passed a valid pointer,
it disposes of the object; if it is passed NULL, it quietly returns
without doing anything. If it is passed an invalid pointer, then this
indicates a program bug, so there is no point returning an error code
anyway: better to report an error message to stderr and even abort the
program.

Looking at the code for FT_Done_Face, from src/base/ftobjs.c:

  FT_EXPORT_DEF( FT_Error )
  FT_Done_Face( FT_Face  face )
  {
FT_Error error;
FT_Driverdriver;
FT_Memorymemory;
FT_ListNode  node;


error = FT_ERR( Invalid_Face_Handle );
if ( face && face->driver )
{
  face->internal->refcount--;
  if ( face->internal->refcount > 0 )
error = FT_Err_Ok;
  else
  {
driver = face->driver;
memory = driver->root.memory;

/* find face in driver's list */
node = FT_List_Find( >faces_list, face );
if ( node )
{
  /* remove face object from the driver's list */
  FT_List_Remove( >faces_list, node );
  FT_FREE( node );

  /* now destroy the object proper */
  destroy_face( memory, face, driver );
  error = FT_Err_Ok;
}
  }
}

return error;
  }

the only thing that can really go wrong is if the face cannot be
found among the driver’s memory blocks. Clearly something has gone
catastrophically wrong in this case, so it makes sense to report an
error and abort the program.

Otherwise, if it is passed NULL, it should just quietly return without
doing anything. This makes it easier to write code that initializes all
temporary pointers up front and unconditionally disposes them at the
end; there is no need to tediously check everything for NULL pointers,
because the disposal routines will take care of that.

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

Re: [ft] Off by one error in freetype (or in programmer?)

[Lawrence D'Oliveiro]

On Fri, 06 Apr 2018 08:40:03 +0200 (CEST), Werner LEMBERG wrote:

> Of course there will be stair-stepping!  Just have a look into the
> additional documentation files that accompany the old TrueType
> specification (both Apple and MS versions).  You'll see rectangles
> everywhere talking about B/W rasterization.

I know, I used Macs in those days. Most of them still had only
one-bit-per-pixel screens, and people didn’t really know any better.

> A graphics system might apply filters to display such bitmaps on
> screens, but this is not covered by the TT specification.

If you are going to be filtering out frequencies above the Nyquist
limit (antialiasing), then a rectangular shape is the wrong thing to
start from, since you have already thrown away even harmonics below the
limit.

You start from a dimensionless point, i.e. an “ideally-sampled” pixel.

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

Re: [ft] Off by one error in freetype (or in programmer?)

[Lawrence D'Oliveiro]

On Fri, 06 Apr 2018 07:15:56 +0200 (CEST), Werner LEMBERG wrote:

>>> In TrueType, for example, all glyphs are shifted by (-1/2,-1/2)
>>> internally to align pixel centers with the grid.  
>> 
>>   
> 
> Nice, but completely irrelevant.  For the conversion of font outlines
> to pixmaps or graymaps, pixels *are* rectangles, both by definition
> and construction.

That cannot be true. The edges of the rectangles would give rise to
aliasing, aka stair-stepping.



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

Re: [ft] Off by one error in freetype (or in programmer?)

[Lawrence D'Oliveiro]

On Thu, 05 Apr 2018 13:08:40 +0200 (CEST), Werner LEMBERG wrote:

> Yes.  Pixels *do* have dimensions :-)
> 
> In TrueType, for example, all glyphs are shifted by (-1/2,-1/2)
> internally to align pixel centers with the grid.



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

Re: [ft] Question about porting source code to C#

[Lawrence D'Oliveiro]

On Fri, 26 Jan 2018 22:40:22 +0300, Александр Струняшев wrote:

> Unfortunately for our project we could use only managed code. And
> that means that current implementation is not really fit our needs.
> We are thinking about porting C++ code to C#.

If you fork the code, then all the maintenance burden for the fork
falls on you. As future feature enhancements and bug fixes (including
security problems!) come along, you will have to do all the work of
recreating them in your fork.

Are you ready to commit to such a thing? Or will your product fall
further behind over time, vis-à-vis the original thing?

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

Re: [ft] Font Writing

[Lawrence D'Oliveiro]

On Wed, 24 Jan 2018 19:57:56 +, Shawn Riordan wrote:

> Can Freetype write a font to a file?

That’s a job for font-authoring tools.

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

Re: [ft] libfreetype/autohint feature

[Lawrence D'Oliveiro]

On Mon, 18 Dec 2017 19:44:24 -0500, westlake wrote:

> So my question is, is there a way I can completely disable
> auto-hinting?

Then you don’t want to use a font-rendering engine like FreeType at
all. Just get the glyph geometry as paths and scan-convert them using a
graphics engine like Cairo.

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

Re: [ft] Render differences on embedded ARM vs other platforms

[Lawrence D'Oliveiro]

On Wed, 29 Nov 2017 23:44:32 +, Wessman, Tim (HP Calculators) wrote:

> Could this be some sort of a floating point rounding behavior issue?
> (hw float on the ARM rounding differently than hw/sw on the other
> systems for example)

Not likely. Everything is IEEE-754-conformant these days.

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

Re: [ft] The fastest way to query size of a rendered bitmap

[Lawrence D'Oliveiro]

On Fri, 15 Sep 2017 20:30:02 +0300, Daniel Plakhotich wrote:

> But I'm a bit confused by The FreeType Tutorial (II. Managing
> Glyphs: 4. Simple Text Rendering: Kerning and Centering), which says:
> 
>> In general, the above function does not compute an exact bounding
>> box of a string! As soon as hinting is involved, glyph dimensions
>> must be derived from the resulting outlines. For anti-aliased
>> pixmaps, FT_Outline_Get_BBox then yields proper results. In case
>> you need 1-bit monochrome bitmaps, it is even necessary to actually
>> render the glyphs because the rules for the conversion from outline
>> to bitmap can also be controlled by hinting instructions.  
> 
> Why it says the rendering is necessary for 1-bit bitmaps, but not
> 8-bit? Maybe I missed something?

Perhaps because hinting is more important when you don’t have
anti-aliasing as well.

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

Re: [ft] Freetype memory allocation

[Lawrence D'Oliveiro]

On Fri, 8 Sep 2017 21:21:13 +0200, Vincenzo NZ wrote:

> The problem is that freetype at every new loop deallocates the
> memory allocated for the bitmap invalidating the address passed to
> *my_draw_bitmap*.

Would glyph slots help with this? Only I couldn’t find any API for
actually adding them...

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

Re: [ft] Reading Glyph Names

[Lawrence D'Oliveiro]

On Fri, 25 Aug 2017 09:11:02 +0200, Ladislav Dudáš wrote:

> Many TrueType fonts provides also glyph names, but this table is
> optional.

Glyph names were a PostScript thing. It’s hard to see what general use
they might have.

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

Re: [ft] Windows font driver Parser

[Lawrence D'Oliveiro]

On Thu, 3 Aug 2017 14:48:01 +0900, Ammar ul hassan wrote:

> Currently the research aim is to create a driver module for METAFONT.

Somehow I don’t think that’s going to work...

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

Re: [ft] Independent Project Help

[Lawrence D'Oliveiro]

On Tue, 1 Aug 2017 09:51:59 -0700, Gene Mosher wrote:

> On 08/01/2017 06:54 AM, Werner LEMBERG wrote:
>
>> What are `FreeType fonts'?
>
> Here
> 

“...how to use the FreeType version 2 font rendering library in OpenGL.”

> Here 

“The FreeType font backend...”

> Here 

“...how to use the FreeType font rendering library in OpenGL.”

> Here 

Spam site.

> Here
> 

“The macros and functions in this section are used to access fonts and
render text to bitmaps using the FreeType 2 library.”

> Here
> 

Just another link back to NeHe.

> Here 

Spam site.

> Here 

Spam site.

> You have made your point and I have made mine. I apologize for having
> disturbed your view of the world.

I’m not sure what point you thought you were making by posting a bunch
of random links you got out of Google or wherever. But none of them
explains what “FreeType fonts” are.

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

Re: [ft] Get line height

[Lawrence D'Oliveiro]

On Mon, 3 Jul 2017 09:16:42 +0200, Satz Klauer wrote:

> I'm a bit lost with the description of different heights in a font. So
> when I want to get the nominal height of a fonts line to calculate the
> distance which is needed for a carriage return/line break to continue
> in next line - which parameter/structure member is responsible for
> this?

This would be the “height” in the Size_Metrics fields.

Bear in mind this may be less than the ascender + descender. It is a
value chosen by the font designer for optimum line spacing.

It is quite common to adjust this value when laying out text, e.g. use
a bigger value for “loose leading”, or a smaller one for “tight
leading”. It depends on the effect you want to achieve.

(That’s ”leading” as in “lead” the metal, not as in the opposite of
“follow”.)

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

Re: [ft] Linking custom code to right Freetype version

[Lawrence D'Oliveiro]

On Fri, 23 Jun 2017 07:06:57 +0200 (CEST), Werner LEMBERG wrote:

> I didn't mean the dynamic linker at runtime but rather
> the linker used during compilation, which also hardcodes the paths
> to the DLLs.

The paths are not hardcoded, unless you use -rpath. The default search
paths for gcc, at least, on my Debian system are:

ldo@theon:~> gcc -Wl,--dll-verbose
...
using internal linker script:
...
SEARCH_DIR("=/usr/local/lib/x86_64-linux-gnu"); 
SEARCH_DIR("=/lib/x86_64-linux-gnu"); SEARCH_DIR("=/usr/lib/x86_64-linux-gnu"); 
SEARCH_DIR("=/usr/local/lib64"); SEARCH_DIR("=/lib64"); 
SEARCH_DIR("=/usr/lib64"); SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib"); 
SEARCH_DIR("=/usr/lib"); SEARCH_DIR("=/usr/x86_64-linux-gnu/lib64"); 
SEARCH_DIR("=/usr/x86_x86_64-linux-gnu/lib");
...

That list seems to match the default ld.so.conf settings, except that
anything architecture-specific takes priority.

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

Re: [ft] Linking custom code to right Freetype version

[Lawrence D'Oliveiro]

On Thu, 22 Jun 2017 17:15:51 +0200 (CEST), Werner LEMBERG wrote:

> `make install' by default installs into `/usr/local'.  I guess your
> system is set up so that the dynamic linker looks into `/usr' first.
> Since virtually all GNU/Linux platforms come with `libfreetype' in
> `/usr', this version will be linked to.  You can use the `ldd' program
> to check which dynamic libraries your application is using.

/usr/local/lib normally has priority over /usr/lib (check
your /etc/ld.so.conf and /etc/ld.so.conf.d/* setups).

Also, did you run ldconfig after installation?

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

Re: [ft] Nonsensical(?) values in font metrics.

[Lawrence D'Oliveiro]

On Sat, 22 Apr 2017 22:07:38 -0500, R0b0t1 wrote:

> What is the best way to draw monospaced fonts?

There is almost no such thing as “monospaced” fonts. Most fonts that
one might consider “monospaced” will still have one or two glyphs that
are bigger than the others.

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

Re: [ft] How to compute the baseline for for a font face?

[Lawrence D'Oliveiro]

On Wed, 19 Apr 2017 15:59:16 -0500, R0b0t1 wrote:

> What surprises me is that it is possible to get the maximum extents of
> any character but it seems impossible to know where to draw a
> character within those extents, granted face->descender is almost
> enough information.

That’s what the baseline is for.

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

Re: [ft] How to compute the baseline for for a font face?

[Lawrence D'Oliveiro]

I wrote:

> You want the FT_Face descender value
> .
> 
> But be aware that this value, like the rest of the font metrics, is
> set by the font designer to make the text lines look good overall, it
> won’t necessarily guarantee that the text won’t get clipped.

Or maybe not. I think it was the Size_Metrics I was thinking of. These
values are probably accurate, since they bound the limits of the area
that need to be rendered by the rasterizer.

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