Re: Bug report: Allow CFF based OT fonts with missing map table
Derek, On Fri, May 31, 2024 at 2:23 PM Derek B. Noonburg wrote: > For what it's worth, I've encountered the same problem in a few PDF > files. In all the cases I've seen, the OpenType file contains just the > 'CFF ' table. My code checks for a missing 'head' table, and in that > case it extracts the CFF blob and handles it as a CFF (not OpenType) > font. > > I haven't run into a font that has 'head' and 'CFF ', but not 'cmap'. > If that's what you have, it would be a problem for my code, too. Please leave a comment at https://gitlab.freedesktop.org/freetype/freetype/-/issues/1278 If you can attach an example PDF file with such font. It'd be even better if you proposed an MR. Thanks, Alexei
ftgamma
Hi Ahmet Actually, src/ftgamma.c is the easiest app to follow with the least complicated code. Let me know if you have questions. Alexei
Re: Gitlab-ci? Re: Another c++ compile failure...
Hi Hin-Tak, These macros were never used before. I fixed them. Now I think they made the code less readable and I might revert to the old code. Thanks, Alexei On Wed, May 22, 2024 at 6:12 PM Hin-Tak Leung wrote: > > Actually it might be a good idea to stick CC=g++/clang++ as an additional job > in .gitlab-ci.yml ? I mean, it already does gcc and clang. > > On Wednesday 22 May 2024 at 23:05:47 BST, Hin-Tak Leung > wrote: > > > Should be obvious - needs casting from "void *" to "unsigned char *" and > etc... > > Shouldn't be too hard to see yourself with CC=c++ when building... > > In file included from > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/truetype.c:22: > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/ttgload.c:421:14: > error: assigning to 'FT_Byte *' (aka 'unsigned char *') from incompatible > type 'FT_Pointer' (aka 'void *') > 421 | if ( FT_DUP( exec->glyphIns, p, n_ins ) ) > | ^~ > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:378:29: > note: expanded from macro 'FT_DUP' > 378 | FT_MEM_SET_ERROR( FT_MEM_DUP( dst, address, size ) ) > | ~~^~ > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:375:19: > note: expanded from macro 'FT_MEM_DUP' > 375 | (dst) = ft_mem_dup( memory, (address), (FT_ULong)(size), > ) > | ^ > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:231:38: > note: expanded from macro 'FT_MEM_SET_ERROR' > 231 | #define FT_MEM_SET_ERROR( cond ) ( (cond), error != 0 ) > | ^~~~ > In file included from > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/truetype.c:23: > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/ttgxvar.c:2718:12: > error: assigning to 'FT_MM_Var *' (aka 'FT_MM_Var_ *') from incompatible > type 'FT_Pointer' (aka 'void *') > 2718 | if ( FT_DUP( mmvar, ttface->blend->mmvar, > ttface->blend->mmvar_len ) ) > | > ^~~ > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:378:29: > note: expanded from macro 'FT_DUP' > 378 | FT_MEM_SET_ERROR( FT_MEM_DUP( dst, address, size ) ) > | ~~^~ > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:375:19: > note: expanded from macro 'FT_MEM_DUP' > 375 | (dst) = ft_mem_dup( memory, (address), (FT_ULong)(size), > ) > | ^ > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/include/freetype/internal/ftmemory.h:231:38: > note: expanded from macro 'FT_MEM_SET_ERROR' > 231 | #define FT_MEM_SET_ERROR( cond ) ( (cond), error != 0 ) > | ^~~~ > 2 errors generated. > make: *** > [/__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/src/truetype/rules.mk:60: > /__w/freetype2-demos-skia/freetype2-demos-skia/freetype2/objs/truetype.lo] > Error 1 > /__w/freetype2-demos-skia/freetype2-demos-skia > Error: Process completed with exit code 1. -- Alexei A. Podtelezhnikov, PhD
Re: [PATCH v2] * builds/windows/ftsystem.c: Correctly detect UWP
> On May 20, 2024, at 04:54, Erin Melucci wrote: > > >_WINRT_DLL:…. /ZW This option seems appropriate https://learn.microsoft.com/en-us/cpp/porting/how-to-use-existing-cpp-code-in-a-universal-windows-platform-app?view=msvc-170 > is this always the case when compiling freetype for UWP? We don’t do it ourselves except in gitlab CI through meson, without /ZW, which looks rather unconventional now. I cannot find good examples to follow. Alexei
Re: Compiling grx11.o
Hi Ahmet, Good to hear from you. I doubt that #ifdef TEST might be useful for you. It has been a dead code for years. What is important is understanding the basic workflow. Notice that the main() programs eventually go into do-while(!Process_Event()) loop. In other words they repeatedly grListenSurface(), which informs if a key was pressed or a window resized. Then the main program redraws the canvas and calls grRefreshSurface(), etc, etc, etc All this stush you should not change, The project is what happens in grListenSurface and grRefreshSurface on macOS. Of course, X11 and Windows do stuff slightly differently there. So you might want to familiarize what surface->refresh_rect and surface->listen_event do on X11 and Windows. Alexei On Sat, May 18, 2024 at 4:34 PM Ahmet Göksu wrote: > > Hello, > First, sorry for delay, I am studying for my final exams that will held > beginning of June. > I am playing with graph/grx11 at the same time. > > Those I what I did so far: > -Research for X11 > -Compiled all the demos and runned them > -Studied build process of graph apps > > I wanted to compile grx11.c by itself to see the output application well > so deleted > > #ifdef TEST > #if 0 > > #endif > #endif > > lines to compile it with its main function. but that time i got huge amount > of errors such as > > /freetype-demos/graph/x11/grx11.c:1529:5: error: call to undeclared function > 'grInit'; ISO C99 and later do not support implicit function declarations > [-Wimplicit-function-declaration] > grInit(); > > > I need to link it with the graph but getting complicated. > > I wanted inform you about the progress and ask if I am on the right path. > > Best, > Goksu > goksu.in -- Alexei A. Podtelezhnikov, PhD
Re: [PATCH v2] * builds/windows/ftsystem.c: Correctly detect UWP
Apparently, WINAPI_FAMILY_GAMES is too new to use. Should we just check ifdef _WINRT_DLL?Alexei A Podtelezhnikov, PhDOn May 17, 2024, at 12:33, Alexei Podtelezhnikov wrote:Erin,We cannot use WINAPI_FAMILY_PARTITION(), because some other compilers might choke on it. Even old MSVC might not be happy. So we have to keep it simple for other compilers to understand.AlexeiOn May 17, 2024, at 12:04, Erin Melucci wrote:Hi Alexei,yes, that is correct - that patch is all that is needed to get FreeType to compile using the GDK.`CreateFileMappingFromApp()` and related calls are exclusive to WINAPI_PARTITION_APP.A better check would be:---WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_APP) && !WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)---but that requires the Windows 10 SDK: I didn't want to break the build for anyone out there using older headers.On Fri, May 17, 2024 at 5:17 PM Alexei Podtelezhnikov <apodt...@gmail.com> wrote:Hi Erin, Just to confirm, you could compile FreeType for Xbox. The stuff in that ifdef was not necessary. Correct? Alexei > On May 17, 2024, at 10:25, Erin Melucci <emelu...@opera.com> wrote: > > > This is not the proper way to detect API availability but it's the least-distuprive change possible to fix building for the GDK (Microsoft Store for games, Xbox). > --- > > Changes since v1: > * Added missing backslash > > --- > > builds/windows/ftsystem.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/builds/windows/ftsystem.c b/builds/windows/ftsystem.c > index 3a56834f6..f8b7126ad 100644 > --- a/builds/windows/ftsystem.c > +++ b/builds/windows/ftsystem.c > @@ -197,7 +197,8 @@ > > > /* non-desktop Universal Windows Platform */ > -#if defined( WINAPI_FAMILY ) && WINAPI_FAMILY != WINAPI_FAMILY_DESKTOP_APP > +#if defined( WINAPI_FAMILY ) && WINAPI_FAMILY != WINAPI_FAMILY_DESKTOP_APP \ > + && WINAPI_FAMILY != WINAPI_FAMILY_GAMES > > #define PACK_DWORD64( hi, lo ) ( ( (DWORD64)(hi) << 32 ) | (DWORD)(lo) ) > > -- > 2.44.0.windows.1 > > -- Erin Melucci | Assistant Engineer, GameMaker Compiler Teamemelu...@opera.comThe information in this email and any attachments is CONFIDENTIAL INFORMATION and is solely for the attention of the intended recipient. If you are not the intended recipient, then you have received this message in error and therefore reading it, copying it, or in any way disclosing its content to any other person is unauthorized. If you have received this message in error, please notify the sender by reply email and then immediately delete this email (including any attachments).
Re: [PATCH v2] * builds/windows/ftsystem.c: Correctly detect UWP
Erin,We cannot use WINAPI_FAMILY_PARTITION(), because some other compilers might choke on it. Even old MSVC might not be happy. So we have to keep it simple for other compilers to understand.AlexeiOn May 17, 2024, at 12:04, Erin Melucci wrote:Hi Alexei,yes, that is correct - that patch is all that is needed to get FreeType to compile using the GDK.`CreateFileMappingFromApp()` and related calls are exclusive to WINAPI_PARTITION_APP.A better check would be:---WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_APP) && !WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)---but that requires the Windows 10 SDK: I didn't want to break the build for anyone out there using older headers.On Fri, May 17, 2024 at 5:17 PM Alexei Podtelezhnikov <apodt...@gmail.com> wrote:Hi Erin, Just to confirm, you could compile FreeType for Xbox. The stuff in that ifdef was not necessary. Correct? Alexei > On May 17, 2024, at 10:25, Erin Melucci <emelu...@opera.com> wrote: > > > This is not the proper way to detect API availability but it's the least-distuprive change possible to fix building for the GDK (Microsoft Store for games, Xbox). > --- > > Changes since v1: > * Added missing backslash > > --- > > builds/windows/ftsystem.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/builds/windows/ftsystem.c b/builds/windows/ftsystem.c > index 3a56834f6..f8b7126ad 100644 > --- a/builds/windows/ftsystem.c > +++ b/builds/windows/ftsystem.c > @@ -197,7 +197,8 @@ > > > /* non-desktop Universal Windows Platform */ > -#if defined( WINAPI_FAMILY ) && WINAPI_FAMILY != WINAPI_FAMILY_DESKTOP_APP > +#if defined( WINAPI_FAMILY ) && WINAPI_FAMILY != WINAPI_FAMILY_DESKTOP_APP \ > + && WINAPI_FAMILY != WINAPI_FAMILY_GAMES > > #define PACK_DWORD64( hi, lo ) ( ( (DWORD64)(hi) << 32 ) | (DWORD)(lo) ) > > -- > 2.44.0.windows.1 > > -- Erin Melucci | Assistant Engineer, GameMaker Compiler Teamemelu...@opera.comThe information in this email and any attachments is CONFIDENTIAL INFORMATION and is solely for the attention of the intended recipient. If you are not the intended recipient, then you have received this message in error and therefore reading it, copying it, or in any way disclosing its content to any other person is unauthorized. If you have received this message in error, please notify the sender by reply email and then immediately delete this email (including any attachments).
Re: [PATCH v2] * builds/windows/ftsystem.c: Correctly detect UWP
Hi Erin, Just to confirm, you could compile FreeType for Xbox. The stuff in that ifdef was not necessary. Correct? Alexei > On May 17, 2024, at 10:25, Erin Melucci wrote: > > > This is not the proper way to detect API availability but it's the > least-distuprive change possible to fix building for the GDK (Microsoft Store > for games, Xbox). > --- > > Changes since v1: > * Added missing backslash > > --- > > builds/windows/ftsystem.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/builds/windows/ftsystem.c b/builds/windows/ftsystem.c > index 3a56834f6..f8b7126ad 100644 > --- a/builds/windows/ftsystem.c > +++ b/builds/windows/ftsystem.c > @@ -197,7 +197,8 @@ > > > /* non-desktop Universal Windows Platform */ > -#if defined( WINAPI_FAMILY ) && WINAPI_FAMILY != WINAPI_FAMILY_DESKTOP_APP > +#if defined( WINAPI_FAMILY ) && WINAPI_FAMILY != WINAPI_FAMILY_DESKTOP_APP \ > + && WINAPI_FAMILY != WINAPI_FAMILY_GAMES > > #define PACK_DWORD64( hi, lo ) ( ( (DWORD64)(hi) << 32 ) | (DWORD)(lo) ) > > -- > 2.44.0.windows.1 > >
Re: small c++ breakage in current freetype git HEAD
On Mon, May 6, 2024 at 2:12 PM Hin-Tak Leung wrote: > I have upgraded to fc40 last week, and there has been some breakage of > skia-python against current skia lately, so I thought I'd update and rebuild > the skia-enabled ft2-demos, now ported over to github CI against freetype git > head. (next e-mail). Since skia is c++, requires setting CC=c++. Found a > small breakage in current freetype git head after 2.13.2 . Diff attached - > should be obvious. > > The actual error is that "enum" is a proper type in c++, and not equivalent > to "int" (as in c), so must be casted as such. Alternatively, T1_FIELD_TYPE_NONE could be used. For some reason T1_FIELD_LOCATION_NONE = 0 is not defined. Alexei
Re: which language you would use for X11-less macOS graphic framework?
On Sat, May 4, 2024 at 10:19 AM Sean McBride wrote: > > Me too. We are talking about an API which opens a window and shows an > > uncompressed pixel buffer in whatever language.Then it passes on > > keystrokes, receives an updated pixel buffer, and updates the window with > > it. > > Is that what we're looking to do? If so, you might also look at NSWindow and > NSView. > > Something else to consider: what is the oldest version of macOS you want to > support with this? Perhaps, this is it. I think we need a few years back and as much as reasonable forward. SetDIBitsToDevice of legacy GDI still works under Windows 11.
Re: Accounting for SHELL in ./configure
> > The main purpose of going through all this trouble is long-term > reproducibility of our scientific publications/results. Reproducibility is not equal to determinism.
Re: which language you would use for X11-less macOS graphic framework?
Xlib uses XPutImage. Windows uses SetDIBitsToDevice. What does macOS use?
Re: which language you would use for X11-less macOS graphic framework?
Forgot to mention window resize events… Again the goal is to remove dependencies like XQuartz and make it work without it. Adding Qt or Py dependencies is not a solution. Or this a different project. > On May 2, 2024, at 10:37, Alexei Podtelezhnikov wrote: > > >> >> Am I missing some points? > > Me too. We are talking about an API which opens a window and shows an > uncompressed pixel buffer in whatever language.Then it passes on keystrokes, > receives an updated pixel buffer, and updates the window with it. > > We are talking about really basic window programming for macOS. The pixel > buffer is already prepared in a system-independent fashion.
Re: which language you would use for X11-less macOS graphic framework?
> Am I missing some points? Me too. We are talking about an API which opens a window and shows an uncompressed pixel buffer in whatever language.Then it passes on keystrokes, receives an updated pixel buffer, and updates the window with it. We are talking about really basic window programming for macOS. The pixel buffer is already prepared in a system-independent fashion.
Re: Hello Again
Welcome back, Ahmet! I look forward to working with you over the summer. We have a warm-up month to chat about the project without any specific goals. I suggest that you play with our demos using XQuartz backend, research possible macOS native API and ask Suzuki some random questions about it. Best regards, Alexei On Wed, May 1, 2024 at 3:31 PM Ahmet Göksu wrote: > > Hello! > Its Ahmet Goksu, last years GSoC contributor on ftbench. > This year, I will be contributing development graphics backend natively on > macOS without X11. > > Its so exciting to be here again! > > here are my infos to connect: > > https://www.linkedin.com/in/ahmetgoksu/ > https://github.com/goeksu > https://resume.goksu.in > > Best, > Goksu > goksu.in -- Alexei A. Podtelezhnikov, PhD
Re: Accounting for SHELL in ./configure
On Wed, May 1, 2024 at 7:11 PM Mohammad Akhlaghi wrote: > > Do you mean here? > > https://gitlab.freedesktop.org/freetype/freetype/-/tree/master/builds/unix > ... Please start at README and README.git or here: https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/docs/INSTALL.UNIX There is this peculiar autogen.sh to be run initially... Still fails? How? FreeType is successfully and routinely built on a wide variety of platforms even without autotools. Please describe your setup carefully before jumping to quick solutions. Perhaps we can help. Alexei
Re: Proposal for Integrate ftbench into FreeType's build structure - GSoC 2024
Hi Ahmet Thanks. Please submit it. This is going to be to be rather low level programming. On windows, it uses GDI, which is ancient. We have untested Carbon implementation for old Mac pre X. It might be Quartz 2D for modern os. I will rely on you to research this. It should be light weight. Alexei > On Apr 12, 2024, at 07:58, Ahmet Göksu wrote: > > > Hello Alexei, > > I wrote my proposal for the related project. > > Best, > Goksu > goksu.in >> On Apr 12, 2024 at 13:41 +0300, Alexei Podtelezhnikov , >> wrote: >> Excellent! >> Take a look at Windows and X11 implementations >> https://gitlab.freedesktop.org/freetype/freetype-demos/-/tree/master/graph/x11 >> https://gitlab.freedesktop.org/freetype/freetype-demos/-/tree/master/graph/win32 >> >> Right now macOS needs XQuartz to run our graphics demos. The goal is >> to implement it natively. It needs basic window opening, displaying a >> flat bitmap, interpreting keyboard strikes.This is less than 1000 >> lines on Windows and X11. >> >> Please submit a proposal if you are interested >> >> Alexei >> >>> On Fri, Apr 12, 2024 at 3:28 AM Ahmet Göksu wrote: >>> >>> Hello Alexei, >>> Yes, I am using mac with m2 processor. I would happy to contribute. >>> >>> Best, >>> Goksu >>> goksu.in >>> On Apr 12, 2024 at 6:05 AM +0300, Alexei Podtelezhnikov >>> , wrote: >>> >>> Hi Akhmet, >>> >>> Do you program on macOS? I am looking for someone to write >>> freetype-demos graphics backend natively on macOS without X11. This >>> could be a GSoC project. >>> >>> Alexei >> >> >> >> -- >> Alexei A. Podtelezhnikov, PhD > >
Re: I want free server application
> I don't understand anything here. It depends whether here is there.
Re: Creating a FreeType GitLab merge request
> On Jan 22, 2024, at 12:45, Hin-Tak Leung wrote: > > FWIW, this seems to duplicate functionality in harfbuzz, and also a mere > subset, for that matter? On the other hand, the dysfunctional kerning API, which exists, is misleading. Partial GPOS support to fulfill the API promise is not a bad idea. The line could be drawn exactly there at the existing API. I agree that the scope of the change should be clearly defined.
Re: Creating a FreeType GitLab merge request
Understandably, you cannot edit files in place. You need an account on gitlab.freedesktop.org and [fork] FreeType, which has been done 114 times already. Alternatively, send your patch here with a good description. Alexei On Fri, Jan 19, 2024 at 9:03 PM David Saltzman wrote: > > Hi, > > I'd like to submit a feature to FreeType. https://freetype.org/developer.html > recommends doing so via GitLab merge requests. But when I tried pushing to a > branch on the command line, git said "ERROR: You are not allowed to push code > to this project." Then I tried clicking edit->web IDE, and that said I can't > edit files in that project and I need to create a new fork. But creating a > fork from that link fails, and the fork button is greyed out on the main page. > > So do I need to join or be added to some access list, or are there other > tricks for permissions or tools to use to submit GitLab merge requests? > > Thanks, > David -- Alexei A. Podtelezhnikov, PhD
Re: The current state of rendering and overlap
> > I think I agree with this - the spec should not bend on > limitations/quirks/bugs in freetype. It isn't the role of the spec to > recommend fonts to be built in with special "hints", just because one > implementation, in its current state, can't render satisfactorily without > those "hints". s/freetype/any coverage integration/ ;) AFAIK this bug is present in macOS, but they might use FreeType, but then FreeType is everything except Windows.. Some quirks then. ;)
Re: The current state of rendering and overlap
> What you're suggesting, if I understand correctly, is that the existing flags > available in the glyf implementation, and a new flag made available in the > CFF2 implementation, be maintained not on the basis of whether a glyph has > overlap, but by the designer based on whether the FreeType renderer in > particular does a good job at rendering the glyph without the flag. This is partly correct. The genesis of rasterizers is not that broad. There are only so many methods for calculating the pixel coverage. (1) Microsoft, reading between the lines in TrueType specifications, is oversampling using their original bi-level rasterizer. That is using a 4x4=16 grid in each pixel and counting how many pixels are inside a contour. This is slow but immune to the overlap artifacts. They do not care about this issue because it is not their problem and they let the SIMPLE_OVELAP flag go too easily in the variation fonts. (2) Rather accurate trapezoid integration of coverage originated in LibArt and adopted by FreeType, but not only FreeType. There are some hints that Apple uses it as well. That is about it. I don't think Adobe does something completely different. The integration methods need oversampling (or, rather, resolution increase) only when it is needed for the overlaps. Otherwise they are pretty accurate and much faster than sampling. So when I advocate for taking into account the integration rasterizer, I don't just mean FreeType, but even that is a huge market share (Android, etc.). > This isn't unimaginable, but it comes close. What I would say is: If this is > how those flags should be used, that convention should presumably be included > in the portions of the OpenType/Open Font Format specification that document > such flags. And this is just not how contemporary specifications work, and > any such suggestion would almost certainly be rejected. It's the job of the > downstream stacks to either deal with things as they come or filter up ideas > that can be generalized -- and bought into -- by all the various parties, > including the various other implementations. It is not the job of the > specification to bend to the unilateral decisions of given implementations. I tried to give more justice to the OVERLAP flags in the specs: https://github.com/MicrosoftDocs/typography-issues/issues/626 For what it is worth there is only two viable methods for the font rasterization, one of which needs the overlap flags explicitly when needed. > Anyway, given that there will be CFF2 fonts that have no such flag, any of > which could have glyphs with overlap, what should be done about those? Should > I add FT_OUTLINE_OVERLAP to outlines extracted from such fonts or not? I would not do it by default.
Re: The current state of rendering and overlap
> The 4-fold speed difference is not an optimization, it is a liability which should be taken explicitly. Some overlaps at single points are not that noticeable. Only long runs along the axes are bad. So I disagree with default oversampling even for variation fonts. Let me explain that not all overlaps are bad - see attached "X". The middle is acceptable because the contours intersect at single points rather than edges. Therefore the artifacts are isolated at single pixels and barely noticeable. The situation at the top is horrible because the stems extend through the serif bars up to the edge. Multiple adjacent pixels are improperly dark. If only the font designers end the stems in the middle of the serif bars, nobody would even notice anything. The font designers should be aware of this and decide if FT_OUTLINE_OVERLAP is truly necessary. [image: ftgrid.png]
Re: The current state of rendering and overlap
> > CFF2 is released, has been for years. As far as I know there's no solid > convention for ignoring unrecognized operators in a CharString, so this would > be CFF2 minor 1 at best. Which would be years out in terms of support. We can do it in days for FreeType, then it is a matter of upgrading downstream.. Behdad floats cubic outlines in TrueType, which is a much larger undertaking but not impossible. > > Practically speaking I don't think this could wind up being a "this glyph has > overlap" flag, as in CFF2 overlap is valid anywhere. If something were added > it would be more like a "this glyph doesn't have overlap, you can optimize > the rendering" flag. The 4-fold speed difference is not an optimization it is a liability which should be taken explicitly. Some overlaps at single points are not that noticeable. Only long runs along the axes are bad. So I disagree with default oversampling even for variation fonts. > > Behdad - there's no provision for a relevant flag in VARC currently, correct? > (I'm not sure there was one in the glyf-based system, as I don't remember a > place where the flag would have lived.)
Re: The current state of rendering and overlap
Why? The sequence 0x0c 0x40 is reserved and not used for example. > I'm afraid the horse has left the barn as far as that goes. > > Skef > >> On 12/19/23 04:23, Alexei Podtelezhnikov wrote: >> I would suggest that CFF2 invent a special charstring to mark overlaps >> with FT_OUTLINE_OVERLAP only when necessary. Let us know to implement >> it in FreeType.
Re: The current state of rendering and overlap
Hi Behdad >> >>> Note that freetype does not use the overlap flags to determine the path >>> fill rule (winding vs even-odd), it always uses winding for TT or CFF2 >>> variable fonts, as the spec mandates; the discussion here is about freetype >>> using the (TT glyf only) overlap flags to enable what Alexei calls "4x4 >>> bilevel oversampling" in order to mitigate the effects of increased pixel >>> coverage where paths overlap inside a glyph. I'm just summarizing the above >>> linked fonttools issue, but I don't fully understand the technical details >>> of this rendering technique. >>> CFF2 doesn't have an equivalent mechanism to say "this glyph may contain >>> overlaps", which prompted this specific email thread. >> CFF was even-odd. CFF2 is non-zero winding. >> This is about the coverage calculation rather than the fill rule. Suppose >> two contours cover half-pixel each. The integral coverage depends on how >> they overlap over that pixel. The only way to reasonably deal with it is >> oversampling. > > I might be wrong, but I think cairo simplifies the shape, merging the > overlaps. I think some font tools do that then saving static instances from variable fonts. It is a not easy on the fly.
Re: The current state of rendering and overlap
> > Note that freetype does not use the overlap flags to determine the path fill > rule (winding vs even-odd), it always uses winding for TT or CFF2 variable > fonts, as the spec mandates; the discussion here is about freetype using the > (TT glyf only) overlap flags to enable what Alexei calls "4x4 bilevel > oversampling" in order to mitigate the effects of increased pixel coverage > where paths overlap inside a glyph. I'm just summarizing the above linked > fonttools issue, but I don't fully understand the technical details of this > rendering technique. > CFF2 doesn't have an equivalent mechanism to say "this glyph may contain > overlaps", which prompted this specific email thread. >> CFF was even-odd. CFF2 is non-zero winding. >> This is about the coverage calculation rather than the fill rule. Suppose two contours cover half-pixel each. The integral coverage depends on how they overlap over that pixel. The only way to reasonably deal with it is oversampling.
Re: The current state of rendering and overlap
> >> >> It's easy enough to add FT_OUTLINE_OVERLAP to any glyph loaded from a >> CFF2 font. Whether that makes sense is one thing I'd like advice about. >> There's currently no such code. > > I would suggest that CFF2 invent a special charstring to mark overlaps > with FT_OUTLINE_OVERLAP only when necessary. Let us know to implement > it in FreeType. https://www.w3.org/TR/WOFF2/#p1 WOFF2 is moving towards accepting explicit overlap flags. Perhaps CFF2 can spare a reserved operator or a two-byte operator.
Re: The current state of rendering and overlap
> It's easy enough to add FT_OUTLINE_OVERLAP to any glyph loaded from a > CFF2 font. Whether that makes sense is one thing I'd like advice about. > There's currently no such code. I would suggest that CFF2 invent a special charstring to mark overlaps with FT_OUTLINE_OVERLAP only when necessary. Let us know to implement it in FreeType.
Re: The current state of rendering and overlap
> It seemed like the simplest answer to this was to mark all outlines > extracted from a CFF2 font as FT_OUTLINE_OVERLAP, because there's no > inexpensive method of detecting it. And so I added code to do that and > verified it was heeded in ftsmooth.c -- but the ftgrid output didn't > look any different. FT_OUTLINE_OVERLAP mitigates the artifact but does not completely remove it. The 4x4 resolution increase might still have some residual artifacts. Further increasing it is impractical and prohibitive from the performance standpoint. I think this is the issue in your example. The most egregious overlaps which cover half-pixels are dealt with quite successfully. Alexei
Re: Which download to build for Windows 11 Pro?
Which file should I download for building freetype dll on Windows 11 Pro for use with Python?ubawurinna/freetype-windows-binaries: Windows binaries of FreeTypegithub.comBut if you insist on building it yourself, you should ask more specific question and describe your compilation tools.
Re: Freetype for Python. AttributeError: module 'freetype' has no attribute 'Face'
> > Both comments from Alex are wrong... > Yeah, I figured it out
Re: Freetype for Python. AttributeError: module 'freetype' has no attribute 'Face'
> I have bindings for freetype 2.4.0 for Python. I dont understand why that:
Do you realize that this version is 13 years old? I recently saw a current
FreeType version in the anaconda environment. Just saying…
>
> AttributeError: module 'freetype' has no attribute 'Face'
>
> is coming from:
>
> import freetype
> face = freetype.Face("Vera.ttf")
> face.set_char_size( 48*64 )
> face.load_char('S')
> bitmap = face.glyph.bitmap
> print(bitmap.buffer)
>
>
FreeType requires initialization (internal module loading). See if you can find
some _init_ method that you might need to call first.
Re: Progress update on alternative rendering engines project
Hi Anurag, Would you like to try smooth_malloc branch for fun? I will announce it soon. Alexei > On Oct 3, 2023, at 17:33, Anurag Thakur > wrote: > > > Hi all, > > Here's a quick update on the project status: > > I have implemented the "preloading" optimization where FreeType can perform > curve flattening at load time to reduce render > time later. > Although the difference in performance seems to be very little (since the > accumulation part takes the majority of rendering time) > (benchmarks attached). > > I am almost done with the rendering algorithm improvement from fontdue as > well. Benchmarks coming soon. > > Will send a more detailed report explaining my implementation in detail later > today and then will work towards the final submission. > > Regards, > Anurag > >
Re: ReactOS: stack vs heap
> > Wanted to point out that compiling with gcc and adding "-stack-usage=2000" to > get reports about stacks larger than 2000 bytes is probably the easiest way > to track down large stacks at the moment. Note that > af_cjk_metrics_init_widths (44480 bytes) and af_latin_metrics_init_widths > (52992 bytes) are by far the largest. cf2_interpT2CharString (27520 bytes) is > also surprisingly large. There are a few others like the rasterizer stacks > that are between 10-20kb which one may also want to look into, but these have > been less problematic on my experience (though that may have been due to the > even larger stacks being allocated first). Just wanted to point out how to > measure and that the rasterizer might not be the first place to look. That is surprisingly large. Someone should examine how much of it is actually used. The rendering pool of "visited cells" (pixels) is rather predictable for a given outline. That is why it is easy for me.
Re: ReactOS: stack vs heap
>> I will try the dynamic heap allocations for the rendering >> buffer. This might be the largest of them, I think. In addition, >> this should help with the rendering speed when rendering complex >> shapes like >> https://fonts.google.com/specimen/Cabin+Sketch. Currently, FreeType >> makes several attempts until a sub-band can fit into a static stack >> buffer. We should be able to fit it into a dynamic buffer easily. I >> wonder if CabinSketch should be about as complex as we can tolerate >> and refuse anything much more complex than this. A lot of time-outs >> will be resolved... > > Perhaps a hybrid approach is the right one: Use the current > infrastructure up to a certain size, being as fast as possible because > dynamic allocation overhead can avoided, and resort to dynamic > allocation otherwise. Werner, FreeType is not shy about allocating buffers to load a glyph. This is just one more I highly doubt that it matters even at small sizes. We always allocate FT_Bitmap even for rendering too. As a matter of fact FreeType loses to the dense renderers when rendering complex glyphs precisely because of multiple restarts to fit the small buffer. Alexei
Re: ReactOS: stack vs heap
Hi Ben, I will try the dynamic heap allocations for the rendering buffer. This might be the largest of them, I think. In addition, this should help with the rendering speed when rendering complex shapes like https://fonts.google.com/specimen/Cabin+Sketch. Currently, FreeType makes several attempts until a sub-band can fit into a static stack buffer. We should be able to fit it into a dynamic buffer easily. I wonder if CabinSketch should be about as complex as we can tolerate and refuse anything much more complex than this. A lot of time-outs will be resolved... Alexei On Thu, Aug 31, 2023 at 7:40 AM Ben Wagner wrote: > > I've been meaning for a long time to propose something like this. One (or > more) of those stacks is bigger than 50KB. While most desktop apps have > threads with large stacks (~xMBs) there are users that run many threads in > one process and force the stack size of the threads to be small (~xxKBs) to > enforce small stacks so that the stack memory stays hot. On macOS secondary > threads are also pretty small at 512KB. Calls to FreeType often happen deep > in some application layout code which often is taking up a bunch of stack > frames, so a sudden deep 50KB stack frame can be too big. > > In any event, I have seen these really big stack frames be an issue in > practice. I've so far generally been able to get around this issue but it > would be nice to not need the work arounds. I think a lot of people would be > happy if FreeType reduced the size of these stack frames. > > On Wed, Aug 30, 2023, 11:20 PM Alexei Podtelezhnikov > wrote: >> >> Hi folks, >> >> Found this patch from ReactOS >> https://git.reactos.org/?p=reactos.git;a=blob;f=sdk/lib/3rdparty/freetype/freetype_ros.diff >> >> Do you understand why they are so averse to large stack allocations? >> >> Thanks, >> Alexei >> -- Alexei A. Podtelezhnikov, PhD
ReactOS: stack vs heap
Hi folks, Found this patch from ReactOS https://git.reactos.org/?p=reactos.git;a=blob;f=sdk/lib/3rdparty/freetype/freetype_ros.diff Do you understand why they are so averse to large stack allocations? Thanks, Alexei
Re: ttfautohint's functionality from the removal of the infinality patch
> As long as v38 is different from v40, some part of it is closer than v40 to > MS/Apple's. Also fact. Also.. You are making it sound like we are handicapping FreeType. Then Phoronix or Slashdot will sensationalize it. OMG! OMG! OMG! Major FreeType regression! This is FUD! This is zero evidence that v40 is worse, Yes. I assert for you (and beating Phoronix to it): v40 has been the default for SIX YEARS and it is good!
Re: ttfautohint's functionality from the removal of the infinality patch
> "Better" is your personal opinion. Anyway, I think some of others' "personal > opinion" (different from yours) is simply based on familiarity - some people > are just more familiar with MS/Apple rendering, and therefore prefer it. In > the end of the day, FreeType is not MS/Apple font scaler. Fact. > > As long as v38 is different from v40, some part of it is closer than v40 to > MS/Apple's. Also fact. Not necessarily! This might be different in the opposite direction. The "fact" that v38 is closer to Microsoft has to be shown. Also, replication of Microsoft was *never* stated as an Infinalit goal. BTW https://github.com/pdeljanov/infinality-remix ... still no mention of Microsoft as gold standard. I am just saying what I know: Infinality was never *closer* to Microsoft than v40.
Re: ttfautohint's functionality from the removal of the infinality patch
Hi Hin-Tak On Fri, Aug 18, 2023 at 2:06 PM Hin-Tak Leung wrote: > I see the infinality patch is already gone (next release, 2.13.2 I guess - > bits of it was removed in 2.13.1 already). Infinality (v38) was substituted by v40 in 2.13.1. Anybody requesting v38 got v40 instead... and nobody even noticed. That is the whole point of the exercise: v40 is perfectly capable and better than just good enough. Now the code is physically gone for good. It is much better to improve faster and lighter v40 moving forward than dwelling on unmaintained, poorly understood, and riddled with exceptions v38. > FWIW, fontval will carry the reverse diff. Why? Or, more precisely, why do you think that either v38 or v40 were ever designed to mimic the corresponding versions of Microsoft engine? That was never the case. *Both* of FreeType implementations were based on principles described in https://learn.microsoft.com/en-us/typography/cleartype/truetypecleartype. Both! but neither was actually tested to reproduce Microsoft precisely. Much like we have no idea how Microsoft does ClearType filtering, except for some public papers. If anybody, Adobe helped here a lot more. Microsoft is multisampling for antialiasing, we don't. Therefore, FreeType != Microsoft in any sense, including v38 != 38 (GETINFO version). Alexei
Re: COLRv1 to gray/alpha question (& color-blindness question)
> Probably both approaches are wrong. I am asking that question both in terms > of the spec and in terms of implementation details - what is the > correct/recommended approach to render multi-layered 32-bit RGBA COLRv1 data > to a non-colour target media? My recommendation is to blend three times, each color separately.Then combine with appropriate non-equal weights. This should be correct. Perhaps, you can combine the color first, than blend using alpha.
Re: COLRv1 to gray/alpha question (& color-blindness question)
> > Hin-Tak, > > > This is probably both a spec question & a technical question. What is the > > recommendation for COLRv1 when the rendering target media is not capable of > > color? > > > > Are you asking about RGB to gray conversion? There are multiple specs with > > slightly different formulas and barely noticeable differences, with and > > without gamma correction. I’m is all pretty arbitrary without settled > > consensus. > > > Gray = 0.3R + 0.6G + 0.1B > > > is good enough. > > I am talking about 32-bit RGBA to 8-bit gray conversion, and I gave two > examples/directions - throwing away the RGB part (and use the alpha channel > as a mask on the current foreground colour), or throw away the A part, and > doing 24-bit colour to gray conversion like you suggested (or even just gray > = (r+g+b)/3). Alpha is colorless until blended. Therefore any conversion of RGB to alpha will produce random blending results because assuming black foreground is wrong even on gray surfaces. Hence, the blending should be done in color (on gray surface r=g=b), then the final result can be converted to gray once again for display as above. This is essentially what should happen in ftgrid/ftview if you choose 8-bit display, e.g.,"-d 800x600x8". A.
Re: COLRv1 to gray/alpha question (& color-blindness question)
Hin-Tak, > This is probably both a spec question & a technical question. What is the > recommendation for COLRv1 when the rendering target media is not capable of > color? Are you asking about RGB to gray conversion? There are multiple specs with slightly different formulas and barely noticeable differences, with and without gamma correction. I’m is all pretty arbitrary without settled consensus. Gray = 0.3R + 0.6G + 0.1B is good enough. A.
Re: ftview segfault on ArefRuqaaInk-Regular.ttf (one of google web fonts)
Hin-Tak, SVG rendering is handled by librsvg. If that buffer does not have correct dimensions set, you might have all kinds of crashes. Therefore, try updating that library. You might have a faulty version. Alexei
Re: ftview segfault on ArefRuqaaInk-Regular.ttf (one of google web fonts)
> Hmm. Then `ftview`'s default cache size should probably be increased > to cover both the number of characters/glyphs in Arabic and Indic > scripts, including (most of) the necessary ligatures. If I call > `ftview ArefRuqaaInk-Regular.ttf`, a bit more than 200 glyphs are > shown; IMHO this *must* fit into the cache. > > Am I missing something? The default cache size is 200,000. Just to cover a small screen of 640x480 with gray glyphs, we might need 300,000. If we go LCD or BGRA on a larger screen... Uh-oh. basically we have never had enough cache for ftview, even if it works. Anyway, until recently I was happy to create some rendering load in ftview for profiling and FTC was never showing up. A.
Re: ftview segfault on ArefRuqaaInk-Regular.ttf (one of google web fonts)
On Sun, May 14, 2023 at 9:08 AM Werner LEMBERG wrote: > > >> it's an SVG color font, and `ftview` lacks caching support for that > >> AFAICS. > > > > With the most-recent-used logic, caching does not do much for ftview > > when it outputs every different glyph once.The SVG speed is out of > > our hands. > > Well, it takes a lot of time if I press, say, F8. For this operation > a cache would help tremendously. FTC is designed for a limited memory. By the time you fill the screen, the top ones are already purged. Then you start from the top again, which are already forgotten. FTC is designed to keep an alphabet, not the whole unicode.
Re: ftview segfault on ArefRuqaaInk-Regular.ttf (one of google web fonts)
> it's an SVG color font, and `ftview` lacks > caching support for that AFAICS. With the most-recent-used logic, caching does not do much for ftview when it outputs every different glyph once.The SVG speed is out of our hands.
Re: ftdump can show the CID registry, ordering, and supplement?
Suzuki, > Currently, my patch cares only FT_Face->num_glyphs > for the face loaded by the t1cid driver. Do you > concern as "the num_glyphs is no more than the > declaration, there is no guarantee that the user > can get a glyph image of the CID within the range > 0...FT_Face->num_glyph, FT_Load_Glyph() test is reliable? In my opinion, only validated CIDs are interesting. Therefore, FT_Get_CID_From_Glyph_Index is confusing to me. It looks like it is useful for CFF only but not for Type 1. It looks like the we need different approaches: FT_Load for t1cid and FT_Get_CID for CFF. Do you know where I can find some CFF CID-fonts? Alexei
Re: ftdump can show the CID registry, ordering, and supplement?
Hi Suzuki, Using these fonts (https://resources.oreilly.com/examples/9781565922242/tree/master/adobe/samples) I learned that FT_Load_Glyph interprets the glyph_index as CID. Could you scan the CID range directly using FT_LOAD_NO_SCALE? Or, is this still too slow? Thanks Alexei On Thu, Apr 20, 2023 at 12:47 AM suzuki toshiya wrote: > > Dear Alexei, Werner, > > Here is reworked version, which assumes > "no zig-zag mapping is found by FT_Get_CID_From_Glyph_Index()". > > https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/commit/453de7aa3f9ccd54824ab3468c5a3b91507a86a9 > > ( > https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/commits/mr-ftdump-print-cid-ros-assume-order > ) > > > Regards, > mpsuzuki > > > On 2023/04/20 12:46, suzuki toshiya wrote: > > Dear Alexei, > > > > Umm, TN#5092 is a document in the world of pure CID-keyed font, > > so it does not care about the mapping between the CID and > > TrueType (or CFF) GID, so I'm unsure if it is a solid footstone > > to exclude the unordered CIDs. > > For example, "GB1 represents the first version of the ordering > > based on the Chinese GB 2312-80 character set" describes > > "how CID numbers are assigned to the characters? It is based > > on the order of GB 2312-80", it might be independent with > > the internal of CID-keyed font. > > > > But anyway, yet I have no concrete example to justify my > > concern about "zig-zag" mapping between GID and CID. > > > > OK, so I propose - I'll rework my patch based on the assumption > > "the larger GID is mapped to the larger CID, no zig-zag > > mapping from GID to CID", to avoid 64kByte array allocation. > > Then, when ftdump receives a font breaking this assumption, > > ftdump aborts with an error, and indicates an email address > > (or website?) to report the issue. Is it acceptable workaround? > > > > Regards, > > mpsuzuki > > > > On 2023/04/20 11:08, Alexei Podtelezhnikov wrote: > >> Dear Suzuki, > >> > >>> Indeed. If GID-CIDs are already sorted, it's easy to dump the > >>> available CIDs in a compressed syntax. Although I have no sample > >>> font including unsorted CIDs, I'm unsure whether it is required > >>> in some specifications. > >> > >> The order of CIDs is in "registry, *ordering*, and supplement". Also > >> it is mentioned in the specs (5092): "A character collection consists > >> of an ordered set of all characters". I think we can rely on that. > >> > >> If there is a CID to glyph index mapping in each file, why doesn't > >> FreeTyope generate a cmap? > >> > >> Thanks, > >> Alexei > > -- Alexei A. Podtelezhnikov, PhD
Re: ftdump can show the CID registry, ordering, and supplement?
Dear Suzuki, > Indeed. If GID-CIDs are already sorted, it's easy to dump the > available CIDs in a compressed syntax. Although I have no sample > font including unsorted CIDs, I'm unsure whether it is required > in some specifications. The order of CIDs is in "registry, *ordering*, and supplement". Also it is mentioned in the specs (5092): "A character collection consists of an ordered set of all characters". I think we can rely on that. If there is a CID to glyph index mapping in each file, why doesn't FreeTyope generate a cmap? Thanks, Alexei
Re: ftdump can show the CID registry, ordering, and supplement?
Dear Suzuki > BTW, if the 64kByte array to check CID availability can be > reduced to a 64kBit (= 8kByte for most architecture) array > by a bitshift calculation, is it the way to go? I agree that bitshift is too complicated. If the glyphs are sorted by CID, you might not need the temporary storage if you keep track of the previous CID and some format string tricks. I can work on that later by adopting the lines 676-707 (if the CIDs are sorted indeed). Thanks, Alexei
Re: ftdump can show the CID registry, ordering, and supplement?
>> The execution "ftdump -c" for OpenType/CFF fonts with "holes" in the >> implemented CIDs, like Hiragino fonts on macOS, generates the output >> ending with: >> >> -- >> (...Charmap printout...),2f9de,2f9df,2f9f4 >> >> /CIDSystemInfo dictionary >> Registry:Adobe >> Ordering:Japan1 >> Supplement: 7 >> >> Implemented CIDs: >> 0-20316,21072-21074,21371,21558,21722,21933,22920,23058,23059 >> -- >> >> >> The execution for real CID-keyed font generates the output ending >> with: >> >> -- >> (font type entries...) >> underline_thickness: 0 >> >> /CIDSystemInfo dictionary >> Registry:Adobe >> Ordering:Japan1 >> Supplement: 1 >> >> Implemented CIDs: >> 0-8359 >> -- >> >> Is this what you expected? > > This looks very nice, thanks! > > Minor issue in a comment: > > * setup 64k-bytes array to scan all CIDs > > should be > > * set up 64kByte array to scan all CIDs > > >Werner I like this too. Please commit. Alexei
Re: ftdump can show the CID registry, ordering, and supplement?
> Here is the 2nd revision, > > https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/compare/8a4879f6...c0267c89 > > To dump the ROS info, it needs "-n" option, as it is needed to dump /FontInfo > dictionary. > For the similarity with /FontInfo dumping, the syntax of the output is > changed. You certainly have a lot more experience with CID-keyed fonts. From my quick reading, they do not have CMap, which is provided separately. CIDinfo gives a clue which CMap is to be used. Therefore, it seems best to show this under Print_Charmaps. You might even consider verbose (-c) output with added FT_Get_CID_From_Glyph_Index output dump. Alexei
Re: ftdump can show the CID registry, ordering, and supplement?
> ftdump is not a font debugger, > but it would be much more helpful if it can dump the ROS info from > OpenType/CFF. I actually think that FreeType demos are the best font debugging tools out there. > My preliminary patch is > https://gitlab.freedesktop.org/mpsuzuki/ft2demos-mps-wip/-/commit/aa425196385b6639616b18291c7aa3a6d865a760 > > Does such a feature in ftdump make sense? I hope to hear your comments. This is great but please consider other output options. I am not familiar with ROS. The CID fonts without charmaps might need this instead. Or is this a name? It is a bit strange right after numeric metrics. Alexei
Re: permissiveness in FreeType for CFF fonts
>> We encountered a few (potentially not fully compliant with the >> specification) CFF fonts (i.e. CIDFontType0) that have enough >> information to be rendered, but FreeType throws an exception due to >> not having both the `head` and the `cmap` tables. > > Could you provide such a font for testing purposes? > >> I was wondering if the second `goto Exit;` in the following code >> could be changed to just logging a warning? > > Probably yes. I guess we didn't have a font that needs it otherwise. I just wonder about scaling in this scenario. Do we ever rely on unitsPerEm from head for CFF? Do we need anything else there? Alexei
Re: grep -E vs. egrep
> > Since neither grep -E nor egrep is portable any more, here is a > > patch that does essentially the same test as AC_PROG_EGREP for the > > top-level configure. Can be overridden with the EGREP envvar. > > Applied, thanks! Would sed be more portable here? The patterns are very easy here. $ make -v | sed -n -e '/GNU/p' -e '/makeapp/p' This would also be consistent with autogen.sh which stays away from grep. Alexei -- Alexei A. Podtelezhnikov, PhD
Re: FreeType INSTCTRL behavior (Po Lu)
> /* UNDOCUMENTED! The MS rasterizer doesn't allow the following */ > /* graphics state variables to be modified by the CVT program. */ On Mon, Feb 13, 2023 at 3:50 PM Hin-Tak Leung wrote: > I think it is probably mis-documented - the projection vector and rp1 are not > even per-glyph/contour parameter, but per contour fragment It does say that "Some [not all] state variables can be reset in the CVT Program." (1) Then it says that "instructions intended to move points within a particular glyph outline cannot be used in the CV Program." (2) I suppose you can figure out that projection vectors and references are *intended to move points*. It could be clarified. (1) https://learn.microsoft.com/en-us/typography/opentype/spec/tt_graphics_state (2) https://learn.microsoft.com/en-us/typography/opentype/spec/prep
Re: FreeType INSTCTRL behavior (Po Lu) (Re: Freetype-devel Digest, Vol 217, Issue 8)
> >> > these new values. > > You are looking at the outdated Apple's specifications. Please check > > with OpenType 1.9 instead: > > https://learn.microsoft.com/en-us/typography/opentype/spec/tt_instructions#instruction-execution-control > > > > Specifically, "INSTCTRL[ ] can only be executed in the CVT program." > > There are further clarifications > > https://learn.microsoft.com/en-us/typography/cleartype/truetypecleartype#instctrl > > > > Best, > > Alexei > > I don't see anything there that contradicts the behavior of my > interpreter, though. > > The control value program executes _NO_ INSTCTRL[] instructions > whatsoever, yet the reference points and the freedom vector are reset > after execution. How about this: https://learn.microsoft.com/en-us/typography/opentype/spec/prep? "The Control Value Program consists of a set of TrueType instructions that will be executed... before each glyph is interpreted."
Re: FreeType INSTCTRL behavior (Po Lu) (Re: Freetype-devel Digest, Vol 217, Issue 8)
Sorry, > > To establish a new default value for a graphics state variable, it is > > necessary to change the value of that variable in the control value > > program. Changes made in the control value program will apply to all > > subsequently processed glyphs unless INSTCTRL[] is used to inhibit > > these new values. You are looking at the outdated Apple's specifications. Please check with OpenType 1.9 instead: https://learn.microsoft.com/en-us/typography/opentype/spec/tt_instructions#instruction-execution-control Specifically, "INSTCTRL[ ] can only be executed in the CVT program." There are further clarifications https://learn.microsoft.com/en-us/typography/cleartype/truetypecleartype#instctrl Best, Alexei
Re: FreeType INSTCTRL behavior (Po Lu) (Re: Freetype-devel Digest, Vol 217, Issue 8)
> To establish a new default value for a graphics state variable, it is > necessary to change the value of that variable in the control value > program. Changes made in the control value program will apply to all > subsequently processed glyphs unless INSTCTRL[] is used to inhibit > these new values.
Re: More axes for `ftmulti`
Hi All > a, Aadjust axis 0 > b, Badjust axis 1 > ... > p, Padjust axis 16 I’ve added a couple more interesting features to ftmulti after the release. F3 now toggles the fill rule (even-odd) flag to reveal the overlaps in the modern variation fonts. F4 now toggles the overlap flags and therefore turns the oversampling on and off. This produces a more subtle rendering effect. The minimal step along an axis is now 0.6% of the axis range. This should be fine considering ftmulti rounds to 0.01, but let me know otherwise. Please test, Alexei
Re: More axes for `ftmulti`
> a, Aadjust axis 0 > b, Badjust axis 1 > ... > p, Padjust axis 16 Now you can collapse all these cases using: axis = event. key - ‘A’; Or axis = event.key - ‘a’; And make an alphabetical list on the screen. A axis B axis C axis
Re: More axes for `ftmulti`
> > ``` > ? display this help screen And F1 as commonly used for help > q, ESC quit ftmulti > F1 toggle axis grouping See above, shift by one > F2 toggle anti-aliasing Might be a part of rendering mode cycle as in other demos. > F3 toggle outline hinting > F4 toggle embedded bitmaps > space toggle rendering mode > > , . previous/next font > > y cycle through hinting engines (if available) > > Up, Downchange pointsize by 1 unit > PgUp, PgDn change pointsize by 10 units > > Left, Right adjust index by 1 > F7, F8 adjust index by 10 > F9, F10 adjust index by 100 > F11, F12adjust index by 1000 Please switch to hexadecimal 16, 256, 4096 This makes it easier to dial charcodes, if charmaps are supported > > a, A adjust axis 0 > b, B adjust axis 1 > ... > p, P adjust axis 16 > > F5, F6 adjust axis range increment > ``` > >Werner
Re: More axes for `ftmulti`
> Can I suggest a more intuitive scheme? > A,a to control axis 1 > B,b to control axis 2 > C,c to control axis 3 > and so on. you can also list them "alphabetically": A "GRAD": 0.0 B "XTRA": 562,00 which makes it super easy to find the appropriate control.
Re: More axes for `ftmulti`
> I've just increased the number of handled axes in `ftmulti` from 6 to > 15. Due to the new support of the 'avar' version 2 OpenType extension > it is expected that the number of axes in many fonts will increase > (after this extension gets accepted in the OpenType standard) because > adding 'virtual axes', which simply warp existing axis data, is cheap > now. > > Behdad, please have a look – a quick test seems to deliver the same > results as `hb-view`. Can I suggest a more intuitive scheme? A,a to control axis 1 B,b to control axis 2 C,c to control axis 3 and so on. This is also easier to process. Or this 1,! to control axis 1 2,@ to control axis 2 but this is only for US keyboard Alexei
Re: t1 and afm
Werner, I got this. Ascender and Descender are optional and could either be omitted or even set to zero in AFM, e.g. in the current URW++ base 35 fonts. The fix is in. Alexei On Fri, Feb 3, 2023 at 12:35 PM Alexei Podtelezhnikov wrote: > Hi Werner, > > URW++ fonts are now distributed as t1 which is binary with an ASCII > header. > > [image: urw-base35-fonts.png] > > urw-base35-fonts/fonts at master · ArtifexSoftware/urw-base35-fonts > <https://github.com/ArtifexSoftware/urw-base35-fonts/tree/master/fonts> > github.com > <https://github.com/ArtifexSoftware/urw-base35-fonts/tree/master/fonts> > <https://github.com/ArtifexSoftware/urw-base35-fonts/tree/master/fonts> > > FreeType opens them just fine. There are also afm files. Do we need to > attach them to t1? I tried but that messed up the ascender so it seams. > Ascender and Descender are optional and could either be omitted or set to zero in AFM.
t1 and afm
Hi Werner,URW++ fonts are now distributed as t1 which is binary with an ASCII header. urw-base35-fonts/fonts at master · ArtifexSoftware/urw-base35-fontsgithub.comFreeType opens them just fine. There are also afm files. Do we need to attach them to t1? I tried but that messed up the ascender so it seams.Alexei
[ftstring] New feature: simple string editor.
https://gitlab.freedesktop.org/freetype/freetype-demos/-/commit/4028f9ac6a1e961bc33b55813398a31aca391d7e Hi folks, ftstring can now edit and display a simple ASCII string interactively, press Enter. Alexei
Re: How to calculate the size of FT_RENDER_POOL for 240x320 LCD
On Wed, Dec 21, 2022 at 3:48 AM ricky rocky wrote: > I saw an info that, can reduce 16kB -> 4kB, but I don't know if that will > cause any bug when rendering. Go ahead and try it. It is surprising for me that you cannot afford 16kB while you want TrueType fonts, which are typically >100kB. FreeType library compiled is typically 700kB. Font rendering is a very computationally expensive task. Somehow I doubt that the rendering pool is a place to conserve resources. I suggest that you look elsewhere, or explain better why 16kB is multiplied or, otherwise, very critical to you. As for your basic typography questions, I suggest https://learn.microsoft.com/en-us/typography/opentype/spec/ttch01 Best, Alexei
Re: How to calculate the size of FT_RENDER_POOL for 240x320 LCD
On Tue, Dec 20, 2022 at 9:11 PM ricky rocky wrote: > #define FT_RENDER_POOL_SIZE 16384L > > This definition is used in smooth/ftgrays.c/gray_convert_glyph() as a local > buffer. > For my small RAM chip, it is the large size. You cannot spare 16kB for rendering. Alrighty. Or, do you want to allocate it elsewhere, not on stack? > For 240x320 LCD, Could I reduce this size? and how much is good? What is the text pixel size that you need? Very roughly, the number of nontrivial pixels is 8x the pixel size, if your font is not too fancy. Each gray pixel is 16 bytes on 32 bit architectures, more on 64 bits. For example, for 20 pixels per EM, you can probably get away with 2kB. You can use even less, but you will pay with performance. I would like to suggest doubling to pool because 32kB is reasonable these days. Alexei
Re: Nice way to do Bold
On Sun, Nov 6, 2022 at 10:34 PM Paul Sheer wrote: > > > > > To be honest, I don't understand why he doesn't use blending with > > gamma correction. It is not like an area of active research and > > debate. > > > > I have no idea what blending means in this context. In essence, your 7/8 and 13/16 might have different brightness on display with different gamma/brightness/contrast. You tuned them for *yourself*. On the other hand, you are right to interpret boldness freely by using brightness and/or color because the screen is not a piece of paper.
Re: Nice way to do Bold
On Sun, Nov 6, 2022 at 12:01 PM Werner LEMBERG wrote: > > > > I have pushed a new method to do terminal bold that seems to work > > well. See screenshot. > > > > Basically I use a brightness of 7/8th for non-bold, and for bold a 1 > > pixel shadow of 13/16ths brightness. After hours of experimentation > > that seems to provide the best results for all fonts. > > > > This is much more pleasing than the method of doubling-rendering the > > font 1 pixel to the left. > > Looks good to me, thanks for showing. > To be honest, I don't understand why he doesn't use blending with gamma correction. It is not like an area of active research and debate.
Re: Glyph Rendering of CJK Font that Appears to have Hints
Some of the differences that you highlight favor FreeType. Actually, most of them favor FreeType over Windows. Since you are talking about QImage, shouldn't you first ask them Qt? If you are asking about the particular font, then you should examine the font. We do have some tools like ftinspect and other freetype-demos to help you. Good luck in your investigation, Alexei
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 Werner, Alexei, and mpsuzuki. Without your precious help, > the GSoC project would never have been completed. > > It was a great experience to work with folks in the FreeType community, and > I'm determined to further contribute to the open source communities including > FreeType. > > Cheers, > Charlie Jiang > OpenPGP_signature Description: Binary data
Python2 to Python3
Hi All, We have a couple of Python2 scripts in src/tools. Would anybody volunteer to upgrade them to Python3? Python2 is quickly disappearing from the Linux distros. Particularly, glnames.py might be challenging. It is used to generate src/psnames/psnames.h and implements a compression algorithm. Others are much easier. See https://gitlab.freedesktop.org/freetype/freetype/-/issues/1185 Any takers? Alexei
Re: This is freetype sourcecode from TSIT(I made many improvements)
> I really love freetype very much, so I want to make it more powerful and. > Waiting for your plan. I already told you that you have to reorganize your code into smaller individual contributions. You have a nice list of changes. Each of the list items has to be presented separately either as a diff patch or a git commit in your git clone, or a merge request . What you have in your git repository is everything together. We cannot consider this seriously. I also told you that you should avoid renaming functions or introducing synonymous functions.The plan is small steps with good rationale, not just "It is more convenient for me to name it differently". You do not have to contribute everything at once. It might take a lot of steps over a long period of time. Alexei
Re: This is freetype sourcecode from TSIT(I made many improvements)
> https://github.com/tsitcn/freetype2-taishan-improved > > Those improvements include: > Outline: > italic for any value. > line thickness. > Bitmap: > Rotate for 4 directions. > Italic. Three type: clockwise, counter-clockwise, top to bottom(chinese > chars needthis feature). > Bold. We use a new algorithm. > Gray Bold. If all pixels use black color, some chinese chars are very > ugly. So I developed a gray bold to make them very beautiful. > Filp. Left to right, and top to bottom. Some of these changes alter API by renaming. This is Not acceptable. Other changes are trivial special cases: flip, turn. This is trivial and not interesting to general public. An intelligent user can easily implement this. If you want us to consider the bitmap emboldening algorithms, which you claim as novel, please present them separately from the rest. And explain them very carefully. Alexei
Re: [GSoC] Status of font-rs port
Anurag > > Can also look at some more challenging fonts with very fine curves, eg, > > Windows' KUNSTLER.TTF > > I tested it, and the rasterizer output is almost identical. > > Curiously, for this font, the dense rasterizer is faster even till 200-300 > ppem font size This is definitely because smooth is constrained by memory and has to restart (see longjmp) with narrower bands to handle the job. It looks like one restart for each glyph approximately. > Relevant files attached. Do you mind continuing this discussion as an issue on GitLab? A
Re: [GSoC] Status of font-rs port
Anurag, > 1 and 2 have been fixed, but monochrome output still crashes ftgrid for the > dense rasterizer Smooth returns Cannot_Render_Glyph for mono, thus passing the job to b/w raster. Dense should do the same. A.
Re: [GSoC] Status of font-rs port
> Also, if there is some way of viewing the libc function name instead of > address, that would be helpful. I am sure these are malloc, free, memset, memcpy, etc. As the size increases they contribute more and more. Still, dense_raster_render must be spending some time just walking around the huge matrix. If you press Enter and Annotate, you will see the hottest lines.
Re: [GSoC] Status of font-rs port
On Thu, Sep 15, 2022 at 5:53 PM Anurag Thakur < anurag105cse...@bpitindia.edu.in> wrote: > List of bugs I have encountered: > 1. Ftgrid produces weird output and crashes at large sizes(~170ppem) > > 2. The inverted bitmap pitch causes rendering differences (can be seen in > the “Q” letter of the ftview output) > > 3. Ftgrid crashes when selecting monochrome output > Should be fixed by *a005039b.* Thanks for the report.
Re: [GSoC] Status of font-rs port
Hi Anurag, The rasterizer code (including SIMD) has been integrated into the FreeType > and seems to be working fine, > > Comparison images: dense and smooth renderer (outlines and dots disabled) > This is a really nice progress indeed. The images look almost identical. Can also look at some more challenging fonts with very fine curves, eg, Windows' KUNSTLER.TTF. We need to make sure that both rasterizers are tuned to similar quality. > The performance is comparable (sometimes better) to the smooth renderer > for small font sizes, however it is several times slower for larger sizes > This is really quite stunning. I look forward to further progress. Can you confirm that straight line drawing still takes most of the time with the dense rastrerizer? > I am thinking of working on the “Direct rendering mode” next. Any pointers > regarding that would be appreciated. > I am not sure about this one. The whole point of direct mode is to leave the canvas allocation to the client. The dense rasterizer defeats this purpose. > And just for reference > > List of bugs I have encountered: > 1. Ftgrid produces weird output and crashes at large sizes(~170ppem) > > 2. The inverted bitmap pitch causes rendering differences (can be seen in > the “Q” letter of the ftview output) > Hmm. Is this only when Q is on the last row? That would be an ftview bug then. I do not see any problems with parentheses? Is this 2.12.1 demos? 3. Ftgrid crashes when selecting monochrome output Do you think this is also a pitch sign bug? 4. [TODO] lcd rendering needs to be implemented This is either three interlaced bitmaps after shifts, or 3x resolution with filtering. You should be able to copy this from smooth. Best, Alexei
Re: CFF font with bogus hint
Hi Derek > I'm attaching f2.cff. Thanks. ‘ftlint 24 f2.cff’ is full of errors 0x0006. Do you mind filing an issue on gitlab.freedesktop.org/freetype/freetype?
Re: Rendering performance comparison between FreeType 2.6.5 and current `master`
On Mon, Sep 5, 2022 at 1:12 PM Anurag Thakur wrote: > (notomono_comp.png) > (notomono_comp_expanded.png) These look very good indeed. The almost linear shape at the small sizes comes from the dominant dependence on the glyph perimeter, more or less. The convex shape apparent in the expanded range comes from the 2D image matrix operations. > I also ran the perf utility, results attached (.data files are the binaries > generated by perf, .txt files are human readable output generated by perf > report) These look appropriate too. > At small sizes, the “TT_RunIns” function dominates, while at larger ones, the > render line function is prominent TT_RunIns is the TrueType instruction interpreter. These are unlikely to have noticeable effects on rendering performance and can be disabled by passing FT_LOAD_NO_HINTING, `ftbench -f 0x2...` > Other notable functions are ` Ins_IUP.constprop.0`,`_iup_worker_interpolate` > which are not prominent at large sizes Just a common and expensive interpolation instruction. It will also disappear with `-f 0x2`. > 10.69% lt-ftbench libfreetype.so.6.18.3 [.] gray_render_line > 4.28% lt-ftbench libfreetype.so.6.18.3 [.] gray_set_cell These two are the workhorses of the rendering algorithm. This *is* what takes the bulk of rendering time, not the curve flattening, not the sparse-to-dense matrix conversions. Alexei
Re: Compiling old version (2.6.5) of FreeType
> On Sep 1, 2022, at 03:56, Anurag Thakur > wrote: > > Version 2.6.5 is important because the original font-rs post is from 2016, > which used 2.6.5 as the benchmark for comparison. > > The aim is to run FreeType 2.6.5 for benchmarking. Any help regarding this > would be appreciated. That is right. A lot of performance improvements went in starting from 2.7. I think the current version is about 50% faster. Please don’t ignore the current version too.
Re: Free type "invalid glyphs"
> > I have found that FT_Get_Char_Index will explicitly return 0 for 'missing' > characters which is the fix for the issue. I am using FT_Load_Char but should > that really return a valid construct for an "invalid" character? > This is ridiculous. You are complaining about very basic typographic concepts.I welcome you to educate yourself: https://docs.microsoft.com/en-us/typography/opentype/spec/recom#glyph-0-the-notdef-glyph
Re: Font-rs GSoC Phase 1 update
On Tue, Jul 26, 2022 at 12:55 AM Anurag Thakur < anurag105cse...@bpitindia.edu.in> wrote: > I cleaned up the code a bit and used `ftbench` to get performance numbers > for the `smooth` and `dense` rasterizers. > There is much room for improvement in the ported code, as can be clearly > seen in the performance graph. > [image: Image] > > (ftbench output for both renderers at 20ppem attached) > Phase-2 will be focused on profiling and improving the performance of the > ported code. > Hi Anurag, This looks encouraging, within reach after some more optimizations, although the square curvature is probably unavoidable for the dense arrays. I suggest you use 'ftbench -bc' to focus on rendering and avoid other benchmarks. You can also add '-f 0x2' to apply FT_LOAD_NO_HINTING and '-i 0-100' or so, to use some portion of good glyphs and avoid simple diacritics. I also strongly recommend 'perf record ftbench -bc...' followed by 'perf report' to find functions that take most of the time. Fedora distributes perf in kernel-tools. Good luck, Alexei
Re: Font-rs GSoC Phase 1 update
> > The rasterizer is working now (albeit with some artefacts, image attached), > but the code is in a very early stage and I'm working on cleaning it. Your rasterizer has a problem with Bézier curves. Any algorithm starts with flattening them or replacing with short straight segments. Then you walk the contours and integrate the area of each visited pixel, called cell in the current algorithm. This is trivial for straight lines. Of course, there are tricks with order linked lists for each scan line. The coverage value helps with the winding rule and correct the integral. I think this part is the same for either algorithm.
Re: Infinality removal (Freetype-devel Digest, Vol 299, Issue 99)
Dear Hin-Tak, > If it is all the same to you, I'd prefer it to say, but I guess I'll end up > maintaining a revert in the FontVal fork. There is incentive in the FontVal > backend to keep this, to match the Microsoft rastering backend. I could not find any references to Infinality or TT_INTERPRETER_VERSION_38 or FT_Property_Set in your Font-Validator repository. I was actually curious how it is useful to you. Are you sure that you use it? Please help me understand how you prefer v38 to v40. Even if you assume that v38 is very popular, please explain why you think so. I am actually very interested to find out. Thank you very much in advance. No, it is not all the same to me. I care very much that Infinality makes it a lot harder to maintain the FreeType code base. Infinality is very invasive and to my knowledge nobody touched it with a 6 foot long pole once it was merged. The author disappeared. My experience was that v40 has the same quality but a lot faster. That is our default for 6 years now. Full verbatim v35 hinting is here to stay, of course. If there is no misunderstanding here, this might actually be a good idea to maintain Infinality as an external patch. Paradoxically, this might actually create better support and community around it. Best regards, Alexei
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 interpreter version 40 has been FreeType's default version for 6 years now and provides an excellent alternative. This is the last FreeType version with TT_INTERPRETER_VERSION_38 and TT_INTERPRETER_VERSION_40 treated differently. https://gitlab.freedesktop.org/freetype/freetype/-/commit/5e48c88d57a89ea7a4fda1b31f4b7fb756dd1732 Please voice any concerns that you might have with this impending change. Alexei
Re: new compiler warnings since 2.10.x
Hi Hin-Tak, > freetype-2.12.1/src/smooth/ftgrays.c: In function 'gray_convert_glyph': > freetype-2.12.1/src/smooth/ftgrays.c:1968:20: warning: storing the address of > local variable 'buffer' in 'worker_56(D)->ycells' [-Wdangling-pointer=] > 1968 | ras.ycells = (PCell*)buffer; > |^ > freetype-2.12.1/src/smooth/ftgrays.c:1950:14: note: 'buffer' declared here> > 1950 | TCellbuffer[FT_MAX_GRAY_POOL]; > | ^~ > freetype-2.12.1/src/smooth/ftgrays.c:1950:14: note: 'worker_56(D)' declared > here Do they really complain that we dare to allocate on the stack? I don't even know how to address this. There was a request to move the pool to the heap recently. I do not know if this is an issue. Same with b/w rasterizer. Same with autohinter. > ft2demos-2.12.1/graph/gblblit.c: In function '_gblender_spans_rgb565': > ft2demos-2.12.1/graph/gblblit.c:158:69: warning: 'color' is used > uninitialized [-Wuninitialized] > 158 | #define GDST_PIX(p,d) unsigned int p = > GRGB565_TO_RGB24(*(unsigned short*)(d)) > | ^ > In file included from ft2demos-2.12.1/graph/gblblit.c:178: > ft2demos-2.12.1/graph/gblany.h:49:19: note: 'color' declared here >49 | grColor color = surface->color; > | ^ This *looks* like 'color' initialization to me. I am puzzled and I think it is a false warning. Alexei
Re: [GSOC 2022]: Integrate FreeType with alternative rendering engines
> On Apr 19, 2022, at 22:36, Matsumura, George wrote: > > From what I could glean, rusttype uses the rust library ab_glyph_rasterizer > for its rendering, which in turn uses the algorithm used by stb_truetype, > which is described here: > https://nothings.org/gamedev/rasterize/ which references LibArt, which is also the basis of FreeType algorithm. I would focus on something with legitimate claims of beating FreeType performance, not just rust for the sake of rust. A
Re: GSoC 2022: Alternative Rendering Engines
On Tue, Apr 12, 2022 at 9:57 AM Matsumura, George wrote: > The blog post mentions "a large constant factor because it’s doing > complicated exact-area calculations for each pixel" as a performance > impediment when drawing into the accumulation buffer. If one were > willing to settle for fewer gray levels in the resulting image, could > something like multisampling be used to eliminate the need for these > area calculations entirely, especially given that SIMD is already being > used to exploit parallelism? I'm sure there's a reason why this isn't > done, but if someone could enlighten me as to exactly why I would highly > appreciate it. There are basically two approaches to rendering: Windows does multisampling, the rest of the world integrates. I do not want to make any claims about the speed of the either approach. There are claims out there that other renderers beat FreeType using parallelism by the expected factor equal to the number of CPUs, maybe more, maybe less.So we want to see if we can borrow some of those approaches. The main reason why FreeType is very careful about adopting alternative approaches is ultra-portability of FreeType to pretty much anything under the Sun because of pure C89 or C99. The performance non-parallel rendering is not bad. Also, you can do parallelism on levels above FreeType and outside of its control. Alexei
Re: [GSOC 2022]: Integrate FreeType with alternative rendering engines
On Tue, Apr 12, 2022 at 1:09 PM Anurag Thakur wrote: > > Having briefly studied the renderers mentioned at FreeType’s GSOC page, I > believe the best course of action would be to first properly integrate a > font-rs based renderer in FreeType > > and then working on optimizing the implementation by studying the code of > font-go and fontdue. Hi Anurag, To be honest, I do not know whether the alternative renderers should be a part of FreeType, or a separate project, or a part of the respective source projects. The module interface is pretty stable and should not be a maintenance burden in either case. It also depends on the performance and size of the modules, or if you are actually planning to do them all, not this summer but eventually. I would however ask that you put something in your proposal. Do you actually plan to port the code to the modules or just link? The summer is short. Even if you succeed with one of them to the point of release quality, it is good. Best, Alexei
Re: [GSoC 2022] Idea on Project "Improve FreeType demo programs"
> I've played around with ftgrid and ftview, but not all features of them. > They directly crash when I press "?" if an IME is enabled (e.g. MS Pinyin > Input Method). > Some keys are not working on Windows (notably arrow keys, maybe related to > console-attachment problems) > The keyboard-based control is not so straightforward (at least for Windows > users), and moving towards a fully Qt-based GUI could certainly relieve this. > However, I noticed some automation functionalities are present (-k option, > and p stroke). Should I consider them in ftinspect project? The lightweight demos rely on traditional Windows API and protocols. There is no need to adopt them to anything beyond that. It sounds like you’re are more interested in ftinspect anyway. There you can borrow any suitable functionality. > There're other tools besides ftgrid and ftview (ftbench, ftchkwd, ftdiff > ...). Should I include all of them in ftinspect as well? No. I would imagine ftview and ftgrid only to start. > I'm not familiar with text rendering and font processing, therefore I'm > refering to FreeType documentations and other online materials. Are those > skills considered as prerequisites before I submit my proposal? Yes. These are FreeType demos. We’re not really interested in Windows API demos except perhaps for side-by-side comparisons. That would be cool actually. Alexei
Re: Update FreeType's build systems (GSoC Project Idea #1)
>> ===> For windows >> Coming to windows I was having trouble building on it. I need some guidance >> to build freetype library on windows. Can anybody help me? > > for an environment similar to linux : install MSYS2 (msys2.org, follow > all the steps there) and you have a posix-like terminal, with packages > installed with a windows port of pacman. Then compile like on linux We also have a Visual Studio project file under builds/windows/vc2010 with a comment on its usage under Build Tools (msbuild).
Re: serving compressed images
> > Adding support for TIFF and JPEG is not much code; it would be > configurable in the same way as PNG. > You probably mean libjpeg-turbo and libtiff as external dependencies. This is a GNU approach. Other systems might have an abstraction layer that handles an arbitrary set of image formats. I mean Windows since GDI+, or Skia, or Qt. Truth be told, those systems are more successful on desktop because of these abstraction layers, perhaps. Skia might not be using FreeType on Windows however. If they do, they might not appreciate depending on libjpeg-turbo as well. The same way as PNG is not necessarily the only or the best way to handle compressed images.That is why FreeType should probably stay out of it. But then, we have a parallel discussion about handling color palettes in FreeType for Skia. Who would have anticipated that? Alexei
serving compressed images
Hi All, As Werner is working on improving the SBIX table support (https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/139), a topic of compressed images came up. Right now, FreeType depends on libpng to uncompress PNG, but SBIX can have TIFF and JPEG. So I was wondering if we should even bother uncompressing those. FreeType could just serve compressed data. With SBIX, FreeType could still match the best strike to the requested size but then just deliver FT_GLYPH_FORMAT_IMAGE with a tag, some minimal metadata, and raw bytes under FT_GlyphSlot->other. This would be quite similar to the SVG plans currently slated for the next release, i.e., we delegate uncompressing and rendering to a client. Is there interest in such a feature? Thanks, Alexei
Re: ftinspect crashes
On Mon, Jan 31, 2022 at 2:16 AM Werner LEMBERG wrote: > > Process terminating with default action of signal 11 (SIGSEGV): dumping core > General Protection Fault >at 0x429C9D: FT_Done_Face (ftobjs.c:2912) >by 0x483061: ftc_face_node_done (ftcmanag.c:272) >by 0x482F69: FTC_MruList_New (ftcmru.c:281) This should be fixed now. Please try again. Alexei
