Re: [ft-devel] ft2build.h being regenerated each time.
Samuel Williams wrote: however other tasks (like hacking with Freetype being one subcomponent which happens to be hacked on; or having Freetype being build by various toolchains) might plainly break if you do that. Can you give a use-case of this point? Project with various targets and several sub-packages, one of them being Freetype; Freetype built differently for some targets. Furthermore, the computation of dependencies is slightly broken for another sub-project, for example because it does not take into account the special form of Freetype internal #includes. If you are hacking on a sub-component, clearly something must change and thus can be tracked using the dependency tree. Again, you are assuming the rest of the world is perfect here. This was my whole point: by default, the project gave up a bit of optimisation in order to deal with environments which are not perfect, but which users expect Freetype to work out of the box (and also, the same way it performed in the past.) If in the case, you make a change, and something isn't recompiled, doesn't this imply the dependency tree is incomplete or incorrect? That is my assertion, yes. Which is why, to be on the safe side, it is better to mark more files as changed, as the install target does. Antoine ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ft2build.h being regenerated each time.
Hi guys, Samuel Williams wrote: The main issue, as demonstrated, is that the mtime of the file is not preserved. This means that build tools that depend on mtime (e.g. make) fail to work as efficiently as possible Mmmh, the definition of 'efficiency' here is not as universal as you might seem to think. I agree some tasks might be made more efficient when mtime is preserved or when unnecessary copying is skipped, like when building distributions; however other tasks (like hacking with Freetype being one subcomponent which happens to be hacked on; or having Freetype being build by various toolchains) might plainly break if you do that. And I guess you'll prefer a sub-efficient correct package over a over-optimized broken one. As a result, it seems to me that the as-shipped default should remain as it is now, to preserve customary habits, to avoid bad surprises, and as Werner said, since it is also the way everybody is doing it at large. Antoine ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Auto Embolding of Lohit Devanagari
Alexei Podtelezhnikov wrote: In this particular font the glyph width is larger than it advance, which is unusual. ... but it is typical of Devanagari fonts, and in general of several hanging scripts, where the upper bar is required to connect at both ends for most glyphs. I am not sure if it was done because of rounding errors while digitalizing the designs, or if this feature was put there to make sure the line is connected even if the outlines are somehow damaged by rounding; but in any case the Freetype library (and any upper-level libraries as well) should expect such a case if it is to handle Devanagari fonts. Antoine ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType patches to support amalgamation
Alan Coopersmith wrote: Using anything but a shared library for FreeType just seems to be begging for pain [...] Unlike many high-profile packages, Freetype is also used on (mostly embedded) platforms where shared libraries just do not exist. Also if some vendor has a design which, perhaps for historic reasons, do not include shared libraries, to make a single exception for Freetype will not ease substantially her updating pain. And forcing a design change to use shared libraries all over the place is often an order of magnitude more complex (and more expensive.) Antoine ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
Vinnie wrote:
I've been wracking my brains and trying to come up with every possibility
but I have given up - what is the utility of these lines:
#ifdef FT2_BUILD_LIBRARY
#define FT_INTERNAL_INTERNAL_H freetype/internal/internal.h
#include FT_INTERNAL_INTERNAL_H
#endif /* FT2_BUILD_LIBRARY */
versus
#ifdef FT2_BUILD_LIBRARY
#include freetype/internal/internal.h
#endif
???
Allowing to work dump sed scripts such as
/^#define/{
s,freetype/,Ft_,
s,/,_,g
}
the _ above is just an example; note it could have been \\ if
DOS/Windows compilers have been dump years ago... Of course, it does not
have to be a sed script, a Visual Studio or Eclipse macro could do the
same job.
As I read the rest of the thread(s), thanks for your work, it will help
to point out some quirks for name space issues which crept in during the
years.
Antoine
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Amalgamation
[ If your reader did not already told you: warning, long post! ]
Vinnie wrote:
I'm interested in building an amalgamated version of FreeType.
If I understand correctly your quest, Freetype 1 used to have such an
option (single object file, a.k.a freetype.[co]); in fact it was/is
even the base option!
For Freetype 2 (b. 1999), David went away from this scheme, in my eyes
for the benefit of a much increased modularity; of course, for
mainstream compilations where all the stuff ends being part of a
shared library or DLL built by mostly automatic tools, there is not much
of a difference at the end; where it IS really different is for others
users of the library, particularly those who compile for embedded
targets, where the space is always a concern.
I do not know if it still useful. Voices?
Specifically, I would like to use an in-house tool to combine all the
FreeType headers and source files into a set consisting of a single .h and .c
(or a couple of .c files if they are too large). This amalgamation would be
much easier to use - instead of requiring a bulky Makefile or IDE-specific
project file, one could just add the .c to an existing project.
Not sure I understand all the point, but it seems to me an issue at
software engineering here.
About the .c first:
In the beginning, (static) libraries where invented in order to share
code between projects; to maximize the space efficiency, the pieces in
the libraries were cut in smallest chunks; and linkers were invoked to
select only the relevant parts into the final binary. This model also
proved very good at paralleling tasks, where the libraries are developed
by some team, with a clearly defined interface, and used by several
independent programs created by different teams.
Then came dynamic linking and shared libraries, and in this view the
cutting process became essentially obsolete: all the code is present on
secondary storage (the shared object), and the selection of the
necessary pieces is done as-needed, mainly by the demand-paging
functions of the operating system through the dynamic linker.
Are you saying the Freetype project should move away from that
cutting-in-pieces process?
Or is it just about merging a big number of independently kept .c and
internal .h into one physical file (like sqlite3 is doing)?
My guess is such a work should pretty easy to do for the .c, but more
complex for the headers internal to the library; it looks like to me as
standard 4.3BSD unifdef(1), expanded to deal with #include as well;
perhaps such a tool already exist. Another possibility is a sed script
along the lines of
/^#include FT_FREETYPE_H/{
d; r path/to/already/merged/freetype/freeetype.h; }
/^#include FT_ERRORS_H/{
d; r path/to/already/merged/freetype/fterrors.h; }
/^#include FT_INTERNAL_OBJECTS_H/{
d; r path/to/already/merged/freetype/internal/ftobjs.h; }
I have no idea if there are cyclic dependencies, however...
Then, about the .h:
First, I understand that from the external point of view, it is already
looks like
#include ft2build.h
#include FT_FREETYPE_H
Granted, they are two files (ft2build.h is really just a proxy for
config/ftheader.h, you could substitute one for the other) not one, but
it really look like to me what you are asking for.
If the point is about the headers for the optional parts (#include
FT_BITMAP_H, FT_CACHE_H, FT_GLYPH_H, FT_TRUETYPE_IDS_H, etc.) this is
really the same point as above: if modularity is dropped, all those
files will be integrated into FT_FREETYPE_H; again very much like as it
was for Freetype 1, or as it is for windows.h or u.h (Plan 9). An
important resulting difference here used to be compilation times --
which issue was solved, particularly for Windows or Carbon, with
pre-compiled headers, a feature which is at odds with Freetype build
system... but I digress ;-)
For my purposes, there is value in being able to distribute a project that
uses FreeType, but has no external dependencies (i.e. someone does not need
to visit a separate source code repository to obtain freetype).
Freetype is basically free-standing, it does not need anything beyond a
C compiler and the most standard C functions; so a full copy of Freetype
tree will fit the purpose, it is just less practical than a couple of files.
The real issue with external dependencies is about upgrading. If we have
a look over the last 10 years of Freetype history as condensed into
docs/CHANGES, most version bumps are either bugfixes for some previously
introduced changes, or vulnerabilities fixes. Both are good reasons to
upgrade as soon as possible the version of Freetype in use. Having
Freetype provided in form of a few big flat files does not change
anything to the issue, upgrading is still recommended practice.
What is important on this respect OTOH, is that the amalgamationprocess
be realised by the Freetype project, and released through it: that way
any recommended upgrade could be made
Re: [ft-devel] FT_Get_Advance() docs
Werner LEMBERG wrote: While looking at the whole issue more closely, I've identified at least four bugs :-( One is extremely serious, making `FT_Get_Advance' return wrongly scaled values if fast advance loading isn't available (now fixed in git). Yesterday I was away from my mail, but I also found this bug, and used about the same fix as you committed. The only difference is a minor nit, in the case FT_LOAD_NO_SCALE is used and the quick way failed with ErrNotImplem, 10 scaling might not be done. Also, see below at the end for another point. The next two are more subtle and not directly related to `FT_Get_Advance' (I get wrong metrics from some fonts), and I need more investigation to fix them. Details please. I did found something myself, most likely a double rounding issue (more below), but I cannot figure where is the problem exactly because I do not know the internals enough :-(. Another thing we need to document is that the -glyph instance inside the face object might be erased after a call through FT_Get_Advance(). Yes. Can you provide a patch? Will do. I noticed there are some places (about GlyphSlotRec) where it is mentioned the API functions which modify them, I should update that. Well, there is also the problem that they used the FT_Get_Advance API specifying light rendering, just to found out later that the lightly hinted advance was actually different... One important issue has been missed completely by me: Advance widths don't change during the light hinting process, however, they get rounded to integer values, similar to TrueType. Yeah, and I understand this was the problem Chromium guys did encounter in the first place. After some thinking I now believe that it is a bug that `FT_Get_Advance' returns unrounded advance widths for the light hinting mode. Okay, but then we have to mimic exactly the rounding process used by the Load_Glyph logic*s*... More below. [...] in TrueType there is a way to get the hinted advances quicker than executing the full bytecode program, even if it is not alluded above: when the requested ppem has an associated hdmx/VDMX table within the font. Do you volunteer to implement support for those two tables? Yes, I will do that (but not today.) I looked at it, but it does not appear to be very easy to do, particularly because the current (*...clazz-get_advances)() functions returns _unscaled_ values (which are to be scaled within FT_Get_Advance while hdmx values are pixels, hence are already scaled. A possible way to deal with that could be for (*clazz-get_advances)() to return FT_PseudoErr_InternalAlreadyScaled (it's internal after all), and dealing with that case at FT_Get_Advance. How do you feel it? I wonder also about a new demo program to check whether FT_Get_Advance() gives, or not, the same results as FT_Load_Glyph(). This might be useful, yes. Attached. -f and -i options behaves the same as with ftbench: so -f 1 forces the use of the light hinting mode; -i is useful when you got many failures, to skip up to interesting glyphs. The -a option checks the value of glyph-advance.x; without -a, it checks the value of glyph-linearHoriAdvance (which are supposedly the base; more below.) I added the -r option after discovering as you did the issue with grid-fitting: so -r rounds the 16.16 values before doing the comparison. The problem I detected then was the behaviour of invocations like Cftchkadv -f 1 -a -r 147 \Windows\Fonts\times.ttf \Windows\Fonts\times.ttf: glyph 376: Load_Glyph--advance: 92. != Get_Advance: 91.7e20 glyph 377: Load_Glyph--advance: 92. != Get_Advance: 91.7e20 glyph 378: Load_Glyph--advance: 92. != Get_Advance: 91.7e20 glyph 379: Load_Glyph--advance: 92. != Get_Advance: 91.7e20 glyph 1620: Load_Glyph--advance: 1d. != Get_Advance: 1c.7ee0 glyph 1962: Load_Glyph--advance: 2b. != Get_Advance: 2a.7e00 glyph 2974: Load_Glyph--advance: 2c. != Get_Advance: 2b.7f40 glyph 3065: Load_Glyph--advance: 2b. != Get_Advance: 2a.7e00 8 fails. Changing ppem only changes the problematic glyphs :-/. Notice that every problem are always with Get_Advance being slightly below the xx.8000 mark. I know the path for Get_Advance: grabs the raw font units in 26.6 then MulDiv(,x_scale,64), and the result is in 16.16; my current guess is that within the Load_Glyph codepath for -advance, there is two rounding steps... but I do not where/how; also the fact I was not able to spot a similar problem with Type1 fonts suggests there is something specific to TrueType happening. But these experimentations with the two values (with -a or without) reminds me with the first point, about the computation of FT_Get_Advance in the fall-back case, and the use of the computed advance.x10 values as references: would it make more sense to use linearHoriAdvance0 there? I tried my test program with that change to ftadvanc.c, and detected another variation, this time with FT_LOAD_NO_HINTING
[ft-devel] Strict compiler warns at gxvmort2.c
Hi Toshiya-san,
Microsoft's compiler bails out while compiling src/gxvalid/gxvalid.c
cl /Za /D_CRT_SECURE_NO_DEPRECATE /Iobjs /I..\freetype2\builds\win32
/I..\freetype2\include /nologo /c /Ox /W3 /WX /DFT2_BUILD_LIBRARY
/DFT_CONFIG_MODULES_H=ftmodule.h /I..\freetype2\src\gxvalid
/Foobjs\gxvalid.obj ..\freetype2\src\gxvalid\gxvalid.c
gxvalid.c
C:\Users\FT\freetype2\src\gxvalid\gxvmort2.c(195) : error C2220: warning
treated as error - no object file generated
C:\Users\FT\freetype2\src\gxvalid\gxvmort2.c(195) : warning C4018: '' :
signed/unsigned mismatch
mingw32-make.exe: *** [objs/gxvalid.obj] Error 2
A quick look shows this is caused by the combination of
typedef struct GXV_mort_subtable_type2_StateOptRec_
{ /* ... */
FT_UShort ligatureTable;
FT_UShort ligActionTable_length;
and the actual code
FT_ULong offset;
/* ... */
} else if ( offset * 2
optdata-ligatureTable + optdata-ligatureTable_length )
The warning is pretty strict but highlights a potential problem on a
16-bit target (the sum can overflow, so being a very big negative, which
will trigger the test in a wrong way.)
I added a cast (to FT_ULong) to avoid the problem.
While I was here, I fixed a number of issues with the printf
specifications in the same area of code; I am not sure this is really
needed since I guess there are a lot of similar mismatches through the
codebase (any comments this about?)
Antoine
diff --git a/src/gxvalid/gxvmort2.c b/src/gxvalid/gxvmort2.c
index 9e08fb7..41bbd7f 100644
--- a/src/gxvalid/gxvmort2.c
+++ b/src/gxvalid/gxvmort2.c
@@ -186,20 +186,23 @@
offset = lig_action 0x3FFFUL;
if ( offset * 2 optdata-ligatureTable )
{
-GXV_TRACE(( too short offset 0x%08x:
- 2 x offset ligatureTable (%d byte rewind)\n,
- offset, optdata-ligatureTable - offset * 2 ));
+GXV_TRACE(( too short offset 0x%08lx:
+ 2 x offset ligatureTable (%ld byte rewind)\n,
+ (unsigned long)offset,
+ optdata-ligatureTable - (long)offset * 2 ));
GXV_SET_ERR_IF_PARANOID( FT_INVALID_OFFSET );
} else if ( offset * 2
- optdata-ligatureTable + optdata-ligatureTable_length )
+ (FT_ULong)optdata-ligatureTable +
+ optdata-ligatureTable_length )
{
-GXV_TRACE(( too long offset 0x%08x:
+GXV_TRACE(( too long offset 0x%08lx:
2 x offset ligatureTable + ligatureTable_length
- (%d byte overrun)\n,
- offset,
- optdata-ligatureTable + optdata-ligatureTable_length
- - offset * 2 ));
+ (%ld byte overrun)\n,
+ (unsigned long)offset,
+ (long)optdata-ligatureTable
+ + optdata-ligatureTable_length
+ - (long)offset * 2 ));
GXV_SET_ERR_IF_PARANOID( FT_INVALID_OFFSET );
}
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Get_Advance() docs
Werner LEMBERG wrote: I am not sure (so comment are welcome), but also I remember that a property of light rendering was to not change the advance (i.e., enforce AF_SCALER_FLAG_NO_ADVANCE); see also http://lists.nongnu.org/archive/html/freetype-devel/2008-09/msg0.html; under such a constraint/compromise, it does make sense to take the quick path to compute the advances. This is correct. However, this condition is not carved in stone and might change (even if this is unlikely), thus the `fast only' test flag. Okay, this makes sense. I guess we really should keep in mind this precondition, for example by documenting it along with the revision text about FT_ADVANCE_FLAG_FAST_ONLY (as a note over the note.) Another thing we need to document is that the -glyph instance inside the face object might be erased after a call through FT_Get_Advance(). Does something changed on this area since September 2008? No. The original poster's confusion was only due to bad documentation, as far as I can see. Well, there is also the problem that they used the FT_Get_Advance API specifying light rendering, just to found out later that the lightly hinted advance was actually different... Also on a related point, in TrueType there is a way to get the hinted advances quicker than executing the full bytecode program, even if it is not alluded above: when the requested ppem has an associated hdmx/VDMX table within the font. Why it is not currently available in Freetype I do not know. Noone has requested it. Do you volunteer to implement support for those two tables? Yes, I will do that (but not today.) I wonder also about a new demo program to check whether FT_Get_Advance() gives, or not, the same results as FT_Load_Glyph(). Finally, after that whole area has been cleaned up, we should revisit the FAQ: http://www.freetype.org/freetype2/docs/ft2faq.html#other-bbox is out of phase. Patches please! Will do too, now that I have the intent clear. Antoine ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Get_Advance() docs
Behdad Esfahbod wrote:
In Chromium, there's a bug being discussed right now about what the expected
return value of FT_Get_Advance() is:
http://code.google.com/p/chromium/issues/detail?id=66073
If I understand correctly the bug report, particularly the advance.cc
snippet (and without peeking at the Chromium and Webkit codes itself), I
got the impression you are using FT_LOAD_TARGET_LIGHT, ain't you?
Testing suggests that it returns glyph-linearHoriAdvance, not
glyph-advance.x. This is understandable, but unintuitive and not documented.
The documentation as it stands now reads as
/*Retrieve the advance value of a given glyph outline in
an */
/*@FT_Face. By default, the unhinted advance is returned in
font*/
/*
units. */
which strongly suggests to me that it is NOT safe to use against hinted
glyphs (OK, I assume one knows also that hinting is the default
behaviour unless overridden.)
Also, the documentation for FT_GlyphSlotRec reads as
/*linearHoriAdvance :: The advance width of the unhinted
glyph. */
and
/*advance :: This shorthand is, [...] , the
transformed*/
/* advance width for the glyph (in
26.6 */
/* fractional pixel format). As specified
with */
which seems to me in agreement with your tests, albeit not your
expectations (and also mine when I first read your message, before
diving deep into the headers of the library.)
In fact, the following suggests that FT_Get_Advance() may in fact take hinting
into account:
/*/
/* */
/* Const */
/*FT_ADVANCE_FLAG_FAST_ONLY */
/* */
/* Description */
/*A bit-flag to be OR-ed with the `flags' parameter of the */
/*@FT_Get_Advance and @FT_Get_Advances functions.*/
/* */
/*If set, it indicates that you want these functions to fail if the */
/*corresponding hinting mode or font driver doesn't allow for very */
/*quick advance computation. */
/* */
/*Typically, glyphs which are either unscaled, unhinted, bitmapped, */
/*or light-hinted can have their advance width computed very */
/*quickly. */
/* */
/*Normal and bytecode hinted modes, which require loading, scaling, */
/*and hinting of the glyph outline, are extremely slow by*/
/*comparison.*/
/* */
If I understand your point, you really would like to get quickly the
advances, even if --or when-- some hinting is involved (which seems a
reasonable quest, even if the current documentation hints otherwise.)
Another point can be made that the default behaviour (when
load_flags=0) for FT_Get_Advance is to return the *hinted* advances :-(
Some can even be see it as a bug, but I cannot decide if either of
documentation or of code.
Even stranger is that the /documented/ behaviour has been /applied/ to
CFF fonts, in
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=14de111f
(last hunk, replacing advance.[xy] with linear{Hori,Vert}Advance.) To
adjust the code to the documentation, the same change ought to be done
at the end of base/ftadvance.c as well.
I am not sure (so comment are welcome), but also I remember that a
property of light rendering was to not change the advance (i.e.,
enforce AF_SCALER_FLAG_NO_ADVANCE); see also
http://lists.nongnu.org/archive/html/freetype-devel/2008-09/msg0.html;
under such a constraint/compromise, it does make sense to take the quick
path to compute the advances.
On the other side, if advances could be modified by light hinting in
the same way as it can with normal hinting, then I believe the
FT_Get_Advance() function should not take the quick way in the former
case but not the later, should it?
Does something changed on this area since September 2008?
Also on a related point, in TrueType there is a way to get the hinted
advances quicker than executing the full bytecode program, even if it is
not alluded above: when the requested ppem has an associated hdmx/VDMX
table within the font. Why it is not currently available
Re: [ft-devel] freetype, undefined behaviour, and clang
Sean McBride wrote: Clang is an interesting tool to discover that sort of gotchas. 360 if ( (FT_ULong)(type-flags - FT_INT_MIN) FT_UINT_MAX ) This one should really look like if ( (FT_ULong)type-flags - FT_INT_MIN FT_UINT_MAX ) according to ANSI C : since FT_INT_MIN has a lesser rank than FT_Ulong (both because FT_Int has less rank than FT_Long and because signed promotes to unsigned in ANSI C), in the latter form the - operation is always done on unsigned values, so cannot overflow; the result is the same as the former except for the overflow possibility. Now, the purpose of such a test I am not sure I understand; if the purpose is to detect any flag set outside the range of FT_Int, then if ( type-flags FT_INT_MAX ) should do the same work in a somewhat cleaner way, shouldn't it? And then, the error message next line is a slight misfit: 0x%x are dropped\n, (type-flags ~((FT_ULong)FT_UINT_MAX)) (and there is another catch there, the format specifier should be %lx.) And if the real intent is what the error message states, then if ( type-flags FT_UINT_MAX ) would do the job. Again, clang is indeed an interesting tool... and it takes time to analyse each and every warning. Antoine ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] autoconf-based cross-building patch ([ft] FT2 Cross-compile Error)
Aaron Parr wrote:
Sorry to resurrect an ancient thread,
Indeed ancient! However that thread
(http://lists.gnu.org/archive/html/freetype-devel/2006-10/msg00026.html)
was about Toshiya-san providing us an updated version of the autoconf
machinery, dealing correctly with a (then new) locally-built helper
tool, apinames; and added a new file named docs/INSTALL.CROSS.
Do you mean you are having problem with the cross-compilation machinery?
Note that most in this area comes from autoconf (currently 2.68), I do
not believe there are much Freetype-specific stuff, probably only the .
but I ran into a similar problem when attempting to cross-compile freetype2
v2.4.6 using LTIB.
Do ``LTIB'' do anything special to process the (uncommon) Freetype
configuration process?
In the hopes of saving someone else the trouble, I'm including my solution in
the form of the attached patch which explains the problem and shows my hacky
fix to allow it to build under LTIB.
-Aaron
# 2011-Nov-07
# This patch provides a workaround for config problems caused by LTIB's env
setup.
# In a nutshell, two issues were occurring:
# 1) Freetype2's configure script was ignoring --build=XXX options
I cannot reproduce that in a basic (clean) installation of Freetype.
Is it possible to you to provide me the .log file of the configure step?
and guessing the wrong compiler triplet for the build machine when called in
LTIB environment
You mean, {FT2src}/build/unix/configure does not use CC_BUILD when
passed _as_argument_ on the command line? Strange, it does work here...
Are you sure you are passing it _after_ configure in the main
invocation, like in
path/to/top/configure --build=current-machine-triplet \
CC_BUILD=overridden-building-compiler \
--host=target-machine-triplet \
CC=overridden-target-gcc
As documented in the INSTALL.CROSS document and clearly explained in the
thread you mentionned, something along the lines of
CC_BUILD=overridden-building-compiler \
CC=overridden-target-gcc \
path/to/top/configure --build=c-m-3 --host=t-m-3
will NOT work!
Also note that Freetype chose (in 2006) to name it CC_BUILD while other
packages often use HOST_CC (*BSD heritage, confusing in the GNU world
based on Canadian cross compilation schemes) or CC_FOR_BUILD (preferred
in GNU world.)
# 2) The [triplet]-gcc file was adding some command switchs and somehow using
the path to find the true gcc when compiling. Since the LTIB environment
places its own spoof dirs first in the path, [triplet]-gcc wound up calling
the cross compiler.
I am not sure this is any different from the problem above.
Antoine
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] autoconf-based cross-building patch ([ft] FT2 Cross-compile Error)
[ Sorry if it appears duplicated, I sent first with the wrong name. ]
Aaron Parr wrote:
Sorry to resurrect an ancient thread,
Indeed ancient! However that thread
(http://lists.gnu.org/archive/html/freetype-devel/2006-10/msg00026.html)
was about Toshiya-san providing us an updated version of the autoconf
machinery, dealing correctly with a (then new) locally-built helper
tool, apinames; and added a new file named docs/INSTALL.CROSS.
Do you mean you are having problem with the cross-compilation machinery?
Note that most in this area comes from autoconf (currently 2.68), I do
not believe there are much Freetype-specific stuff, probably only the
part with deals with extension for executables (EXEEXT_BUILD, E_BUILD).
but I ran into a similar problem when attempting to cross-compile
freetype2 v2.4.6 using LTIB.
Do ``LTIB'' do anything special to process the (uncommon) Freetype
configuration process? I browsed the web site about it without success.
In the hopes of saving someone else the trouble, I'm including my
solution in the form of the attached patch which explains the problem
and shows my hacky fix to allow it to build under LTIB.
-Aaron
# 2011-Nov-07
# This patch provides a workaround for config problems caused by LTIB's env
setup.
# In a nutshell, two issues were occurring:
# 1) Freetype2's configure script was ignoring --build=XXX options
I cannot reproduce that in a basic (clean) installation of Freetype.
Is it possible to you to provide me the .log file of the configure
phase? (and of the former steps, if any.)
and guessing the wrong compiler triplet for the build machine when
called in LTIB environment
You mean, {FT2src}/build/unix/configure does not use CC_BUILD when
passed _as_argument_ on the command line? Strange, it does work here...
Are you sure you are passing it _after_ configure in the main
invocation, like in
$ path/to/top/configure --build=current-machine-triplet \
CC_BUILD=overridden-building-compiler \
--host=target-machine-triplet \
CC=overridden-target-gcc
As documented in the INSTALL.CROSS document and clearly explained in the
thread you mentioned, something along the lines of
$ CC_BUILD=overridden-building-compiler \
CC=overridden-target-gcc \
path/to/top/configure --build=c-m-3 --host=t-m-3
is NOT guaranteed to work!
Also note that Freetype chose (in 2006) to name it CC_BUILD, while other
packages commonly use instead HOST_CC (*BSD heritage, confusing in the
GNU world which is based on the Canadian cross-compilation scheme) or
CC_FOR_BUILD (preferred in GNU world.)
# 2) The [triplet]-gcc file was adding some command switchs and
somehow using the path to find the true gcc when compiling. Since
the LTIB environment places its own spoof dirs first in the path,
[triplet]-gcc wound up calling the cross compiler.
I am not sure this is any different from the problem above.
Antoine
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] 2.4.7 Copyright Years
Infinality wrote: While I was doing some merging of patches on my system, I noticed that 2.4.7 has at least some of the copyright headers showing years up to 2010 only. The patch I was working with, which is older than 2.4.7, has through 2011. 2.4.7: /* Copyright 1996-2001, 2002, 2003, 2004, 2005, 2006, 2007, 2010 by */ Older patch I have: /* Copyright 1996-2007, 2010-2011 by */ By the way, I believe both are unnecessary complex. The only dates which are significant are the one from the first copyright assignment, and the one from the last modification (assuming of course no change of copyright holders, or place of living of them.) So here I assume 1996-2011 does the trick. On the other hand, just modifying a file to update the year of copyright assignment is not fully correct IMHO if there are not any substantial modifications in the file itself. Just my idea though; WKMV [Werner's kilometrage may vary ;-) ] Antoine ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Apple Patents on font hinting expired?
Russell Hay wrote: Apologies if this is a much revisited topic, but I noticed that in the archives of this mailing list, there are some end dates stated for the relevant Apple patents; http://lists.nongnu.org/archive/html/freetype-devel/2006-11/msg6.html which states that// they are, respectively, 1992-10-13 and 1992-10-27, corresponding to expiration dates of: 5,155,805: October 13, 2009 5,159,668: October 27, 2009 ...has this 'removed the restrictions on distributing the the bytecode interpreter? [ I believe the restrictions are not upon distribution but rather upon use. But that is unimportant. ] As we know, Apple did file a few more patent requests. One of them, of special relevance, is FR1995712 19900507 (a follow-up of request US19890348703 19890508 which is now U.S. Pat. No. 5,159,668). This request was granted by the French Patent Office under No. 2,646,729 (FR2646729, dated 1990-11-09; more details in French at http://fr.espacenet.com/publicationDetails/biblio?KC=A1date=19901109; NR=2646729A1DB=fr.espacenet.comlocale=fr_FRCC=FRFT=D if you rebuild the brocken URL.) I am not a lawyer, and I cannot decide exactly if the expiration date of this particular patent is October 27th this year or May 5th next year (20 years from filing, the valid rule for French patents). Yet I think this may be relevant, particularly since David is living in France... Sorry Daddy^W David to awake you, but I believe you are the one who should answer on this one... Antoine PS: I would love to know the valid expiration date was October 27th. But after re-reading your mail referenced above, particularly And don't forget that there are equivalent EU, UK and FR patents (at least), which may have been filed later, with even later expiration dates. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ft_setjmp in Codewarrior
[EMAIL PROTECTED] wrote:
Wow, you've done a great and detailled analysis.
Thinking about a code like:
struct a_struct_ {
jmp_buf jb_memb;
} volatile* a_struct_ptr;
volatile jmp_buf* dest = ( a_struct_ptr-jb_memb );
...
For volatile jmp_buf* dest, according to the error message
by Metrowerks C compiler:
Error : illegal implicit conversion from 'long *volatile (*)[70]'
to 'volatile long * (*)[70]'
the memories pointed by the *dest elements are qualified as
volatile. This would NOT be expected qualification, because
the machine status is stored in the *dest elements, not in
the memories pointed by the *dest elements.
Agreed, there is a bug in the determination of the type for the dest object:
assuming jmb_buf is declared as array of _JBLEN elements of type _JB_t, it
sees dest as
volatile _JB_t [_JBLEN]
instead of the correct
_JB_t volatile [_JBLEN]
When _JB_t is a simple type like int, there is no difference; but when there
is a pointer embedded within _JB_t, there IS a difference.
By the way, it may be useful to report this bug to Metrowerks. Judging from
the form they are using for the error message, where volatile comes /before/
the type specifier, it looks like they have a problem of priority inside the
type evaluation code...
Therefore, an insertion of cast (volatile jmp_buf *) to right
side for Metrowerks C compiler may not be good idea, because
the interpretation of left side would be the root of problem.
Yes.
...
So, now I have 3 workarounds:
Did you try
jmp_buf volatile* dest = ( a_struct_ptr-jb_memb );
If this works, you've got a 4th workaround: there is no difference for a
conforming compiler between the two forms, but it might help a faulty
compiler to insert the volatile qualifier in the right place.
If this doesn't, I agree b is (much) better.
c) Use volatile void* instead of volatile jmp_buf*.
BTW, c is technically incorrect, since void* can have a different
representation from jmp_buf*; of course, this is not the case of mainstream
desktop compilers with 4GB address space, but it may be encountered e.g. in
segmented architecture like 16-bit i8086, where the jmp_buf* could be a
16-bit segment pointer, while void* would be a 32-bit far pointer.
Antoine
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] building freetype on z/OS
annubius hosted at hotmail.com wrote: For the most part it's building but I run into an error with zconf.h. Since it includes unistd.h it has the declaration of getopt which conflicts with stdio.h. This is a clear violation of the Posix standard, as unistd.h and stdio.h are two standard include files to be provided with your compiler, and they should interoperate quietly, so you should not get an conflict error just by including those two files jointly... However I guess this is not the reason why you made this point (furthermore, bashing the OS vendor here is not likely to give any fruitful advance.) If the #includeunistd.h in zconf.h is removed for unistd.h then all is well. OK, so what you are really asking/suggesting is to that we investigate/revise _why_ we are #including unistd.h in zconf.h, ain't you? zconf.h is one of the three places in Freetype where we do so if I am not mistaken, the second one being the src/tools/ftrandom/ftrandom.c but since it is not even protected I assume this ftrandom is an utilitary tool we can ignore for the moment, and the third one are the Unix+VMS ftsystem.[hc] to provide memory-mapping, but there I do not expect problems. The zconf.h source has currently: #ifdef HAVE_UNISTD_H # include sys/types.h /* for off_t */ # include unistd.h/* for SEEK_* and off_t */ # define z_off_t off_t #endif #ifndef SEEK_SET # define SEEK_SET0 /* Seek from beginning of file. */ # define SEEK_CUR1 /* Seek from current position. */ # define SEEK_END2 /* Set file pointer to EOF plus offset */ #endif #ifndef z_off_t # define z_off_t long #endif ... and it always had since the adding of this module in 2002; so this is something we inheritated from zlib. In fact, the current version of zlib have an even more elaborated setup: #if HAVE_UNISTD_H # include sys/types.h /* for off_t */ # include unistd.h/* for SEEK_* and off_t */ # ifdef VMS #include unixio.h /* for off_t */ # endif # define z_off_t off_t #endif [ ... rest unchanged... ] SEEK_* ought to be defined in stdio.h at any rate, which would be included anyway in Freetype (not so sure with raw zlib); so if I trust the comments, this all boils down to trigger the eventual typedefinition of z_off_t based on off_t. And off_t is not ANSI C, which explain the strecht. Posix requires off_t to be defined in both sys/types.h and unistd.h, and SEEK_* only in unistd.h; I guess Jean-Loup and Mark did put both headers in order to accomodate the widest audience, including ancient configurations; we do not have such requirement (beyond ANSI C that is), and the scene might have evolved somewhat here, so perhaps we can restrict ourselves to #include just sys/types.h (which is less problematic, and more common as unistd.h too), and drop the unistd.h stuff altogether. The idea would then be to test about HAVE_SYS_TYPES_H rather than HAVE_UNISTD_H, or perhaps even directly aiming at finding off_t typedef (can we?); so it requires high surgery in the autoconfigure stuff, something I am not able to do in a ten-minute post like this one :-) If someone (Werner ?) has the free time to test it over the week end, please do, it'll provide Annubius a speedier solution. At any rate, comments are most welcome! I am such a newbie at those Unix intrincacies that I am perhaps on wrong bases... Furthermore, we should probably add a note somewhere about the VMS test to get at unixio.h (which is probably here to get 64-bit support...) I also determined that it had to do due with the -D_ALL_SOURCE flag that was used on the xlC compiler. Well, this means the library went away from the requirement of ANSI compatibility (for this compiler). Did you build using `configure`, or by sticking to the normal method? Is this something that is needed for freetype to work successfully? Officially it should not, provided your compiler strictly conforms to the ANSI/ISO C standard. Since the above looks like a standard infringement to me (although of a different standard), my guess is that you are suffering of the same cause here. Antoine [ Courtoisie copy to the OP ] ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] freetype-2.3.7 -- ftconfig.h for biarch systems
On Thursday, July 10th, 2008, Werner LEMBERG wrote: Freetype effectively expects 8-bit char (I am not sure 9-bit chars or 16-bit chars could work or not, but I believe nobody checks it anyway). This is not correct. Some time ago a guy asked for support of 16-bit chars, and support for it has been added (cf. FT_CHAR_BIT). You are (of course) right, and I failed to remember it, my mistake. Based on your feedback and Suzuki-san points, I guess I really should put myself up-to-date about _all_ this stuff, and revisit it from ground up. The good point is that I remember some (I hope most) of the events which drove things this or that way (like the discoveries that Suzuki-san did yesterday). The bad point of course is that I am lacking time, but I promise to spend time on this during this summer (this way I shall be forced to finally make working my Linux x86_64, which is waiting in the dark since... December '04 :-/). Since I am *not* fluent with Linux configuration mechanism, do not expect quick solutions, though. To come back to the start of this thread, Werner answered to Peter that his purpose was addressed by issue #21250 (https://savannah.nongnu.org/bugs/index.php?21250). So I will restrict myself with that problem, since I fully understand what is the problem with Linux biarch (for the record, I am currently trying to build a similar toolchain for Windows' GCC). I am lost with potential issues (beyond what is reported on Savannah) with ppc's, Sparcs, or Macintoshes: I read the post from Suzuki-san to the autoconf list, which details (thank you) the problem on MacOSX, but for me it boils down exactly to the problem described by Peter: the installed headers should be target-agnostic. Of course, please comment if (and where) I am wrong here. I believe the autoconf way developped by Suzuki-san in the other thread is a complementary way (that I do not understand in details, but it looks promising); and it is tempting to try both ways: so we have better chances to finally end with good solutions. Antoine ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] freetype-2.3.7 -- ftconfig.h for biarch systems
On Tuesday, July 1st, 2008, Sean McBride wrote: On 7/1/08 10:19 PM, Werner LEMBERG said: Can freetype use C99 features? Not in general, but I don't object to put it into proper #ifdef...#endif blocks -- AFAIK, C99 can be checked by a preprocessor macro, right? Yes. __STDC_VERSION__ is defined as 199901L. Or would be a bigger value with the next versions of the standard. Currently freetype has things like: #if FT_SIZEOF_INT == (32 / FT_CHAR_BIT) typedef signed int FT_Int32; typedef unsigned intFT_UInt32; snip In C99 this could simply be: typedef int32_t FT_Int32; typedef uint32_tFT_UInt32; No size testing required. No problems with cross compilation nor universal binaries. First, you should use int_least32_t etc. which are guaranteed to exist, while int32_t ain't so. Next, as Werner says earlier, you whould really put this below a clause #if __STDC_VERSION__-0=199901 #include stdint.h and then _keeps_ the existing text (with the first #if changed to #elif). On Wednesday, July 2nd, 2008, mpsuzuki noted: On many platforms, gcc does not set the value __STDC_VERSION__ by default. Users have to set by -std=xxx option. Sure. This is because the STDC_VERSION mechanism is linked with the -std=c9x options: if you invoke the compiler with the -std=c99 option, you get the test macro as 199901L (and the above code could be brought in); however, if the compiler defaults to C90, you got no cookie (!) and are required to fall back at the present mechanism. On the other hand, it does not seem unreasonable to me to *require* bi-arch compilers to operate in C99 mode, providing this is adequately documented: as far as I understand, 32/64 bi-arch compilers are normally recent, so C99 ought to be available even if it is an option (as you pointed out for GCC 3.x) I do not know what is the context with MacOS vs C99, but fortunately you should know more than necessary this about! This puts 16/32 bi-arch compilers (like Digital Mars, or some targetting MC680x0) a bit out, but: - this has been the situation for many years now, and to date it did not show as a top-ranking problem ;-) - 16-bit Freetype is quite of exotic anyway (despite what I said earlier in this thread), so forcing 16/32 bi-arch compilers to operate in 32-bit mode does not seem a real stop. Similar reasonment applies for multi-arch compilers (like those for microcontrollers). Antoine ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] freetype-2.3.7 -- ftconfig.h for biarch systems
Hi Suzuki-san, On Tue, 8 Jul 2008 22:39:58 +0200 Antoine Leca wrote: There is a real defect with the above approach: imagine a conforming C90 compiler with 32 bits being the widest type; on such a compiler, cpp would evaluate the quantities using 32-bit arithmetic snip So my revised proposal has the check of cpp feature: #if ( 0x7FFFUL 0x7FFFUL ) # warning cpp can evaluate 64bit numerics Oh yes, this is really cute! The only backpoint is that #warning is a GNU extension (which is likely to cause havoc on several other compilers). On a technical sidepoint (read pedantic if you prefer), I know this is not 100% conforming because cpp is not required to perform using the same arithmetic rule as the target, but this is a case for .001% of the cross compilers, so we can ignore it (add a comment if you want). Formally you can drop the L suffix, it adds nothings (but does not break anything); of course you should keep the U suffix to avoid problem with signedness. # if ( INT_MAX 0x7FFF ) # error Non-standard C whose int cannot cover signed 16bit # elif ( 0x7FFF = INT_MAX ) ( INT_MAX 0x7FFFUL ) # define FT_SIZEOF_INT 2 # elif ( 0x7FFF = INT_MAX ) ( INT_MAX 0x7FFFUL ) # define FT_SIZEOF_INT 4 # else # define FT_SIZEOF_INT 8 # endif (http://lists.gnu.org/archive/html/freetype-devel/2008-07/msg00010.html). The truncation (as a string process from the beginning) of too long numerical constant is de-jure behaviour in C90? I think so, but the probability for occurences of bugs in this area is quite high, even for compilers seen as ANSI conforming by both its authors and its users, so you cannot really count on this. :-( I was misunderstanding that too long numerical constant causes some overflow in cpp. Considering the possibility of the string truncation from the end to fit 32bit integer, should I check another possibility like following? # if ( 0x7FFFUL 0x00017FFFUL ) I believe this is not necessary. Okay, it's going to be a bit technical; you were warned. Freetype effectively expects 8-bit char (I am not sure 9-bit chars or 16-bit chars could work or not, but I believe nobody checks it anyway). So we could restrict ourselves to the general cases, 16/32/64-bit etc. Particularly if it is about detecting the size of int. So either there is a limit with 32-bit so 0x7FFFul (case of most of C90 compilers), or we step forward to include 64-bit support and 0x7FFFul is the next frontier. Furthermore, I remember David used in ftinter some properties of 32×32 arithmetic (giving 64-bit results), and while my wild guess is that 33-bit or 34-bit should suffice according to the TT specs (David?), it is possible that our code really expects full 64-bit support. Seeing a bit farther, many developpers will consider 64-bit support would be granted with types names like FT_Long64; and they may develop algorithms taking this as granted; and nobody will uncovers bugs there for those architectures where there is only 36-bit (like PDP-10) or 40-bit (like TMS microchips) targets... Finally, I should say that the trick above is really a good one. Chapeau! Regards, Antoine ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] freetype-2.3.7 -- ftconfig.h for biarch systems
On Wednesday, July 9th, 2008 , mpsuzuki wrote: On Tue, 8 Jul 2008 22:56:12 +0200 Antoine Leca wrote: On Wednesday, July 2nd, 2008, mpsuzuki noted: On many platforms, gcc does not set the value __STDC_VERSION__ by default. Users have to set by -std=xxx option. On the other hand, it does not seem unreasonable to me to *require* bi-arch compilers to operate in C99 mode, providing this is adequately documented: as far as I understand, 32/64 bi-arch compilers are normally recent, so C99 ought to be available even if it is an option (as you pointed out for GCC 3.x) Hmm, if C99-dependent bi-arch header file is installed as a part of FreeType2, I'm afraid that all softwares using FreeType2 should be compiled with C99-conforming C compiler. And, C99-unconforming C compiler should be refused (or warned at least) during the compilation including FreeType2 header. I think it's not welcomed except of the developers on the platforms whose compiler works in C99-mode by default. Hmm, you are right, we were talking about the public headers and requiring C99 here, even for bi-arch toolchains, really hinders the portability of the library (think about the XYZ distro of Linux, whose maintainer uses a bi-arch compiler to simplify her job: this would restrict any FT-dependent package to be C99-conformant: clearly unreasonable). So I have to retract my suggestion. Even if we restrict the scope to C99-conforming cpp, there is no portable cpp conditional to check the size of long. This is a unimportant sidepoint, but you are slightly incorrect here: C99 requires 64-bit support, so any C99-conforming cpp could correctly detect (using your first proposal, among other solutions) 64-bit int's or long's. You are correct it is impossible to detect larger than 64-bit architectures (for the same reason it is impossible to detect larger-than-32 with C90), but on the other hand neither do we care! On a historical perspective, the real stuff was about detecting 32-bit int's, because several parts of the library could not be handled with 16-bit int, so we (well, DavidWerner;-)) decided long ago to use (now named as) FT_Int32 everywhere, requesting it to be at least 32 bits. Next phase, the problem was that the first choice for FT_Int32 was to use long: on 16-bit this is correct, and on classical 32-bit machines (read: all computers are Vaxen/x86) where int and long are the same thing, this is harmless. However on newer (around 1997) computers things were different, long could be 64-bit with a performance penalty wrt 32-bit int; furthermore at the same time we had a necessity to handle some (few) operations using 64-bit arithmetic. So we introduced the mechanism to select the best FT_Int32 and «FT_Long64» types, in the best (Standard-wise) way; the result is more or less what you are dealing with in ftconfig.h Those notes are there to remember you that perhaps verifying the real use of this mechanism (and I guess there are differences between FT_Int32 and «FT_Long64» here), and perhaps revisit part of the whole thing. I know this is a hard job (that I do not have the free time to do right now), but if someone which understands about varying sizes of int and bi-arch etc. has some free time to invest, it should be rewarding. Regards, Antoine ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] freetype-2.3.7 -- ftconfig.h for biarch systems
Hi Suzuki-san, On Tue, 8 Jul 2008 22:39:58 +0200 Antoine Leca wrote: There is a real defect with the above approach: imagine a conforming C90 compiler with 32 bits being the widest type; on such a compiler, cpp would evaluate the quantities using 32-bit arithmetic snip So my revised proposal has the check of cpp feature: #if ( 0x7FFFUL 0x7FFFUL ) # warning cpp can evaluate 64bit numerics Oh yes, this is really cute! The only backpoint is that #warning is a GNU extension (which is likely to cause havoc on several other compilers). On a technical sidepoint (read pedantic if you prefer), I know this is not 100% conforming because cpp is not required to perform using the same arithmetic rule as the target, but this is a case for .001% of the cross compilers, so we can ignore it (add a comment if you want). Formally you can drop the L suffix, it adds nothings (but does not break anything); of course you should keep the U suffix to avoid problem with signedness. # if ( INT_MAX 0x7FFF ) # error Non-standard C whose int cannot cover signed 16bit # elif ( 0x7FFF = INT_MAX ) ( INT_MAX 0x7FFFUL ) # define FT_SIZEOF_INT 2 # elif ( 0x7FFF = INT_MAX ) ( INT_MAX 0x7FFFUL ) # define FT_SIZEOF_INT 4 # else # define FT_SIZEOF_INT 8 # endif (http://lists.gnu.org/archive/html/freetype-devel/2008-07/msg00010.html). The truncation (as a string process from the beginning) of too long numerical constant is de-jure behaviour in C90? I think so, but the probability for occurences of bugs in this area is quite high, even for compilers seen as ANSI conforming by both its authors and its users, so you cannot really count on this. :-( I was misunderstanding that too long numerical constant causes some overflow in cpp. Considering the possibility of the string truncation from the end to fit 32bit integer, should I check another possibility like following? # if ( 0x7FFFUL 0x00017FFFUL ) I believe this is not necessary. Okay, it's going to be a bit technical; you were warned. Freetype effectively expects 8-bit char (I am not sure 9-bit chars or 16-bit chars could work or not, but I believe nobody checks it anyway). So we could restrict ourselves to the general cases, 16/32/64-bit etc. Particularly if it is about detecting the size of int. So either there is a limit with 32-bit so 0x7FFFul (case of most of C90 compilers), or we step forward to include 64-bit support and 0x7FFFul is the next frontier. Furthermore, I remember David used in ftinter some properties of 32×32 arithmetic (giving 64-bit results), and while my wild guess is that 33-bit or 34-bit should suffice according to the TT specs (David?), it is possible that our code really expects full 64-bit support. Seeing a bit farther, many developpers will consider 64-bit support would be granted with types names like FT_Long64; and they may develop algorithms taking this as granted; and nobody will uncovers bugs there for those architectures where there is only 36-bit (like PDP-10) or 40-bit (like TMS microchips) targets... Finally, I should say that the trick above is really a good one. Chapeau! Regards, Antoine ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] freetype-2.3.7 -- ftconfig.h for biarch systems
On Tuesday, July 1st, 2008, Sean McBride wrote: On 7/1/08 10:19 PM, Werner LEMBERG said: Can freetype use C99 features? Not in general, but I don't object to put it into proper #ifdef...#endif blocks -- AFAIK, C99 can be checked by a preprocessor macro, right? Yes. __STDC_VERSION__ is defined as 199901L. Or would be a bigger value with the next versions of the standard. Currently freetype has things like: #if FT_SIZEOF_INT == (32 / FT_CHAR_BIT) typedef signed int FT_Int32; typedef unsigned intFT_UInt32; snip In C99 this could simply be: typedef int32_t FT_Int32; typedef uint32_tFT_UInt32; No size testing required. No problems with cross compilation nor universal binaries. First, you should use int_least32_t etc. which are guaranteed to exist, while int32_t ain't so. Next, as Werner says earlier, you whould really put this below a clause #if __STDC_VERSION__-0=199901 #include stdint.h and then _keeps_ the existing text (with the first #if changed to #elif). On Wednesday, July 2nd, 2008, mpsuzuki noted: On many platforms, gcc does not set the value __STDC_VERSION__ by default. Users have to set by -std=xxx option. Sure. This is because the STDC_VERSION mechanism is linked with the -std=c9x options: if you invoke the compiler with the -std=c99 option, you get the test macro as 199901L (and the above code could be brought in); however, if the compiler defaults to C90, you got no cookie (!) and are required to fall back at the present mechanism. On the other hand, it does not seem unreasonable to me to *require* bi-arch compilers to operate in C99 mode, providing this is adequately documented: as far as I understand, 32/64 bi-arch compilers are normally recent, so C99 ought to be available even if it is an option (as you pointed out for GCC 3.x) I do not know what is the context with MacOS vs C99, but fortunately you should know more than necessary this about! This puts 16/32 bi-arch compilers (like Digital Mars, or some targetting MC680x0) a bit out, but: - this has been the situation for many years now, and to date it did not show as a top-ranking problem ;-) - 16-bit Freetype is quite of exotic anyway (despite what I said earlier in this thread), so forcing 16/32 bi-arch compilers to operate in 32-bit mode does not seem a real stop. Similar reasonment applies for multi-arch compilers (like those for microcontrollers). Antoine ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] bug fix: pointers in FT_Open_Args should be const
Graham Asher wrote: Casting from non-const to const is always legal, I believe, so I don't see how this can break compatibility. It is a struct, not a function prototype. So if your (= client) code manipulates such things, perhaps storing them, committing the change may make the code now stores a not-const-decorated pointer (from earlier API) to a const*... Definitively something compilers do not like! Antoine ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] No support for side-by-side installation of x86-64and i386
[Resend since I did not see the original one. Sorry if it duplicates. ] Hallo Werner, On Thursday, December 8th, 2005 14:37Z, Werner LEMBERG wrote: As far as I've seen, most system headers exist in one copy only, and use preprocessor macros to detect which the architecture is; usually via sys/isa_defs.h, which defines macros for most of the interesting cases: [...] This is the solution I like most. I don't know how difficult it is to achieve that... Well, if you are reading Ilya's original message, it is about what is currently done for Freetype (no surprise to me): Ilya wrote on Tuesday, December 6th, 17:02Z: ] Currently, freetype i386 and x86-64 collide in the following files: ] /usr/bin/freetype-config ] /usr/include/freetype2/freetype/config/ftconfig.h that is, they collide ONLY on the two built configuration files which describe the target architecture; in fact, it boils down that the target architecture bi-arch x86-32 + x86-64 has not been forcasted (in freetype-config.in and ftconfig.h.in). This is only what we need (but that's not easy). This is why I asked Ilya to provide his idea of his environment which would lead to the automatic selection of the correct subtarget/more/arch (to get back to the analogy with Solaris headers, the selecting macros in sys/isa_defs.h, if I got it correctly : sorry I do not use Solaris either). Then, we can probably build the picture of the two files to create for a GNU/Linux x86-64 target, allowing selection of x86-32 as well : if I am not mistaken it is the most sensible option. Then backport it into the .in templates (this is NOT the easy part). Please, do NOT make the mistake to assume that target=*-x86_64 is sufficient: while nowadays every targetting x86-64 also supports x86-32 (i386 if you prefer), there are no architectural reason for this to hold forever, particularly in embeeded; and also, and perhaps more importantly, the trick to have /lib for x86-32 and /lib64 for x86-64 is NOT universal (e.g. on Windows, it is /lib, or more exactly /Program Files or system32, for x86-64, and something along the lines of /lib32 (like /Program Files (x86)) for x86-32). Also as said earlier, we probably should not assume everybody has GLib or pkg-config installed when targetting x86-64 (furthermore it may lead to version dependencies). Antoine ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] No support for side-by-side installation of x86-64 andi386
On Tuesday, December 6th, 2005 17:02Z, Ilya Konstantinov wrote: Currently, freetype i386 and x86-64 collide in the following files: /usr/bin/freetype-config /usr/include/freetype2/freetype/config/ftconfig.h This makes installation of two freetype development kits impossible. Installing two development kits is desirable when the developer does plenty of cross-compiling to x86-64/i386, which is often the case on x86-64 machines. BTW, this is not really cross-compiling. Real cross-compiling IMHO usually involves having a cross-compiling target environment, different from the host environment (usually selected as higher priority flags overriding the normal ones). In the case of freetype, it would mean having a dedicated directory for ftconfig.h et alii appropriate to each target, and of course different from /usr/include... BTW, this works great in general (and almost always did)! You are really seeking to have two separate freetype libraries (I assume in /usr/lib for x86-32 and /usr/lib64 for x86-64) available simultaneously _by default_, and perhaps select the correct ones according to flags such as -m32 and -m64 for gcc..., that is, _not_ really doing something as complex as setting up a complete cross-compiling environment. It would be very much desired that: 1. freetype-config would be recoded to detect its environment Can you please elaborate on what do you mean by your environment here? I am sorry if it seems ingenious. I am not currently running Linux, nor GLib; as such I am not sure what is the current official process of configuration of Freetype; if I am not a normal user of Freetype and as such my remarks are irrelevant, please say so, I won't be sad. Antoine ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Digital signatures
Salut David, On Friday, August 26th, 2005 10:19Z, David Turner wrote: About the threat to enforcing DSIG or for Microsoft: We completely gave up competing with Apple on the graphics design and print market. Also, we forgot what the PC revolution was all about. It will also mean a huge rush on technical support for both MS and its OEM resellers (my font does not work any more), which in turn means a bunch of big bucks, something that is definitively out of order. Not to mention a lot of trials about enforcing monopolies, with the consequence that the enforcement will not be effective in unmanaged environment (read home/SOHO users, as opposed to big corporations, see below.) The only plausible scenario for DSIG I can think of is the head of an IT department deciding to only allow signed binaries/documents/fonts/ wathever on its Windows network. I'm also convinced that the experiment will not last more than 24 hours :-) Since I am in the head if IT dept business ;-), I am not that sure the experiment may not last a bit longer. Sure, a wide part of the public, i.e. the technically-skilled people, the same that as George does not worry very much if their station crash because of an experiment with a strange font ;-), would be excluded of the experiment starting on hour H+2 as a maximum!!! This includes everybody reading me, BTW, and it includes the proper head if IT dept and his staff, of course! :-D But the IT head might have other ideas for his more peaceful victims... and there the experiment could last a bit longer. Particularly if he succeeds at convincing the big boss that this would allow restriction in the use of PCs to replay/download/whatever 'illegal' (in the sense of DRM/MDCA) content ;-). Also, if some hacker succeed at creating a TT font exploit (still to see it even in lab), *and* that it appears that enforcing the signature is a valuable countermeasure (not true today, but with Palladium these kind of things could be envisioned), *then* I can assure you that such an experiment could be set up: as you might know, counter threats like virus spreading allow to quick and vigorous measures to be taken. Of course, such a fix is a (bad) kludge. OK, enough rambling, I've real job to do. Antoine ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Digital signatures
On Thursday, August 25th, 2005 14:17Z George Williams wrote: First of all that seems a very weak form of protection. I believe it is more social than technically effective. Secondly I don't really understand what damage a font can do to my system. The worst I can think of is a) crash the X server b) send pango into an infinite loop. To me neither of these seems all that worrying. Because you are using a workstation. Think about it if you are running a server instead (or an embeeded device). Then you do worry about about crashing or sending a thread into infinite loop. DSIG is a MS thing, and they have (thanks to the monolithic architecture which integrates the GUI with the kernel, while targetting both workstations and servers) to think about these issues. I don't see how a bad font can have any real effect on the integrity of my system. Right now, neither am I. However it seems that in security, paranoia is a needed skill. Antoine ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Digital signatures
Salut David, Tu peux dormir ? ;-) On Thursday, August 25th, 2005 15:18Z Turner, David wrote: My opinion is that the DSIG table is the brain-child of DRM-obsessed managers at Microsoft Typography (or above), who don't understand much things regarding security. They only understand that security is a buzzword (and it was even _before_ the 2001 'revolution' codenamed 'code-red'), and that's all that matters about DRM and the like (FUD) :-). If digital signatures are not mandatory _and_ used with non-reversible encryption, they're simply useless. Useless about security, probably. Worse, the MS tool that signs does not check many things (and certainly not possible exploit, since none are known ;-)), and anyway you can set it up to allow signing using /another/ checking tool... Which are the reasons why you, George, me, and the majority of the writers in the OpenType thread, believe this is related to anything except computer security. From the Adobe page about this (http://minilien.com/?J9TnbFnOrb), the two objectives are Secure identification (of the provider, i.e. DRM) and no tampering; and this page then goes to great length to explain that Digital signatures do not guarantee that that the font is a good font. OTOH, the threat about requiring all fonts to be signed in a future version of Windows is clearly written (remember this page targets font developpers, who should buy the certificates, then manage them.) Even if I believe they never will in fact enforce the threat (as you can read in the thread). All we can add at this point, is that *Free*Type probably will /never/ require fonts to be 'signed', in any future release ;-). David, is it a good point to add this to the website? Antoine ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
