Re: [ft] [ft-devel] heads-up: TrueType height computation has been fixed

On Wed, Jan 23, 2013 at 5:31 AM, Werner LEMBERG w...@gnu.org 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

Re: [ft] [ft-devel] heads-up: TrueType height computation has been fixed

On Wed, Jan 23, 2013 at 10:50 AM, Wojciech Mamrak wmam...@gmail.com 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

Re: [ft] [ft-devel] heads-up: TrueType height computation has been fixed

On Thu, Jan 24, 2013 at 2:23 AM, Wojciech Mamrak wmam...@gmail.com wrote: 2013/1/23 Alexei Podtelezhnikov apodt...@gmail.com: On Wed, Jan 23, 2013 at 10:50 AM, Wojciech Mamrak wmam...@gmail.com wrote: What is the largest possible height change between the old and new implementation? Can

Re: [ft] [ft-devel] heads-up: TrueType height computation has been fixed

On Thu, Jan 24, 2013 at 10:16 AM, Werner LEMBERG w...@gnu.org 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

Re: [ft] Determining pixel dimensions for bitmap

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, and xMax and yMax have

Re: [ft] Manually constructing an FT_Outline

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't, but I

Re: [ft] Manually constructing an FT_Outline

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

[ft] Rendering differences between 2.3.12 and 2.5.3

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

Re: [ft] Rendering differences between 2.3.12 and 2.5.3

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

Re: [ft] Rendering differences between 2.3.12 and 2.5.3

On Sun, Nov 23, 2014 at 2:26 AM, Werner LEMBERG w...@gnu.org 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

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

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 >

Re: [ft] Rendering regression in 2.8.1 on RGB screens

> 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

Re: [ft] Rendering regression in 2.8.1 on RGB screens

> 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 Podtelez

[ft] Unusual LCD pixel layout

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

[ft] Straight FT_PIXEL_MODE_RGBA

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

Re: [ft] Prevent synthesis of Unicode charmap?

> 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,

Re: [ft] are there font types for which FT_LOAD_NO_RECURSE is supposed to fail?

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

Re: [ft] are there font types for which FT_LOAD_NO_RECURSE is supposed to fail?

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)

Re: [ft] _sprintf already defined

> 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

Re: [ft] [ft-devel] Three GSoC projects for FreeType

> 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

Re: FT Performance Regression?

> 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

Re: FT Performance Regression?

> > 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

Re: FT Performance Regression?

> > 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

Re: FT Performance Regression?

> 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?

Re: FT Performance Regression?

> 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,

Re: FT Performance Regression?

> >> 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

Re: undefined reference error when running c++ file depends on freetype2.5

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

Re: building ghostscript with FreeType 2.10.3 and newer

> withdrawn macro that wasn't intended for external usage We should drop it from the demos too, shouldn't we?

Re: Compiling freetype without make and cmake

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

Re: Question about zero render issue

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, ); > FT_Glyph_To_Bitmap(, FT_RENDER_MODE_NORMAL, 0, 1); As Werner said, this is a matter of

Re: render 3 glyphes into the one buffer

> 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.

Re: render 3 glyphes into the one buffer

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

Re: FT_Render_Glyph() and the usage of the stack for embeded software.

> 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

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

> 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

Re: Using the image cache.

> 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

Re: FT Cache Subsystem: Custom caches

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

Infinality removal

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

Re: GSoC project `ftinspect` now in master

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

2.10.3 BW renderer changes

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

Re: 2.10.3 BW renderer changes

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 Rizzo >

Re: Fw: How to have sharp fonts?

>> * 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 >

Re: Fw: How to have sharp fonts?

>> 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:

Re: Inconsistent endianness in differing bitmap depths

> 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

Re: Font Rendering: Multiple FT_Faces and baselines

> > ... 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,

[ft-devel] move band check outside of the loop.

This patch is a trivial move of band check out of the loop in the cubic flattener. The arcs resulting from any split are always smaller than the original. If the original is inside the band, the children are inside by definition, so there is no need to loop this rather long check. I am working on

Re: [ft-devel] move band check outside of the loop.

Same thing for conic. Children arcs are small than the parent. If the parent fits in the band, children do too. A tiny off by one correction is a bonus. diff --git a/src/smooth/ftgrays.c b/src/smooth/ftgrays.c index 40de269..0e26d7b 100644 --- a/src/smooth/ftgrays.c +++ b/src/smooth/ftgrays.c @@

Re: [ft-devel] move band check outside of the loop.

This is a final version of the patch that optimizes both conic and cubic flatteners. Polished and tested. Please consider. diff --git a/src/smooth/ftgrays.c b/src/smooth/ftgrays.c index 40de269..2b90571 100644 --- a/src/smooth/ftgrays.c +++ b/src/smooth/ftgrays.c @@ -872,6 +872,7 @@ typedef

Re: [ft-devel] broken hinted DejaVuSans et 4

On Tue, Sep 13, 2011 at 1:49 PM, Werner LEMBERG w...@gnu.org wrote: This means that FreeType is fine and DejaVuSans's hinting at 4ppm is buggy. :-) Due to the `gasp' table, this is a non-issue anyway. It cannot be both non-issue and buggy font. No blame for ftview and its handling of gasp?

Re: [ft-devel] [ANN] Freetype/OpenGL (with good rendering quality)

I think you can pack the bin better if you start from the largest size. There is tons of empty space at the bottom that could easily be filled with small glyphs. Or go bottom-up for more natural fill. In other words, I bet you can pack more glyphs into 512x512. I am not sure I understood how you

Re: [ft-devel] regarding freetype 2 cubic curve flattening

On 30/10/2011 08:25, Vivek Rathod wrote: according to Hain's paper dmax = (s/L) * dnorm ;  here s  is not normalized. dmax is the tolerance for flatness and dnorm is the normalized flatness of the curve. so s_limit = (dmax / dnorm) * L ; by putting dnorm = 0.75 we get the permissible height

Re: [ft-devel] regarding freetype 2 cubic curve flattening

On Mon, Oct 31, 2011 at 3:22 AM, Vivek Rathod vivekmrat...@gmail.com wrote: s is calculated as s = FT_ABS( dy * dx1 - dx * dy1 );   which means s is the perpendicular distance of the control point from chord multiplied by L which means currently  s_limit is being compared with perpendicular

Re: [ft-devel] regarding freetype 2 cubic curve flattening

On Mon, Oct 31, 2011 at 7:43 AM, Vivek Rathod vivekmrat...@gmail.com wrote: The formula for deviation ( from Hein's paper). d = dnorm * s ; here s is normalized --- (1) so the formula when s is not normalized becomes d = dnorm * (s / L)  ; -(2) and I think the

Re: [ft-devel] regarding freetype 2 cubic curve flattening

pixel-by-pixel shape. Therefore, we *always* tolerate a constant fraction of ONE_PIXEL no matter how long the arch is. Alexei On Mon, Oct 31, 2011 at 7:51 AM, Alexei Podtelezhnikov apodt...@gmail.com wrote: On Mon, Oct 31, 2011 at 7:43 AM, Vivek Rathod vivekmrat...@gmail.com wrote

Re: [ft-devel] FT_Get_Advance() docs

The problem that your description starts with long cumbersome condition. Start description with what the flag actually does: FT_ADVANCE_FLAG_FAST_ONLY:  . Enable quick retrieval of advance in the special cases of - unhinted (FT_LOAD_NO_HINTING), - lightly hinted (FT_RENDER_MODE_LIGHT),

Re: [ft-devel] FreeType License and patents

On Fri, Jan 13, 2012 at 2:13 PM, Werner LEMBERG w...@gnu.org 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

Re: [ft-devel] ftgrays - exact pixel coverage?

On Wed, Feb 8, 2012 at 11:36 PM, Werner LEMBERG w...@gnu.org wrote: I believe there is discrepancy between what's written in ftgrays.c and its actual functioning.  It is said it computes the _exact_ coverage of the outline on each pixel cell.  But the following program shows this is not true.

[ft-devel] direction of autofit-ed outlines

Werner, It seems to me that the autofit module reverses the direction of outlines originating from Type 1 fonts without resetting FT_OUTLINE_REVERSE_FILL bit back to 0. Alexei ___ Freetype-devel mailing list Freetype-devel@nongnu.org

[ft-devel] losing outline flags while auto-hinting

Hi all, Attached is a small program that demonstrates how freetype loses outline flags during auto-hinting. This is a demonstration: $ ./outflags /usr/share/fonts/liberation/LiberationSerif-Regular.ttf 0x2 Liberation Serif Regular loaded... Loading Flags: 0x2 Outline Flags: 0x100 $ ./outflags

Re: [ft-devel] losing outline flags while auto-hinting

On Thu, Feb 16, 2012 at 2:07 AM, Werner LEMBERG w...@gnu.org wrote: This is a bug.  Reason is that the autohinter doesn't preserve this flag while copying around the outlines (in function af_loader_load_g). There are two possibilities to fix this.  One of them is to extend FT_GlyphLoader_Add

[ft-devel] [PATCH] Re: losing outline flags while auto-hinting

On Thu, Feb 16, 2012 at 2:07 AM, Werner LEMBERG w...@gnu.org wrote: This is a bug.  Reason is that the autohinter doesn't preserve this flag while copying around the outlines (in function af_loader_load_g). This safe patch fixes it for me. diff --git a/src/autofit/afloader.c

Re: [ft-devel] FreeType patches to support amalgamation

To be honest, I am perplexed by this amalgamation exercise. All of this apparently needed because some obscure in-house tool does not know how to resolve the name conflicts. Teach the damn tool how to resolve the name conflicts by adding prefixes or suffixes! Why do you butcher perfectly legal

Re: [ft-devel] FreeType patches to support amalgamation

You again manage to present this as a legitimate goal :) It is your tool that breaks the code :) You are not fooling me here. Again, I'll say that this is just such a bizarre objective that you HAVE TO justify this and tell which platform on Earth needs it. Remember it has to be a platform which

Re: [ft-devel] FreeType patches to support amalgamation

On Mon, Feb 20, 2012 at 5:45 PM, Werner LEMBERG w...@gnu.org wrote: Again, I'll say that this is just such a bizarre objective that you HAVE TO justify this and tell which platform on Earth needs it. ???  It's not related to a specific platform at all.  It's a matter of an easy way to

Re: [ft-devel] FreeType patches to support amalgamation

How about a shared header file if those modules share a structure? Don't you see that this patch set is just a pile of pure stinking crap??? On Tue, Feb 21, 2012 at 9:56 AM, Vinnie thev...@yahoo.com wrote: Werner: 2012-02-20  Vinnie Falco vinnie.fa...@gmail.com   ftgrays.c, ftraster.c:

Re: [ft-devel] FreeType patches to support amalgamation

On Tue, Feb 21, 2012 at 10:44 AM, Vinnie thev...@yahoo.com wrote: Date: Tue, 21 Feb 2012 08:02:43 -0500 From: Alexei Podtelezhnikov apodt...@gmail.com You planing this for Stone Age people who do not know how to use make. I rest my case. Actually, that is true. My target audience

Re: [ft-devel] FreeType patches to support amalgamation

On Tue, Feb 21, 2012 at 11:03 AM, Chris Morgan chmor...@gmail.com wrote: Hey. This kind of response isn't cool man. If Vinnie's patches disambiguate and otherwise clarify the code then they are good changes, even if it enables him to do things that we find odd. There is nothing ambiguous in

Re: [ft-devel] FreeType patches to support amalgamation

On Tue, Feb 21, 2012 at 11:54 AM, Vinnie thev...@yahoo.com wrote: From: Alexei Podtelezhnikov apodt...@gmail.com Sent: Tuesday, February 21, 2012 8:28 AM It is hard to believe that there are people who'll dive into font rendering without first learning how to use multiple files

Re: [ft-devel] where might be a problem

On Fri, Feb 24, 2012 at 4:05 AM, pravin@gmail.com pravin@gmail.com wrote:   Lohit Devanagari does not have Bold variant and presently using auto bold algorithm. It does not work correctly in gnome  see http://pravins.fedorapeople.org/Screenshot.png   Can someone given me pointer that

Re: [ft-devel] Auto Embolding of Lohit Devanagari

On Fri, Feb 24, 2012 at 9:54 PM, suzuki toshiya mpsuz...@hiroshima-u.ac.jp wrote: I think there are 2 issues in auto-embolden Lohit Devanagari; a) disconnection of horizontal strokes (which should be connected with previous/next glyph)4.8 It looks like advance value is incorrectly adjusted

Re: [ft-devel] Auto Embolding of Lohit Devanagari

On Mon, Feb 27, 2012 at 2:12 AM, pravin@gmail.com pravin@gmail.com wrote: On 27 February 2012 07:58, Alexei Podtelezhnikov apodt...@gmail.com wrote: mpsuz...@hiroshima-u.ac.jp wrote: I think there are 2 issues in auto-embolden Lohit Devanagari; a) disconnection of horizontal strokes

Re: [ft-devel] Auto Embolding of Lohit Devanagari

On Mon, Feb 27, 2012 at 10:41 AM, pravin@gmail.com pravin@gmail.com wrote: On 27 February 2012 19:36, Alexei Podtelezhnikov apodt...@gmail.com wrote: On Mon, Feb 27, 2012 at 2:12 AM, pravin@gmail.com pravin@gmail.com wrote: On 27 February 2012 07:58, Alexei Podtelezhnikov

Re: [ft-devel] Auto Embolding of Lohit Devanagari

On Mon, Feb 27, 2012 at 12:17 PM, Antoine Leca antoine-freet...@leca-marti.org wrote: Alexei Podtelezhnikov wrote: In this particular font the glyph width is larger than it advance, which is unusual. ... but it is typical of Devanagari fonts, and in general of several hanging scripts, where

Re: [ft-devel] Auto Embolding of Lohit Devanagari

ftstring is supposed to be an exemplar string renderer for other libraries because it handles lsb_delta and rsb_delta. This is short of kerning but at least it is better than ftview. Unfortunately, auto-emboldened fonts are not a part of ftstring's functionality. So other libraries could not copy

Re: [ft-devel] Patch to allow '\0' in sfnt name table entries

On Wed, Mar 14, 2012 at 7:26 AM, Huw Davies h...@codeweavers.com wrote: The attached patch fixes a problem with fonts that include a trailing '\0' in name table entries.  Currently the font name would have a question mark appended to it. Why would the name contain \0? Is this because

[ft-devel] [patch] emboldening rework v1

In memory of Paul Alexi The attached patch is a rework of outline emboldening. 1) It introduces uneven emboldening in x- and y-direction. I understand that the straight change in API is not going to fly but I really do not want to introduce a separate

Re: [ft-devel] [patch] emboldening rework v1

A testable version of the patch is attached. At the end I decided to introduce a new interface FT_Outline_EmboldenXY. Comments? faster-embolden.patch Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org

Re: [ft-devel] [patch] emboldening rework v1

On Sat, Mar 31, 2012 at 12:50 AM, Werner LEMBERG w...@gnu.org wrote: A testable version of the patch is attached. At the end I decided to introduce a new interface FT_Outline_EmboldenXY. Comments? From a quick glance, this looks like a good solution, thanks!  I will have to test and check

Re: [ft-devel] Issues due to commit Fix metrics on size request for scalable fonts.

On Tue, Apr 3, 2012 at 9:05 AM, Peter Hurley pe...@hurleysoftware.com wrote: Werner LEMBERG wrote: We had report of regression in GTK markups rendering in Ubuntu precise, (i.e ulabel/u would render underlined), [...] AFAIK, the problem is in gtk.  For years, FreeType had this metrics

Re: [ft-devel] [patch] emboldening rework v1

In memory of Paul Alexi As a way of ping, I going to throw in a much simpler FT_Outline_Get_Orientation patch. So the whole collection of three patches now looks like the attached. Comments, suggestions? Alexei faster-embolden.patch Description: Binary

Re: [ft-devel] [patch] emboldening rework v1

On Tue, Apr 10, 2012 at 2:00 AM, Werner LEMBERG w...@gnu.org wrote: As a way of ping, I going to throw in a much simpler FT_Outline_Get_Orientation patch.  So the whole collection of three patches now looks like the attached.  Comments, suggestions? Thanks a lot for your work!  Everything

Re: [ft-devel] [patch] emboldening rework v1

On Tue, Apr 10, 2012 at 11:54 AM, Behdad Esfahbod beh...@behdad.org wrote: I like the area-based algorithm.  I had to implement outline orientation code recently and I wish I had remembered that algorithm! What I found in testing my implementation was that fonts don't have consistent contour

Re: [ft-devel] [patch] emboldening rework v1

On Tue, Apr 10, 2012 at 3:02 PM, Behdad Esfahbod beh...@behdad.org wrote: Humm.  The docs say:  /*    FT_OUTLINE_EVEN_ODD_FILL ::                                        */  /*      By default, outlines are filled using the non-zero winding rule. */  /*      If set to 1, the outline will be

Re: [ft-devel] [patch] emboldening rework v1

Werner et al., In the current incarnation, FT_Outline_Get_Orientation cannot possibly return FT_ORIENTATION_NONE, in spite of what the documentation suggests. The return values are simply conditioned as != FT_ORIENTATION_NONE. FT_ORIENTATION_NONE is supposed to mean CANNOT BE DETERMINED, which

Re: [ft-devel] [patch] emboldening rework v1

On Wed, Apr 18, 2012 at 2:18 PM, Werner LEMBERG w...@gnu.org wrote: FT_ORIENTATION_NONE is supposed to mean CANNOT BE DETERMINED, which is easier said than done. Any contour has a well defined orientation as a sign of the area it covers: plus or minus. It is only the degenerate contours or the

Re: [ft-devel] [patch] emboldening rework v1

On Thu, Apr 19, 2012 at 2:12 PM, Behdad Esfahbod beh...@behdad.org wrote: On 04/18/2012 01:36 PM, Alexei Podtelezhnikov wrote: When we talk about an outline as a collection of contours, things get out of control very quickly, because to do a good job you have to inspect the whole layout

Re: [ft-devel] [patch] emboldening rework v1

On Tue, Apr 24, 2012 at 4:25 PM, Behdad Esfahbod beh...@behdad.org wrote: On 04/20/2012 11:59 AM, Alexei Podtelezhnikov wrote: On Thu, Apr 19, 2012 at 2:12 PM, Behdad Esfahbod beh...@behdad.org wrote: On 04/18/2012 01:36 PM, Alexei Podtelezhnikov wrote: When we talk about an outline

Re: [ft-devel] [patch] emboldening rework v1

On Mon, May 28, 2012 at 5:12 PM, Werner LEMBERG w...@gnu.org wrote: As a way of ping, I going to throw in a much simpler FT_Outline_Get_Orientation patch. So the whole collection of three patches now looks like the attached. Comments, suggestions? I've applied all three patches.  Sorry for

Re: [ft-devel] display broken

On Wed, May 30, 2012 at 3:34 AM, Werner LEMBERG w...@gnu.org wrote: Well, I've read that that Apple is going to sell iBooks with `retina displays' soon, with really impressive DPI values, and I suspect that other companies will provide similar things, which is good! Let me steer this

Re: [ft-devel] Artefacts when rendering with FreeType 2.4.9

This is clearly a bug in BW rasterizer. Can you help to git bisect it? You know two versions with and without a bug. On Thu, May 31, 2012 at 10:38 AM, jola hans-jochen@lhsystems.com wrote: To make use of new API (kerning etc.) I upgraded from FT 2.1.10 to FT 2.4.8 and then 2.4.9. When

Re: [ft-devel] Artefacts when rendering with FreeType 2.4.9

On Mon, Jun 4, 2012 at 4:38 AM, jola hans-jochen@lhsystems.com wrote: the bug was obviously introduced with the transition from 2.3.12 (working) to 2.4.0 (showing the bug). HTH. The only potential change in question is this:

Re: [ft-devel] Artefacts when rendering with FreeType 2.4.9

On Tue, Jun 5, 2012 at 7:20 AM, jola hans-jochen@lhsystems.com wrote: Alexei Podtelezhnikov-2 wrote: The only potential change in question is this: http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=7baeeafcec7fd2267191937e14c1f753424beb89 It was supposed to fix bug

Re: [ft-devel] Artefacts when rendering with FreeType 2.4.9

On Wed, Jun 6, 2012 at 7:25 AM, Werner LEMBERG w...@gnu.org wrote: The only potential change in question is this: http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=7baeeafcec7fd2267191937e14c1f753424beb89 Your guess was not wrong!  This morning I repeated the tests, I had

Re: [ft-devel] [patch] emboldening rework v1

On Wed, Jun 6, 2012 at 10:18 AM, Werner LEMBERG w...@gnu.org wrote: [...] let's bring FT_GlyphSlot_Embolden in agreement with what ftview does.  This removes too much width that used to be added to the emboldened glyphs. Thanks.  Do you have time to provide some documentation also? Sure.

Re: [ft-devel] Artefacts when rendering with FreeType 2.4.9

On Wed, Jun 13, 2012 at 9:22 AM, Werner LEMBERG w...@gnu.org wrote: It's probably a good idea to fix Rx also.  What about this:  old:       Rx = ( ras.precision * Dx ) % Dy;  new:       Rx = ( ( ras.precision % Dy ) * ( Dx % Dy ) ) % Dy; Let's not rush with this and just say that your fix

Re: [ft-devel] FT_Outline_Embolden() is Blurry

On Fri, Jun 15, 2012 at 5:31 PM, Infinality infinal...@infinality.net wrote: Sorry to resurrect an old thread here, but I think I have a solution that preserves the addition of Y-weight at larger font sizes, while still keeping the blur to a minimum: In FT_Outline_Embolden (which is now

Re: [ft-devel] FT_Outline_Embolden() is Blurry

think that rounding the emboldening strength is sufficient, you must assume that the original outline is already well hinted, which is just wrong. There is no way you can shortcut the hinting like that. On 06/16/2012 10:07 PM, Alexei Podtelezhnikov wrote: On Fri, Jun 15, 2012 at 5:31 PM

Re: [ft-devel] New Infinality Release

On Mon, Jun 18, 2012 at 4:38 AM, Werner LEMBERG w...@gnu.org wrote: The patch is now in the repository.  Thanks a lot! I am not sure why Round_To_Grid and its family are modified but not used. I am actually more concerned with the way they are modified. Things like this look dangerous: - val =

Re: [ft-devel] New Infinality Release

I really dislike how you disabled hinting in the x-direction. You essentially replaced '64' in the rounding functions with '64 / 64', aka '1'. This is brutal and takes a performance toll on this part of the code even when your subpixel hinting is not used. I strongly suggest that you just

Re: [ft-devel] New Infinality Release

On Mon, Jun 18, 2012 at 9:52 AM, Infinality infinal...@infinality.net wrote: On 06/18/2012 08:40 AM, Werner LEMBERG wrote: I really dislike how you disabled hinting in the x-direction.  [...] Thanks for your reviews, and please continue.  I'm sure Erik will collect them all :-) Note that I

[ft-devel] [patch] fuller right margin in ftview

In memory of Paul Alexi Hi all, The attached patch changes the way 'ftview' fills the window with glyphs so that the right margin is less blank and a larger number of glyphs shown. It uses the actual width of the current grBitmap, instead of super

  1   2   3   4   5   6   7   8   9   10   >