[Fonts]Re: [Freetype] FreeType 2 changes required for XFree86
Brian Stell wrote: > > Defining common names like ''read'' always leads to problems > when using multiple packages. Fully agreed. > Why doesn't XFree86 follow common C protocol and use uppercase? Perhaps because this is not *that* common, except of course for the C code produced by a small company in far north-west USA, named something like yocto$oft. ;-) > Better yet, why not use a name like XF86_READ to avoid conflicts > on such common names? This sounds much much better to me. Also an option is XF86_Read (plain full caps is commonly reserved for manifest constants). Antoine ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: [Freetype] FreeType 2 changes required for XFree86
Juliusz Chroboczek wrote: > > BS> Defining common names like ''read'' always leads to problems > BS> when using multiple packages. > > BS> Why doesn't XFree86 follow common C protocol and use uppercase? > > The goal being to use common source code both in the X server (when > using the wrappers) and outside it, it would be rather pointless to > use ``common C protocol'', wouldn't it? > > The symbol name is xf86_read; it is the choice of the module author > whether to include xf86_libc and use xf86_read directly, or whether to > include xf86_ansic and have a nice define from read to xf86_read. Hmmm, just to point out that read is not ANSI C (it is POSIX instead), and that using read in any ANSI C source always lead to problems, because (obviously) there is a number of platforms where read() is defined, even when compiling for strict ANSI C... I am not sure you (both Brian and Juliusz) will have a similar dispute about tolower or malloc, would you? Antoine ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: [Freetype] FreeType 2 changes required for XFree86
Juliusz Chroboczek wrote: > ... > BS> Defining common names like ''read'' always leads to problems > BS> when using multiple packages. > BS> Why doesn't XFree86 follow common C protocol and use uppercase? > > >> The goal being to use common source code both in the X server (when > >> using the wrappers) and outside it, it would be rather pointless to > >> use ``common C protocol'', wouldn't it? > > Brian is absolutely right that all-caps names should be used for > processor defines in the ordinary case, and XFree86 code follows this > convention religiously. The definitions done in xf86_ansic.h are in a > completely different situation, and Brian's received wisdom does not > apply to them. It could. > In XFree86 modules that include xf86_ansic.h, a number of libc symbols > (standard or not, that's not the point) are redirected to their > cross-platform xf86_* equivalents. Due to the lack of a module system > in C, this redirection is done at the preprocessor level: > > #define read(x, y, z) xf86_read(x, y, z) > #define tolower(x) xf86_tolower(x) > ... etc ... A different way to approach the problem could be to ask 3rd party code such as FreeType to use macros for the fuctions XFree86 needs to override and have XFree86 override those macros. For example FreeType could have: /* Allow outside code to override these */ #ifndef READ # define READ read #endif XFree86 could define READ to be xf86_read and thus override the values in FreeType. This would follow common C protocol and allow readers of FreeType to know that these were macros. This more directly address the issue that XFree86 has whereas changing the structure member names hides the issue. The FreeType code would have clear markings where things were being "fiddled with under the hood". -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]New version of FreeType 2 backend
You will find a new version of the FreeType 2 backend on http://www.pps.jussieu.fr/~jch/software/files/ New features: - generates the same set of properties as the FreeType 1 version; - support for the X11R6 XLFD extensions. Still to do: - support for non-AGL Type 1 fonts (typically symbol fonts); - support for CIDFOnts. At the same place, you will find a minor patch for the mkfontscale utility (submitted as 5214). Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
