> > have to convert to pixels
>
> Can you explain how to do that? Since the bounding box is fixed, I
> presume it will somehow involve the pixel size I'm passing to to
> FT_Set_Pixel_Sizes. I've gone through the documentation and am
> still a little confused.
I suggest using x_scale and y_scale f
Hi Kelvin
If you only interested in subpixels shifts and intend to cache 3
positions, you can achieve using LCD rendering and
https://freetype.org/freetype2/docs/reference/ft2-lcd_rendering.html#ft_library_setlcdgeometry.
It is apparent that LCD rendering is essentially 3 traditional
antialiased b
> > ... 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.
Or... whatever works. FreeType provides a client with all kinds of
metrics and bounding boxes,
> When using mono mode, the bitmap is rendered in big endian format where the
> most significant bit is the leftmost pixel, while in default mode the
> bitmap is rendered in little endian, consistent with my cpu.
This is documented
https://freetype.org/freetype2/docs/reference/ft2-basic_types.html
>> * Usually pure greyscale (pixel) antialasing is way better for
>> me, but it also depends on whether the background is dark or
>> light and whether the rendering library applies the right
>> gamma correction for that
>
> Since many/most text setting libraries don't take this into
> account
>> I have problem with all linux distros about fonts generally,
>> fonts are very smooth or fuzzy and it hurts my eyes when i
>> read more of the texts , [...] any patches to improve the
>> fonts to be like windows, very sharp
Since Windows is your gold standard, this is their tunable settings:
ht
With freetype up to 2.10.2 I obtain the desired nice bitmap, with
> freetype since 2.10.3 (including the last 2.12.1) I obtain a different
> bitmap.
>
> My question is if it's possible with some parameter to obtain the "old"
> bitmap with freetype 2.12.1.
>
> Thank you
>
Davide,
> The new output is much worse, most of chars have single dots protruding
in the external outline.
We won't be able to help you unless you help us to reproduce or see
the issue. At the very least you should name the font and the size,
and give a screenshot. Also, in our mind, only bugs i
Congratulations!
Alexei
> On Oct 3, 2022, at 12:41, Charlie Jiang wrote:
>
> Hi Werner and other folks,
>
> It's extremely delightful to hear that my project has been merged into
> `master`!
>
> I would express my deep gratitude to all who lent me a hand during the
> project, especially We
Dear FreeType community,
We have just committed a forewarning about Infinality removal.
- TrueType interpreter version 38 (aka Infinality) that was first
introduced about 10 years ago in FreeType 2.4.11 is now deprecated
and slated to be removed in the next version. TrueType interprete
> cd builds/unix; \
> ./configure
> /bin/sh: 2: ./configure: not found
./autogen.sh, see
https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/docs/INSTALL.UNIX
or https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/README.git
FreeType has good docs worth your time rea
> using FT_Glyph.advance.x to move the cursor to the next start.
Do you also use FT_BitmapGlyph->left?
https://freetype.org/freetype2/docs/reference/ft2-glyph_management.html#ft_bitmapglyphrec
Alexei
> Is there any way that would allow Ft_Render_Glyph() to use more heap instead?
We use stack for performance reasons, but I never checked that. The
majority of rendering stack are reserved here:
https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/src/smooth/ftgrays.c#L1941
for smooth a
On Tue, Aug 3, 2021 at 9:32 AM Vitaliy Fadeev wrote:
>
> On Вт, 2021-08-03 at 08:47 -0400, Alexei Podtelezhnikov wrote:
> > > Question 1: Possible to render glyphs directly into te one big
> > > bitmap ?
> >
> > If you are ready to manage the buffer yourse
> Question 1: Possible to render glyphs directly into te one big bitmap ?
If you are ready to manage the buffer yourselves and carefully track
the pen coordinates for proper layout, you might be able to use
FT_Outline_Render with FT_RASTER_FLAG_DIRECT and some callback
function.
https://www.free
Hi there
If you can create and contribute platformio.ini for FreeType, we do
not mind distributing it and can certainly check if it makes sense.
The syntax and structure of platformio.ini seems rather
straightforward. FreeType has very optional external dependencies.
Alexei
You can add this to mimic Adobe for this glyph
> error = FT_Load_Glyph(pFTFace, 3, FT_LOAD_DEFAULT);
pFTFace->glyph->outline.flags |= FT_OUTLINE_EVEN_ODD_FILL;
> error = FT_Get_Glyph(pFTFace->glyph, &glyph);
> FT_Glyph_To_Bitmap(&glyph, FT_RENDER_MODE_NORMAL, 0, 1);
As Werner said, this is a
> withdrawn macro that wasn't intended for external usage
We should drop it from the demos too, shouldn't we?
On Tue, May 19, 2020 at 9:52 AM Othman El-Kurdi wrote:
> I'm trying to compile freetype2.5 on ubuntu 20.04 LTS (virtual machine), so
> that I can use it to compile a c++ script. where I'm facing lot's of errors.
Huh? Ubuntu 20.04 comes with FreeType 2.10.1. Try to use or install
that. Then you j
> > This is definitely not a bottle neck
>
> Maybe, but 1/3rd of a function call being spent not doing actual work is
> definitely concerning in a world where you only have 33.3ms or 16.6ms to do
> all your work that frame.
>
> It looks like setjmp in FreeType is basically used to do exception-like
> Thanks, do you know how much difference the span batching made to
performance?
In depends on your program. Simple scanlines might be delivered at once.
Freetype won't wait for you to process each spam.
> It's also been pointed out to me that setjmp/longjmp can be very slow
(eg, 12ms of a 36ms c
> > Does using clip_box solve it?
> Yes, using the clip_box logic from my earlier email. Once again, not
> documented nor called out in a release note. I've not looked at the code for
> 2.10.1, but if all you've done is fixed the crash when omitting
> FT_RASTER_FLAG_CLIP so that it uses an unbou
> On Oct 27, 2019, at 18:07, Jamie Dale wrote:
>
> > This is fixed in 2.10.1.
> Good to know. Once again, not called out in the upgrade notes.
Huh? See line 70.
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/docs/CHANGES
> > What is the performance issue?
>
> Seriously, FT_Ou
> FreeType 2.10 we found that if you use FT_RASTER_FLAG_DIRECT you now *must*
> also use FT_RASTER_FLAG_CLIP and specify a clip_box otherwise FreeType will
> crash.
This is fixed in 2.10.1. What is the performance issue?
>
>> FreeType 2.6 used to use an unbounded clip_box in the
>> FT_Raster_Params struct, and internally the gray_compute_cbox
>> function would clamp it to a reasonable range.
>>
>> That clamping no longer happens, so you have to do it yourself
>> before calling the function. The docs don't real
> LNK2005: _sprintf already defined in freetype.lib(bdf.ob)
> LNK2019: unresolved external symbol __stdio_common_vsprintf referenced in
> function _vsnprintf_l
Why don't you use freetype2/builds/windows/vc2010/freetype.vcxproj? It
may ask for an upgrade to VC2019 but should work.
If you insist on
> Which svg renderer will be used? Which XML parser will be used? Because,
> that
> could add heavy SDK deps to freetype.
There are constraints that make this project possible. These some quotes
from https://docs.microsoft.com/en-us/typography/opentype/spec/svg
- Adoption of SVG for use in OpenT
> Is there a way to prevent FreeType from synthesizing a Unicode charmap, or
at least clearly identifying the synthesized charmap as such?
FT_Get_CMap_Format will return -1 for synthetic cmaps in TrueType
fonts, but also return -1 for all non-TrueType cmaps
The synthetic cmap is added last, which
On Wed, Sep 19, 2018 at 2:37 AM Kevin Rogovin wrote:
> I am thinking that whether or not glyph metrics are loaded with
> FT_LOAD_NO_RECURSE is dependent on font driver, i.e font format.
No. It depends on the glyph format (FT_GlyphSlot->format)
https://www.freetype.org/freetype2/docs/reference/ft
Kevin,
To understand relationships between the flags, please study just a few
lines of code here:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/base/ftobjs.c#n818
FT_LOAD_NO_RECURSE basically cancels everything including metrics
calculations. It only gives you a list of glyph c
Hi all,
I propose to default to straight RGBA color space in FreeType. This is
especially important before the next FreeType release 2.10 with
CPAL/COLR support. I will quote from PNG documentation for the
overarching reason:
"PNG also uses only unassociated alpha, wherein the actual gray or
colo
Hi all,
If you own an LCD panel with unusual pixel layout, not the regular RGB
or BGR stripes, this is a call for testing for you. Traditional
ClearType-style subpixel rendering would not work for you, but Harmony
LCD rendering just might.
Harmony was discovered when I realized that ClearType ren
> Do you know which change / version in Firefox fixed this, or did you simply
> mean that you can't reproduce it on your machine with Firefox 56?
20 days ago.
https://bugzilla.mozilla.org/show_bug.cgi?id=1400721
I tested Firefox 56 final.
>
> On 2017-10-10 14:07, Alexei Pod
> rendering artifacts can be observed in Mozilla Firefox:
I am happy to report that this is fixed now in Firefox 56.
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype
On Thu, Oct 8, 2015 at 2:39 AM, Jan Engelhardt wrote:
>>Why distributions are more conservative about FreeType than kernel is beyond
>>me.
>
> If you have too old a kernel, some of your hardware may not
> activate/behave properly. If you have too old a freetype, the worst that
> can happen is "ju
On Wed, Oct 7, 2015 at 4:33 PM, Behdad Esfahbod
wrote:
> Can you please make more quick-and-small releases for important fixes?
It does not matter considering that
Fedora 22 runs 2.5.5, which is progressive in comparison to
Android 5.1.1 runs 2.5.3
Ubuntu Vivid runs 2.5.2
iOS runs 2.4.7 last time
On Sun, Nov 23, 2014 at 2:26 AM, Werner LEMBERG wrote:
> Can you provide a recipe how to emulate the old behaviour? It might
> be worth to add it to the documentation.
As far as I remember. Freetype used to increase the advance by 2x the
emboldening strength, which was too much. Now it is 1x, w
>> This is the change that you want to undo for yourself
>> http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=cea9d7a6820bf7cca8d79d813908ce085a3d3d5d
>
> Does this also undo the changes to the italicized text? From
> a quick glance at the diff it looks as if this affects
> FT_Glyp
> If the text rendered by freetype is only a little bit wider than it
> used to be, whole words might suddenly end up on a new line
> which can mess up the whole layout.
You've got to admit that 2.5.3 looks better. :)
Yes advances for emboldened text changed,
but ultimately Freetype is not a text
> So FreeType could really fill in a market gap, i.e. a vector drawing engine
> with a strong copyleft license.
Right. Freetype is going to need arc and ellipse primitives before then. :)
___
Freetype mailing list
Freetype@nongnu.org
https://lists.nongn
>> are there any convenience functions or macros to manually construct
>> an FT_Outline in a way that is similar to the FT_Stroker APIs?
>> e.g. functions like FT_Outline_LineTo(),
>> FT_Outline_CubicTo()would come in really handy or do I really
>> have to do all this manually?
> No there aren
Earlier you said:
> > width = bbox.xMax - bbox.xMin;
> > height = bbox.yMax - bbox.yMin;
> >
> > pixelwidth = width >> 6;
> > pixelheight = height >> 6;
> >
> > if((width & 0x3f) > 31) pixelwidth++;
> > if((height & 0x3f) > 31) pixelheight++;
Actually, xMin and and yMin have to be rounded down, a
On Thu, Jan 24, 2013 at 10:16 AM, Werner LEMBERG wrote:
>
>> I think that David's idea to make the change conditional can work
>> except we should use a softer condition: [...]
>
> This is all moot. It was my error mixing up the glyph height with
> the `height' value in FT_Face which actually is
On Thu, Jan 24, 2013 at 2:23 AM, Wojciech Mamrak wrote:
> 2013/1/23 Alexei Podtelezhnikov :
>> On Wed, Jan 23, 2013 at 10:50 AM, Wojciech Mamrak wrote:
>>> What is the largest possible "height" change between the old and new
>>> implementation? Can it exceed
On Wed, Jan 23, 2013 at 10:50 AM, Wojciech Mamrak wrote:
> What is the largest possible "height" change between the old and new
> implementation? Can it exceed one pixel?
>
It should not exceed 1 pixel unless the height specified in the font
differs from (acsender - descender) by more than 1 pixe
On Wed, Jan 23, 2013 at 11:10 AM, David Turner wrote:
> Unless I'm missing something (which is entirely possible, and I've not
> looked at the patch details yet).
>
> If that so, maybe add some code to deal with this, e.g.:
>
> if (height_26.6 == ascender_26.6 - descender_26.6) {
> height_in
On Wed, Jan 23, 2013 at 5:31 AM, Werner LEMBERG wrote:
> just a heads-up which might influence applications: I've just fixed a
> bug in the TrueType handler to correctly compute the `height' value of
> the `FT_Face' structure...
>
> ...to be in sync with Windows.
>
> I wonder whether we should do
On Fri, Jan 13, 2012 at 2:13 PM, Werner LEMBERG wrote:
> 3. Grant of Patent License.
>
>
Do freetype authors hold or have they filed for a patent? Don't you
need it first before granting any patent license? This is one strange
and curious discussion thread without a patent at hand. There is
48 matches
Mail list logo
