from:"\"mpsuzuki\""

Dear Mr. Werner LEMBERG,

On Tue, 23 Aug 2005 11:50:35 +0200 (CEST)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:

> thanks a lot for your work!  I've given both of you write access to
> the FreeType repository -- please add everything to the CVS; I'll
> revise it later on.

Great Thank you for CVS permission!
I will commit gxvalid patch within 48 hours from now.

> Just a minor nit: Wouldn't it be better if you thoroughly use
> `TRUETYPE_GX' instead of `TRUETYPEGX'?  Or maybe `GX' is sufficient to
> avoid too long tags?

Thank you for pointing out.

Yes, the keyword "TRUETYPEGX" is ugly and lengthy for
capitalized keyword. We've chosen it by a process of elimination.

"TRUETYPE_GX" is more natural analogous of the name "TrueType GX".
But there are existing "FT_TRUETYPE_XXX" macros,
so we've thought "TRUETYPEGX" is better to avoid namespace confusion,
for the people unfamiliar with font formats.

"GX" looks enoughly short, in fact, ICU uses such naming rule.
But I'm afraid that "GX" is a bit too generic keyword,
it can be used in different context, in future.
If "GX" is expected to be particular keyword in future,
I will rewrite with "GX". How do you think about?

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [patch] TrueType GX/AAT validator

Dear Mr. George Williams,

On 22 Aug 2005 22:04:00 -0700
George Williams <[EMAIL PROTECTED]> wrote:

>On Mon, 2005-08-22 at 18:29, [EMAIL PROTECTED] wrote:
>>   - state transition diagram uses undefined glyph ID
>A note of caution here, the apple world makes use of undefined glyph IDs
>as temporary state flags. One state machine will test for a condition
>and apply a substitution which creates an invalid GID, then another
>state machine will detect the bad GID, change it to something valid and
>enter a new state where it does other substitutions.
>   Example font: Zapfino 4.1d6

Based on your detailed analysis (thanks again), I removed the line
"   - state transition diagram uses undefined glyph ID"
from the essential error list, and add following paragraph
into the section. If I'm misunderstanding, please let me know.

In addition,  gxvalid doesn't check  "temporal glyph ID" used in the
chained State Machines (in "mort" and "morx" tables).  When a layout
feature is implemented by  single State Machine,  glyph ID converted
by State Machine is passed to the glyph renderer, thus it should not
point to undefined glyph ID.  But if a layout feature is implemented
by chained State Machines, the component State Machine (if it is not
final one) is permitted to generate  undefined glyph ID for temporal
use, because it is handled  by next component State Machine, instead
of the glyph renderer.  To validate such temporal glyph ID,  gxvalid
must stack  all undefined glyph IDs  which is possible in the output
of previous State Machine and search them in "ClassTable" of current
State Machine.  It is too complexed work to  list all possible glyph
IDs from StateTable, especially from ligature substitution table.

I think quick hack is not enough to solve this issue,
so I want to put it to TODO of gxvalid.

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [patch] TrueType GX/AAT validator

Dear Mr. George Williams,

On 23 Aug 2005 14:50:54 -0700
George Williams <[EMAIL PROTECTED]> wrote:

>On Mon, 2005-08-22 at 18:29, [EMAIL PROTECTED] wrote:
>> 4-5. invalid feature number (117/183)
>> -
>> GX/AAT extension can include 255 different features for layout,  but
>> popular layout features are predefined

>Are you sure it's only 255? The 'feat' table stores both feature and
>setting ids as uint16. The 'mort'/'morx' chains also use uint16. I
>didn't see anything which said they were limited to 255 -- but I haven't
>read everything:-)

Excuse me, it was my mistake in documentation: 65535, not 255.
gxvalid can use uint16 feature number, does not limit to 255.

>(And there are certainly fonts which use feature numbers>255,
>Osaka.dfont for one)

Thanks for giving concrete example, OK,
following is (part of) output of gxvalid on Osaka 4.2.

[ftvalid:gx] validation targets: mort
---
validation mort table
validate chain 1/1
  mort chain header table
mort feature list table
featureType 16000 is out of registered range, setting 0 is unchecked
featureType 16000 is out of registered range, setting 1 is unchecked
featureType 16001 is out of registered range, setting 0 is unchecked
featureType 16001 is out of registered range, setting 1 is unchecked
featureType 4 is registeredsetting 0
featureType 4 is registeredsetting 1
featureType 103 is registeredsetting 0
featureType 103 is registeredsetting 2
featureType 25 is registeredsetting 0
featureType 25 is registeredsetting 1
featureType 0 is registeredsetting 1

I see, as you've pointed out, featureType > 255 are used,
and gxvalid handles them correctly.

>> (see http://developer.apple.com/fonts/Registry/index.html).
>> Some  fonts  include  feature  number  which  is  incompatible  with
>> predefined feature registry.
>> 
>> In our survey, there are 140 fonts including "feat" table.
>> a)  14 fonts uses too-large feature number (out of defined range).
>> b)  67 fonts uses feature number which should not be used.
>> c) 117 fonts set wrong feature range (nSetting).
>>this infraction is found in mort/morx.

>The 'feat' (and 'mort') documentation says:
>Apple has defined a standard set of text features. You may
>include one or more of these or create your own text features.
>Font features that will be supported by your font must be part
>of the Font Feature Registry maintained by Apple Computer, Inc.
>To me this seems contradictory. First we are told we can create our own
>features, then we are told we can only use standard ones.
>(I really dislike Apple's TrueType documentation)

I see. In fact, Osaka.dfont is manifactured by Apple themselves,
but uses non-standard feature number, and it is not registered.

Umm, I remove "too-large feature number" from the error list,
because it is 'officially' permitted to use non-standard feature
number, and Apple themselves do so, as you pointed out.

As attached in above, at present, gxvalid shows tracing message
about such feature number: featureType is not in predefined range,
so the correctness of setting value cannot be validated.
I think it is acceptable point of compromise.

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [patch] TrueType GX/AAT validator

Dear Mr. George Williams,

Oops, sorry for crossing of paths.

On 23 Aug 2005 17:35:12 -0700
George Williams <[EMAIL PROTECTED]> wrote:

>So:
>a) 14 fonts uses too-large feature number (out of defined range).
>I can't find anything that says the range is a byte, but there may be
>something I've missed.

I agree. I remove it from the error list.

>b)  67 fonts uses feature number which should not be used.
>I'm assuming this means features not defined in Apple's Registry. I
>think this should be ok.

No, I was meaning about the hole of predefined range.
According to http://developer.apple.com/fonts/Registry/index.html,

>   kanaSpacingType = 25,

>   ideographicSpacingType = 26,

>   cjkRomanSpacingType = 103,

>/* The following types are provided for compatibility; note that
>   their use is deprecated. */
>
>   adobeCharacterSpacingType = 100,/* prefer 22 */
>   adobeKanaSpacingType = 101, /* prefer 25 */
>   adobeKanjiSpacingType = 102,/* prefer 26 */
>   adobeSquareLigatures = 104, /* prefer 1 */

There is a hole from 27 to 99, I thought it is reserved area,
although I could not find any documentation about it.
It should be used as same as the undefined area > 105?

>c) 117 fonts set wrong feature range (nSetting).
>do you mean that more settings are defined for a feature than are
>present for that feature in the 'feat' table? If so, I agree this should
>be an error.

>Or do you mean more settings are defined than are present in the
>registry? I think that should be ok.

The latter. I was meaning the nSetting value is out of range
defined in Apple registry. For example, feature number 1
(ligatureType) has 15 settings aslike:

>enum {
...
>   ligaturesType = 1,
>
>  requiredLigaturesOnSelector  = 0,
...
>  abbrevSquaredLigaturesOffSelector= 15,

But, Courier 3.5 in MacOS 9.2.2:

[ftvalid:gx] validation targets: mort
---
validation mort table
validate chain 1/2
  mort chain header table
mort feature list table
...
featureType 1 is registeredsetting 2
featureType 1 is registeredsetting 3
featureType 1 is registeredsetting 32out of defined range 15
featureType 1 is registeredsetting 33out of defined range 15

setting 32, 33 are out of defined range.

Your suggestion is that undefined setting values should be handled
as the same way for user-defined feature number (so they are not errors)?
If so, I will remove this from the error list.

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gxvalid patch for ftvalid.c

On Wed, 24 Aug 2005 00:14:10 +0200 (CEST)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:
> > I will rewrite with "GX". How do you think about?
> 
> This is fine with me.

After replacing "_TRUETYPEGX_" macros to "_GX_",
I've just committed whole of gxvalid patch to CVS.

Yamato-san, please commit ft2demos patch, after replacing
the line in ftvalid.c

#include FT_TRUETYPEGX_VALIDATE_H

to

#include FT_GX_VALIDATE_H

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Freetype on Mac uses deprecated functions

2005-08-24 Thread mpsuzuki

Hi,

On Wed, 24 Aug 2005 12:41:52 -0400
"Sean McBride" <[EMAIL PROTECTED]> wrote:
>These functions have been officially deprecated as of Mac OS 10.4 Tiger,
>but unofficially deprecated long ago.  The two main points are:
> - FSSpecs should be replaced with FSRefs
>   - <http://developer.apple.com/technotes/tn2002/tn2078.html>
> - Font Manager calls should be replaced with ATS for Fonts.
>   - <http://developer.apple.com/documentation/Carbon/Conceptual/
>ATS_Concepts/atsfonts_intro/chapter_1_section_1.html>
>   - The main header is ATSFont.h, in ApplicationServices/ATS

Thank you for informative references. Do you know any docs to
know about: which version of MacOS has which functions?
I'm not sure if FreeType maintainers have enough sparetime to
support antique MacOSs (System7, MacOS 8 etc), but I think it's
important which platforms are dropped in next ftmac.c (if there's).

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Freetype on Mac uses deprecated functions

2005-09-01 Thread mpsuzuki

On Thu, 01 Sep 2005 23:39:34 +0200 (CEST)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:

>
>> Another reason to move away from the old Font Manager and to ATS, is
>> that some of the Font Manager stuff will not carry over to Mac OS X
>> on Intel without extra work, [...]
>
>Any volunteers?  Neither David nor I use a Mac...

I want to do. I have MacOS 9.2 + MacOS X 10.0 + MacOS 10.1
+ MacOS 10.3 machine. Unfortunately, I have no developer
kit for MacOS 9. Any recommendation what I have to buy?

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Freetype on Mac uses deprecated functions

2005-09-03 Thread mpsuzuki

Dear Sirs,

Sorry for lated response.

On Fri, 02 Sep 2005 11:14:56 +0200
[EMAIL PROTECTED] (Christian Demmer) wrote:
>[EMAIL PROTECTED] wrote:
>>I want to do. I have MacOS 9.2 + MacOS X 10.0 + MacOS 10.1
>>+ MacOS 10.3 machine. Unfortunately, I have no developer
>>kit for MacOS 9. Any recommendation what I have to buy?
>
>No need to buy anything. Just get MPW from Apple. It's free.
><http://developer.apple.com/tools/mpw-tools/>
>
>Be sure to apply the latest updates (Updated MPW Components) since the
>last release is from 2001. There is no new release because Apple does
>not actively support it anymore.

Excuse me, please let me ask fundamental question: MPW or CodeWarrior
are required to compile ftmac.c? There are 3 building control files
in FreeType tree:

* freetype2/builds/mac/freetype.makeis for MPW
* freetype2/builds/mac/ftlib.prjis for CodeWarrior
* freetype2/base/Jamfileis cross platform,
but ftmac.c is quoted for MPW

Could I compile ftmac.c via UNIX style configure/make process?

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Freetype on Mac uses deprecated functions

2005-09-03 Thread mpsuzuki

Dear Mr. Christian Demmer,

On Sat, 03 Sep 2005 16:42:31 +0200
[EMAIL PROTECTED] (Christian Demmer) wrote:

>[EMAIL PROTECTED] wrote:
>>Excuse me, please let me ask fundamental question: MPW or CodeWarrior
>>are required to compile ftmac.c?
>
>Not necessarily. It depends on your target OS and runtime environment
>ABI. If you want OS 9 (CFM) then you need MPW or Codewarrior. OS X can
>run CFM (MPW/Codewarrior) or Mach-O produced by gcc or Codewarrior?
>(not sure, I don't use Codewarrior).
>
>> There are 3 building control files
>>in FreeType tree:
>>
>>* freetype2/builds/mac/freetype.make  is for MPW
>
>MPW is a shell with makefiles but the makefiles are different from Unix.
>
>>* freetype2/builds/mac/ftlib.prj  is for CodeWarrior
>>* freetype2/base/Jamfile  is cross platform,
>>  but ftmac.c is quoted for MPW
>Not sure here either. I think Jamfiles were used in ProjectBuilder some
>time ago, that means OS X/gcc -> Mach-O environment.
>
>>Could I compile ftmac.c via UNIX style configure/make process?
>
>Yes, but only on OS X targeting Mach-O.

Great Thank you very much for detailed explanation. In fact,
I didn't know ProjectBuilder can recognize Jamfile. Now I could
compile ftmac.c for Mach-O target by MacOS X's gcc manually.

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Freetype on Mac uses deprecated functions

2005-09-04 Thread mpsuzuki

Dear Sirs,

First of all, Great Thanks to people giving helpful informations
of Macintosh issues: Sean McBride, George Williams, Tom Bishop, 
Christian Demmer, David Turner and Werner LEMBERG.

I've written a diagram of function-calling-tree of related
functions in ftmac.c.

http://www.gyve.org/~mpsuzuki/ftmac_c.txt

As Sean McBride cited 2 Apple documents, the deprecation issue
consists of 2 function groups: FileManager and FontManager.
I think fixes can be done separately.

For first, I will try fix the problem of FileManager issue.

--

According to Apple TechNotes TN2078, it seems that replacement
of FSSpecXXX() by FSRefXXX() is not sufficient of the deprecation
issue, because the data struture "FSSpec" (which is used to point
a file in Macintosh) itself is deprecated and replacement by
"FSRef" is recommended.

At present, ftmac.c provides a public function to open new face
from given "FSSpec":  FT_New_Face_From_FSSpec(). Thus, complete
cleasing "FSSpec" will cause API incompatibility.
Some configuration option to build without FSSpec might be expected
(and it is expected to be switched off by default, until the day
Apple removes FSSpecXXX() completely).

# I don't know PBMakeFSSpecSync() is deprecated in Tiger.
# If there are some undeprecated functions handling FSSpec,
# it is possible to provide FT_New_Face_From_FSSpec() without
# compiler warning of deprecation. However, PBMakeFSSpecSync()
# is not easy to use, for me.

In addition, from the viewpoint of application programmers,
something like FT_New_Face_From_FSRef() is expected to replace
"FSSpec" in their applications.

Any suggestion about the deprecation of "FSSpec"?

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Freetype on Mac uses deprecated functions

2005-09-05 Thread mpsuzuki

Dear Sirs,

Status for Tiger's API deprecation issue:
My working source is available from GNU arch archive from

URL: http://www.gyve.org/~mpsuzuki/arch-2005.09.03
archive name: [EMAIL PROTECTED]
project: freetype2--mps-macos--0.1

George Williams sent me his patch skelton to replace
FSSpec by FSRef, it's slightly fixed and applied in
the working tree. Now I'm working for replacement of
FontManager by AppleTypeService, used in FT_GetFile_From_Mac_Name().

The function resolves "abstract" fontname recognized by system
to "concrete" file, but the resolved result is returned by
obsolete FSSpec structure. ATS provides the replacements for
the most functions of FontManager, by 1:1 corresponding functions. 
But FontManager does not provide function to return font file
by FSRef structure, and ATS does not either. In fact, there's
no ATS function to find font file for a given font name,
except of ATSFontGetFileSpecification(). I'm afraid it will be
deprecated in future.

However, I've already written sample programs to resolve
font name -> font file by ATS functions and FSRef data.
They are available from GNU arch in above,

project: carbon-sample--mps--0.0

Yet I've not checked other APIs,
I suppose ATS is designed to hide "concrete" font data, and
I should search other API to find "concrete" font data.
Any suggestions?

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Freetype on Mac uses deprecated functions

2005-09-06 Thread mpsuzuki

Dear Mr. Sean McBride,

On Tue, 6 Sep 2005 13:31:13 -0400
"Sean McBride" <[EMAIL PROTECTED]> wrote:

>On 2005-09-06 10:54, [EMAIL PROTECTED] said:
>
>>In fact, there's no ATS function to find font file for a given font name,
>>except of ATSFontGetFileSpecification().
>
>Unfortunately I think you are right. :(  But ATSFontGetFileSpecification
>() is not deprecated, so you can use that.  Then convert the FSSpec it
>gives you into something else, like an FSRef.  I filed a bug with Apple
>to make an FSRef version of that function.

Thank you for advice. OK, I write this issue in TODO and
use ATSFontGetFileSpecification() as temporal workaround.
If you receive any reply from Apple about this issue,
please inform ft-devel people.

>>I'm afraid it will be deprecated in future.
>
>They will only deprecated it if/when they replace it.

I wish this issue is fixed before Intel Mac :-)

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Freetype on Mac uses deprecated functions

2005-09-07 Thread mpsuzuki

Dear Sirs,

Now I'm afraid the replacement of obsolete QuickDraw
FontManager by AppleTypeService with keeping API compatibility
is POSSIBLE but will be complexed. Please allow me spend
a few weeks more. I attached the memo of working direction.

Regards,
mpsuzuki


How to handle QuickDraw FontName without FontManager?
=

outline

To build FreeType2 without compiler's warning on Tiger,
we have to replace almost FM functions by ATS functions.
To handle QuickDraw FM's font name without FM functions,
devious technique may be required.

1. How to specify a font in QuickDraw FontManager system

In FM, a font is specified by "family" typed as FMFamily
(e.g. Courier) and its "instance" typed as FMFont
(e.g. "Courier", "Courier Bold", "Courier Italic": usually
 suffixes like "Bold" "Italic" etc are called as "style").
The FMFont instance itself has no storage for its own name,
the name of instance is specified by joined string of
family-name and style-suffix. This is QuickDraw FontName.
The font name passed to FT_GetFile_From_Mac_Name() is
QuickDraw FontName.

So, to keep API compatibility, we have to handle
QuickDraw FontName.

# [NOTE]
# The suffixes for style are not reserved word.
# Fonts designed for Windows are not in suitcase format,
# and the family is named directly, as "Courier New Bold".

2. How to specify a font in Apple Type Service system
-
In ATS, a font is specified by "font" typed as ATSFontRef.
Also there is "family" typed as ATSFontFamilyRef, but
there's no hierarchical relationship between "font" and
"family". ATS has no support to find a font as a member of
given "family".

# [NOTE]
# There are conversion functions for migration purpose.
# FMFontFamily <-> ATSFontFamilyRef, FMFont <-> ATSFontRef.

3. How to handle QuickDraw FontName in ATS system?


3-1. Problem: discontinuity between ATS font and family
---

ATS "family" can be searched by QuickDraw FamilyName,
but ATS "font" cannot be searched by QuickDraw FontName.
On the other hand, ATS "font" can be used to find a font
file, but ATS "family" cannot be.

Making the situation worse, the naming conventions of
ATS "font" and ATS "family" are incompatible.
Although I've not find exact regularity, it seems that
ATS "font" pefers to ASCII/Roman names but
ATS "family" prefers to nationalized names.
QuickDraw FamilyName is usually nationalized.

For example, for a Korean font file
/Library/Fonts/#Gungseouche.dfont,
ATSFontGetName() returns "#GungSeo Regular",
ATSFontFamilyGetName() returns a Korean script.

Therefore, it's difficult to find a ATS "font" from
given ATS "family" by scanning font names.

3-2. Suggestion: utilization of ATSUI system

Apple Type Services for Unicode Imaging (ATSUI) is text
layout system on the top of ATS. Although it's system
at higher layer, it has its own (in the other word,
incompatible with ATS) font management system, and
ATSUI font-id is compatible with QuickDraw FontManager.

In the font name extraction of ATSUI system, we can specify
the encoding of font name. Therefore, ATSUI can be used
as a translator of font-name.

[continues to experimental result which is now prepared...]


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Freetype on Mac uses deprecated functions

2005-09-14 Thread mpsuzuki

Dear Sirs,

Finally I've finished benchmark testing of
"Resolving QuickDraw FontName by ATS, without QuickDraw API".
The result is summarized at:

http://www.gyve.org/~mpsuzuki/ats_benchmark.html

>From the benchmark result, rewriting FT_GetFile_From_Mac_Name() 
with keeping full compatibility with QuickDraw FontName
without QuickDraw FontManager API is very very slow,
it wouldn't payable solution.

In fact, in comparison with original QuickDraw API,
it will be 20 times slower on Panther (Mac OS X 10.3),
and 500 times slower on Cheetar (Mac OS X 10.0).
I think using QuickDraw FontManager API is simple and better.

When we ignore the QuickDraw compatibility, some font names
will be unresolvable after upgrading FreeType. For example,
on Panther, I can find "Courier CE" by QuickDraw, but cannot
find that by ATS.
Correctly speeking, this is not FreeType's problem. There is
fundamental incompatibility of font menu based on QuickDraw
FontManager and that based on ATS. Also this difference is
summarized in the page in above.

Let me ask a question, which is better solution?

Fix A:
FT_GetFile_From_Mac_Name() is kept for QuickDraw.
Add FT_GetFile_From_ATS_Name() for ATS.
To avoid "XXX is deprecated" warning,
FT_GetFile_From_Mac_Name() should be excluded in building.

Fix B:
Change the behaviour of FT_GetFile_From_Mac_Name()
as system-dependent. If configured for ATS only,
it will be incompatible with QuickDraw configuration.

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Freetype on Mac uses deprecated functions

2005-09-16 Thread mpsuzuki

Dear Sirs,

On Thu, 15 Sep 2005 12:11:15 +0900
[EMAIL PROTECTED] wrote:
>Fix A:
>   FT_GetFile_From_Mac_Name() is kept for QuickDraw.
>   Add FT_GetFile_From_ATS_Name() for ATS.
>   To avoid "XXX is deprecated" warning,
>   FT_GetFile_From_Mac_Name() should be excluded in building.
>
>Fix B:
>   Change the behaviour of FT_GetFile_From_Mac_Name()
>   as system-dependent. If configured for ATS only,
>   it will be incompatible with QuickDraw configuration.

On Thu, 15 Sep 2005 06:34:52 +0200 (CEST)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:
>Since I don't use a Mac, I have no opinion.  Hopefully, others can
>comment.

On Thu, 15 Sep 2005 09:32:39 -0400
"Sean McBride" <[EMAIL PROTECTED]> wrote:
>Well, I don't even use freetype (except via vtk) so I'm not sure my
>opinion is important, but I think A sounds better.

Mr. Sean McBride and Mr. Werner LEMBERG, Thank you for comments.
I attach 2 patch of this issue.

migrate_fsspec2fsref.patch
This patch changes src/base/ftmac.c to use FSRef at maximum,
if TARGET_API_MAC_OS9 is not defined. Originally written by
Mr. George Williams and slightly modified by me.

migrate_qdfm2ats.patch
This patch adds FT_GetFile_From_Mac_ATS_Name() in
src/base/ftmac.c, which is an AppleTypeService-based
replacement of QuickDraw based FT_GetFile_From_Mac_Name(),
written by me. If "HAVE_QUICKDRAW" is set to false on the
future Mac OS X system without QuickDraw,
FT_GetFile_From_Mac_Name() is changed to a function that
returns error always. If "HAVE_ATS" is set to false on old
system without ATS, FT_GetFile_From_Mac_ATS_Name() will be
a function that returns error always.

Also a patch for configure.ac is attached to set HAVE_QUICKDRAW
and HAVE_ATS automatically, if --with-old-mac-fonts=yes.

At present, yet I've not finished macro hooking for MPW,
ProjectBuilder, Xcode and CodeWarriror.

By the way, thinking of ATS patch is written to remove deprecated
function, the 2nd argument of FT_GetFile_From_Mac_ATS_Name() should
be FSRef, than FSSpec? The current API is designed to be same with
FT_GetFile_From_Mac_Name(), for programmers' convenience.
But, FSSpec is deprecated data type, so I should propose different
function using no deprecated data? For example:

FT_GetFile_From_Mac_Name( const char*  fontName,
  FSRef*   pathRef,
  FT_Long* face_index)

# yet I'm not sure if the idea of "face" fits ATS font model.

Mr. Sean McBride (and anybody interested in this issue),
how do you think of?

Regards,
mpsuzuki

migrate_fsspec2fsref.patch
Description: Binary data

migrate_qdfm2ats.patch
Description: Binary data
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Porting Free Type on 8 Bit platform!

2005-09-23 Thread mpsuzuki

On Fri, 23 Sep 2005 19:34:27 +0530
Kiran Mahajan <[EMAIL PROTECTED]> wrote:

>On Fri, 2005-09-23 at 10:31 +0200, Turner, David wrote:
>> In theory, FreeType should work on 16-bit platforms, but
>> this hasn't been officially verified for a very long time.
>> 
>> However, I don't know of any 8-bit platform that is capable
>> of dealing with, say, memory-mapped files or heap blocks
>> that are larger than, say, 64 Kb, and this ability is
>> required to support certain fonts which require very
>> large allocations.
>yes it would be difficult or not possible to port whole freetype engine
>on 8 bit due to memory shortage but what you say about customized form
>of it? means i want to say that freetype having support of such fonts
>like BDF which are small.

I think, saying just "8 bit platform" is insufficient to ask further.
Could you give us example of 8 bit platform system which is similar
to your target? There are UNIX like OS for Z80 (e.g. UZI, UZIX),
CP/M families etc etc. In fact, on 8 bit platform, the programming
model, function calling convention, compilers etc would effect the
size of program.

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Status of TT_CONFIG_OPTION_UNPATENTED_HINTING

2005-09-28 Thread mpsuzuki

On Wed, 28 Sep 2005 20:07:10 +0200 (CEST)
Jan Slupski <[EMAIL PROTECTED]> wrote:

>> Is there any definitive list out there of the fonts known to have these
>> issues? (I see that MingLiU and KaiU are specifically named in the
>> archives).
>
>Once I have created http://freetype.freedesktop.org/wiki/Fonts
>but it seems that the idea of creating such list didn't catched...

I was not aware of the exist of the page. Taking a glance on it,
I'm afraid, people may wonder what is important information in the list,
why the list should be maintained, and how to add new information.
I think what is the point of the list should be stated.

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Status of 2.2

2005-10-03 Thread mpsuzuki

Hi,

On Mon, 03 Oct 2005 14:24:49 -0400
Matthias Clasen <[EMAIL PROTECTED]> wrote:
> - Does FT_OPTIMIZE_MEMORY still break apps ? I know that Pango
>   has been patched, but I hear xfs segfaults with the memory
>   optimizations. Are there patches beyond the (applied) pango 
>   patches to fix breakage due to this ?

Yet I'm unfamiliar with the reason why they want to use
FT_OPTIMIZE_MEMORY, if you know, please let me know.
If it's something like "maximum optimization is required",
is there any benchmark tests comparing FreeType with/without
FT_OPTIMIZE_MEMORY?

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] update CodeWarrior project file (builds/mac/ftlib.prj)

2005-10-24 Thread mpsuzuki

Dear Sirs,

Yesterday I've got CodeWarrior 9.0 for MacOS, and
checked CW project file at builds/mac/ftlib.prj.
There is an issue: the project file tries to compile
autohint.c which was already removed from source tree.

# Yet I've not checked if built library works well
# with ftdemos, sorry

I've attached updated CW project file in CW native
binary format (ftlib.prj), and in XML format (ftlib.prj.xml).
I think, XML project file is better, because we can
update it without CW, when some sources are added
or removed.

I'm unfamiliar old CW can import XML project file,
but, at least, even if I choose CW native binary
project format, I cannot generate project file for
old CW (e.g: CW7, CW8 etc).
Any comments about update of CW project file?

Regards,
mpsuzuki


ftlib.prj.gz
Description: application/gunzip


ftlib.prj.xml.gz
Description: application/gunzip
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] update CodeWarrior project file (builds/mac/ftlib.prj)

2005-10-25 Thread mpsuzuki

On Tue, 25 Oct 2005 10:37:40 +0200 (CEST)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:

>> There is an issue: the project file tries to compile
>> autohint.c which was already removed from source tree. [...]
>>
>> Any comments about update of CW project file?
>
>Again, please update the CVS as you think is correct.  Neither David
>nor me use a Mac.
>
>It might useful also to exactly document what environment you are
>using for a successful compilation.

Thank you, I will update builds/mac/README and builds/mac/ftlib.prj
within this week. Possibly I will replace ftlib.prj by ftlib.prj.xml.

--

Now I'm checking Makefile for vanilla MPW: builds/mac/freetype.mak,
I think it's also broken (pointing to autohint.c), and 8bit characters
in MPW makefile syntax are broken. I will write an AWK script (Python
is prefered?) to convert MPW makefile to pure US-ASCII text file,
and its reversal script, to avoid such problem in future.

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] update CodeWarrior project file (builds/mac/ftlib.prj)

2005-10-25 Thread mpsuzuki

Dear Sir,

On Tue, 25 Oct 2005 10:35:03 -0400
"Sean McBride" <[EMAIL PROTECTED]> wrote:

>On 2005-10-25 12:34, [EMAIL PROTECTED] said:
>
>>Yesterday I've got CodeWarrior 9.0 for MacOS, and
>
>You should definitely download the free 9.6 update, it fixes many many
>bugs:   
>
><http://www.metrowerks.com/mw/download/updates.asp?date_op=on+or
>+after&year=95&month=01&day=1&did=find&vers=CWMACOS9&submit=Select+%3E%3E>

Thank you for notice.

BTW, I'm looking for infos about the compatibility
of CW project file, there's any documentation?

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] "comp" is reserved word in Apple SC compiler?

2005-10-27 Thread mpsuzuki

Dear Sirs,

Now I'm testing my MPW makefiles to build FreeType2 by vanilla MPW
(a free-charged developer environment for classic MacOS). Sorry for
my lated work of MacOS issues.

In testing, I've found that "SC" (Apple's m68k C compiler) seems to
use "comp" as a reserved word. In compilation of ttsbit.c, I receive
following error:

>SC :src:sfnt:sfnt.c -c :objs:sfnt.c.o -includes unix -i :include: -i :src: 
> -sym off -model far
>SC C Compiler 8.9.0d3e1
>Copyright (C) 1985-2000 by Apple Computer, Inc.
>
>  TT_SBit_Component  comp;
>^
>File ":src:sfnt:ttsbit.c"; line 1358 #Error: illegal combination of types
>   #---
>  for ( comp 
>   ^
>File ":src:sfnt:ttsbit.c"; line 1371 #Error: expression expected

When I replace the variable "comp" by "compo", SC does not complains
anymore. I grepped MPW's header files and the output by SC's cpp,
but I couldn't find any part which defines "comp" for their own use.
In addition, "MrC" (Apple's PowerPC C compiler) does not complain
about "comp" at all. So, I think "comp" is undocumented & internal
reserved word for SC.

A haphazard Workaround for such issue (which replace "comp" by "compo")
is acceptable?

Regards,
mpsuzuki


freetype2_mpw.patch
Description: Binary data
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] "comp" is reserved word in Apple SC compiler?

2005-10-27 Thread mpsuzuki

Dear Sirs,

Thanks to all who posted this issue. I'm very happy
to receive helpful infos about unknown keyword "comp".
I will take a look in mpw-devel mailing list, too.

As Werner has already pointed out, I think the solution
(pass "-ansi strict" option to SC) proposed by Christian
Demmer looks most reasonable. Following to his proposal,
I could compile FreeType.

However, a few explicit typecasts are needed in ftmac.c
like this. I think it's acceptable.

--- orig/src/base/ftmac.c
+++ mod/src/base/ftmac.c
@@ -838,8 +838,8 @@
 OSStatus  status = FMCreateFontFamilyIterator( NULL, NULL,
options,
&famIter );
-FMFontthe_font = NULL;
-FMFontFamily  family   = NULL;
+FMFontthe_font = ( FMFont ) NULL;
+FMFontFamily  family   = ( FMFontFamily ) NULL;
 
 
 *face_index = 0;


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] "comp" is reserved word in Apple SC compiler?

2005-10-27 Thread mpsuzuki

On Fri, 28 Oct 2005 13:29:51 +0900 (JST)
Masatake YAMATO <[EMAIL PROTECTED]> wrote:

>> -FMFontthe_font = NULL;
>> -FMFontFamily  family   = NULL;
>> +FMFontthe_font = ( FMFont ) NULL;
>> +FMFontFamily  family   = ( FMFontFamily ) NULL;
>
>   FMFontFamily  family   = ( void* ) NULL;
>
>is not ok with the compiler?

Not enough. Speaking exactly, both of FMFont and FMFontFamily
in MPW are not pointer-type. I receive following errors:
---
SC :src:base:ftmac.c -o :objs:ftmac.c.o \
-ansi strict -includes unix \
-i :include: -i :src: -sym off -model far
SC C Compiler 8.9.0d3e1
Copyright (C) 1985-2000 by Apple Computer, Inc.

FMFontthe_font = ( void * ) NULL;
^
File ":src:base:ftmac.c"; line 841 #Error: cannot implicitly convert
from: (void *)
to  : (unsigned long)
#---
FMFontFamily  family   = ( void * ) NULL;
^
File ":src:base:ftmac.c"; line 842 #Error: cannot implicitly convert
from: (void *)
to  : (short)
---

Now I think the exact solution for MPW might be:

FMFontthe_font = 0;
FMFontFamily  family   = 0;

I found that MacTypes.h defines NULL as following.
---
#ifndef NULL
#if !defined(__cplusplus) && (defined(__SC__) || defined(THINK_C))
/* Symantec C compilers (but not C++) want NULL and nil to be (void*)0  
*/
#define NULL ((void *) 0)
#else
/* in case int is 16-bits, make sure NULL is 32-bits */
#define NULL 0L
#endif
#endif
---

In the case that target CPU is PowerPC, NULL is defined to 0 in 32bit.
Therefore, when ftmac.c is compiled for MacOS on PowerPC, this problem
didn't arise. Unfortunately, Apple does not document about whether 0
is suitable for "undefined" or "unresolved" FMFont/FMFontFamily data.

In summary, I will replace "NULL" in the part by "0L".
How do you think of?

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] "comp" is reserved word in Apple SC compiler?

2005-10-28 Thread mpsuzuki

On Fri, 28 Oct 2005 09:38:54 +0200
"Turner, David" <[EMAIL PROTECTED]> wrote:

>> In summary, I will replace "NULL" in the part by "0L".
>> How do you think of?
>> 
>
>I think you should only use "0", since this is a magic token for C compilers
>that can be interpreted either as an integer or as a pointer, depending on
>context.

Thank you for information!
OK, I'll do so: I'll use "0", not "0L" nor "NULL".

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Question about cidparse.c/cid_parser_new( )

2005-11-03 Thread mpsuzuki

Hi

On Wed, 2 Nov 2005 11:55:08 -0500
"Taek Kwan(TK) Lee" <[EMAIL PROTECTED]> wrote:

>When this function locates 'StartData' , it reads in by '256 + 10 -
>buff_len' from stream. Sometimes, the font data after 'StartData' is
>not very long and stream read function fails in this case.
>I think stream->size should be considered to get the correct reading length.

I think following patch realizes your proposal.
I want to test, could you provide some example
CIDFont that original FreeType cannot parse correctly?

Regards,
mpsuzuki


Index: src/cid/cidparse.c
===
RCS file: /cvsroot/freetype/freetype2/src/cid/cidparse.c,v
retrieving revision 1.44
diff -u -r1.44 cidparse.c
--- src/cid/cidparse.c  13 Feb 2005 21:42:42 -  1.44
+++ src/cid/cidparse.c  4 Nov 2005 02:33:28 -
@@ -101,8 +101,15 @@
 
   p = buffer + buff_len;
 
-  if ( FT_STREAM_READ( p, 256 + 10 - buff_len ) )
-goto Exit;
+  {
+FT_ULong  oldpos   = FT_STREAM_POS();
+FT_ULong  size = stream->size - oldpos;
+FT_Intmax_read_len = 256 + 10 - buff_len;
+
+
+if ( FT_STREAM_READ( p, max_read_len > size ? size : max_read_len ) )
+  goto Exit;
+  }
 
   top_position = FT_STREAM_POS() - buff_len;
   buff_len = 256 + 10;



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Question about cidparse.c/cid_parser_new( )

2005-11-08 Thread mpsuzuki

On Tue, 08 Nov 2005 10:12:19 +0100 (CET)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:

>
>> And I think there should be more change in this code section:
>> 'limit' should be reset by 'buffer + readsize' in where readsize is
>> actual read size.
>
>Please provide a patch.

Excuse me, give me 4 hours.

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Question about cidparse.c/cid_parser_new( )

2005-11-08 Thread mpsuzuki

On Tue, 8 Nov 2005 19:17:02 +0900
[EMAIL PROTECTED] wrote:

>On Tue, 08 Nov 2005 10:12:19 +0100 (CET)
>Werner LEMBERG <[EMAIL PROTECTED]> wrote:
>
>>
>>> And I think there should be more change in this code section:
>>> 'limit' should be reset by 'buffer + readsize' in where readsize is
>>> actual read size.
>>
>>Please provide a patch.
>
>Excuse me, give me 4 hours.

I've written 2 patchs to fix a bug reported by Mr. Taek Kwan Lee.
I want to hear comments which is easier to maintain in future.

Regards,
mpsuzuki



Following is the first one. Shorter.

Index: src/cid/cidparse.c
===
RCS file: /cvsroot/freetype/freetype2/src/cid/cidparse.c,v
retrieving revision 1.44
diff -u -r1.44 cidparse.c
--- src/cid/cidparse.c  13 Feb 2005 21:42:42 -  1.44
+++ src/cid/cidparse.c  8 Nov 2005 14:10:00 -
@@ -101,10 +101,24 @@
 
   p = buffer + buff_len;
 
-  if ( FT_STREAM_READ( p, 256 + 10 - buff_len ) )
-goto Exit;
+  {
+FT_ULong  oldpos   = FT_STREAM_POS();
+FT_ULong  size = stream->size - oldpos;
+FT_Intmax_read_len = 256 + 10 - buff_len;
+
+
+if ( FT_STREAM_READ( p, FT_MIN( max_read_len, size ) ) )
+  goto Exit;
+
+if ( max_read_len > size )
+{
+  limit = p + size - 10;
+  top_position = FT_STREAM_POS() - size - 10;
+}
+else
+  top_position = FT_STREAM_POS() - buff_len;
+  }
 
-  top_position = FT_STREAM_POS() - buff_len;
   buff_len = 256 + 10;
 
   /* look for `StartData' */


The second one is deep rewriting and make the function shoter,
so I attach modified one.

  Again:
/* now, read the rest of the file until we find a `StartData' */
{
  FT_Byte   buffer[256 + 10];
  FT_Intread_len = 256 + 10;
  FT_Byte*  p= buffer;


  for ( offset = (FT_ULong)FT_STREAM_POS(); ; offset += 256 )
  {
FT_Intstream_len;
FT_Byte*  limit;


stream_len = stream->size - FT_STREAM_POS();
if ( stream_len == 0 )
  goto Exit;

read_len = FT_MIN( read_len, stream_len );
if ( FT_STREAM_READ( p, read_len ) )
  goto Exit;

if ( read_len < 256 )
  p[read_len]  = '\0';

limit = p + read_len - 10;

for ( p = buffer; p < limit; p++ )
{
  if ( p[0] == 'S' && ft_strncmp( (char*)p, "StartData", 9 ) == 0 )
  {
/* save offset of binary data after `StartData' */
offset += p - buffer + 10;
goto Found;
  }
}

FT_MEM_MOVE( buffer, p, 10 );
read_len = 256;
p = buffer + 10;
  }
}

  Found:

-



src_cid_cidparse_fix1.c.patch
Description: Binary data


src_cid_cidparse_fix2.c.patch
Description: Binary data
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] "make distclean" and objs/apinames, objs/ftexport.sym

2005-11-08 Thread mpsuzuki

Hi

When I tested cross building of latest FreeType2 on CVS,
I found that "make distclean" deletes all object files
but it does not execute "clean_project" in exports.mk,
so objs/apinames & objs/ftexport.sym are left. I think
"make clean_project" works, but configuration is required
to use the target.

In FreeType2, which target should be used to clean files
to unconfigured status?

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Problem with Type 42 incremental downloading font

2005-11-10 Thread mpsuzuki

On Thu, 10 Nov 2005 10:10:20 -0500
"Taek Kwan(TK) Lee" <[EMAIL PROTECTED]> wrote:

>I accidentally press send button with unfinished docuemnt a while ago.
>This one is the finished one. Please ignore the other one.
>
>In case of Type 42 Incremental downloading, 'glyf' and 'loca' table do
>not present in the font data by Adobe specification. However, by
>setting parameter and providing incremental interface, Freetype should
>be able to print it.

I think this issue is same with glyf->glyx, loca->locx issue:
  http://lists.gnu.org/archive/html/freetype-devel/2002-07/msg00022.html

At present, Type42 font handler of FreeType is designed to
load persistent Type42 font object from file or memory, I
guess. FreeType is intended to support dynamically updated
font object in memory?

And, the incremental downloaded Type42 font object only I
know is in PostScript printing data: especially that generated
for Distiller. I agree, if FreeType can supporting incremental
is good idea, but what application uses it?

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] failed to compile ftvalid.c

2005-11-16 Thread mpsuzuki

Hi

On Thu, 17 Nov 2005 10:36:00 +0800
Chia-I Wu <[EMAIL PROTECTED]> wrote:
>When compiling ftvalid.c, I get this error:
>
>ft2demos/obj/ftvalid.o: In function `run_ot_validator':
>ft2demos/src/ftvalid.c:447: undefined reference to `FT_Free_Debug'
>ft2demos/obj/ftvalid.o: In function `run_gx_validator':
>ft2demos/src/ftvalid.c:498: undefined reference to `FT_Free_Debug'
>ft2demos/obj/ftvalid.o: In function `run_ckern_validator':
>ft2demos/src/ftvalid.c:566: undefined reference to `FT_Free_Debug'
>
>FT_Free_Debug is called indirectly by FT_FREE to free various tables,
>which is no longer public. (and freetype reports leaks when use `free'
>, not FT_FREE, to free these tables)

Thank you, it's task of me (or Yamato-san).
Give me 24 hours to fix it.

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] failed to compile ftvalid.c

2005-11-16 Thread mpsuzuki

Hi,

On Thu, 17 Nov 2005 11:46:09 +0900
[EMAIL PROTECTED] wrote:

>>ft2demos/obj/ftvalid.o: In function `run_ot_validator':
>>ft2demos/src/ftvalid.c:447: undefined reference to `FT_Free_Debug'
>>ft2demos/obj/ftvalid.o: In function `run_gx_validator':
>>ft2demos/src/ftvalid.c:498: undefined reference to `FT_Free_Debug'
>>ft2demos/obj/ftvalid.o: In function `run_ckern_validator':
>>ft2demos/src/ftvalid.c:566: undefined reference to `FT_Free_Debug'

Excuse me, you received this error in compiling ftvalid.c
into ftvalid.o? Or, you received it in linking ftvalid.o
to ftvalid executable?

If it's in compiling, I don't know why it's complained,
because the compiler should know that FT_Free_Debug is
declared as external symbol, by including
freetype2/include/freetype/internal/ftmemory.h.

If it's in linking, it's a bit complexed problem. GNU ld
with --retain-symbols-file removes unlisted symbols from
.symtab, but don't remove them from .dynsym. As a result,
I cannot find FT_Free_Debug in
"nm -a freetype2/objs/.libs/libfreetype.so",
but I can find it in
"nm -D freetype2/objs/.libs/libfreetype.so".

When I link ftvalid.o refering FT_Free_Debug(),
with libfreetype.so that does not have FT_Free_Debug() in its
.symtab, GNU ld detects that FT_Free_Debug() exists in
libfreetype.so, and linking is finished successfully.
When I add "-Wl,--trace-symbol=FT_Free_Debug", I receive
following output. GNU ld detects FT_Free_Debug() in
libfreetype.so.

$ gcc -Wl,--trace-symbol=FT_Free_Debug -Wall -ansi -pedantic \
  -DFT_DEBUG_LEVEL_ERROR -DFT_DEBUG_LEVEL_TRACE -DFT_DEBUG_MEMORY \
  -o ./bin/.libs/ftvalid \
 ./obj/ftvalid.o ./obj/common.o \
 ../freetype2/objs/.libs/libfreetype.so \
 -lz 

./obj/ftvalid.o: reference to FT_Free_Debug
../freetype2/objs/.libs/libfreetype.so: definition of FT_Free_Debug

I guess this is the known behaviour of GNU ld, See:
    http://sourceware.org/ml/binutils/2001-12/msg00143.html

How did you remove FT_Free_Debug() completely?

Regards,
mpsuzuki

P.S.
BTW, now I think about this issue: the tools outside of libfreetype
should not refer FT_Alloc_Debug(), FT_Free_Debug() etc etc anymore.
Therefore, ftvalid.c should include ftdbgmem.c by itself?

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] failed to compile ftvalid.c

On Thu, 17 Nov 2005 16:04:45 +0900 (JST)
Masatake YAMATO <[EMAIL PROTECTED]> wrote:

>>>FT_Free_Debug is called indirectly by FT_FREE to free various tables,
>>>which is no longer public. (and freetype reports leaks when use `free'
>>>, not FT_FREE, to free these tables)
>
>mpsuzuki, I don't have time now. Could you compare gxvalid with otvalid?

>  * @note:
>  *   This function only works with OpenType fonts, returning an error
>  *   otherwise.
>  *
>  *   After use, the application should deallocate the five tables with
>  *   `free'.  A NULL value indicates that the table either doesn't exist
>  *   in the font, or the application hasn't asked for validation.
>  */
>
>In otvalid, documents say `free' should be used.

I see. The usage of FT_ALLOC() and FT_FREE() is very same between
otvalid and gxvalid. Yet I'm not sure the reason why free() should
be used for tools using otvalid, I suppose it is to make FreeType
report the consumed memory for validation, by "memory leak" detection.
If it's correct, ftvalid should use free() instead of FT_FREE(),
to report the consumed memory for validation.

Werner, my supposition about "why tools using otvalid should use
free()" is right?

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] failed to compile ftvalid.c

On Thu, 17 Nov 2005 17:04:43 +0800
Chia-I Wu <[EMAIL PROTECTED]> wrote:

>$ nm -a objs/.libs/libfreetype.so | grep Free_Debug
>6cb8 t FT_Free_Debug
>$ nm -D objs/.libs/libfreetype.so | grep Free_Debug
>(gives nothing)
>$ nm --version
>GNU nm 2.16.91 20050902 Debian GNU/Linux

Thanks, I think, the result is really what we want
to do by apinames. At present, I don't have enough
machines to install latest Debian...

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] failed to compile ftvalid.c

On Thu, 17 Nov 2005 20:48:05 +0100 (CET)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:

>> I suggest exporting another function, which simply calls FT_FREE, to
>> free the tables.
>
>Yes, David suggests the same.
>
>Toshiya or Masatake, do you have time to implement proper functions,
>say, FT_TrueTypeGX_Validate_Free, which do the obvious?  Maybe you
>find better function names.

OK, I will do that. Give me 6 hours.

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] failed to compile ftvalid.c

Dear Sirs,

On Fri, 18 Nov 2005 10:05:32 +0900
[EMAIL PROTECTED] wrote:
>OK, I will do that. Give me 6 hours.

I attached 4 patches, please check.

freetype2_fix-FT_FREE_GX.patch:
add FT_TrueTypeGX_Free() and FT_ClassicKern_Free()
freetype2_fix-FT_FREE_OT.patch
add FT_OpenType_Free()
ft2demos_fix-FT_FREE_GX.patch
fix ftvalid.c to use FT_TrueTypeGX_Free(), FT_ClassicKern_Free()
ft2demos_fix-FT_FREE_OT.patch
fix ftvalid.c to use FT_OpenType_Free()

I wrote FT_TrueTypeGX_Free() to receive FT_Face (to
identify the memory object) and FT_Bytes to free,
but it is possible to receive FT_Memory instead of
FT_Face. Any recommendation?

Regards,
mpsuzuki


freetype2_fix-FT_FREE_GX.patch
Description: Binary data


freetype2_fix-FT_FREE_OT.patch
Description: Binary data


ft2demos_fix-FT_FREE_GX.patch
Description: Binary data


ft2demos_fix-FT_FREE_OT.patch
Description: Binary data
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Problem with Type 42 incremental downloading font

Thanks to all.

I asked:
>>> And, the incremental downloaded Type42 font object only I know is in
>>> PostScript printing data: especially that generated for Distiller.
>>> I agree, if FreeType can supporting incremental is good idea, but
>>> what application uses it?

Werner wrote:
>>The incremental code has been contributed by Graham Asher, mainly for
>>use with GhostScript, IIRC (or was it Symbian?).  We don't actively
>>maintain it.

On Mon, 14 Nov 2005 15:08:20 -
"Graham Asher" <[EMAIL PROTECTED]> wrote:
>GhostScript can use it. I am not sure whether the current version of
>GhostScript does actually use it,. but that was what I wrote it for.

On Mon, 14 Nov 2005 10:41:14 -0800
Dirck Blaskey <[EMAIL PROTECTED]> wrote:
>This code is also used by the Liberty Systems Postscript Interpreter 
>(CentraDoc). It is quite handy in dealing with Postscript Type 42
>fonts defined on-the-fly. I had no idea it wasn't actively maintained.

Now I think that incrementally-loaded Type42 font driver
is almost impossible to utilize without PostScript interpreter.
>From the viewpoint of PostScript interpreter maintainer,
the current implementation incrementally-loaded Type42
font driver should be improved? There's any expected feature
in "future issue" status?

Regards,
mpsuzuki


P.S.
I suppose "generating subsetted Type42 font object" is expected
by various applications, but it is another issue, and I think
it's not task of FreeType library.


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] failed to compile ftvalid.c

2005-11-18 Thread mpsuzuki

On Fri, 18 Nov 2005 08:19:40 +0100 (CET)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:
>> I attached 4 patches, please check.
>
>And please install!

Just I've committed 4 patches. Thanks to all for helpful comments!

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Migrating layout table validation code to a new CVS module

2005-11-19 Thread mpsuzuki

heir implementation will simply return
>> > FT_Err_Unimplemented instead.
>> 
>> Ideally, FreeType should have support for external plugins.  This is,
>> if FreeType finds libftvalid, it uses it, otherwise you get
>> FT_Err_Unimplemented.  It seems that we have to start with libtool's
>> `dlopen' function...
>>
>> Sigh.  All these things mean a lot of additional work.  Isn't it
>> easier to simply disable those two modules?  I'm already thinking how
>> to have a central configuration file which controls the used modules
>> -- without removing or renaming the rules.mk files...
>> 
>We probably need something like that, but I want, at a minimum, that
>these modules be out of a default build.

About plugin, it is good idea (although I'm afraid
that FreeType is very very widely used on platforms
without dlopen etc), but it will be long way work.
It should be FreeType3, even if the binary compatibility
is kept.

I have no objection against the pointing out: gxvalid
is too big as a module built/included by default.
I think, otlayout is still very compact in contrast
with gxvalid, and no problem to include it in freetype.
If I rewrite gxvalid to smaller and limited validation
(e.g. memory alignment, number of members etc) by
default, it's acceptable to include?

Regards, sorry for long mail with poor English.
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Migrating layout table validation code to a new CVSmodule

2005-11-21 Thread mpsuzuki

On Mon, 21 Nov 2005 10:39:32 +0100
"Turner, David" <[EMAIL PROTECTED]> wrote:
>> About plugin, it is good idea (although I'm afraid
>> that FreeType is very very widely used on platforms
>> without dlopen etc), but it will be long way work.
>> It should be FreeType3, even if the binary compatibility
>> is kept.
>> 
>There is no need for dlopen() or equivalent. We have FT_Add_Module
>which can be called just after FT_Init_FreeType to add modules to
>the font engine.
>
>That's what I use on my company's embedded software, to register
>custom font drivers for some proprietary bitmap formats we need
>to support. All is done statically.

Excuse me, I'm unfamiliar with FT_Add_Module().
I think, FT_Add_Modules() is capable to use functions
that are available in linking time. I'm not sure if
it can add modules derived from dlopen()-ed objects,
but, at least, on no-dlopen() systems, we have to link
both of libfreetype.a and libftvalid.a, to retain the
possibility to use otvalid/gxvalid module. Therefore,
I think, the situation is same with the case that otvalid
/gxvalid are included but disabled-by-default in
libfreetype.a itself. I'm afraid the difference is
just in the viewpoint of FreeType maintainer: the separate
update of libftvalid.a is enabled. My understanding
is right?

>>If I rewrite gxvalid to smaller and limited validation
>>(e.g. memory alignment, number of members etc) by
>>default, it's acceptable to include?
>
>I think that wouldn't solve the issue:
>
>- it's not really part of the font engine's work, since
>  we don't provide APIs to process the tables.

Indeed, but still I want the validation functions are
included to check the available feature before real
font file loading procedure. Werner, how do you think
of this issue?

>- it ties the releases of the validation and FT2 code,
>  when these could be independent.

I think, the feature of otvalid is almost fixed and won't
cause "urgent update to fix severe bug in otvalid". And,
my propose is the simplification gxvalid for such level.

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Open Type font that contains Adobe CFF (PostScript outlines) data

2005-11-27 Thread mpsuzuki

excuse me, i attached too big files for ft-devel.
i reduced screenshot and compressed cff table and
send this message again to the list.

--

Hi Vitaly,

On Sun, 27 Nov 2005 22:08:34 +0100 (CET)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:
>> This font extracted from PDF 1.6 file.  Font was embedded in PDF
>> document as subset in the FontFile3 stream and based on Type1 font.
>> PDFReference 1.6 describe OpenType embedding in the FontFile3 stream
>> in the 3 way
>
>Well, the font *is* broken.  It can't work standalone.  Both the GSUB
>and GPOS tables refer to non-existent glyphs (and BASE probably too I
>suspect).  I really wonder which information of this font is valid at
>all.  It is probably used as a glyph container only, and all other
>information is already in the PDF.

I agree with Werner, I suppose this font is not standalone.
Sorry, yet I'm unfamiliar with OpenType embedding into PDF,
although I'm familiar with Type1/Type9/Type11/Type42 embedding.
If you seek to CFF table directly, FreeType can load it as usual,
and renders included glyphs. I attached extracted CFF table and
screenshot by ftview. Almost glyphs are just spaces. Could you
send me the original PDF documents?

And, current FreeType does not provide OpenType layout functions,
loading and handling of OpenType extension tables is the task of
other libraries.

Regards,
mpsuzuki

WarnockPro.cff.bz2
Description: Binary data
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] Adding "-ansi strict" to MPW SC causes unresolved symbol error

2005-11-29 Thread mpsuzuki

Hi,

Now I'm porting FreeType library to m68k MacOS
(there had ever port for ppc MacOS, but not for m68k),
and found strange behaviour of MPW SC.

Following is a sample source.
--
#if defined(__GNUC__) && defined(__APPLE_CC__)
# include 
# include 
#else
# include 
# include 
#endif

int main()
{
  CInfoPBRec  cipb;

  PBGetCatInfoSync( &cipb );
  return 0;
}
--

This is building test only, to call FileManager function.
If I compile it normally, the compiling/linking finishes
normally. But when I add "-strict ansi", I receive following
errors in linking. The name of function PBGetCatInfoSync() is
capitalized and could not resolve it. SC version is 8.9.0d3e1.
In addition, when I tried by MrC, such problem does not occur.

[excuse me, long lines are folded]

--
# 2:49:34 PM - Build of callPBGetCatInfoSync.exe.
# 2:49:34 PM - Analyzing dependencies.
# 2:49:34 PM - Executing build commands.
  SC callPBGetCatInfoSync.c -o :callPBGetCatInfoSync.c.o \
-sym off -model far -ansi strict

  ILink -o callPBGetCatInfoSync.exe \
":callPBGetCatInfoSync.c.o" \
"works:MPW:MPW::Interfaces&Libraries:Libraries:Libraries:Stubs.o" \
"works:MPW:MPW::Interfaces&Libraries:Libraries:Libraries:MathLib.far.o" \
"works:MPW:MPW::Interfaces&Libraries:Libraries:CLibraries:StdCLib.far.o" \
"works:MPW:MPW::Interfaces&Libraries:Libraries:Libraries:MacRuntime.o" \
"works:MPW:MPW::Interfaces&Libraries:Libraries:Libraries:IntEnv.far.o" \
"works:MPW:MPW::Interfaces&Libraries:Libraries:Libraries:ToolLibs.far.o" \
"works:MPW:MPW::Interfaces&Libraries:Libraries:Libraries:Interface.o" \
-sym off -mf -d -t 'MPST' -c 'MPS ' -model far -state rewrite \
-compact -pad 0
# Undefined entry, name: "PBGETCATINFOSYNC"
# Referenced from "main" in file "callPBGetCatInfoSync.c.o"
#
--

Due to SC uses some undocumented(?) reserved keywords,
now I add "-ansi strict" option to compile FreeType sources.
I could not find explicit notes about such issue in "Help SC",
but there's no problem in building by MrC, I suppose it is
SC's bug. If I'm misunderstanding, please let me know.
And, mixing objects compiled with "-ansi strict" and without
it causes problem?


Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] aface->num_faces of FT_New_Face() in ftmac.c

2005-11-30 Thread mpsuzuki

Hi,

Sorry for long lated working for FreeType classic MacOS port.
I've almost finished to modularize framework-dependent parts of
ftmac.c (as initial revision), and now I proceed to regression
test.

# BTW, the commandline interface of MPW (classic MacOS developer
# environment) is very difficult to use for UNIX junkies, like me.
# I wrote a MPW program which scans specified folder and tries
# to open all files as font.

The current status is available from GNU arch archives at

URL
http://www.gyve.org/~mpsuzuki/arch-2005.09.03

Archive Name
[EMAIL PROTECTED]

Project Name
freetype2--mps-macos--0.2
ft2demos--mps-macos--0.2


In the regression test, I've found that FT_New_Face() in ftmac.c
does not return correct aface->num_faces.

>From the document in freetype.h, original FT_New_Face() is designed
to return available number of faces: if 2 TTF faces are embedded
in single TTC file, aface->num_faces must be 2. But, aface->num_faces
is not touch in ftmac.c (you can know easily by grep ftmac.).
Therefore, FT_New_Face() in ftmac.c cannot count the faces of special
font format supported by ftmac.c: old PS font for MacOS (LWFN:
LaserWriter FoNt), and Suitcase.

About LWFN, it is noted that FT_New_Face() cannot count the faces
in it, in ftmac.c. However, I never seen LWFN font including
multiple resources, and I suppose it's not widely used.

On the other hand, Suitcase font format is designed to include
multiple sfnt scalable font resources into single font file.
It is still used in classic MacOS (you can find Courier of MacOS
9.2 includes 2 sfnt resources). I think it is expected to count
the faces in Suitcase correctly.

...So, now I'm going to fix this, and I want to ask about binary
compatibility. At present, via FT_New_Face() in ftmac.c, we can
access the 2nd sfnt resource as the 2nd face of the font, although
we don't know how many sfnt resources are included in the font.
Other resources, like fbit bitmap, NFNT bitmap, are ignored and
not counted at all.

At present, fbit and NFNT bitmap resources are not supported by
FreeType, but I want to support it in future (I've ever written
a ruby script to parse it). In my understanding, the usage of NFNT
bitmap is similar to the bitmap font in sfnt. So, it is expected
to ignore the number of NFNT in available-face-counting. Possibly
FreeType user don't want to receive the number of embedded bitmap
font (numSizes of EBLC table) via aface->num_faces. I wish so.
By excluding NFNT resource from available-face-counting, we can
use Suitcase font aslike TTC. In fact, think about the situation:
the first face is outline only, the second face is bitmap only,
the third face is outline only... everyone will be confused. 

But, if we exclude NFNT bitmap resources from available-face-counting,
we cannot access them anymore, because they are separated from
sfnt resource. To solve this problem, some ugly hook in sfnt
resource handler will be required. From the viewpoint of FreeType
developer, I don't want to do so - counting NFNT resource as
separated resource is better to code modularization.

Yet I don't have ready-to-commit NFNT driver, so this issue can
be suspended. "This font has 4 faces, but 2 faces are in
unsupported formats" is not good reply, my first fix must be
counting without NFNT. Any comments are welcome.

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] aface->num_faces of FT_New_Face() in ftmac.c

2005-11-30 Thread mpsuzuki

On Wed, 30 Nov 2005 22:05:58 +0100 (CET)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:

>> In the regression test, I've found that FT_New_Face() in ftmac.c
>> does not return correct aface->num_faces.  [...]
>>
>> ...So, now I'm going to fix this, and I want to ask about binary
>> compatibility.
>
>Where's the problem with binary compatibility?  You are going to
>extend the functionality, not to change, aren't you?

Ah, excuse me, "binary compatibility" is wrong word. I wanted to
ask the compatibility from current "sfnt/LWFN driver" to future
"fbit/NFNT/sfnt/LWFN driver". Your reply about NFNT is enoughly
suggestive.

>> At present, fbit and NFNT bitmap resources are not supported by
>> FreeType, but I want to support it in future (I've ever written a
>> ruby script to parse it).  In my understanding, the usage of NFNT
>> bitmap is similar to the bitmap font in sfnt.
>
>Hmm, is it really just a `strike'?  Or is it more like a full-featured
>face, similar to the faces in WINFNT files?  Because of encoding
>issues I have changed the bitmap handling for this driver from strikes
>to faces.

Yes, thank you for pointing out! NFNT resources are separated
for each sizes, just aslike strike of sbit. Could I know more
about WINFNT encoding issue in ft-devel archive? I found a note
of moving from strikes to faces in docs/CHANGES freetype-2.1.4
to 2.1.5. My initial fix of ftmac.c will ignore the number of
NFNT resource.

Regards,
mpsuzuki

___
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 and i386

Hi

On Tue, 06 Dec 2005 19:02:52 +0200
Ilya Konstantinov <[EMAIL PROTECTED]> wrote:
>Currently, freetype i386 and x86-64 collide in the following files:
>/usr/bin/freetype-config
>/usr/include/freetype2/freetype/config/ftconfig.h

I see.

>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.

I see. Let me clarify the condition: the issue you reported is
specific to GNU/Linux on x86-64, ppc64 and s390x. Grepping
configuration files of X11R6.8.2, I found that only GNU/Linux
on these processors use special separation of libraries by
lib & lib64 (no separation for binary executables, header files).
Such co-existence of multiple binary formats might be useful
on mips64, sparc64 and sh64 either, but I could not find such
library separation for these processors. Oops, yet I've not
checked the situation of MacOS using ppc32 and ppc64.

Do you know Linux's policy to use, or not-to-use lib/lib64
library separation? It's important to determine the suitable
directory to install. For the first step, configure script
can be used to find the system uses lib/lib64 library separation,
but it's insufficient to support cross-building completely.

>It would be very much desired that:
>1. freetype-config would be recoded to detect its environment and return
>the appropriate directories, thus creating a single copy of
>freetype-config on equal-prefix builds *or* freetype moved to pkgconfig
>(freetype-config may remain a frontend)

Umm, moving to pkgconfig sounds easy solution.
But I'm afraid about the systems using freetype-config
without pkgconfig. How pkgconfig separates lib/lib64?

>2. ftconfig.h would be moved to the lib(64)/config directory, just as it
>is for glib2 etc.

Sounds reasonable, although I want to revise configure.ac and
builds/unix/ftconfig.in to support both platforms (ah, I must
learn more about Jam for multi binary formats). BTW, when the
header files are different between i386 & x86-64 (I call it as
arch-dependent), GNU/Linux for x86-64 always separates arch-
dependent files out of /usr/include? Such softwares are exceptional?

Regards,
mpsuzuki

___
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

Hi,

On Wed, 7 Dec 2005 11:30:03 +0100
"Antoine Leca" <[EMAIL PROTECTED]> wrote:
>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).

Yeah, as you pointed out, the standard cross-compiling by
GNU tools use completely separated directories: aslike
"/usr/i386-pc-linux-gnu" and "/usr/amd64-pc-linux-gnu",
to avoid mixing files for target platform with files for
host platform.

GNU/Linux for x86-64 stores i386 libraries into /lib and
x86-64 native libraries into /lib64. Without doubt, it's
for runtime binary compatibilities with existing GNU/Linux
for i386, but I don't know if it's for developer environment
compatibility. I'm afraid that there are many softwares
that we cannot share header files between i386 and x86-64
architechtures.

>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.

I agree. It's a bit confusing to call such compiling as
"cross-compiling"

>> 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.

I'm afraid there's no official process in this issue -
there might be just "how popular GNU/Linux distributors
(wanna) do".

Regards,
mpsuzuki

___
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 and i386

Hi,

On Wed, 7 Dec 2005 14:15:52 +0100 (CET)
>On Wed, 7 Dec 2005, [EMAIL PROTECTED] wrote:
>> I see. Let me clarify the condition: the issue you reported is
>> specific to GNU/Linux on x86-64, ppc64 and s390x.
>
>Solaris 64-bit also has ABI-separated library directories:

Great Thank you for helpful info.
Let me ask more about the separations on Solaris:

* Optional softwares use same separation rules?
  For example, there are something like /usr/X11R6/lib/64 ?

* How about header files?
  The header files are separated completely?
  Or, the shareable headers are installed in /usr/include and
  other arch-dependent headers are separated in other directories?
  Or, system has only headers for most-suitable architechture? 

Regards,
mpsuzuki

P.S.: Hey, any guys on IRIX, AIX and HP-UX?

___
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 and i386

On Wed, 7 Dec 2005 18:42:52 +0900
[EMAIL PROTECTED] wrote:
>I see. Let me clarify the condition: the issue you reported is
>specific to GNU/Linux on x86-64, ppc64 and s390x.

>Do you know Linux's policy to use, or not-to-use lib/lib64
>library separation?

FHS v2.3 has "Linux-specific" annex about lib/lib64:

http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64

For x86-64, ppc64, s390x and sparc64, using lib64
is recommended. Unfortunately, I've checked FHS and
LSB, I could not find documents about the location
of arch-dependent header files.

Regards,
mpsuzuki

___
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 and i386

2005-12-11 Thread mpsuzuki

Hi all,

Sorry for lated post.

About Solaris' management for arch-dep & arch-indep header files...

On Thu, 08 Dec 2005 15:37:23 +0100 (CET)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:
>> > * How about header files?
>>
>> 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 , 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...

I propose 2 step solution.
I'm not sure if there's freetype-2.1.11, but I don't want to
change the numbers of important header files until freetype-2.2,
not to bother binary packagers.

Step 1: Modify ftconfig.h to support both of 32 & 64bit archs
by single file, for amd64, ppc64, sparc64 and s390x.
At least, I will write autoconf patch to do that.
Unfortunately, at present, I have no idea to fix this
issue on other building systems: Jam, Win32 systems,
Mac Xcode etc. I expect this issue is specific to a few
Unix style systems.

Step 2: Separate arch-dependent part to another file.
About the location of arch-dependent header, we should
discuss more. I suppose Linux people want to move them
from /XXX/include to /XXX/lib, but I'm not sure if
it's right solution (I feel /usr/lib of Linux is
now being hell-like blackhole).

I suspend MacOS porting work, and post quick fix of step1
within this week. I have a question to write step1 fix.
The configure script generates dual-platformed ftconfig.h,
but built library should be dual-platformed? For example,
on amd64 system, something like:
$ env CFLAGS="-m32" ./configure
$ make
$ file ./objs/.libs/libfreetype.so.6.3.6
ELF 32-bit LSB shared object, Intel 80386, version 1

./build/unix/ftconfig.h supports both of amd64 and i386
(no other platform) but the built library is only for i386.
Is it too ugly?

Regards,
mpsuzuki

___
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

2005-12-18 Thread mpsuzuki

Hi all,

Here is the first revision of my patch to support
32/64bit ABI by generating unified ftconfig.h.
Ilya, could you test it? After patching this,
./configure --enable-multi-abi="64_32"
will generate unified ftconfig.h which is same
in the both cases of "-m32" and "-m64".

--

My patch for configure.ac is very very lengthy,
so here is the outline about what it does.

1) check new option "--enable-multi-abi".

2) if multi-abi is specified...
   check the pair of multi-abi-type and host-type
   objdump (or file) is searched to check whether ABI in object file
   is default and optional.

   2-1) determine the default ABI.
   2-2) check CFLAGS to generate objects with optional ABI
At present, only "-m32" or "-m64" are tested.

3) if we could know how to generate objects with optional ABI...
   unset autoconf cache and re-check ABI-dependent features
   (at present, only sizeof(int) & sizeof(long) are checked)
   in optional ABI.

4) if ABI-dependent features are different...
   search CPP macro to determine current ABI from keywords like
   C features (LP64, etc) or arch-name (AMD64, PPC64 etc).

5) if useful CPP is found...
   generate dual-ABI header file with the name "arch_dep.tmp"

6) if there is "arch_dep.tmp"...
   replace ABI-dependent feature part in ftconfig.h by "arch_dep.tmp"

At present, only Linux is supported by --enable-multi-abi:
Linux + GNU C compiler on x86_64. I think ppc64,
s390x and sparc64 could be supported by same hook,
but I've not tested yet. Solaris + GNU C compiler
on x86_64, sparc64 should be very similar framework.
I'm not sure about Intel C compiler and Sun C compiler.

My next goal might be AIX on POWER architechture:
AIX stores both of 32bit and 64bit libraries into
same directories (/lib, /usr/lib), but with _64
suffixes, aslike crt0.o and crt0_64.o.
It seems that default is 32bit-ABI, and "-maix64"
is usable to generate 64bit-ABI. I can find many
__64BIT__ hooks in /usr/include/*.h.
Also I have to learn about IRIX (ECOFF, o32, n32,
n64) and HP-UX on RISC (32bit-SOM, 32bit-ELF,
64bit-ELF).


diff -NBurb freetype2.orig/builds/unix/configure.ac 
freetype2-multi-abi/builds/unix/configure.ac
--- freetype2.orig/builds/unix/configure.ac 2005-12-19 14:08:50.0 
+0900
+++ freetype2-multi-abi/builds/unix/configure.ac2005-12-19 
14:08:04.0 +0900
@@ -88,6 +89,182 @@
 AC_CHECK_SIZEOF([long])
 
 
+# when --enable-multi-abi is specified
+# some 64bit platforms sharring header files for 32bit & 64bit ABI.
+AC_ARG_ENABLE([multi-abi],
+  [  --enable-multi-abimake ftconfig.h shareable between 
multiple ABI],
+  [], [])
+if test x"${enable_multi_abi}" = xyes; then
+  enable_multi_abi="64_32"
+fi
+rm -f arch_dep.tmp
+cflags_64=""
+cflags_32=""
+case "${enable_multi_abi}":"${host}" in
+  64_32:amd64-*linux* | 64_32:x86_64-*linux* | \
+  64_32:ppc64-*linux* | 64_32:s390x-*linux*  | 64_32:sparc64-*linux* )
+AC_PATH_PROG(OBJDUMP, ${host}"-objdump", ${PATH})
+if test x"${OBJDUMP}" = x ; then
+  AC_PATH_PROG(OBJDUMP, objdump, ${PATH})
+fi
+if test x"${OBJDUMP}" != x ; then
+  OBJDUMP="${OBJDUMP} -p"
+else
+  AC_PATH_PROG(OBJDUMP, file, ${PATH})
+fi
+
+echo "int main()" >  conftest.c
+echo "{"  >> conftest.c
+echo "  exit(0);" >> conftest.c
+echo "}"  >> conftest.c
+
+AC_MSG_CHECKING([default object format])
+${CC} ${XX_CFLAGS} ${CPPFLAGS} ${CFLAGS} -c conftest.c
+if test 0 != $?; then
+  AC_MSG_ERROR([compiler does not working])
+fi
+default_obj_format=`${OBJDUMP} conftest.${OBJEXT} | expand | tr ' ' '_'`
+if test 0 != $?; then
+  AC_MSG_ERROR([cannot detect object format])
+fi
+case "${default_obj_format}" in
+*64* )
+  AC_MSG_RESULT([64bit])
+  AC_MSG_CHECKING([CFLAGS -m32 is usable to generate 32bit object file])
+  ${CC} ${XX_CFLAGS} ${CPPFLAGS} ${CFLAGS} -m32 -c conftest.c
+  if test 0 != $?; then
+AC_MSG_RESULT([no])
+  else
+obj32_format=`${OBJDUMP} conftest.${OBJEXT} | expand | tr ' ' '_'`
+if test x"${obj32_format}" = x"${default_obj_format}"; then
+  AC_MSG_RESULT([compiled, but object file is same with 64bit])
+else
+  AC_MSG_RESULT([yes])
+  cflags_32="-m32"
+fi
+  fi
+  ;;
+*32* )
+  AC_MSG_RESULT([32bit])
+  AC_MSG_CHECKING([CFLAGS -m64 is usable to generate 64bit object file])
+  ${CC} ${XX_CFLAGS} ${CPPFLAGS} ${CFLAGS} -m64 -c conftest.c
+  if test 0 != $?; then
+AC_MSG_RESULT([no])
+  else
+obj64_format=`${OBJDUMP} conftest.${OBJEXT} | expand | tr ' ' '_'`
+if test x"${obj64_format}" = x"${default_obj_format}"; then
+  AC_MSG_RESULT([compiled, but object file is same with 32bit])
+else
+  AC_MSG_RESULT([yes])
+  cflags_32="-m64"
+fi
+  fi
+  ;;
+esac
+rm -f conftest.c conftest.${OBJEXT}
+if test x"${cflags_64}"

Re: [ft-devel] aface->num_faces of FT_New_Face() in ftmac.c

2005-12-18 Thread mpsuzuki

Hi all,

Attached is patch for ftmac.c, make it to return the number
of unique scalable faces. I've tested with TrueType fonts
bundled to MacOS. The functionalities for resource-fork based
PS font (LWFN font) are not tested at all (although I think
I don't change behaviour for LWFN resource), please give me
informations about where I can obtain from.

Also I attached ftoldmac.c that is (unifinished) small test
program: scanning fonts in a directory and passing them to
FT_New_Face_From_FSSpec(). If anybody interested in regression
test, ask me to hurry for the documentation.

NOTE: this is a part of forthcoming jumbo patch to fix ftmac.c's
  obsolete functions issue on Tiger.

Regards,
mpsuzuki




original patched
 ---
* face->num_faces is always 0* face->num_faces is the number of
   included sfnt or LWFN resource

* face->num_fixed_size is set* face->num_fixed_size is set
  to the number of embeddedto the number of embedded
  bitmap in sfnt resource. bitmap in sfnt resource.
   The number of NFNT resource is
   ignored.
  
* face index counts both of  * face index does not count NFNT
  sfnt and NFNT resource,  resource (until the day NFNT
  although FT_New_Face()   bitmap font is supported).
  with the face index to
  NFNT resource returns the
  previous sfnt resource.
  In following example,
  when you call face 1/2/3,
  you receive face 0.


  +-+- sfnt A  face 0  +--+- sfnt A  face 0
  | |  |  |
  | +- NFNT A1 face 1  |  +- NFNT A1   x
  | +- NFNT A2 face 2  |  +- NFNT A2   x
  | +- NFNT A3 face 3  |  +- NFNT A3   x
  ||
  +-+- sfnt B  face 4  +--+- sfnt B  face 1
  | |  |  |
  | +- NFNT B1 face 5  |  +- NFNT B1   x
  | +- NFNT B2 face 6  
  | +- NFNT B3 face 7
  |
  

--- freetype2.orig/src/base/ftmac.c 2005-12-14 09:10:29.0 +0900
+++ freetype2_ftmacfix/src/base/ftmac.c 2005-12-14 10:42:49.0 +0900
@@ -23,15 +23,11 @@
 support this I use the face_index argument of FT_(Open|New)_Face()
 functions, and pretend the suitcase file is a collection.
 
-Warning: Although the FOND driver sets face->num_faces field to the
-number of available fonts, but the Type 1 driver sets it to 1 anyway.
-So this field is currently not reliable, and I don't see a clean way
-to  resolve that.  The face_index argument translates to
-
-  Get1IndResource( 'FOND', face_index + 1 );
-
-so clients should figure out the resource index of the FOND.
-(I'll try to provide some example code for this at some point.)
+Warning: fbit and NFNT bitmap resources are not supported yet.
+In old sfnt fonts, bitmap glyph data for each sizes are stored in
+each NFNT resources, instead of bdat table in sfnt resource.
+Therefore, face->num_fixed_sizes is set to 0, because bitmap
+data in NFNT resource is unavailable at present.
 
 The Mac FOND support works roughly like this:
 
@@ -267,6 +263,8 @@
   }
 
 
+  /* count_faces_sfnt() counts both of sfnt & NFNT refered by FOND */
+  /* count_faces_scalable() counts sfnt only refered by FOND   */
   static short
   count_faces_sfnt( char *fond_data )
   {
@@ -277,6 +275,28 @@
   }
 
 
+  static short
+  count_faces_scalable( char *fond_data )
+  {
+AsscEntry*  assoc;
+FamRec* fond;
+short   i, face, face_all;
+
+
+fond   = (FamRec*)fond_data;
+face_all   = *( (short *)( fond_data + sizeof ( FamRec ) ) ) + 1;
+assoc  = (AsscEntry*)( fond_data + sizeof ( FamRec ) + 2 );
+face   = 0;
+
+for ( i = 0; i < face_all; i++ )
+{
+  if ( 0 == assoc[i].fontSize )
+face ++;
+}
+return face;
+  }
+
+
   /* Look inside the FOND data, answer whether there should be an SFNT
  resource, and answer the name of a possible LWFN Type 1 file.
 
@@ -411,7 +431,7 @@
 if ( have_lwfn && ( !have_sfnt || PREFER_LWFN ) )
   return 1;
 else
-  return count_faces_sfnt( *fond );
+  return count_faces_scalable( *fond );
   }
 
 
@@ -744,36 +764,33 @@
  FT_Long face_index,
  FT_Face*aface )
   {
-FT_Error  error = FT_Err_Ok;
+FT_Error  error = FT_Err_Cannot_Open_Resource;
 short res_index;
 Handlefond;
-short num_faces;
+short num_faces_in_res, num_faces_in_fond;
 
 
 UseResFile( res_ref );
 
+num_faces_in_res = 0;
 for ( res_index = 1; ; ++res_index )
 {
   fond = Get1IndResource( 'FOND', res_index );
   if ( ResError() )
-  {
-error = FT_Err_Cannot_Open_Resou

[ft-devel] MacOS-specific API regression test tool

2005-12-24 Thread mpsuzuki

Hi all,

On Thu, 22 Dec 2005 22:00:54 +0100 (CET)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:
> > Attached is patch for ftmac.c, make it to return the number
> > of unique scalable faces.
> 
> Please check in, and document the changes in the docs/CHANGES file.

Thanks Werner, I had checked my patch in CVS.

Before posting jumbo patch for ftmac.c to fix
deprecated FileManager & FontManager API issue,
here is a dirty new year gift: small tool for
regression-test of MacOS specific APIs. Somers,
How do you think of?

Attached is a patch of ftoldmac.c and bits to
build the tool "ftoldmac" on MacOS X. Makefiles
for MPW are now being worked. Yet I'm unfamiliar
to write portable Makefile that builds ftoldmac
on MacOS only, I cannot apply the this patch to
CVS tree of ft2demos.

USAGE
-

 ftoldmac  [pathname in HFS syntax]

   e.g. "Macintosh HD:System Folder:Fonts:"
   quotation is required to avoid shell expansion
   scan directory and open all font files in there

Example:

$ ftoldmac "Macintosh HD:System:Library:Fonts:"

scans all files in /System/Library/Fonts, try to open
as font file, and reports results: how many faces the
file includes, the name of face and style, how many
glyphs are included in each faces, the style (Bold/Italic)
for each faces.
Finally, ftoldmac prints how many files are scanned,
and how many files are opened (as font) successfully,
how many faces are scanned how many faces are opened
successfully. So you can know how many faces are lost
in the regression, by comparison the numbers for previous
libfreetype.

 ftoldmac  --font-listing-api=XXX --font-resolve-api=YYY

   --font-listing-api={quickdraw_old|quickdraw|ats}
   specify API to get system font list
   quickdraw_old:  use GetFontName()
   quickdraw:  use FMGetFontFamilyName()
   ats:use ATSFontGetName()

   --font-listing-api={quickdraw|ats}
   specify API to search font file for given font name
   quickdraw:  use FT_GetFile_From_Mac_Name()
   ats:use FT_GetFile_From_Mac_ATS_Name()

Example:

$ ftoldmac --font-listing-api=ats --font-resolve-api=quickdraw

get the fontname list by ATS, and lookup font file for
each fontname by QuickDraw. By comparison the numbers
of scanned faces and opened faces, we can know "unresolvable"
face name. This is implemented to migrate QuickDraw to ATS,
you can know which font name in QuickDraw is unresolvable
in ATS.

# FT_GetFile_From_Mac_ATS_Name() will be added by forthcoming
# jumbo patch.

Regards,
mpsuzuki

ftoldmac.patch.bz2
Description: Binary data
___
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

Hi all,

Here's revised version of dual-ABI patch which
generates unified ftconfig.h for 64/32bit UNIX
platforms.

Based on the information by Henrik, I've added
experimental support for Solaris (amd64, sparc64)
and AIX (ia64, ppc64).

Unfortunately, my testing environment is only
cross-building system on Linux/i386. Any testing
report is welcomed.

Regards,
mpsuzuki


diff -x {arch} -x '.*' -Burb 
freetype2--mps-multilib--0.1--base-0/builds/unix/configure.ac 
freetype2--mps-multilib--0.1--patch-4/builds/unix/configure.ac
--- freetype2--mps-multilib--0.1--base-0/builds/unix/configure.ac   
2005-12-26 18:37:24.0 +0900
+++ freetype2--mps-multilib--0.1--patch-4/builds/unix/configure.ac  
2005-12-26 18:25:25.0 +0900
@@ -88,6 +89,240 @@
 AC_CHECK_SIZEOF([long])
 
 
+# when --enable-multi-abi is specified
+# some 64bit platforms sharring header files for 32bit & 64bit ABI.
+rm -f arch_dep.tmp
+AC_ARG_ENABLE([multi-abi],
+  [  --enable-multi-abimake ftconfig.h shareable between 
multiple ABI],
+  [], [])
+if test x"${enable_multi_abi}" = x; then
+  enable_multi_abi="no"
+elif test x"${enable_multi_abi}" = xyes; then
+  enable_multi_abi="64_32"
+fi
+
+# prepare known CFLAGS for multilib
+case "${enable_multi_abi}":"${host}" in
+  64_32:amd64-*linux* | 64_32:x86_64-*linux* | \
+  64_32:ppc64-*linux* | 64_32:s390x-*linux*  | 64_32:sparc64-*linux* )
+cflags_to_check="-m64 -m32"
+;;
+  64_32:amd64-*sunos*   | 64_32:x86_64-*sunos* | \
+  64_32:amd64-*solaris* | 64_32:x86_64-*solaris* )
+case x"${CC}" in
+*gcc* )
+  cflags_to_check="-m64 -m32"
+  ;;
+* ) # assume Sun Forte Studio
+  cflags_to_check="-xtarget=generic64 -xtarget=generic32 -m64 -m32 
-xarch=generic64 -xarch=generic32"
+  ;;
+esac
+;;
+  64_32:ia64-*aix* )
+case x"${CC}" in
+*gcc* )
+  cflags_to_check="-m64 -m32"
+  ;;
+* ) # assume IBM compiler
+  cflags_to_check="-q64 -q32 -m64 -m32"
+  ;;
+esac
+;;
+  64_32:ppc*-*aix* | 64_32:power*-aix* )
+cflags_to_check="-maix64 -m64 -m32"
+;;
+  no:* | NO:* )
+;;
+  *)
+AC_MSG_ERROR([this platform is unsupported for multilib configuration: 
${enable_multi_abi}])
+;;
+esac
+
+
+# setup command to detect binary format
+cflag_fmt0=""
+cflag_fmt1=""
+if test x"${cflags_to_check}" != x; then
+  if test x"${host}" != x"${build}"; then
+AC_PATH_PROG(OBJDUMP, ${host}"-objdump", ${PATH})
+  fi
+  if test x"${OBJDUMP}" = x ; then
+AC_PATH_PROG(OBJDUMP, objdump, ${PATH})
+  fi
+  if test x"${OBJDUMP}" != x ; then
+OBJDUMP="${OBJDUMP} -p"
+  else
+AC_PATH_PROG(OBJDUMP, file, ${PATH})
+  fi
+
+  if test x"${OBJDUMP}" = x ; then
+AC_MSG_ERROR([no program to detect binary format])
+  fi
+fi
+
+
+# check the binary format of default object file
+if test x"${OBJDUMP}" != x; then
+
+  echo '#include "confdefs.h"' >> conftest.c
+  echo '#if HAVE_STDLIB_H' >> conftest.c
+  echo '# include '  >> conftest.c
+  echo '#endif'>> conftest.c
+  echo 'int main()' >> conftest.c
+  echo '{'  >> conftest.c
+  echo '  exit(0);' >> conftest.c
+  echo '}'  >> conftest.c
+
+  AC_MSG_CHECKING([default object format])
+  ${CC} ${XX_CFLAGS} ${CPPFLAGS} ${CFLAGS} -I. -c conftest.c
+  if test 0 != $?; then
+AC_MSG_ERROR([compiler does not working])
+  fi
+  obj_fmt0=`${OBJDUMP} conftest.${OBJEXT} | expand | tr ' ' '_'`
+  if test 0 != $?; then
+AC_MSG_ERROR([cannot detect object format])
+  fi
+  case "${obj_fmt0}" in
+  *64* )
+AC_MSG_RESULT([64bit])
+;;
+  *32* )
+AC_MSG_RESULT([32bit])
+;;
+  *)
+AC_MSG_RESULT([unknown])
+;;
+  esac
+fi
+
+# lookup explicit CFLAG to generate object file in default format
+orig_CC="${CC}"
+if test x"${obj_fmt0}" != x"${obj_fmt1}"; then
+  for test_cflag in ${cflags_to_check} NONE
+  do
+if test x"${test_cflag}" != xNONE && test x"${cflag_fmt0}" = x ; then
+  AC_MSG_CHECKING([${test_cflag} and its output])
+  CC=`echo "${orig_CC} x" | sed "s/ / ${test_cflag} /" | sed 's,x$,,'`
+  ${CC} ${XX_CFLAGS} ${CPPFLAGS} ${CFLAGS} -I. -c conftest.c 2>/dev/null 
1>/dev/null
+  if test 0 != $?; then
+AC_MSG_RESULT([unusable flag])
+  else
+obj_fmt=`${OBJDUMP} conftest.${OBJEXT} | expand | tr ' ' '_'`
+if test x"${obj_fmt0}" = x"${obj_fmt}"; then
+  AC_MSG_RESULT([default])
+

Re: [ft-devel] rendering differences between OS X and Win32

Hi,

On Mon, 26 Dec 2005 03:29:22 -0700
Kevin Barabash <[EMAIL PROTECTED]> wrote:

>I'm try to write a cross platform application and I'd like there to be
>uniform behaviour when it comes to rendering fonts.  Unfortunately I
>ran into a bug and just to make sure that there wasn't a problem with
>my code I wrote a short test program to highlight the bug.  Here's a
>list of the program and the output for both OS X and Win32.

I'm interested in the bug you reported, but
I don't have enough time to track indepth
mechanism. Give me 2 weeks before join to
discussion...

BTW, the font file arial.ttf is same?
It is taken from MSIE fonts? If you see similar
bug in various fonts, please let me know - we
can test on other platforms too.

Regards,
mpsuzuki

___
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

On Mon, 26 Dec 2005 11:28:30 +0100 (CET)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:
>> AC_ARG_ENABLE([multi-abi],
>> [...]
>
>Please put all this stuff into one or more separate files (similar to
>ft-munmap.m4) to make it more comprehensible.  Additionally I wonder
>whether there isn't already some stuff in, say, libtool.  Otherwise
>you could probably contribute your code -- I'm quite sure that the
>libtool maintainers can give you additional advice.

OK, I'll check libtool and reconsider to reduce the script
size. Although I believe mine is not the first autoconf macro,
I've checked macros bundled with automake, autoconf, and
http://ac-archive.sourceforge.net/ but I could not find.

>> +  /* ARCH_DEP_BEGIN */
>>  #undef SIZEOF_INT
>>  #undef SIZEOF_LONG
>> +  /* ARCH_DEP_END */
>
>Here we need more comments to explain what the comments mean and that
>they must not be changed.

OK!

Regards,
mpsuzuki


___
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

Hi

On Mon, 26 Dec 2005 20:55:34 +0900
[EMAIL PROTECTED] wrote:
>On Mon, 26 Dec 2005 11:28:30 +0100 (CET)
>Werner LEMBERG <[EMAIL PROTECTED]> wrote:
>>Additionally I wonder whether there isn't already
>>some stuff in, say, libtool.  Otherwise you could
>>probably contribute your code -- I'm quite sure
>>that the libtool maintainers can give you additional
>>advice.
>
>OK, I'll check libtool and reconsider to reduce the script
>size.

Just I've searched documents in libtool-1.5.22 & 2.1a,
and libtool mail list archive. In the latest CVS snapshot
(2.1a), still multilib support is written as future issue.
>From the mail list archive, the last mention about multilib
issue is 03/Dec/2004:

http://lists.gnu.org/archive/html/libtool/2004-12/msg00020.html

I'm afraid no implementation had been worked.
Interesting is that they mentioned about RedHat multilib
patch for libtool. It just fixes library search path from
/usr/lib to /usr/lib64 on 64bit platforms, as attached.
Of course, the patch was proposed once, but refused by
libtool maintainers.

I guess, libtool maintainers want to support to build multi
libraries by unified single make target (aslike, current
libtool can generate both of static/dynamic libraries by
the single make target for libXXX.la), so the work must be
very very hard. In fact, if we expect "configure && make"
builds multi ABI libraries, config.h must be ABI independent,
as the issue now we have :-).

Anyway, I will ask future plan and advise to libtool list,
but I think my patch is sufficient for urgent fix until
future libtool update.

Regards,
mpsuzuki


--- libtool-1.5.14/libtool.m4.multilib  2005-02-12 12:18:34.0 +
+++ libtool-1.5.14/libtool.m4   2005-02-15 08:48:42.189498479 +
@@ -1456,10 +1456,27 @@
   # before this can be enabled.
   hardcode_into_libs=yes
 
+  # find out which ABI we are using
+  libsuff=
+  case "$host_cpu" in
+  x86_64*|s390x*|powerpc64*)
+echo '[#]line __oline__ "configure"' > conftest.$ac_ext
+if AC_TRY_EVAL(ac_compile); then
+  case `/usr/bin/file conftest.$ac_objext` in
+  *64-bit*)
+libsuff=64
+sys_lib_search_path_spec="/lib${libsuff} /usr/lib${libsuff} 
/usr/local/lib${libsuff}"
+;;
+  esac
+fi
+rm -rf conftest*
+;;
+  esac
+
   # Append ld.so.conf contents to the search path
   if test -f /etc/ld.so.conf; then
 lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s", \[$]2)); 
skip = 1; } { if (!skip) print \[$]0; skip = 0; }' < /etc/ld.so.conf | $SED -e 
's/#.*//;s/[:,   ]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;/^$/d' | tr '\n' ' '`
-sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"
+sys_lib_dlsearch_path_spec="/lib${libsuff} /usr/lib${libsuff} $lt_ld_extra"
   fi
 
   # We used to test for /lib/ld.so.1 and disable shared libraries on




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Freetype on Mac uses deprecated functions

2005-12-27 Thread mpsuzuki

Hi all,

Finally I post my jumbo patch to fix "deprecated function
XXX is used" issue on MacOS X 10.4, since 25/Aug/2005.

PROBLEM
---
You will see the warning when you build for Intel-based Mac,
aslike:

$ env \
CC="i686-apple-darwin8-gcc-4.0.1 -isysroot /Developer/SDKs/MacOSX10.4u.sdk/" \
./configure \
--with-old-mac-fonts \
--host=i686-apple-darwin8 \
--build=powerpc-apple-darwin8.3.0
...

$ make
...

In file included from /Users/mps/redhat/BUILD/freetype2/src/base/ftbase.c:35:
/Users/mps/redhat/BUILD/freetype2/src/base/ftmac.c: In function
'FT_GetFile_From_Mac_Name':
/Users/mps/redhat/BUILD/freetype2/src/base/ftmac.c:150: warning:
'FMCreateFontFamilyIterator' is deprecated (declared at
/Developer/SDKs/MacOSX10.4u.sdk//System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Fonts.h:573)
...

SOLUTION

After applying my jumbo patch to latest freetype2 (on CVS)
and recreate builds/unix/configure, it provides several
switches to use or ignore MacOS specific APIs.

--with-fsspec use obsolete FSSpec API of MacOS, if available
(default=yes)
--with-fsrefuse Carbon FSRef API of MacOS, if available
(default=yes)
--with-quickdraw-toolbox
use MacOS QuickDraw in ToolBox, if available
(default=yes)
--with-quickdraw-carbon use MacOS QuickDraw in Carbon, if available
(default=yes)
--with-ats use AppleTypeService, if available (default=yes)

By default, these switchs check availability automatically,
but you can set them explicitly.

If FSRef API is available (checked automatically), ftmac.c
uses FSRef API instead of deprecated FSSpec API, at maximum,
so "deprecated" warning about FSSpec won't appear.

On the other hand, even if QuickDraw APIs are deprecated,
the switchs detect them automatically, and use them for
FT_GetFile_From_Mac_Name(). To remove "deprecated" warning,
you have to set "--with-quickdraw-toolbox=no" and
"--with-quickdraw-carbon=no" manually. By disabling QuickDraw,
FT_GetFile_From_Mac_Name() is changed to pseudo function
which returns FT_Err_Unimplemented_Feature always.

Apple recommends to migrate from QuickDraw to ATS, but,
as I've ever reported, compatible function is hard to
implement and will be unbelievably slow. As a quick replacement,
I added FT_GetFile_From_Mac_ATS_Name() that returns FSSpec
(oops, it's obsolete!) for given ATS font name.

About the "abscondence" of font in migration from QuickDraw
to ATS, use my "ftoldmac" tool (see previous post in this
list).

By ftoldmac tool, I checked that the number of loadable
font files and loadable font faces are same with original
FreeType, on MacOS X 10.4.

TODO

* Tests on real System6 & 7.

It seems that new QuickDraw APIs in Carbon (e.g.
FMCreateFontFamilyIterator() etc) are not available
on ToolBox library (say, System 7 environment)
I classify 2 groups of QuickDraw FontManager APIs:
"quickdraw-toolbox" is old API described in ancient
"Inside Macintosh: Fonts". "quickdraw-carbon" is new
API described in Carbon reference.

* On MacOS X, giving "--with-fsref=no" disables FreeType2
to load most data-fork fonts

FreeType2 uses stdio functions to load font files. On
MacOS, there are several incompatible font access APIs:
FSSpec comes from FileManager, not from POSIX, so its
pathname separator is always ":". stdio in MPW's StdCLib
uses such syntax. But, on MacOS X, stdio comes from POSIX,
its pathname separator is "/". FSRef API has support
to work on both syntax, but FSSpec does not have.

Maybe you wish if there's regression test for all combination
of FSSpec|FSRef and QuickDraw|ATS. MacOS X might be best
platform for such automated regression test. Unfortunately
it's impossible, at present.

* Complete cleaning of FSSpec.

Apple recommends to migrate from FSSpec to FSRef, because
FSSpec cannot handle long file name and UTF-16 encoded
file name. But some Carbon functions are left in FSSpec-
dependent because there's no replacements.

* Unification with POSIX resource fork accessor.

Masatake Yamato wrotes resource fork accessor by POSIX
functions, to use resource-fork fonts on real UNIX system
that can access resource fork. To reduce the cost of
maintainance, unification is expected.

Regards,
mpsuzuki

freetype2_ftmac_jumbo.patch.bz2
Description: Binary data
___
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

2005-12-31 Thread mpsuzuki

On Tue, 27 Dec 2005 09:15:46 +0100 (CET)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:

>> Just I've searched documents in libtool-1.5.22 & 2.1a, and libtool
>> mail list archive. In the latest CVS snapshot (2.1a), still multilib
>> support is written as future issue.
>
>OK.

Here I attach revised patch. It includes:
* ft-uniconf.m4
  utility macros to generate unified ftconfig.h
* configure.ac
  hook is added to generate ftconfig.h
* ftconfig.in
  add keyphrase to quote ABI-dependent part

I changed the feature name to uniconf, because
it does not built multi libraries, it just generates
unified ftconfig.h which is capable to use for both of
32 & 64bit ABIs on amd64, ppc64, sparc64 and s390x.

While I search "multilib" in libtool mail list archive,
I remember that "multilib" is also supported in recent
gcc, by config-ml.in. Taking a look on that, I think,
gcc config-ml.in is designed to work as meta-configure
level: it executes configure in separated directories
for each configurations (usually, gcc multilib is used
to support the CPUs whose FPU is optional (e.g. m68k
& ARM), CPUs whoese family is big and instruction sets
are defined (e.g. MIPS & ARM), and, finally, CPUs supports
both of 64- and 32bit ABI. I think gcc config-ml.in is
designed to build libraries for various configuration
at once, but it's not designed to generate unified config.h.

The goal of gcc config-ml.in is more generic than
RedHat's 64bit-32bit issue, but more specified than
that of libtool future plan. The goal of libtool multilib
is, I guess, to build libraries at once, for more
various configurations: archive/shared/debug/profiled
(as X11), untuned/tuned (as GNU libc), and 32/64bit ABI.
However, I don't think libtool is designed to distribute
the header files to suitable directories (e.g. Linux's
/usr/lib/freetype/include and /usr/lib64/freetype/include),
nor designed to unify the header files (as my patch does).
I think, such header file management is not libtool's
business.

Attached patch has ugly hook to flush informations
(sizeof(int) and sizeof(long)) for the default configuration
and reconfigure them for non-default target. I think
it's not easy to maintain. Because, when a developer
modifies configure.ac, he must care if it's reconfigured
in multilib case and he must know how to reset cached
informations (as I reset unset ac_cv_type_int etc).
He have to keep the integrity among ft-uniconf.m4,
configure.ac and ftconfig.in. This is troublesome work.

Now I think, the next step to improve multilib support
would be modification of freetype2/configure, instead
of freetype2/builds/unix/configure. It's like gcc config-ml.in.
By executing configure in separated directories, we can
collect ftconfig.h files for each configuration easily,
and exactly. I've already wrote several useful macros
for multilib support (they are in ft-uniconf.h):
* check how many object formats are available
* check required CFLAG for specified object format
* check CPP macro to specify the object format
The left task is gathering ftconfig.h from each
configured directories and merge them into single
unified ftconfig.h. I will propose a patch for
freetype2/configure to support. But, freetype2/configure
has not been autoconfized, so I'm afraid I should
not use macros in ft-uniconf.m4...?

Werner, could you tell me about the restriction to
modify that?

Regards,
mpsuzuki

--

diff -NBurb -x {arch} -x '.*' 
freetype2--mps-multilib--0.1--base-0/builds/unix/configure.ac 
freetype2--mps-multilib--0.1--patch-11/builds/unix/configure.ac
--- freetype2--mps-multilib--0.1--base-0/builds/unix/configure.ac   
2005-12-31 19:19:10.0 +0900
+++ freetype2--mps-multilib--0.1--patch-11/builds/unix/configure.ac 
2005-12-31 19:19:26.0 +0900
@@ -88,6 +89,23 @@
 AC_CHECK_SIZEOF([long])

+# generate unified header file, if requested
+
+FT_UNICONF_ENABLE([uniconf_type])
+FT_UNICONF_CFLAGS_GETLIST([uniconf_type],[cflags_to_check])
+if test x"${uniconf_type}" != xno; then
+  FT_UNICONF_PROG_OBJDUMP([OBJDUMP],[objdump_filter])
+fi
+if test x"${uniconf_type}" != xno && test x"${OBJDUMP}" != x; then
+  FT_UNICONF_MAKE_OBJFMT_LIST([${cflags_to_check}],[obj_fmt0 
obj_fmt1],[objdump_filter])
+  
FT_UNICONF_GET_CFLAG_FOR_OBJFMT([${cflags_to_check}],[obj_fmt0],[cflag_fmt0],[objdump_filter])
+  
FT_UNICONF_GET_CFLAG_FOR_OBJFMT([${cflags_to_check}],[obj_fmt1],[cflag_fmt1],[objdump_filter])
+fi
+if test x"${cflag_fmt0}" != x"${cflag_fmt1}"; then
+  FT_UNICONF_MAKE_ARCHDEP([arch_dep.tmp],[cflag_fmt0],[cflag_fmt1])
+fi
+
+
 # checks for library functions

 # Here we check whether we can use our mmap file component.
@@ -168,8 +186,10 @@
 AC_CONFIG_HEADERS([ftconfig.h:ftconfig.in],
   [mv ftconfig.h ftconfig.tmp
sed 's|/undef|#undef|' < ftconfig.tmp > ftconfig.h
+

Re: [ft-devel] MacOS-specific API regression test tool

2006-01-04 Thread mpsuzuki

happy new year!

On Wed, 04 Jan 2006 18:15:08 +0100 (CET)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:
>> Before posting jumbo patch for ftmac.c to fix deprecated FileManager
>> & FontManager API issue, here is a dirty new year gift: small tool
>> for regression-test of MacOS specific APIs.
>
>What about adding this to the CVS?  Probably not building it by
>default, but for reference.

Thank you! I will add ftoldmac.c (any better name?)
to ft2demos/mac/, and write ft2demos/mac/Makefile
(for MacOS X) to build ftoldmac in the directory.
I've already finished MPW makefile for m68k MacOS,
and checked it works as expected.

BTW, yet I've not checked if ftview_m.c, ftlint_m.c
are ft2demos/mac/ are still usable. MacOS GUI application
cannot receive argc/argv, so Just van Rossum wrote
a hook to pass essential data via GUI menu. At present,
it seems that only CodeWarrior target is prepared
(no MPW targets are written). But, if these programs
are executed via MPW shell, they can receive argc/argv.
I think such are easier to maintain, because it will
be almost platform independent. The left issue is that
"how to display graphical results" by ftview & ftstring.
I think, if they are enabled to work as fully commandline
tool, they will be easier to maintain.

I remember, a volunteer was wanted to add PNM output
to ftstring, in Werner's post:

Date: Fri, 07 Oct 2005 01:18:55 +0200 (CEST)
Message-Id: <[EMAIL PROTECTED]>
Subject: Re: [ft] Simple CL Tool
From: Werner LEMBERG <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
>
>> > Why not using the `ftstring' demo program, then capturing the image?
>> 
>> Probably becuase it's  easier to just load a PNG file (or a BMP
>> or a TIF or whatever) into an image viewer than it is to monkey
>> around with a capturing images, etc.
>
>Well, it should be rather straightforward to add PNM output to
>ftstring as an option (this can be then converted with, say, pnmtopng
>or pnmtojpeg).  Any volunteers?

If there's nobody yet, I want to do that, although
I cannot give the highest priority to this task.

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Freetype on Mac uses deprecated functions

2006-01-09 Thread mpsuzuki

Hi,

On Sun, 08 Jan 2006 14:36:04 +0100 (CET)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:
>> Finally I post my jumbo patch to fix "deprecated function
>> XXX is used" issue on MacOS X 10.4, since 25/Aug/2005.
>
>In case you patch is ready for inclusion into the CVS, please do so.

OK, I will commit the patch to CVS (although I wish if
I could receive any comments by Sean).

I've grepped Xcode (Apple's official SDK based on gcc)
and applications on Mac OS X, and I could find no Apple
application that requires FT_GetFile_From_Mac_Name() or
FT_New_Face_From_FSSpec(), so I think my jumbo patch
won't cause severe problem.

I wrote detailed document about the deprecated function
issue (as a patch to builds/mac/README). In the document,
I refered my benchmarks of QuickDraw & ATSUI font name
resolver (to notice that it's hard to provide QuickDraw
compatible functions by ATS). If required, I can transfer
the document onto FreeType website.

Regards,
mpsuzuki


--- freetype2--official-maintrunk--0.1--patch-123/builds/mac/README 
2006-01-10 14:18:36.0 +0900
+++ freetype2-macos/builds/mac/README   2006-01-10 14:13:27.0 +0900
@@ -18,6 +18,9 @@
 However, Mac OS X is most useful to manipulate files in
 vanilla FreeType to fit classic MacOS.
 
+The information about MacOS specific API is written in
+appendix of this document.
+
 2. Requirement
 --
 
@@ -205,8 +208,190 @@
   to MPW. To update classic MacOS support easily,
   building by Jam is expected on MPW.
 
+
+APPENDIX I
+--
+
+  A-1. Framework dependencies
+  ---
+
+  src/base/ftmac.c adds two Mac-specific features to
+  FreeType. These features are based on MacOS libraries.
+
+  * accessing resource-fork font
+  The fonts for classic MacOS store their graphical data
+  in resource forks which cannot be accessed via ANSI C
+  functions. FreeType2 provides functions to handle such
+  resource fork fonts, they are based on File Manager
+  framework of MacOS.  Following functions are for this
+  purpose.
+
+FT_New_Face_From_Resource()
+FT_New_Face_From_FSSpec()
+FT_New_Face_From_FSRef()
+
+  * resolving font name to font file
+  The font menu of MacOS application prefers font name
+  written in FOND resource than sfnt resoure. FreeType2
+  provides functions to find font file by name in MacOS
+  application, they are based on QuickDraw Font Manager
+  and Apple Type Service framework of MacOS.
+
+FT_GetFile_From_Mac_Name()
+FT_GetFile_From_Mac_ATS_Name()
+
+  Working functions for each MacOS are summarized as
+  following.
+
+  upto MacOS 6:
+not tested (you have to obtain MPW 2.x)
+
+  MacOS 7.x, 8.x, 9.x (without CarbonLib):
+FT_GetFile_From_Mac_Name()
+FT_New_Face_From_Resource()
+FT_New_Face_From_FSSpec()
+
+  MacOS 9.x (with CarbonLib):
+FT_GetFile_From_Mac_Name()
+FT_New_Face_From_Resource()
+FT_New_Face_From_FSSpec()
+FT_New_Face_From_FSRef()
+
+  Mac OS X upto 10.4.x:
+FT_GetFile_From_Mac_Name() deprecated
+FT_New_Face_From_FSSpec()  deprecated
+FT_GetFile_From_Mac_ATS_Name() deprecated?
+FT_New_Face_From_FSRef()
+
+  A-2. Deprecated Functions
+  -
+
+A-2-1. FileManager
+--
+
+For convenience to write MacOS application, ftmac.c
+provides functions to specify a file by FSSpec and FSRef,
+because the file identification pathname had ever been
+unrecommended method in MacOS programming.
+
+Toward to MacOS X 10.4 & 5, Carbon functions using FSSpec
+datatype is noticed as deprecated, and recommended to
+migrate to FSRef datatype. The big differences of FSRef
+against FSSpec are explained in Apple TechNotes 2078.
+
+http://developer.apple.com/technotes/tn2002/tn2078.html
+
+- filename length: the max length of file
+name of FSRef is 255 chars (it is limit of HFS+),
+that of FSSpec is 31 chars (it is limit of HFS).
+
+- filename encoding: FSSpec is localized by
+legacy encoding for each language system,
+FSRef is Unicode enabled.
+
+A-2-2. FontManager
+--
+
+Following functions receive QuickDraw fontname:
+
+  FT_GetFile_From_Mac_Name()
+
+QuickDraw is deprecated and replaced by Quartz
+since Mac OS X 10.4. They are still kept for
+backward compatibility. By undefinition of
+HAVE_QUICKDRAW in building, you can change these
+functions to return FT_Err_Unimplemented always.
+
+Replacement functions are added for migration.
+
+  FT_GetFile_From_Mac_ATS_Name()
+
+They are usable on Mac OS X only. On older systems,
+these functions return FT_Err_Unimplemented always.
+
+The detailed incompatibilities and possibility
+of FontManager emulation without QuickDraw is
+explained in
+
+  http://www.gyve.org/~mpsuzuki/ats_benchmark.html
+
+  A-3. Framework Availabilities 
+  -

Re: [ft-devel] Freetype on Mac uses deprecated functions

2006-01-11 Thread mpsuzuki

Hi,

Sean, Thank you for comment!
Just I've commited my jumbo patch to CVS.

On Tue, 10 Jan 2006 11:47:53 -0500
"Sean McBride" <[EMAIL PROTECTED]> wrote:

>On 2006-01-10 14:34, [EMAIL PROTECTED] said:
>
 Finally I post my jumbo patch to fix "deprecated function
 XXX is used" issue on MacOS X 10.4, since 25/Aug/2005.
>>>
>>>In case you patch is ready for inclusion into the CVS, please do so.
>>
>>OK, I will commit the patch to CVS (although I wish if
>>I could receive any comments by Sean).
>>
>>I've grepped Xcode (Apple's official SDK based on gcc)
>>and applications on Mac OS X, and I could find no Apple
>>application that requires FT_GetFile_From_Mac_Name() or
>>FT_New_Face_From_FSSpec(), so I think my jumbo patch
>>won't cause severe problem.
>
>I only use freetype indirectly by using vtk.  I have checked the vtk
>source and it uses neither of those two functions.


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] MacOS-specific API regression test tool

2006-01-11 Thread mpsuzuki

Hi,

On Thu, 05 Jan 2006 07:25:48 +0100 (CET)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:

>> >What about adding this to the CVS?  Probably not building it by
>> >default, but for reference.
>> 
>> Thank you! I will add ftoldmac.c (any better name?)  to
>> ft2demos/mac/, and write ft2demos/mac/Makefile (for MacOS X) to
>> build ftoldmac in the directory.  I've already finished MPW makefile
>> for m68k MacOS, and checked it works as expected.
>
>Thank you in advance.

Just I've added ftoldmac.c & makefiles into ft2demos/mac/ in CVS.
To build ftoldmac.c on MacOS X, typing "make -C mac" in ft2demos
top directory is enough.

Update of ft2demos/mac/README is not completed, because the old
works by Just van Rossum (written for CodeWarrior) is not updated
yet, I added only short note about ftoldmac. The step-by-step usage
(e.g. how to use it regression test) is not described yet. If it's
essential, I'll write more.

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] is it possible to retrieve whole kerning table?

2006-01-14 Thread mpsuzuki

Hi,

>I am trying to figure out how to implement WIN32 GetKerningPairs[1] function 
>in Wine. Unfortunately, I can't find a similar function in freetype API. 
>There is FT_Get_Kerning, but in order to build a whole table I would need to 
>know all the kerning pairs in a font, or brute-force check all 
>combinations :)

Yes, current FreeType2 does not provide the functions
like Win32 GetKerningPairs(). I think, such functions
require large memory allocation to load whole of kern
subtable. Due to memory alignment and byte order (Win32
struct KERNINGPAIR looks native byte order - the size
and byte order is exactly same among all platforms?),
passing the pointer to the memory image of kern subtable
is not enough. We have to rewrite all entries explicitly.

My propose is writing a simple function to: pickup file
stream or memory image from font object loaded by FreeType,
allocate memory to store converted kern subtable, and
convert the entries internally (without kern table handler
of FreeType2). By conversion without FreeType, the conversion
time can be minimized. BTW, if kern table has multiple
subtables, how WIN32 API choose the "best" subtable? 
The device context is used?

There are a "cross-platform" issue to discuss. Microsoft
supports kern subtable format 0 only, but there are two
dialects in format 0: Microsoft and Apple. For detail,
please check freetype2/src/gxvalid/README in latest CVS
version of freetype2, or viewCVS:

http://cvs.savannah.nongnu.org/viewcvs/freetype2/src/gxvalid/README?rev=1.2&root=freetype&view=markup

In the rendering procedure, FreeType2 supports horizontal
kerning in Microsoft dialect only. For example, FreeType2
does not count the number of entries in vertical kerning
table, even in Microsoft dialect. Other formats (Apple
dialect, new formats 1, 2, 3) are not used at all. It it
expected behaviour? I think some people want WINE to run
on MacOS X, with TrueType fonts bundled to MacOS X.

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] is it possible to retrieve whole kerning table?

2006-01-14 Thread mpsuzuki

Hi,

On Sat, 14 Jan 2006 15:46:03 +0100 (CET)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:
>>>I am trying to figure out how to implement WIN32 GetKerningPairs[1]
>>>function in Wine.  Unfortunately, I can't find a similar function
>>>in freetype API.
>>
>>Yes, current FreeType2 does not provide the functions like Win32
>>GetKerningPairs().
>>We have to rewrite all entries explicitly.
>
>I have the feeling that such a function doesn't belong to FreeType but
>should be added one level higher.

Talking personally, as you say, such a function
should be out of FreeType. Although I'm not sure
how many, I guess many functions should be written
to emulate font functions in Win32 GDI, and there's
possibility that Win32 specific datatypes & macros
are required (for GetLastError). It's too early to
decide whether a module for Win32 GDI emulation is
reasonable, I think.

# I suppose, GetKerningPairs() assumes that the font
# data is already validated/restructured and loaded
# onto kernel space memory, so GetKerningPairs() just
# lookups the header of subtable and returns it.

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] when does the next version of freetype release?

2006-01-19 Thread mpsuzuki

Hi,

On Wed, 18 Jan 2006 11:18:00 +0100
david turner <[EMAIL PROTECTED]> wrote:
>> And will the major .so version be bumpped up?
>>
>Nope, because this would create problems as Owen Taylor pointed out,
>since through indirect linking, a given program might find itself dependent
>on both libfreetype6 and libfreetype7, which could cause major problems
>depending on the code paths being used.

Could you tell me about the condition that
libfreetype.so "must" bump its major version?

Today FreeType is very widely used as the most
important foundation for text rendering, and
the request for full binary compatibility
(unfortunately, including internal functions,
internal data types, macros, etc etc :-)) is
getting stronger and stronger, I'm afraid.
Some people may want libfreetype3.so.X instead
of libfreetype.so.7.

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] Re: [ft] updating www.freetype.org

2006-01-25 Thread mpsuzuki

Hi,

On Mon, 16 Jan 2006 22:42:23 +0100 (CET)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:
>I've updated all top-level documents of www.freetype.org.  Please
>report any problems and/or inconsistencies you find.

Excuse me, this is not about top-level documents.
I found that CVS repository is still pointing to
the lost server of savannah. Following patch fixes it.

Should I write some warning (or color the line to
show up) for the developpers who have source trees
with obsolete CVS repository?

Regards,
mpsuzuki

--- developer.html.orig Tue Jan 17 06:24:20 2006
+++ developer.html  Thu Jan 26 10:13:55 2006
@@ -189,7 +189,7 @@
   following value for CVSROOT

   :pserver:[EMAIL 
PROTECTED]:/cvsroot/freetype
+  align=center>:pserver:[EMAIL 
PROTECTED]:/cvsroot/freetype

   When asked for a password, simply press Enter for cvs
   login.  The module names are freetype (Freetype

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] Re: [ft] updating www.freetype.org

2006-01-25 Thread mpsuzuki

Hi,

On Thu, 26 Jan 2006 05:56:53 +0100 (CET)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:
>> Should I write some warning (or color the line to
>> show up) for the developpers who have source trees
>> with obsolete CVS repository?
>
>Yes, this might be helpful.

OK, following short patch is enough? I think I should not
write too lengthy notes (like "howto update ~/.cvspass,
how to rewrite files under CVS/").

Regards,
mpsuzuki

--- developer.html.orig Thu Jan 26 14:33:51 2006
+++ developer.html  Thu Jan 26 14:42:03 2006
@@ -185,6 +185,9 @@
 
 
   Use anonymous CVS access
+  GNU Savannah CVS server moved to
+  cvs.savannah.nongnu.org on 12-Dec-2005. You should login again
+  and update the trees that checked out before.
   The FreeType sources can be downloaded to you through CVS.  Use the
   following value for CVSROOT
 


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Freetype crashes on ARM

2006-01-26 Thread mpsuzuki

Hi,

On Thu, 26 Jan 2006 09:54:24 +0100
Frank Meerkoetter <[EMAIL PROTECTED]> wrote:
>i'm using poppler(xpdf derived) and freetype on an ARM based system
>to render pdf documents.
>I encounter crashes when loading documents which contained embedded
>Type1 fonts. The crashes were due to "Illegal Intructions".
>I could track it down to FT_Get_Name_Index().

I will check the issue, could you provide sample PDF to
crash poppler? And, it can crash xpdf too?

# my ARM box is not tuned for Desktop environment, so
# I have to build xpdf and poppler by myself. Please
# give me a few weeks.

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] zos / ebcdic platform

2006-01-29 Thread mpsuzuki

Hi,

On Fri, 27 Jan 2006 11:59:08 +0100
regis bertrand <[EMAIL PROTECTED]> wrote:
>can't be found. True type files now work in both versions but opentype can't
>be open with the last version.

Excuse me, I think FreeType does not provide any OpenType
specific features, so I guess you mean CFF OpenType (which
includes PS font in its "CFF " table instead of sfnt table).
Is it right? And, what kind of errors you had?
If you could build FreeType with debug option as written in
docs/DEBUG, please post detailed debug messages you receive.

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] fix --with-old-mac-fonts option

2006-02-05 Thread mpsuzuki

Hi all,

I'm sorry that --with-old-mac-fonts option in
configure.ac was broken by my previous jumbo
patch (to fix deprecated API issue on MacOS X).
At present, the option does not work well on
UNIX platforms. Following is patch to fix it.

Thinking of that CoreFoundation library is
published under OSI license, Carbon subset
is possible on traditional UNIX platform.
(maybe, we cannot expect opensource Quartz,
 but can expect opensource FSRef functions)
In such case, I should change linking test
for MacOS X specific LDFLAGS "-Xlinker -framework ..."
into more generic test. If anybody knows
such implementation, please let me know.

Regards,
mpsuzuki

--- freetype2.orig/builds/unix/configure.ac
+++ freetype2/builds/unix/configure.ac
@@ -140,10 +140,17 @@
   AS_HELP_STRING([--with-old-mac-fonts],
  [allow Mac resource-based fonts to be used]))
 if test x$with_old_mac_fonts = xyes; then
+  orig_LDFLAGS="${LDFLAGS}"
+  AC_MSG_CHECKING([CoreServices & ApplicationServices of Mac OS X])
   LDFLAGS="$LDFLAGS -Xlinker -framework -Xlinker CoreServices \
 -Xlinker -framework -Xlinker ApplicationServices"
-else
-  CFLAGS="$CFLAGS -DDARWIN_NO_CARBON"
+  AC_TRY_LINK([ ], [ ], [
+AC_MSG_RESULT([ok])
+  ], [
+AC_MSG_RESULT([not found])
+LDFLAGS="${orig_LDFLAGS}"
+CFLAGS="$CFLAGS -DDARWIN_NO_CARBON"
+  ])
 fi
 
 


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] fix --with-old-mac-fonts option

2006-02-08 Thread mpsuzuki

Hi,

Just I've committed my fix to configure.ac,
thank Werner for comment.

On Mon, 6 Feb 2006 11:09:42 -0500
"Sean McBride" <[EMAIL PROTECTED]> wrote:
>On 2006-02-06 10:12, [EMAIL PROTECTED] said:
>
>>Thinking of that CoreFoundation library is
>>published under OSI license, Carbon subset
>>is possible on traditional UNIX platform.
>>(maybe, we cannot expect opensource Quartz,
>> but can expect opensource FSRef functions)
>
>Only a subset of CoreFoundation (called CoreFoundationLite IIRC) is
>available as open source.  None of Carbon is open source, and I would
>not expect that to change.

Thank you, I've not known the difference between
CF and CFLite. I with my fix is enough for next
release :-).

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Some fragmentized characters.

2006-02-16 Thread mpsuzuki

Hi,

On Wed, 15 Feb 2006 20:31:13 +0800
DingLi(丁力) <[EMAIL PROTECTED]> wrote:
>When I use Freetype, I found that some phenomenon
>that some fragmentized characters.
>
>For example, the mingliu.tcc(True Collection), is it a bug?

This is not bug of FreeType.
MingLiU.ttc requires bytecode hinting support
which is covered by Apple patent. Possibly you
will find same issue in Ghostscript.

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] about freetype-1.3.1 compile issue

2006-02-21 Thread mpsuzuki

Hi

On Mon, 20 Feb 2006 17:03:15 +0800
Giant SZ Li <[EMAIL PROTECTED]> wrote:
>How do you compile static library libttf.a for ARM7?
> our arm7 platform run linux 2.4,
> our cross compiler is arm-linux-uclibc-(3.4.2 version)!
>
>I download freetype-1.3.1.tar.gz, and uncompress it, 
>
>cd freetype-1.3.1
>
>./configure --disable-shared --enable--static
>
>then make

I think freetype-1.3.1 had been packaged before
autoconf knows the name of "arm-uclibc-linux",
I'm not sure if configure works well for the target.
Have you checked the object files are really compiled
with uclibc headers?

Now I'm trying to cross build on glibc-based Linux/ARM
to uclibc library.

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] about freetype-1.3.1 compile issue

2006-02-21 Thread mpsuzuki

Hi

Just I've built libttf.a successfully. Following is my procedure:

0. install autoconf-2.54
I suppose older (2.52 etc) can work,
but I don't know the lowest version.

1. unpack freetype-1.3.1

2. fix freetype-1.3.1/configure.in
remove the line "AC_REQUIRE([AC_PROG_MAKE_SET])"
which newer autoconf cannot handle correctly.

3. rebuild configure by "autoconf -I ."

4. configure for cross building
./configure \
--disable-shared --enable-static \
--host=arm-uclibc-linux --build=arm-linux

5. check the compiler is arm-uclibc-linux-gcc, instead of gcc.

6. make

Regards,
mpsuzuki

On Tue, 21 Feb 2006 13:02:14 +0900
[EMAIL PROTECTED] wrote:

>Hi
>
>On Mon, 20 Feb 2006 17:03:15 +0800
>Giant SZ Li <[EMAIL PROTECTED]> wrote:
>>How do you compile static library libttf.a for ARM7?
>> our arm7 platform run linux 2.4,
>> our cross compiler is arm-linux-uclibc-(3.4.2 version)!
>>
>>I download freetype-1.3.1.tar.gz, and uncompress it, 
>>
>>cd freetype-1.3.1
>>
>>./configure --disable-shared --enable--static
>>
>>then make
>
>I think freetype-1.3.1 had been packaged before
>autoconf knows the name of "arm-uclibc-linux",
>I'm not sure if configure works well for the target.
>Have you checked the object files are really compiled
>with uclibc headers?
>
>Now I'm trying to cross build on glibc-based Linux/ARM
>to uclibc library.
>
>Regards,
>mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] Re: [ft-cvs] freetype2 ./ChangeLog src/sfnt/ttmtx.c

2006-02-22 Thread mpsuzuki

Hi,

On Tue, 21 Feb 2006 17:06:35 +
David Turner <[EMAIL PROTECTED]> wrote:
>CVSROOT:   /cvsroot/freetype
>Module name:   freetype2
>Branch:
>Changes by:David Turner <[EMAIL PROTECTED]>06/02/21 17:06:35
>
>Modified files:
>   .  : ChangeLog 
>   src/sfnt   : ttmtx.c 
>
>Log message:
>   * src/sfnt/sfmtx.c: disabling memory optimization when
>   FT_CONFIG_OPTION_OLD_INTERNALS is used. This is because libXfont
>   is directly accessing the HMTX data. Gr

Now you're working for libXfont from the side of FreeType?
I was working for libXfont to build with FreeType-2.2 with
correct manner (my scratch is available
https://www.codeblog.org/blog/mpsuzuki/20060211.html), but
my work is now stopped because I found that libXfont accesses
internal TrueType font table directly, as you pointed out,
and I didn't have quick fix. If you have any comment to
libXfont side, please let me know.

However, the packages depending libXfont are small part of
X11R7.0, and I'm looking for test tools for comprehensive
regression test.

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] about freetype-1.3.1 compile issue

2006-02-24 Thread mpsuzuki

Hi,

A few exchange with Giant, we could build libttf.a,
so I post a short summary to cross build freetype-1.3.1,
for search engine users :-).

On Tue, 21 Feb 2006 07:01:23 +0100 (CET)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:
>> but how can I configure for my embedded arm7 system?
>
>Normally this is controlled with the --host, --build, and --target
>options of the configure script.  I can't remember whether version 1.x
>supports cross compiling.

configure in freetype-1.3.1 tarball is not ready for
cross building. to recreate configure supporting cross
buidling, commenting-out "AC_REQUIRE([AC_PROG_MAKE_SET])"
and executing autoconf again is enough.

However, in this case (target is arm-linux-uclibc, not
arm-uclibc-linux) config.sub could not recognize target
system name. small fix is required for config.sub aslike:

--- config.sub.orig 2006-02-21 19:42:24.0 +0900
+++ config.sub  2006-02-21 19:40:12.0 +0900
@@ -68,7 +68,7 @@
 # Here we must recognize all the valid KERNEL-OS combinations.
 maybe_os=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\2/'`
 case $maybe_os in
-  linux-gnu*)
+  linux-gnu* | linux-uclibc* )
 os=-$maybe_os
 basic_machine=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`
 ;;

I think it's enough to build libttf.a. Unfortunately,
test programs (like ftdump) are not ready for cross
build. Anyway, I wish people to migrate to FreeType2,
as Werner wrote.

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] last fixes for forthcoming release

Hi

Sorry for my inactivity for the urgent tasks
to release freetype-2.2..

Just I've tested cvs HEAD on GNU/Linux and MacOSX 10.4.,
and I'm afraid that gcc-4.x cannot build ftccache.c.
I received complains aslike:

 gcc -pedantic -ansi -I/Users/mps/redhat/BUILD/ft22test/freetype2/objs \
 -I./builds/unix -I/Users/mps/redhat/BUILD/ft22test/freetype2/include \
 -c -Wall -g -O2 -DFT_CONFIG_OPTION_SYSTEM_ZLIB -DHAVE_FSSPEC=1 \
 -DHAVE_FSREF=1 -DHAVE_QUICKDRAW_TOOLBOX=1 -DHAVE_QUICKDRAW_CARBON=1 \
 -DHAVE_ATS=1 "-DFT_CONFIG_CONFIG_H=" -DFT2_BUILD_LIBRARY \
 "-DFT_CONFIG_MODULES_H=" \
 -I/Users/mps/redhat/BUILD/ft22test/freetype2/src/cache \
 /Users/mps/redhat/BUILD/ft22test/freetype2/src/cache/ftcache.c \
 -fno-common -DPIC -o \
 /Users/mps/redhat/BUILD/ft22test/freetype2/objs/.libs/ftcache.o
In file included from 
/Users/mps/redhat/BUILD/ft22test/freetype2/src/cache/ftcache.c:24:
/Users/mps/redhat/BUILD/ft22test/freetype2/src/cache/ftccache.c:262: error: 
static declaration of 'ftc_node_destroy' follows non-static declaration
/Users/mps/redhat/BUILD/ft22test/freetype2/include/freetype/cache/ftccache.h:89:
 error: previous declaration of 'ftc_node_destroy' was here
make: *** [/Users/mps/redhat/BUILD/ft22test/freetype2/objs/ftcache.lo] Error 1
mps-iBook:~/redhat/BUILD/ft22test/freetype2 mps$ gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5247)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I received same error on GNU/Linux with gcc-4.0,
although no error in building by gcc-2.95.3 and gcc-3.3.x.
Am I testing wrong branch?

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] last fixes for forthcoming release

On Mon, 27 Feb 2006 12:23:36 +0900
[EMAIL PROTECTED] wrote:

> In file included from 
> /Users/mps/redhat/BUILD/ft22test/freetype2/src/cache/ftcache.c:24:
> /Users/mps/redhat/BUILD/ft22test/freetype2/src/cache/ftccache.c:262: error: 
> static declaration of 'ftc_node_destroy' follows non-static declaration
> /Users/mps/redhat/BUILD/ft22test/freetype2/include/freetype/cache/ftccache.h:89:
>  error: previous declaration of 'ftc_node_destroy' was here

The error caused by following conflict:

ftccache.h declares, around line #89

FT_BASE( void ) ftc_node_destroy( ... )

ftccache.c declares, around line #262

FT_LOCAL_DEF( void ) ftc_node_destroy( ... )

Which type is correct?

Regards,
mpsuzuki


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] last fixes for forthcoming release

Excuse me, I was misunderstanding new modularized building system.

On Mon, 27 Feb 2006 13:28:57 +0900
[EMAIL PROTECTED] wrote:
>1. Makefile in ft2demos should refer freetype2/modules.cfg,
>   but does not at present. Therefore, libfreetype.la is
>   built without gxvalid/otlavid module by default, but
>   make -C ft2demos tries to build ftvalid and failed.

In module.cfg, gxvalid, otvalid, ftgxval are disabled,
but ftotval is enabled. I think ftgxval and ftotval
are thin wrappers to provide public interface of gxvalid
and otvalid modules.

The interface functions in ftgxval and ftotval return
errors safely, when libfreetype is built without gxvalid
and otvalid. So, I think, ftgxval/ftotval should be
enabled always, except of the cases that the memory
filled by these wrappers are not negligible (e.g. very
small systems). If ftgxval/ftotval are always built,
we can always build ftvalid, and ft2demos/Makefile
is not needed to be modified.

But, now I found that modules.cfg disables ftgxval.
ft2demos/Makefile should be capable for such cases?

Regards,
mpsuzuki

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] last fixes for forthcoming release