Re: [ft-devel] merged CFF and Type1 hinting code now in master

>> I've just committed Ewald's GSoC project to master. Please test! > > Sorry, I've been a bit out of the loop on this > > Does this mean that Type 1 hinting will now be applied to the scaled > outline? No. Adobe's CFF engine will now hint Type1 fonts. Since FreeType's Type1 hinter was n

[ft-devel] various Type 1 -> CFF issues

Ewald, here is a first list of things that should still be handled. * Make the old type 1 driver optional. The file `ftt1drv.h' is talking about a `T1_CONFIG_OPTION_OLD_ENGINE' configuration macro, however, this isn't implemented yet. * Implement the `hinting-engine' property for the `typ

Re: [ft-devel] various Type 1 -> CFF issues

>> * Make the old type 1 driver optional. The file `ftt1drv.h' is >> talking about a `T1_CONFIG_OPTION_OLD_ENGINE' configuration >> macro, however, this isn't implemented yet. > > I had actually implemented it, but did not commit later on, c.f. > http://lists.nongnu.org/archive/html/freety

Re: [ft-devel] Come across Cross-compile error

> In file included from src/sfnt/sfnt.c:29:0: > src/sfnt/ttload.c: In function 'tt_face_load_font_dir': > src/sfnt/ttload.c:396:10: > warning: 'valid_entries' may be used uninitialized in this function > [-Wmaybe-uninitialized] I've added an initialization to pacify the compiler. > In file i

Re: [ft-devel] various Type 1 -> CFF issues

>> In file included from /home/apodtele/freetype2/src/psaux/psaux.c:35:0: >> /home/apodtele/freetype2/src/psaux/pshints.c: In function ‘cf2_hintmap_dump’: >> /home/apodtele/freetype2/src/psaux/pshints.c:312:17: warning: unused >> variable ‘hint’ [-Wunused-variable] >>CF2_Hint hint = &hint

Re: [ft-devel] Curb the scaling

> As per our discussion I propose the following patch to limit the > outline scaling so that ppem values do not exceed 65535. As far as > I can see, no such limits are currently in place, ppem values are > simply truncated while the scaling factors are not limited. Looks good. > My secret goal

Re: [ft-devel] ttinst updates

> Have you noticed updated TrueType instruction file version 1.8? > http://download.microsoft.com/download/2/7/C/27CD5B2C-B7BA-4A85-B121-4C7F339D54F9/ttinst2.docx Yep. > It comes with full specifications of GETINFO and GETVARIATION. Everything should be already implemented in FreeType, please c

Re: [ft-devel] ttinst updates

>> Everything should be already implemented in FreeType, please check. > > I see a lot of /* XXX: UNDOCUMENTED! */, which are all documented > now. Please update whatever you think is correctly documented now. > Have you seen the other half, new ttinst1.docx? No. > Can you ask about it through

Re: [ft-devel] various Type 1 -> CFF issues

* Implement the `hinting-engine' property for the `type1' module. > > All done. Attached patches that separate the advance width > function, adds the config macro, and adds the property service for > `type1' and `cid'. Excellent, thanks! Please proceed. I have a minor nit: * Please ma

Re: [ft-devel] Curb the scaling

>>> As per our discussion I propose the following patch to limit the >>> outline scaling so that ppem values do not exceed 65535. As far >>> as I can see, no such limits are currently in place, ppem values >>> are simply truncated while the scaling factors are not limited. >> >> Looks good. > > I

Re: [ft-devel] Curb the scaling

>> As mentioned earlier, there is no chance to ever catch cumulative >> values without actively comparing against a maximum value. And >> such a comparison is more expensive that using ADD_LONG and >> friends. > > Largely, it comes down to taste. The cumulative one is *not* a matter of taste.

Re: [ft-devel] Rounding issue

> Please see https://github.com/behdad/harfbuzz/issues/551 > > With this font (I *think* it was Noto Sans Bengali), No, it's `Lohit Assamese' (according to the font's `name' table entry). > font has upem 769, and a glyph has advance of 520. In hb-ft, I'm > asking FreeType for size 769/64.; the

Re: [ft-devel] Curb the scaling

>>> > [*] Actually, what's ugly is the macro syntax. I would like to have >>> > compiler support like >>> > >>> > foo = bar + baz __attribute__ ((allowed_overflow)); >>> > >>> > so that the mathematical operators are not hidden. > This __attribute__((no_sanitize("signed-intege

Re: [ft-devel] Speeding up afshaper.c

> I wrote a small test that measures initializing the autohinter. > Attached. Would be nice if ftbench could do this as well. Ie. not > just load face, but load face and try loading one glyph. OK. With the just updated ftbench program in git, the call main foo.ttf 1000 of your test program

Re: [ft-devel] [PATCH 2/2] [cmake] add support for customized ftsystem on Windows

> Now the question is whether this is appropriate for FreeType to deal > with UTF-8 filenames on Windows, which does not itself use UTF-8 > filenames, which are, therefore, superfluous. Exactly. The very issue is that the `pathname' field in `FT_Open_Args' is of type `FT_String*'. It would have

Re: [ft-devel] [PATCH 2/2] [cmake] add support for customized ftsystem on Windows

Hello Azamat, thanks for your contribution. Hin-Tak writes: > This patch set looks wrong - you seem to be special-casing windows, > copying and forking the two files, src/base/ftdebug.c , > src/base/ftsystem.c to builds/windows/ftdebug.c , > builds/windows/ftsystem.c , builds/wince/ftdebug.c .

Re: [ft-devel] [PATCH 2/2] [cmake] add support for customized ftsystem on Windows

> For one project which I contribute to, we need some mechanism that > loads specific FontFace from file. Currently we are using little > quirky approach what messing with FreeType's internal structures, so > actually we bundled library into our code. My intention is > externalize it. OK. > T

Re: [ft-devel] merged CFF and Type1 hinting code now in master

Hello Nikolaus, sorry for the late reply. No time yet to actually test your patch. > +FT_Bool isType1FontWithLightHinter = > + ( strncmp(driver->root.clazz->module_name, "type1", 5) == 0 && What about using `FT_Get_Font_Format' instead? Werner _

Re: [ft-devel] Text rendering error

> Hi all， i render the char "西" use 1_.ttf/freetype 2.7.1，but it > renders error use hint, see 3.png is anyone can help analyze the > reason? is this a bug of hint rendering？Thanks. This seems to be a subsetted `tricky' font. However, all bytecode instructions have been stripped off from the gl

Re: [ft-devel] Text rendering error

> This seems to be a subsetted `tricky' font. However, all bytecode > instructions have been stripped off from the glyphs... Of course, > this *must* fail :-) Oops, sorry, there actually *is* bytecode in the glyphs and it works, but only in v35 mode of the bytecode interpreter. Because FreeTyp

Re: [ft-devel] Text rendering error

> Werner and Toshiya-san, i found the base name is > DAWJQA+DFGothic-EB-WIN-RKSJ-H in the pdf file , I found a `DFGothic-EB-WIN-RKSJ-H' version 2.1 (from 1997) in the internet, which is no longer tricky. We thus would need an earlier version, which might be difficult to find... Werner ___

Re: [ft-devel] Text rendering error

> One of the strange points is that the maxp glyph number of tricky > DFGothic-EB is greater than non-tricky DFGothic-EB (?_?) Maybe Dynalab had to reduce the number of glyphs because non-tricky fonts need more space on disk and/or memory. Werner ___

Re: [ft-devel] Text rendering error

> So, do you have any objection to include the checksums of > the tables from the subsetted fonts of sample PDFs? No. Please proceed, and thanks in advance! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.or

Re: [ft-devel] Text rendering error

> So, DFGothic-EB(version 2.1 (1997 later)) is not tricky font? Correct. Around this time Dynalab abandonded the concept of fonts where components are moved and scaled by bytecode. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org

Re: [ft-devel] Text rendering error

> Just I've updated the tricky font list! Thanks a lot! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Text rendering error

> Could you help check this file? the subpixel rendering effect is not > very good for this tricky font。I render text use 10 font size， it > look very sharp. For tricky fonts there is no subpixel rendering at all it seems... Nikolaus, Alexei, do you think this can be improved? Werner _

Re: [ft-devel] Text rendering error

> Werner, I'm thinking about the insertion of some debug > messages for tricky font checker for users to help what > is going on. Yes! > * trace message when the font is recognized as tricky > * supposed family name when nameless font is recognized as tricky Both are good ideas, thanks! > It i

Re: [ft-devel] too many old DynaLab fonts in tricky list?

> Although concrete examples in my hand are only 3: DFHSGothic-W5, > DFHSMincho-W3, DFHSMincho-W7, I guess all of > DFHS{Gothic,Mincho}-W{3,5,7,9} in same version would have once been > tricky. Should we add all of them into tricky font list? Good question. Probably yes. > I think the checksum

Re: [ft-devel] Text rendering error

>> For tricky fonts there is no subpixel rendering at all it seems... > > Huh? I see subpixel rendering. Maybe set gamma = 1.0 to see the > glorious color fringing. Right, my bad. So there's nothing we can do to improve the appearance of tricky fonts in a sub-pixel environment, AFAICS. We

Re: [ft-devel] Text rendering error

>>> Huh? I see subpixel rendering. Maybe set gamma = 1.0 to see the >>> glorious color fringing. >> >> Right, my bad. So there's nothing we can do to improve the >> appearance of tricky fonts in a sub-pixel environment, AFAICS. > > Brrr. Please explain. Do you mean that tricky fonts are to be hin

Re: [ft-devel] merged CFF and Type1 hinting code now in master

>> What about using `FT_Get_Font_Format' instead? > > Still ugly but oh well :) Committed, thanks, with slight modifications. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-deve

Re: [ft-devel] merged CFF and Type1 hinting code now in master

> I believe that TrueType without bytecode are handled by autohinter > that still respects NORMAL and LIGHT flags. What happens to > CFF/Type1 without hints? Unfortunately, it is not possible to recognize this without parsing the whole font, including all glyphs. We could argue, however, that a

Re: [ft-devel] [PATCH] Correct type signature for FT_Renderer_RenderFunc

> Hello, the following patch updates the type of the 3rd argument of > FT_Renderer_RenderFunc from FT_UInt (unsigned int) to FT_Render_Mode > (enum, hence signed int) to match the implementations of > FT_Renderer_RenderFunc. [...] Patch applied, thanks! Werner

Re: [ft-devel] merged CFF and Type1 hinting code now in master

>> Unfortunately, it is not possible to recognize this without parsing >> the whole font, including all glyphs. We could argue, however, >> that a Type 1 or CFF font that lacks global blue zone information >> should be handled by the auto-hinter > > No hints should trigger the autohinter, yes. >

Re: [ft-devel] merged CFF and Type1 hinting code now in master

Hello Dave! >>> I consider a font broken if it has a blue zone table but no hints >>> – shall we really take care of that?  We don't do any harm; it's >>> just that the font stays unhinted. >> >> Hm, well, yeah, it's okay I guess. Might be solved by teaching the >> Adobe hinter to cope with blue

Re: [ft-devel] buiding ttfautohint with cmake?

Hello Cosmimo, > I would like to make a Python wrapper for ttfautohint, [...] I want > to build a shared library (.so, .dll, .dylib) and call that from > Python using either ctypes or better CFFI. [...] OK. > Now, freetype and harfbuzz both support cmake as an alternative to > ./configure &&

Re: [ft-devel] Patch for allow many version on vc2010 to build

> i'm very sorry to contact you about this, but can you includ the patch > to your repo please. Applied – however, I got the impression that it is not urgent for you. We are all busy people... Werner ___ Freetype-devel mailing list Freetype-devel@

Re: [ft-devel] buiding ttfautohint with cmake?

> libtool doesn't seem to be able to link DLL dependencies statically. I've asked this question on the libtool mailing list. > I haven't investigated this further, though. The easiest way to get > a statically linked DLL is to use dllwrap: > > - build all libraries statically, including libttfau

Re: [ft-devel] buiding ttfautohint with cmake?

> with the build system. The attached patch modifies the autotool > scripts so that public static and shared libraries are built and > installed. Thanks a lot! Installed in git. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org ht

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

> Werner, do you think libttfautohint is stable enough to provide it > as a separate static and shared library and not just as an internal > one for the ttfautohint executables? It would be great if third > party applications could link against it too in order to benefit > from your great work.

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

> Could you also add a function to the library that returns the > current ttfautohint version, e.g. "1.7"? Maybe something simple > like this: > > TA_LIB_EXPORT const char* > TTF_autohint_version() > { > return VERSION; > } Now implemented in git, please test! I've added two functions: `TTF_

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

> However, there's a small issue at the moment. I currently can't > build the library from the git repo due to the missing file > lib/taversion.c. Oops! Added. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

> could you please also add another function to free the memory > allocated by malloc inside the libttfautohint DLL? Hmm. > In general a DLL where memory gets allocated should also provide a > function to free that memory. What do you think about providing function pointers to TTF_autohint for

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

>> What do you think about providing function pointers to TTF_autohint >> for memory allocation and deallocation instead? > > it's bit more complicated to pass a function pointer with ctypes, > but it's possible. Whatever you think is best, Well, I simply don't know what is best. I can imagine

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

Hello Tom! > Have you considered CFFI? [1] > > This might make things a little easier, but I am not sure since I > don't have as much experience with that as I do ctypes. Or are you > more or less married to ctypes? Well, I guess this doesn't make a difference on the ttfautohint library side.

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

> IMO, what matters is not which specific memory allocator/deallocator > is used (whether the defaults, or user provided ones), but that they > match with one another (they are defined by the same library). > > That’s why I like the simplicity of a TTF_autohint_done function. > That’s just a one

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

>> Well, yes, but what about the callbacks? For example, >> `TA_Info_Post_Func' expects that the user modifies entries allocated >> with `malloc'. For such cases I guess we actually *need* function >> pointers to allocation rountines, right? > > no, as long as TTF_autohint_done frees them. unle

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

> If you think that function is essential for the ttfautohint API, > then maybe you need to add those func pointers to allocation > routines Two fields `alloc-func' and `free-func' are now added to the git repository. The corresponding code is untested yet, so please check whether it works corre

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

> I tested them in my ctypes wrapper (both the version functions, and > the alloc/free callbacks) and they seem to be working well! Glad to hear. > If you like I can also add you as collaborator on the repo Thanks, but no. At least not yet :-) Werner

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

> When do you think you'll be ready to cut a new release of > ttfautohint with the shared library support? I hope in the end of December. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/f

Re: [ft-devel] Another font variation bug fix

Thanks for the patch, which I've applied with slight modifications. > Subject: [PATCH] Fix clamping of font variation axis values > > We were clamping the value correctly here, but then used the > original value for normalization anyway. This subject line and the omment I don't understand. You

Re: [ft-devel] Another font variation bug fix

> We store coords[i] in the local variable coord, then we apply the > clamping to coord, but then ... we use coords[i] as input for the > normalization, so the clamping is lost. Ah, ok. Werner ___ Freetype-devel mailing list Freetype-devel@nongn

Re: [ft-devel] Minor FT_Set_Var_Design_Coordinates() request

Hello Behdad and Matthias, thanks for the demo code. > Is there any chance you can modify FT_Set_Var_Design_Coordinates() > to detect when the set face coordinates are not changed and > shortcircuit out early? Implemented. Please test! Werner ___

Re: [ft-devel] MultipleMaster: no setweightvector?

> I'm guessing setting the weight vector directly isn't included > because it wasn't originally part of Adobe's MM usage. Maybe. Another reason was probably the goal to have a uniform interface for both MM and GX fonts. > I'd like to add the ability to set/get the weight vector directly > (FT_S

Re: [ft-devel] FT_[SG]et_Var_Design_Coordinates() / FT_[SG]et_Var_Blend_Coordinates() interactions

> I'm hitting a problem with FreeType / HarfBuzz / Cairo interaction > for variable fonts that is easiest solved in FreeType. Currently, > if one sets Blend coordinates, then gets Design coordinates, the > returned design coordinates do not reflect the set blend > coordinates. Can you please fix

Re: [ft-devel] Fwd: buiding ttfautohint with cmake?

> I was able to run make dist by applying the patch attached below. Applied. Thanks a lot! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Compilation fails after commit 3cc88e2e44f1db959bb0146d798d261f104846d1

> I'm getting this log after a git clean -xdf and autogen plus > configure: > https://paste.fedoraproject.org/paste/pq5l9IkzOhCtSxGRxGwZlQ > > Introduced by commit 3cc88e2e44f1db959bb0146d798d261f104846d1. Fixed in git. Thanks for the report! Werner __

[ft-devel] New FreeType release within a week

Folks, I want to make a new FreeType release within a week, if possible. Some issues. . Behdad, please provide a problematic example w.r.t. conversion of design to blend coordinates. . Alexei, please take care of `ft_lcd_padding' and `ft_lcd_filter_fir'. . Ewald, I suggest that we simply

Re: [ft-devel] A few symbols missing in the visual studio build of freetype

> Surprisingly, there are windows users of python ... which uses > windows version of freetype. So they got a bit upset when the newer > version of freetype-py cannot find the FT_Get_BDF_* functions (the > list of expected symbols are looked-for on load). > > I also checked that FT_Get_CID_* seems

Re: [ft-devel] New FreeType release within a week

>> . Ewald, I suggest that we simply increase the allowed number of >> hints for Type 1 fonts – we can still fix this later if really >> needed. > > The allowed number of hints is set by the value `CF2_MAX_HINTS' > defined in `pshints.h', this value determines the amount of memory > allocated

[ft-devel] Announcing ttfautohint 1.8

ttfautohint 1.8.1 has been released. The source tarball, statically-linked binaries for Win32 (TTY and GUI) and OS X (TTY only) are available from http://savannah.nongnu.org/download/freetype/ or http://sourceforge.net/projects/freetype/files/ttfautohint/1.7 Instructions to build the

Re: [ft-devel] Announcing ttfautohint 1.8

> PPS: Due to a bug in another package (which I can't control), Homebrew > support is not yet available, cf. > >https://github.com/Homebrew/homebrew-core/pull/22321 This has just been fixed, so the new version has also landed in Homebrew. Werner __

Re: [ft-devel] New FreeType release within a week

> The largest number of hints is 4111 (!). Ouch! > Attached is the output for all fonts still with rejected glyphs. Thanks. > It's definitely not practical to increase the limit so much; I'm > thinking that this is good enough for now. OK. It would be nice if FreeType switched to unhinted di

Re: [ft-devel] New FreeType release within a week

>> I'm wondering, how about leaving the CFF limit as is and apply it >> to Type1, too, and just turn off hinting for that glyph? Not >> entirely correct, but an easy way out when the hinting obviously >> went wrong. > > Actually, since the FreeType hinter handles it fine, how about > returning a

Re: [ft-devel] Building in a custom directory

> Why when building in a custom directory, the headers are located in > sub directories? These cannot be found by other linkers. > > https://stackoverflow.com/questions/45627349/building-freetype2-in-a-custom-directory-which-must-be-found-when-building-gd After installation of FreeType there are

Re: [ft-devel] New FreeType release within a week

>>> The largest number of hints is 4111 (!). > > WL> Ouch! > > That glyph (uni2591) is an offset array of 16x16 circles. > > Not hinting that one would certainly be fine. > > (U+2591 is LIGHT SHADE.) Indeed. And the next glyph in this font gets heavily distorted with the old Type 1 engine...

Re: [ft-devel] New FreeType release within a week

> Set blend coordinates, then get design coordinates and observe that > they reflect the default instance. Got it, thanks. Should be fixed now in git, please test! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.no

Re: [ft-devel] New FreeType release within a week

> I think this may be a result of an implementation choice for > combining T1 and CFF. There is no limit to the number of hints that > can occur in a Type1 charstring. Each time there is a hint > substitution, previously used hints are discarded. On the other > hand, CFF requires that all hints

Re: [ft-devel] Disable ROUND_XY_TO_GRID in not hinting

> I believe FreeType should disable ROUND_XY_TO_GRID processing if > hinting is disabled. OK. > Likewise, maybe disable the X rounding if hinting mode does not > apply to X direction. WDYT? Implemented. Please give it a try! Werner ___ Freety

Re: [ft-devel] How to free FT_MM_Var?

>> The docs say return value of FT_Get_MM_Var() should be freed by >> calling "free()". But given this is allocated using FT_ALLOC(), >> shouldn't caller use FT_FREE()? > > Neither FT_ALLOC nor FT_FREE is in API. The documentation is crystal > clear on this subject. > https://www.freetype.org/fre

Re: [ft-devel] New FreeType release within a week

> [...] I went with a different approach, to switch off hinting only > if the hintmap is full. Compare attached patches. Honestly, I can't decide which is better. Please proceed as you believe is best. And thanks for working on this! Werner __

Re: [ft-devel] New FreeType release within a week

> In the interest of time, I've commited the original suggestion for > now, as I feel that my alternative solution is a bit of a hack as it > is; I have to test other fonts and decide if it's better to keep > hinting on, and devise a better way of ignoring the hintmask than > what I've provided ab

[ft-devel] Announcing FreeType 2.9

FreeType 2.9 has been released. It is available from http://savannah.nongnu.org/download/freetype/ or http://sourceforge.net/projects/freetype/files/ The latter site also holds older versions of the FreeType library. See below for the relevant snippet from the CHANGES file. Enjoy!

Re: [ft-devel] build ttfautohint without freetype-config script

Buon giorno! > The freetype-config script seems to be required in order to build > ttfautohint. The configure.ac errors if it cannot find one. > However, building freetype library with cmake, or with nmake (visual > studio), does not install that script to the prefix bin. Indeed, I haven't con

Re: [ft-devel] build ttfautohint without freetype-config script

> autoconf is not my cup of tea, but I've tried anyway. See the patch > attached below. Thanks! However, this is not exactly what I had in mind – and sorry for not telling you earlier: If `freetype-config' isn't found, the configure script should call the `PKG_CHECK_MODULES' macro (as with harf

Re: [ft-devel] Query about FTL License

> So I want to confirm if I use FreeType with distributing FTL text > file and providing a suitable acknowledgment. In other words, don't > I need to open(distribute) my application source code using > FreeType-distinct from GPL- and have any legal problem? Correct. Werner ___

Re: [ft-devel] FreeType DLL support

> by default, configure created by autoconf enables both static and > shared library. For me static library is useless, DLL's are what > should be used. And compilation is slower with both enabled as both > static and share lib are created I don't plan to change the default... Werner _

Re: [ft-devel] FreeType DLL support

>> I don't plan to change the default... > > so ? i've not ask anyone to change the default behavior, i just > mentioned the facts. That's why there are options to configure and > that's why **I** pass --disable-static for all **my** DLL. Then we are in violent agreement :-) Werner __

Re: [ft-devel] ttfautohint without freetype-config script

> I cannot find an authoritative source of reference for PKG_CONFIG in > cross-compilation, but here are a few non-authoritative sources: > > https://github.com/alexcrichton/pkg-config-rs/issues/41 > https://stackoverflow.com/questions/23202146/cannot-find-pkg-config-error > https://autotools.io/p

Re: [ft-devel] FreeType DLL support

> Btw, visual studio's project/sln files can contain compiler > preprocessor definitions also. You can do that FT_EXPORT redefine > hacks in those. There is no need to polute the rest of Freetype > source/header. The requirement is entirely visual studio specific > and mingw does not need it.

Re: [ft-devel] FreeType DLL support

>> But Visual C is a front-end to a command line compiler, isn't it? > > it is. Thanks for confirmation. >> In that it makes sense to have this stuff in FreeType's header >> file also; for example, people want to call nmake manually... > > also it is necessary for applications or libraries us

Re: [ft-devel] build ttfautohint without freetype-config script

> I'm now using PKG_CHECK_MODULES as you requested, when > freetype-config can't be found or is set to "no" by the user. > > It's also possible to skip pkg-config altogether by setting > PKG_CONFIG=true and passing FREETYPE_CFLAGS and FREETYPE_LIBS > directly on the configure command line. > > L

Re: [ft-devel] FreeType DLL support

LGTM, thanks! > +ifneq ($(RC),) > +FTVER_SRC := $(BASE_DIR)/ftver.rc > +FTVER_OBJ := $(OBJ_DIR)/ftver.$O > + > +OBJECTS_LIST += $(FTVER_OBJ) > + > +$(FTVER_OBJ): $(FTVER_SRC) > + $(RC) -o $@ $< > +endif Please indent the stuff within the IF clause. Werner ___

Re: [ft-devel] ttfautohint: freeing invalid pointer on composite glyph in TA_sfnt_build_delta_exceptions()

> we stumbled over the following issue that is present since at least > 1.7: > > 1. Unzip test.zip > 2. fontmake -u test.ufo/ -o ttf > 3. ttfautohint -l 8 -r 50 -G 50 -x 14 -D latn -f latn -m test.ctrl \ >-w G -X "" master_ttf/.ttf test.ttf --symbol > > The program aborts with "munmap_chunk():

Re: [ft-devel] Google Summer of Code 2018

> I am Akbar Hashmi, a second-year Computer Science Engineering > student. I wanted confirmation if Free Type is participating in > GSOC 2018. We don't know that yet. Please look at Google's GSoC pages after the participants will have been announced. Werner __

Re: [ft-devel] LD version script

> I've just found out that libtool wraps the --export-symbols file > into a --Wl,--version- script file, perhaps because of this paper > . That got me reading > further about version/symbol maps or scripts, which can keep track > on newly added interfa

Re: [ft-devel] LD version script

>> Good question. I've never seen this before, and I have no idea >> what to do with that information... > > We should be careful to notify downstream consumers of FreeType as > some Linux vendors may already do symbol versioning in their > implementations of it - any changes we make may have an

Re: [ft-devel] FreeType incremental glyph loading

> We decided to use your engine for fonts rendering. But we need to > add chinese glyphs on demand and add them into a face. I found that > Incremental glyph loading is perfect solution for us. But... I have > faced with a problem: no info about structure FT_IncrementalRec_ was > found in sourc

Re: [ft-devel] LD version script

>> OK. After a bit of searching the internet I now believe to know >> what symbol versioning is good for. Is there any better-known >> (GNU) library (besides libc) that does that by default? > > libc is confined by the standard. FreeType, on the other hand, can > deprecate, rename, and adopt in

Re: [ft-devel] LD version script

> I would possibly commit my bash script that extracts the versions > from our git repository to src/tools/. OK. > I would consider, maybe, providing the version mapfile in the > builds/unix/ folder, with regular upgrades as a part of the release > cycle. Hmm. Maybe it makes more sense to simp

Re: [ft-devel] LD version script

>>> I would consider, maybe, providing the version mapfile in the >>> builds/unix/ folder, with regular upgrades as a part of the >>> release cycle. >> >> Hmm. Maybe it makes more sense to simply call the script during >> `make dist', additionally having a Makefile rule to (re)generate >> it. >

Re: [ft-devel] LD version script

> Admittedly, symbol versioning is very poorly supported and > documented [...] Yes. > [...] All in all, this looks like something to stay away from. Maybe there are more knowledgeable people who want to contribute... Werner ___ Freetype-devel

Re: [ft-devel] G-Soc

> I'm new to open source , and would like to contribute as much as > possible. I found your organization quite interesting and will be > glad to work with you on any task you care to assign me. You are too early. On Feb. 12th Google will announce the participating organizations. Regardless of

Re: [ft-devel] LD version script

> Despite all of the talk about whether symbol versioning is useful > (and this is not meant to be snarky), keep in mind the major > commercial Linux distributions use symbol versioning, as well as the > free Linux distributions. No doubt that it is useful. However, we lack experience, and there

Re: [ft-devel] LD version script

> I also hated the frontend of the symbol versions which requires GCC > assembler trickery. > > https://gcc.gnu.org/wiki/SymbolVersioning > > This is a can of warms, which I do not want to open. I guess we don't need this. > I have started this when I saw that libtool wraps the flat file of >

Re: [ft-devel] LD version script

>> Just let me know if you want me to proceed. I am not going to >> spend the time on this if the consensus (sans me) is that we don't >> need/want it. Making new applications work with older versions of FreeType shared libraries in case the new or changed functionality isn't needed sounds usefu

Re: [ft-devel] LD version script

> Again, the symbol versioning does not improve performance, the > attribute does. Yep. However, the benefits for FreeType are rather small, I believe, since the number of library functions is small. > I am attaching my slightly updated script. We need to discuss the > tag, FREETYPE or FT or Fr

Re: [ft-devel] FreeType and Windows WingDing font...

> I have a font viewer that uses your freetype library. It displays > all Windows fonts correctly except the WebDings/Wingdings ones. You don't tell us which FreeType version you are using... > FT_UInt index; > FT_ULong charcode = FT_Get_First_Char( g_FT_face, &index ); > > while ( index

Re: [ft-devel] LD version script

> I looked aver the changes apinames.c to see how the GNU and Solaris > linker version script is handled. Good, but... > The question I have is how are we going to add the actual symbol > versions - read in a version tag or something else?. Also, how are > we going to handle inheritance?, For i

Re: [ft-devel] LD version script

> I have the latest master repository cloned. and cannot find a > symvergen script it in. I pulled again to make sure I had the > latest, and didn't see it. Moreover I ran "git branch" to see if > there was a different branch into which the symvergen script would > go, and did not see it. > > W

<    2   3   4   5   6   7   8   9   10   11   >