Re: [ft-devel] Time for a new FreeType release
At 09:09 01/04/2018 +0200, Werner LEMBERG wrote: Folks, I would like to do a new FreeType release within the next few weeks. Is there anything that should be handled before doing so? Hi Werner, We're currently experiencing a problem with FreeType 2.9 in conjunction with Ghostscript. Some TrueType glyphs are rendering as if the hinting is broken, or points are being moved/dropped. We haven't mentioned it yet because we intend to diagnose it ourselves and get back to you with an explanation and proposed solution, but the prospect of a release soon made me think I should at least tell you we see a problem I know Chris Liddell was hoping to get somewhere with debugging (or at least bisecting to the commit) this week. Chris is on vacation today but he may get back to you shortly. If your projected timescale is later than this week that's probably OK for us. I hope we can at least isolate the problem this week and then you can decide whether to delay releasing until we can propose a good fix. Regards, Ken Sharp ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType incremental glyph loading
At 14:31 25/01/2018 +0300, Ann Brednikhina wrote: Thanks for your quick reply! But the situation with git clone is absolutely the same. I have cloned http://git.sv.nongnu.org/r/freetype/freetype2.git c:\GIT\freetype2>grep -RnP --color=always FT_IncrementalRec . ./include/freetype/ftincrem.h:85: typedef struct FT_IncrementalRec_* FT_Incremental; That is all. Its an opaque object, to be defined by the recipient and used by them. FreeType doesn't need to know anything about it. If you look at the comments above the definition there you will see: /*** * * @type: * FT_Incremental * * @description: * An opaque type describing a user-provided object used to implement * `incremental' glyph loading within FreeType. This is used to support * embedded fonts in certain environments (e.g., PostScript interpreters), * where the glyph data isn't in the font file, or must be overridden by * different values. * * @note: * It is up to client applications to create and implement @FT_Incremental * objects, as long as they provide implementations for the methods * @FT_Incremental_GetGlyphDataFunc, @FT_Incremental_FreeGlyphDataFunc * and @FT_Incremental_GetGlyphMetricsFunc. * * See the description of @FT_Incremental_InterfaceRec to understand how * to use incremental objects with FreeType. * */ The FT_Incremental_InterfaceRec is defined around line 280 in the same file. If you want to know how Ghostscript uses it (and as far as I know Ghostscript is currently the only client that uses incremental font loading) then you'll need to look at the Ghostscript sources. Ghostscript is also open source. Essentially, the client (in our case Ghostscript) adds glyphs to the font, and tracks them, itself. The methods for retrieving the glyph data and metrics are supplied by the client. So, when using the incremental interface, FreeType just requests the data it needs from the client when it needs either the metrics or outline data. Its up to the client how to store the data, and how to make it available to FreeType, FT doesn't need to care. Ken ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType incremental glyph loading
At 11:51 25/01/2018 +0100, Werner LEMBERG wrote: > Please send me a link to the full sources or some instructions how to > add into our project. Incremental glyph loading is contributed code; I'm not familiar with it. I hope that Chris or some other person from Artifex (the ghostscript maintainers) can give hints. I was under the impression we just supplied a fix when it got broken in the past, but I could be mistaken. I've pinged Chris who actually has a memory and should be able to say definitely. Of course the full sources are available for FreeType, since its an Open Source Project. https://www.freetype.org/developer.html If you want to contribute, or really even develop *using* FreeType, I'd very strongly recommend going the Git route and cloning the FreeType Git repository. Ken ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] "Inside the fastest font renderer in the world"
At 09:09 05/08/2016 +0100, Graham Asher wrote: I see your point, but I think that adding obfuscation (the extra complexity introduced by using C) to the code to support a tiny and vanishing minority of systems without C++ is not worth the bother; such systems would very probably not be able to run FreeType in any case because of lack of support for 32-bit integers; and I doubt very much whether they would have any need to rasterize glyphs. Speaking for Ghostscript, this is not the case. We are required to support a number of embedded operating systems, many of which are of some degree of legacy and which have limited (if any) support for C++. These platforms drive printers, which very much do have a need to render glyphs :-) Please don't assume that all glyph rendering is for screen display! I no longer have responsibility for FreeType in Ghostscript, but if FT were to move to requiring C++ I think we would have to fork it (as we did once before) in order to maintain a pure C build. Personally, as one of the two people who did a load of work to get FreeType integrated into Ghostscript in place of the (old) fork that was being used, I'd be very disappointed to have to go back to using a fork. Ken ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Windows x64 Build Re: Freetype-devel Digest, Vol 105, Issue 12
At 20:31 23/10/2013 +0200, Werner LEMBERG wrote: Just wish to point out that a copy of the whole of freetype is bundled with ghostscript, and ghostscript has been routinely built for win64 for quite a few years. For as long as it was, the preferred compiler for building ghostscript for windows has always been MS VC. I haven't looked for some time, but AFAIK they are using a very special set of FreeType source code files, not a vanilla FreeType 2 distribution. Nope we use a vanilla FreeType, to the best of my knowledge. I'm not dealing with fonts any more though Chris Liddell is, and he may contradict me. But as far as I know we don't have any special patches or anything. We do use FreeType in a slightly unusual way, that is we seem to be the only people using certain of its features, but nothing that is not supported in the current code. Note that on Linux its possible to build Ghostscript so that it will use the system shared library for FT, I believe that a number of Linux distributions do this (though we would rather people didn't) Ken ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
At 10:26 30/08/2012 -0400, Alexei Podtelezhnikov wrote: Can we ask FreeType users what do they want to have and have simplified in API? What do they not need too? By users I mostly mean: - Cairo and Pango (Behdad ?) - Qt - fontconfig - ghostscript (Ken Sharp ?) Should be Chris Liddell for Ghostscript now, though (obviously) I'm still lurking and still interested :-) Ken ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] TrueType hinting
At 15:18 24/08/2012 +0200, Werner LEMBERG wrote: Thank you for your prompt response. I am surprised, because when embedded in a PDF file, the font is displayed incorrectly by GhostScript 9.02 which uses FreeType 2.4.3. Indeed, using ftview from 2.4.2 and 2.4.4, the font fails splendidly. However, version 2.4.6 and later works just fine. I don't have time to bisect the source code to find out the commit which fixes the font, so I suggest that you upgrade to a more recent GhostScript version (which hopefully incorporates a newer FreeType version also). Ghostscript 9.06 was released a week or so back and incorporates FreeType version 2.4.9 and a few patches which were later added to 2.4.10. Ken ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: Fw: [ft-devel] FreeType 2.4.0 has been released
At 11:20 29/07/2010 +0200, Werner LEMBERG wrote: can you answer this mail? No problem :-) I. IMPORTANT CHANGES - Since May 2010, all patents regarding the TrueType bytecode interpreter have expired worldwide. Consequently, we now define TT_CONFIG_OPTION_BYTECODE_INTERPRETER by default (and undefine TT_CONFIG_OPTION_UNPATENTED_HINTING). I think that not yet expired US5325479. US5325479 is until June,2011 ? (1994-06-28 + 17year) Please teach expired grounds. Kind Regards I did the research on this for the Ghostscript project, which was reviewed by a US patent lawyer, so I'm reasonably sure of my ground. If you look at Ghostscript bug #690621 : http://bugs.ghostscript.com/show_bug.cgi?id=690621 you can find a complete description of all the relevant patents I was able to locate, their filing and grant dates and an explanation of how I arrived at the expiration dates, based on the patent law in the country of application. The short answer for US patent US5325479 is that on the USPTO web site: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2Sect2=HITOFFp=1u=%2Fnetahtml%2FPTO%2Fsearch-bool.htmlr=43f=Gl=50co1=ANDd=PTXTs1=5325479OS=5325479RS=5325479 there is a notice which states that 'The portion of the term of this patent subsequent to October 13, 2009 has been disclaimed'. (Just below the Inventors and Assignee in the box below the Abstract) To me this means (and our patent lawyer seems to agree) that Apple have given up the right to that patent from October 13 2009. This is the date when the original patent on which it depends, US5155805, expired. Ken ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: possible inefficiency in gray_render_cubic
At 10:04 08/06/2010 +0200, Werner LEMBERG wrote: I am sceptical about the need to calculate both da and db. Perhaps db only will suffice. I hope that David or Werner can comment. This is something Ken can probably check: He has a large database for Ghostscript to compare rendering results, and artifacts introduced by the simplified shorthand calculation would easily show up, I think. I'd like to be able to, but at the moment GS doesn't use FreeType for anti-aliased rendering, hich is when this would get used I think ? Currently GS renders text to create a bitmap mask, and fills the mask with a colour (in PostScript colour can mean something complicated, like a pattern) It's on the schedule to replace the Ghostscript (crude) anti-aliasing with the FreeType anti-aliasing, but probably after we get the PCL and XPS interpreters to use FT (at the moment only the PS and PDF ones do). If I'm wrong please let me know and I'll be happy to put a patch through our regression testing. Ken ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] inconsistently dropping sub-pixel features
At 13:44 21/03/2010 +0100, Werner LEMBERG wrote: Needed some minor tweaking for Windows (inttypes.h doesn't exist, so conditionally typedef FT_Int64 as __int64) Patch, please. Uploaded alongside the issue report, it really is quite trivial. Should I open an issue in Savannah and attach my test harness there ? Please do so. Opened as #29298. James I haven't added you on the CC list there, I assume you will add yourself if you want to follow this further. Ken ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] inconsistently dropping sub-pixel features
At 23:32 20/03/2010 +0100, Werner LEMBERG wrote: However, I did notice while reading ftraster.c that it can be built stand-alone without the rest of FreeType (I hope that's not just a legacy comment ;-) I check regularly whether it compiles, and a few months ago someone even sent fixes for stand-alone mode. Needed some minor tweaking for Windows (inttypes.h doesn't exist, so conditionally typedef FT_Int64 as __int64) but other than that I have it working, and a test harness which feeds in the relevant numbers and demonstrates the result. Should I open an issue in Savannah and attach my test harness there ? Ken ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] inconsistently dropping sub-pixel features
At 08:08 20/03/2010 +0100, Werner LEMBERG wrote: Can you provide a font which I can use to do some debugging? Which parameters shall I use for, say, ftview? Hi Werner, this is a PostScript font, not a TrueType, and as usual it depends on using Ghostscript as the FreeType client, so I can't easily do this. The problem is that all the matrix transforms and so on are created to fit the GS requirements, it would be difficult if not impossible to recreate these rather exacting conditions elsewhere. However, I did notice while reading ftraster.c that it can be built stand-alone without the rest of FreeType (I hope that's not just a legacy comment ;-) So what I plan to do is create a *very* simple test harness that feeds in the problematic numbers, and debug my way through the code. Assuming that works, would that be OK to pass along to you ? I should probably open an issue at Savannah if I do that I guess. Ken ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] inconsistently dropping sub-pixel features
Hi James, all, At 10:49 18/03/2010 -0400, James Cloos wrote: It looks like ftraster.c:Vertical_Sweep_Drop() is responsible for that. Actually this routine never gets called in either case. It seems the vertical pass processing decides there is nothing to do. That is, in Render_Single_Pass for the vertical pass, fProfile ends up as NULL, so we don't call Draw_Sweep. I wonder whether the Overshoot_Top and Overshoot_Bottom flags remain constatnt when the glyph is flipped with FT_Set_Transform()? The flags do seem to be reversed, the 'working' case gets Overshoot_Top while the flipped, nonworking, case gets Overshoot_Bottom. This appears to be due to the fact that the glyph vertical direction is reversed, because the outline has been flipped. So instead of flowing up (in the working case) the glyph is marked as flowing down. It seems that in the 'working' case, ie where the glyph does not disappear, the pixels are marked by the *horizontal* drop out control code. The reason that the dropout correction doesn't get applied to the 'incorrect' case is because in ftraster.c:Horizontal_Sweep_Drop, line 2608: e1 = TRUNC( pxl ); if ( e1 = 0 e1 ras.target.rows ) pxl is -4096 and e1 drops to -1, so we don't mark the pixel in the raster. pxl is set from either e1 or e2, which according to the comment are the centres of the pixels. I think these are not expected to both be below 0 I'm not certain why this is happening of course, I don't understand the code well enough yet. I believe it is something to do with offsetting the outline by half a pixel. This results in the lowest bound of the outline becoming -2048 (-half a pixel) while the upper bound becomes -448 (-7 64ths of a pixel). Because we have offset the outline like this, it lies entirely outside the current pixel. The flipped glyph works because after offset by half a pixel it still has an upper bound inside the current pixel, and so it gets set. Ken ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] inconsistently dropping sub-pixel features
Hi James, At 10:49 18/03/2010 -0400, James Cloos wrote: KS This is the point for discussion, it seems to me that the location KS of the feature within the pixel should not have any effect on KS whether the pixel is marked or not, that should only depend (In my KS opinion of course) on the size of the feature. It looks like ftraster.c:Vertical_Sweep_Drop() is responsible for that. I wonder whether the Overshoot_Top and Overshoot_Bottom flags remain constatnt when the glyph is flipped with FT_Set_Transform()? Good question, I'll try and find out this afternoon (dragged away to something else temporarily). If Vertical_Sweep_Drop() is the problem, chaning it to test more than just =50% may have significant effects elsewhere. I'd guess it probably might, again I'll try and find the time to try it and see. Thanks for your reply, much appreciated! Ken ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] inconsistently dropping sub-pixel features
Hi all, This may or may not be regarded as a bug, so I thought I'd put it up for discussion before potentially raising it as an issue. Background === I've been interfacing Freetype with Ghostscript for some time. The project is going pretty well on the whole, but as you can imagine we have a large number of test files to run and there are still some outstanding issues which we are working our way through. In this case the build with FreeType is dropping some glyphs at low resolution, which the regular Ghostscript build doesn't do, and I've been looking into why. After some investigation it transpires that FreeType is dropping the glyph because it is very small. In this case its a 'underline' character, and at 72 dpi the glyph is 25 64ths of a pixel high. It seems that this is regarded as too small to render, and so the whole glyph gets elided. I don't have an issue with that, at some point we obviously need to stop rendering very small features. However When rendering on a different device, at the same resolution, the glyph doesn't drop out. The only difference is the transformation that gets applied. In the second device we are drawing 'upside down', so we use FT_Set_Transform to 'flip' the glyph vertically. Details The glyph is, as noted, an underline and more than that it lies entirely below the baseline. (This is a PostScript font). After interpretation the outline points are: 500 -125 500 -75 0 -75 0 -125 When using the regular transformation, in ftrend1.c, ft_raster1_render, the outline points become: 252 -64 252 -39 0 -39 0 -64 and the 'control box' is calculated as: 0 -64 252 -39 Because the control box is below 0, FT_Outline_Translate moves the entire glyph 'up' sufficiently to make the lowest point has a y co-ordinate of 0. So the final outline points are: 252 0 252 25 0 25 0 0 This renders as 4 'white' (unmarked) pixels. Now, when the 'y flip' transformation is used we see that in ft_raster1_render the outline points are: 252 64 252 39 0 39 0 64 The control box is: 0 39 252 64 Because the minimum y co-ordinate is 0 FT_Translate_Outline does nothing and this is the outline we feed into raster_render. This results in a line of 'black' (marked) pixels. So why the difference ? I'm debugging my way through the rendering code to try and establish that precisely, but broadly its because of the position of the feature within the pixel. By altering the outline points in the debugger (fortunately its a nice simple glyph) I can move the outline around and I see the following: If the feature lies completely below one half pixel (ie yMax 32) then the whole glyph is elided. If any part of the glyph lies above half the pixel (ie yMax = 32) then the pixel is marked. This is the point for discussion, it seems to me that the location of the feature within the pixel should not have any effect on whether the pixel is marked or not, that should only depend (In my opinion of course) on the size of the feature. An example reason why the inconsistency is a problem is because we can be in a situation where alternate pages are 'flipped' vertically, for duplex printing. We don't want the presence/absence of very small features to depend on whether the page is recto or verso. Thanks for your time reading this rather lengthy post, I'd welcome any thoughts or other opinions. Ken - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - TASK: Shoot yourself in the foot. C: You shoot yourself in the foot. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] What is 26.6 fractional points?
At 19:21 13/01/2010 +, rsr wrote: Hi, Can any one please explain me what is nominal width, 26.6 fractional points Its a way of representing a non-integer number in a 32-bit word. The first 26 bits are used to represent the integer portion of the number so the integer can vary from 0 to 67,108,864. The remaining 6 are used to represent the fractional portion. Do a Google for fixed precision arithmetic or see Wikipedia http://en.wikipedia.org/wiki/Fixed-point_arithmetic You *are* a software developer, right ? ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: improved incremental interface for metrics
At 17:03 22/06/2009 +0200, Werner LEMBERG wrote: The `FT_Incremental_MetricsRec' expects integer values. My suggestion is to introduce a new function `get_fractional_glyph_metrics'; if this function is defined, use it, otherwise use `get_glyph_metrics'. Objections? Looks fine to me, should be easy enough to implement. I've cc'ed a couple of other people to solicit opinions and will let you know if anyone objects. It does look like GS is deliberately ignoring some of the values returned in the metrics structure from the 'get_glyph_metrics' function though, I wonder why... Ken ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
