Re: [ft-devel] first auto-hinter infinality patch added to git
Will this arrive in ttfautohint? :) This is already in ttfautohint since a few months (option -x). For testing properties, I've first played with this in ttfautohint, and using the new FreeType property framework, I've added this feature to the auto-hinter too. Right now I'm synchronizing ttfautohint with FreeType again so that the upper limit for ttfautohint's -x option gets removed. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype 2.4.10 MSVC++ / Cygwin Compile fails
RMWChaos wrote: On 2012-09-18 23:26, mpsuz...@hiroshima-u.ac.jp wrote: $ /cygdrive/e/MSVC2005/VC/bin/cl.exe /? /cygdrive/e/MSVC2005/VC/bin/cl.exe: error while loading shared libraries: MSVCR80.dll: cannot open shared object file: No such file or directory I don't have this problem, but I'm probably not initializing things the same way that you do. In my batch file, I'm using SETLOCAL/ENDLOCAL to contain any vars, including PATH, so that I can modify the PATH statement during batch execution without modifying it for the entire life of the CMD shell. Then I call the appropriate command for MSVC (vcvarsall.bat for MSVC2008/SDK7.0 and setenv.bat for MSVC2010/SDK7.1), which modifies the PATH statement as appropriate. Then, I call bash and can run cl.exe within it ... $ cl.exe /? Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.01 for x64 Copyright (C) Microsoft Corporation. All rights reserved. C/C++ COMPILER OPTIONS Ahh, I see. I will try. This allows autoconf to confirm the compiler works and set the appropriate flags, etc. within bash. Once that's done, however, bash exits and make is called from the Windows CMD shell prompt directly, not within bash. * Autoconf's configure is often designed for the compilers on Unix systems. For example, AC_CHECK_LIB macro (used to check the existence of a library with given name) assumes that -lxxx option will make the compiler search libxxx. Apparently, it would not work with MSVC (/Fl should be used instead of -l). I could not find the abstraction system in Autoconf to translate such options, I'm afraid that Autoconf's configure is not safe solution for the people working with MSVC. Using autoconf for Cygwin/MSVC is pretty common in my (albeit limited) experience. You can refer to various libs to see this for yourself. An example is lib ICU, which has a CYGWIN/MSVC option in its configure file. I don't think ICU is good example, but anyway I will try some libraries using genuine autoconf only. c:\freetype vcvarsall amd64 c:\freetype bash ./configure --prefix=[path] --enable-static CFLAGS=/Gy /MD /EHsc /nologo CXXFLAGS=/Gy /MD /EHsc /nologo c:\freetype make c:\freetype make install To reiterate, I'm *NOT* running make in bash, but at the Windows CMD shell prompt, which is not the same as what you were indicating with configure make make install. That may be where the miscommunication is coming from here. Oh! Thank you very much for clarification, yes, I had overlooked that make was executed out of bash. I've never tried such. Regards, -RMWChaos -RMWChaos On 2012-09-18 12:01, suzuki toshiya wrote: Today I don't have my machine with MSVC in my hand... I think make setup visualc is not designed for the combination of Cygwin bash/make + MSVC. It would be suitable for MinGW make + MSVC. The binaries you want to build are those running on Windows platform WITHOUT cygwin? Or, those running DEPENDING cygwin? Cygwin is designed to pretend as if it were Unix platform, so configure will be (mis)guided as if it finds the platform as Unix. bash ./configure %FLAGS% make make install For most packages, this is working well; however, I'm really struggling Without giving concrete example, I could not comment about whether this (configure make make install) is right direction, because, I'm not sure which binary (with cygwin? without cygwin?) you want. What kind of packages you could get expected result? Regards, mpsuzuki RMWChaos wrote: *ENVIRONMENT:* MS Windows 7 x64 MSVC 2008 / SDK 7.0 -or- 2010 / SDK 7.1 Cygwin bash GNU make 3.8.1 *PREAMBLE:* Ultimately, this might turn out to be one build 'bug' and one build feature 'enhancement / change request', and perhaps I should submit this as two separate issues; however, they both relate to the same problem: I can't get Freetype2 to compile in Windows 7 x64 using Cygwin / GNU Make / MSVC 2008 or 2010. I'll wait to see what some initial responses are before deciding how to proceed. I'm attempting to develop an automated build process for a Windows application that requires the Freetype2 lib. The automated build allows for the selection of x86 / x64, MSVC 2008 / 2010, static / shared libs, and other options. To accommodate these options and simplify the build process, I want to build all libs using the following steps, where all the chosen build options are stored in var FLAGS... bash ./configure %FLAGS% make make install For most packages, this is working well; however, I'm really struggling with Freetype2. As noted in the two problem descriptions below, these steps aren't working because the Freetype2 configure and makefiles appear to be using absolute paths rather than relative paths (if I can modify this one thing, I can get my preferred method above to work). Alternatively,
Re: [ft-devel] first auto-hinter infinality patch added to git
I know i've asked this before :) but, could this concept also be used to Decrease the xheight at particular char sizes? Because decreasing the xheight can also increase legibility at some small sizes on some fonts. -v On Sep 18, 2012, at 10:02 PM, Werner LEMBERG w...@gnu.org wrote: Folks, I've just committed a first experimental auto-hinter addition from the Infinality patch: What you could originally control by the environment variable `INFINALITY_FT_AUTOHINT_INCREASE_GLYPH_HEIGHTS' can now be handled with the new property `increase-x-height' (and even fine-tuned, not possible with the original implementation). From the documentation: For ppem values in the range 6 = ppem = ‘increase-x-height’, round up the font's x height much more often than normally. If the value is set to 0, which is the default, this feature is switched off. Use this property to improve the legibility of small font sizes if necessary. FT_Library library; FT_Face face; FT_Prop_IncreaseXHeight prop; FT_Init_FreeType( library ); FT_New_Face( library, foo.ttf, 0, face ); FT_Set_Char_Size( face, 10 * 64, 0, 72, 0 ); prop.face = face; prop.limit = 14; FT_Property_Set( library, autofitter, increase-x-height, prop ); Along these lines it should be possible to add other auto-hinter extensions. Erik? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype 2.4.10 MSVC++ / Cygwin Compile fails
On 2012-09-18 23:26, mpsuz...@hiroshima-u.ac.jp wrote: Hmm. My concerns about Cygwin + MSVC cross compiling are following 2 points: * The compiler linker of MSVC are dependent with many MSDOS environmental variables designed for MSVC (to make compiler/linker search appropriate SDK directories including headers libraries). MSVC installation will provide a shortcut menu to start MSDOS command prompt with appropriate environment (I remember MSVC installer warns us NOT to put the environmental variables for MSVC to the default setting, because it can confuse the runtime dynamic loading), but no Cygwin terminal with appropriate environment for MSVC - we have to set by ourselves. In fact, when I invoke MSVC compiler in Cygwin's terminal, it will immediately failed. $ /cygdrive/e/MSVC2005/VC/bin/cl.exe /? /cygdrive/e/MSVC2005/VC/bin/cl.exe: error while loading shared libraries: MSVCR80.dll: cannot open shared object file: No such file or directory I don't have this problem, but I'm probably not initializing things the same way that you do. In my batch file, I'm using SETLOCAL/ENDLOCAL to contain any vars, including PATH, so that I can modify the PATH statement during batch execution without modifying it for the entire life of the CMD shell. Then I call the appropriate command for MSVC (vcvarsall.bat for MSVC2008/SDK7.0 and setenv.bat for MSVC2010/SDK7.1), which modifies the PATH statement as appropriate. Then, I call bash and can run cl.exe within it ... $ cl.exe /? Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.01 for x64 Copyright (C) Microsoft Corporation. All rights reserved. C/C++ COMPILER OPTIONS This allows autoconf to confirm the compiler works and set the appropriate flags, etc. within bash. Once that's done, however, bash exits and make is called from the Windows CMD shell prompt directly, not within bash. * Autoconf's configure is often designed for the compilers on Unix systems. For example, AC_CHECK_LIB macro (used to check the existence of a library with given name) assumes that -lxxx option will make the compiler search libxxx. Apparently, it would not work with MSVC (/Fl should be used instead of -l). I could not find the abstraction system in Autoconf to translate such options, I'm afraid that Autoconf's configure is not safe solution for the people working with MSVC. -- Because of my 2 concerns, I'm questionable whether the binary (configued by Autoconf's configure compiled by MSVC) is really useful. Maybe you want to ask if Autoconf configure MSVC combination is not recommended, what is recommended solution?. It would be MinGW make + MSVC. FreeType2's makefile (which is out of Autoconf) have the abstraction system mapping -l to /Fl for MSVC. Using autoconf for Cygwin/MSVC is pretty common in my (albeit limited) experience. You can refer to various libs to see this for yourself. An example is lib ICU, which has a CYGWIN/MSVC option in its configure file. I think the problem is not autoconf, but rather specifically how Freetype's configure files are coded. Generally, the flags for different compilers are set when the compiler is set; so if gcc or cc were found, then -l would be used, whereas if cl is found, /Fl would be used. That's a fairly simple code to write. Again, my experience with compiling is relatively new and growing, but so far other than Freetype, I'm not having any issues compiling this way... c:\freetype vcvarsall amd64 c:\freetype bash ./configure --prefix=[path] --enable-static CFLAGS=/Gy /MD /EHsc /nologo CXXFLAGS=/Gy /MD /EHsc /nologo c:\freetype make c:\freetype make install To reiterate, I'm *NOT* running make in bash, but at the Windows CMD shell prompt, which is not the same as what you were indicating with configure make make install. That may be where the miscommunication is coming from here. Regards, -RMWChaos -RMWChaos On 2012-09-18 12:01, suzuki toshiya wrote: Today I don't have my machine with MSVC in my hand... I think make setup visualc is not designed for the combination of Cygwin bash/make + MSVC. It would be suitable for MinGW make + MSVC. The binaries you want to build are those running on Windows platform WITHOUT cygwin? Or, those running DEPENDING cygwin? Cygwin is designed to pretend as if it were Unix platform, so configure will be (mis)guided as if it finds the platform as Unix. bash ./configure %FLAGS% make make install For most packages, this is working well; however, I'm really struggling Without giving concrete example, I could not comment about whether this (configure make make install) is right direction, because, I'm not sure which binary (with cygwin? without cygwin?) you want. What kind of packages you could get expected result? Regards, mpsuzuki RMWChaos wrote: *ENVIRONMENT:* MS Windows 7 x64 MSVC 2008 / SDK 7.0 -or- 2010 / SDK 7.1 Cygwin bash GNU make 3.8.1
Re: [ft-devel] first auto-hinter infinality patch added to git
I know i've asked this before :) Have you? I can't remember. but, could this concept also be used to Decrease the xheight at particular char sizes? Because decreasing the xheight can also increase legibility at some small sizes on some fonts. I'll add this to the TODO list. Could you provide examples? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype 2.4.10 MSVC++ / Cygwin Compile fails
On 2012-09-19 10:30, suzuki toshiya wrote: [...snip...] Ahh, I see. I will try. Using autoconf for Cygwin/MSVC is pretty common in my (albeit limited) experience. You can refer to various libs to see this for yourself. An example is lib ICU, which has a CYGWIN/MSVC option in its configure file. I don't think ICU is good example, but anyway I will try some libraries using genuine autoconf only. I may be able to save you the trouble of testing further with cygwin bash / MSVC unless you truly want to see how it works. In that case, I can provide you with a test batch file that will automatically setup your environment for MSVC 2008 or 2010, download, and compile a number of libraries including ICONV, ICU, BOOST, ZLIB, PNG, POSTGRESQL, TIFF, LIBPROJ, GEOTIFF, LIBXML2, PIXMAN, CAIRO, SIGC++, SQLITE, EXPAT, JPEG, and JPEG-Turbo (all Mapnik dependencies). Probably can do a whole lot more that were pyspatialite dependencies as well, but there's a lot of crossover here. Note - with ICU, I don't use the custom ./runConfigureICU file, but the standard ./configure, which TMK is genuine autoconf. I could be wrong; it's happened once or twice. ;-) To reiterate, I'm *NOT* running make in bash, but at the Windows CMD shell prompt, which is not the same as what you were indicating with configure make make install. That may be where the miscommunication is coming from here. Oh! Thank you very much for clarification, yes, I had overlooked that make was executed out of bash. I've never tried such. As for saving you the trouble of testing altogether, as I further read and better understood the INSTALL.GNU and CUSTOMIZE docs and did a little further testing, I saw why make setup ... was auto-detecting as unix every time. If I remove cygwin from my path statement first, it then defaults to the dos/windows setup, which is an improvement. Unfortunately, something else is now failing... process_begin: CreateProcess(NULL, type builds\newline, ...) failed. make (e=2): The system cannot find the file specified. make: *** [dos_setup] Error 2 So now I need to figure out why that is. It might have to do with the code to replace unix-style forward slashes with dos/windows-style backslashes. I'll look into this further then see how the compile goes once it's actually detecting a Win OS rather than unix. Additionally, I noted that freetype/builds/detect.mk is using a very klugy workaround for echoing newlines to the console. Instead of using this ... @type builds$(SEP)newline With an empty newline file, it's much easier just to use this... @echo: Same result, no fuss, no muss. Batch file magic. ;-) Regards, -RMWChaos -RMWChaos On 2012-09-18 12:01, suzuki toshiya wrote: Today I don't have my machine with MSVC in my hand... I think make setup visualc is not designed for the combination of Cygwin bash/make + MSVC. It would be suitable for MinGW make + MSVC. The binaries you want to build are those running on Windows platform WITHOUT cygwin? Or, those running DEPENDING cygwin? Cygwin is designed to pretend as if it were Unix platform, so configure will be (mis)guided as if it finds the platform as Unix. bash ./configure %FLAGS% make make install For most packages, this is working well; however, I'm really struggling Without giving concrete example, I could not comment about whether this (configure make make install) is right direction, because, I'm not sure which binary (with cygwin? without cygwin?) you want. What kind of packages you could get expected result? Regards, mpsuzuki RMWChaos wrote: *ENVIRONMENT:* MS Windows 7 x64 MSVC 2008 / SDK 7.0 -or- 2010 / SDK 7.1 Cygwin bash GNU make 3.8.1 *PREAMBLE:* Ultimately, this might turn out to be one build 'bug' and one build feature 'enhancement / change request', and perhaps I should submit this as two separate issues; however, they both relate to the same problem: I can't get Freetype2 to compile in Windows 7 x64 using Cygwin / GNU Make / MSVC 2008 or 2010. I'll wait to see what some initial responses are before deciding how to proceed. I'm attempting to develop an automated build process for a Windows application that requires the Freetype2 lib. The automated build allows for the selection of x86 / x64, MSVC 2008 / 2010, static / shared libs, and other options. To accommodate these options and simplify the build process, I want to build all libs using the following steps, where all the chosen build options are stored in var FLAGS... bash ./configure %FLAGS% make make install For most packages, this is working well; however, I'm really struggling with Freetype2. As noted in the two problem descriptions below, these steps aren't working because the Freetype2 configure and makefiles appear to be using absolute paths rather than relative paths (if I can modify this one thing, I can get my preferred method above to work). Alternatively, running 'make setup
Re: [ft-devel] Freetype 2.4.10 MSVC++ / Cygwin Compile fails
On 2012-09-19 11:07, RMWChaos wrote:
If I remove cygwin from my path statement first, it then defaults to
the dos/windows setup, which is an improvement. Unfortunately,
something else is now failing...
process_begin: CreateProcess(NULL, type builds\newline, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [dos_setup] Error 2
So now I need to figure out why that is. It might have to do with the
code to replace unix-style forward slashes with dos/windows-style
backslashes. I'll look into this further then see how the compile goes
once it's actually detecting a Win OS rather than unix.
Additionally, I noted that freetype/builds/detect.mk is using a very
klugy workaround for echoing newlines to the console. Instead of using
this ...
@type builds$(SEP)newline
With an empty newline file, it's much easier just to use this...
@echo:
Same result, no fuss, no muss. Batch file magic. ;-)
Curiouser and curiouser... I guess Win7 (and probably Vista) CMD shell
functionality has changed somewhat from earlier Win_NT, WinXP, and other
versions. In order to get ./builds/detect.mk to work properly for
DOS_SETUP, I had to modify it to a mix of the STD_SETUP using unix-type
commands and the original DOS_SETUP. Now this works...
# Special case for Windows 7 / Vista where echo works correctly,
but forward-slash ('/') needs to replaced with backslash ('\')
#and text should be surrounded by double-quotes to avoid errors when
the text contains parenthesis.
#
win_setup:
@echo
@echo $(PROJECT_TITLE) build system -- automatic system detection
@echo
@echo The following settings are used:
@echo
@echo platform $(PLATFORM)
@echo compiler $(CC)
@echo configuration directory $(subst /,$(SEP),$(BUILD_DIR))
@echo configuration rules $(subst /,$(SEP),$(CONFIG_RULES))
@echo
@echo If this doesn't correspond to your system or settings please
remove the
@echo file '$(CONFIG_MK)' from this directory then read the INSTALL
file for help.
@echo
@echo Otherwise, simply type '$(MAKE)' again to build the library,
or type
@echo '$(MAKE) refdoc' to build the API reference (the latter needs
python).
@echo
@$(COPY) $(subst /,$(SEP),$(CONFIG_RULES)) $(CONFIG_MK)
Where previously @echo would not work in a Win CMD shell. @echo:
results in the same problem as the original @type builds$(SEP)newline.
This is bizarre to me because echo: works for a newline in a batch/cmd
file. Oh well, this works, so no complaints.
However, the make setup process fails in the next step with...
process_begin: CreateProcess(NULL, del ./objs/ftmodule.h, ...) failed.
make (e=2): The system cannot find the file specified.
make: [objs/ftmodule.h] Error 2 (ignored)
Generating modules list in ./objs/ftmodule.h...
/usr/bin/sh: -c: line 0: syntax error near unexpected token `('
/usr/bin/sh: -c: line 0: `echo FT_USE_MODULE( FT_Driver_ClassRec,
tt_driver_
class ) ./objs/ftmodule.h'
make: *** [objs/ftmodule.h] Error 258
So now I need to go in and edit some additional files to make them work
here as well. Likely it's just more formatting as above.
Has anyone ever successfully built Freetype2 in a Windows 7 x64
environment (or x86), or is this a new hiccup? Or is something just
weirdly messed up with my config?? Perhaps what is needed now is an
additional check for Win7/Vista and this third type of formatting?
Regards,
-RMWChaos
-RMWChaos
On 2012-09-18 12:01, suzuki toshiya wrote:
Today I don't have my machine with MSVC in my hand...
I think make setup visualc is not designed for the combination
of Cygwin bash/make + MSVC. It would be suitable for MinGW make + MSVC.
The binaries you want to build are those running on Windows
platform WITHOUT cygwin? Or, those running DEPENDING cygwin?
Cygwin is designed to pretend as if it were Unix platform,
so configure will be (mis)guided as if it finds the platform
as Unix.
bash ./configure %FLAGS%
make
make install
For most packages, this is working well; however, I'm really
struggling
Without giving concrete example, I could not comment about
whether this (configure make make install) is right
direction, because, I'm not sure which binary (with cygwin?
without cygwin?) you want. What kind of packages you could
get expected result?
Regards,
mpsuzuki
RMWChaos wrote:
*ENVIRONMENT:*
MS Windows 7 x64
MSVC 2008 / SDK 7.0 -or- 2010 / SDK 7.1
Cygwin bash
GNU make 3.8.1
*PREAMBLE:*
Ultimately, this might turn out to be one build 'bug' and one build
feature 'enhancement / change request', and perhaps I should submit
this
as two separate issues; however, they both relate to the same
problem: I
can't get Freetype2 to compile in Windows 7 x64 using Cygwin / GNU
Make
/ MSVC 2008 or 2010. I'll wait to see what some initial responses are
before deciding how to proceed.
I'm
