Re: [ft-devel] Question on Freetype/OpenType feature
No. This should be done one level higher since it needs contextual string processing normally. Have a look at the Pango or ICU libraries, or do it yourself! As previous posts told, FreeType is font library and not text renderer, it should not act as locale-aware softwares. Well, for this particular problem (namely, to use simplified or traditional Chinese glyph shapes depending on some option), a selfmade solution is sufficient. For example, if I find some time to port ttf2pk to FreeType 2, I will go this route because most of the more sophisticated OpenType features are useless for ttf2pk. I don't know whether Pango's module-loader is locale-aware (if so we can write simple glyph substituter and let module-loader to use it when expected locale is selected), or locale-unaware (if so we have to write locale-aware module, but i'm afraid it breaks Pango's structural hierarchy). Hmm, I think it is the job of the application to select the proper OpenType features, depending on the locale. It becomes more complicated IMHO if Pango also takes locales into account, especially if the application wants to override the locale settings. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
As fontconfig and xft already have the code to embolden and rely on FT_GlyphSlot_Embolden to do the real job, I think FT_GlyphSlot_Embolden should be made standard API. This is an important feature for Chinese (maybe also Japanese and Korean) users, as most Chinese fonts don't have a real bold style. Basically, I don't object, but this won't happen in the next release which is in pretest stage right now. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
Considering there is such root of embolding request, I wonder whether FT_GlyphSlot_Embolden() API is already enough for the purpose. It does not receive much parameters to control embolding (am I misunderstanding?). I'm afraid several control parameters are requested in future, for example: * strength to embolding * switch to enable/disable changing glyph metrics in embolding * switch to enable/disable embolding of bitmap font * choosing embolding algorithm I agree. As already said, nothing for 2.1.10. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] tweaks to make ftraster.c compile in _STANDALONE_ mode
this looks nice! Can you change your patch slightly to put ftmisc.h into the same directory as ftraster.c? Similarly, `ftimage.h' should be expected in the same directory as ftraster.c if _STANDALONE_ is active. Sure Applied, thanks. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] compiler warnings
I still get those two compiler warnings (from gcc): In file included from src/sfnt/sfnt.c:26: src/sfnt/sfdriver.c: In function `sfnt_get_interface': src/sfnt/sfdriver.c:322: warning: ISO C forbids conversion of function pointer to object pointer type src/sfnt/sfdriver.c:325: warning: ISO C forbids conversion of function pointer to object pointer type Anybody an idea how to get rid of them? Just using `void' instead of `void*' fails if a C++ compiler is used for compiling. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Bug on PowerPC: Illegal Intruction in FT_Get_Name_Index (worksforme)
One more thing: I found it very hard to reconfigure freetype2 on Unix, to use another compiler for example. When I rerun ./configure with another CFLAGS, I see it report the new compiler, but when making, it's still using the old one. My humble solution was checking out a fresh copy... This is a bug. I'll try to fix it. It should be fixed now. Please test. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Bug on PowerPC: Illegal Intruction in FT_Get_Name_Index (worksforme)
Uh, oh, those two warnings are still there for your compiler? Then your double-cast patch has no effect :-( I'm not able to verify that because I don't get any warning with 3.3.3 with and without your change. No, double casting solves the error problem on C++, [...] Hmm, it compiled fine on C++ even without your recent change! You don't get these two with -pedantic? Yep. This seems to be a buglet in gcc which has been fixed in later versions. The code is specific to the sfnt module. Right. But why does it really need to return two functions with completely different signatures? It should always return a pointer to FT_Module_Interface. And another question, where is output returned by this function used? In sfobjs.c there is a call to FT_Get_Module_Interface which asks for the `sfnt' service. The idea of this function is to split the `sfnt' service into two subservices, namely `get_sfnt' and `load_sfnt' which can be accessed separately. Since this is the only place where this functionality is implemented and used it is easily possible that there are buglets in the declaration of the involved functions and data structures. Hmm, after checking the source it is probably best to remove the offending lines completely. No part of the FreeType library asks for those subservices, so it is dead code currently. David? AFAIU there should be the same warning somewhere else when you cast the void* back to a function pointer, unless there's no code that uses this function (directly or indirectly) in the FreeType code. Is it the case? Surprisingly, there's no warning anywhere else. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
[...] you can see that the glyphs get fatter and fatter. Thanks for testing. The attached patch should fix the problem. Applied, . (Changelog entry included. You may need to change the date.) It's better to include the ChangeLog entry in the mail instead of the patch. In case someone else has added a different patch, the ChangeLog chunk will fail. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
This is introduced by the last patch :( Hehe, there still seem to be problems :-) The glyphs in the two attached fonts don't change at all (neither the appearance nor the advance width) if I check embolding with ftview (not using your patch). Werner STARTFONT 2.1 COMMENT Anti-aliased test font. COMMENT It uses the BDF of Mark Leisher's xmbdfed package FONT -Misc-Fixed-Medium-R-Normal--20-200-75-75-C-100-ISO10646-1 SIZE 20 75 75 4 FONTBOUNDINGBOX 10 20 0 -4 STARTPROPERTIES 19 FONTNAME_REGISTRY FOUNDRY Misc FAMILY_NAME Fixed WEIGHT_NAME Medium SLANT R SETWIDTH_NAME Normal ADD_STYLE_NAME PIXEL_SIZE 20 POINT_SIZE 200 RESOLUTION_X 75 RESOLUTION_Y 75 SPACING C AVERAGE_WIDTH 100 CHARSET_REGISTRY ISO10646 CHARSET_ENCODING 1 DEFAULT_CHAR 65534 FONT_DESCENT 4 FONT_ASCENT 16 COPYRIGHT Public domain font. Share and enjoy. ENDPROPERTIES CHARS 1 STARTCHAR char0 ENCODING 0 SWIDTH 480 0 DWIDTH 10 0 BBX 10 20 0 -4 BITMAP 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD ENDCHAR ENDFONT STARTFONT 2.1 COMMENT Anti-aliased test font. COMMENT It uses the BDF of Mark Leisher's xmbdfed package FONT -Misc-Fixed-Medium-R-Normal--20-200-75-75-C-100-ISO10646-1 SIZE 20 75 75 2 FONTBOUNDINGBOX 17 20 0 -4 STARTPROPERTIES 19 FONTNAME_REGISTRY FOUNDRY Misc FAMILY_NAME Fixed WEIGHT_NAME Medium SLANT R SETWIDTH_NAME Normal ADD_STYLE_NAME PIXEL_SIZE 20 POINT_SIZE 200 RESOLUTION_X 75 RESOLUTION_Y 75 SPACING C AVERAGE_WIDTH 100 CHARSET_REGISTRY ISO10646 CHARSET_ENCODING 1 DEFAULT_CHAR 65534 FONT_DESCENT 4 FONT_ASCENT 16 COPYRIGHT Public domain font. Share and enjoy. ENDPROPERTIES CHARS 1 STARTCHAR char0 ENCODING 0 SWIDTH 480 0 DWIDTH 10 0 BBX 13 20 0 -4 BITMAP 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 ENDCHAR ENDFONT ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [PATCH] Small patch for builds/unix/.cvsignore
This patch updates builds/unix/.cvsignore so that cvs up is more silent now. Please apply. Done, thanks. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: const problems
Sounds good, but I think the name should be something more specific, like FT_CONST for the least. Yes, definitely. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] 2.1.10 ready
Folks, I've tagged 2.1.10 in the CVS, but I don't have quick internet access until Sunday evening for uploading, so there are no packages yet. Please stay patient! There is other good news: FreeType's new home is freetype.freedesktop.org and right now we are in the process of mapping freetype.org to this new address. Please note that those webpages are still the old ones. Finally, we have a new MoinMoinWiki at freetype.freedesktop.org/wiki which currently holds the tutorial only. Contributions and corrections are welcome! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] otv in Jamfile
We decide to make the development version public. Great! Is it OK for you to put this into the FreeType CVS (in the next week or so)? If you agree, can you provide proper patches to create a new module? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: FreeType and MSVC problem
[About incorrect argument prescan in MSVC's preprocessor for C which prevents correct compilation of FreeType's `otvalid' module.] This is a known bug. Aah, thanks. If you have further questions regarding this issue, Jason Shirk can help you out. Jason, I'm interested in the history of this bug, this is, when has it been introduced, which bug number it has (in case this information is publicly available), and whether there are plans to fix it, and finally, which version of MSVC you expect that this bug is fixed. Apparently, the word `argument prescan' isn't used for this bug -- a search on microsoft.com haven't had a single hit. How do you call it? Thanks in advance for your help! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Bug in ftmemory.h...
I notice that the FT_REALLOC_ARRAY #define in freetype-2.1.10/include/ freetype/internal/ftmemory.h takes _pointer_ as an argument, but uses _pointer (without the last underscore) in it's definition. I'm pretty sure that this is a bug and breaks the latest Pango build. (Sorry if this has already been mentioned). Fixed, thanks. Fortunately, it isn't used in the FreeType sources currently. Note that Pango shouldn't rely on FreeType internals! David Turner has already provided patches to the Pango people which fixes that, IIRC. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Outline_Embolden using incorrect macro.
The function declaration for FT_Outline_Embolden in ftoutln.h is using the wrong export macro. Fixed in the CVS, thanks. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Setting FT_ValidationLevel
Why FT_VALIDATE_BASE is started from 0x0100? It seems that 0xFF is reserved. It was just convenience -- a new series of information which has a different function. I guessed this 0xFF is reserved for passing the validation level. Using this reserved area, it is easy to pass a validation level to validator; and it is easy to switch the validation level dynamically. Yes, this is a possibility, but it isn't implemented. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: [ft] Compiling of freetype 2.1.1
The dsp- or dsw-file for Visual Studio is not usable.(downloaded version 2.1.11) But you have written it. I'm depending on volunteers since I don't use Windows. Please have a look at the FreeType Wiki at http://freetype.freedesktop.org/wiki which gives some help how to create a Windows DLL. I would be glad if someone can contribute completely functional DSP and DSW files for the current CVS. Another problem is the compiler doesn't find #include Carbon/Carbon.h //for IBM PC This shouldn't happen. #include Resources.h #include Fonts.h #include Errors.h #include Files.h #include TextUtils.h This shouldn't happen too. Both files are for Mac only. Please explain in more detaul how you compile; maybe other Windows users can guide you. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: xorg crashes with freetype2-2.1.10
My test of the freetype module showed that I could cause a crash by loading any -iso10646-1 ttf font I tried; but using an eight bit encoding never caused a crash. I didn't try any other sixteen bit encodings (such as legacy CJK encodings) and I didn't try otf or type1 fonts in that test. Thanks for all your tests, but to really find out the problem we need backtraces, which I was told is not an easy thing with X. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: xorg crashes with freetype2-2.1.10
For me xorg 6.8.2 crashes with freetype-2.1.10 when I try to run xterm -font -monotype-courier new-medium-r-normal--20-0-0-0-m-0-koi8-r Yes, I can finally(?) crash my x-server with this as well. Can you produce a backtrace? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Source compatibility for 2.2.0
Leaving aside the question of soname and binary compatibility, I was surprised to see in CVS the change to FT_Outline_MoveToFunc and friends; from the CVS commit message: [...] Such a change means that a project like Cairo either has to: A) Choose to compile *only* with 2.2.0 or newer B) Use ugly #defines to try and compile with both Is that really the intention? Personally, I prefer A). This allows us to fix issues best IMHO, but I'm probably alone with this opinion... Unfortunately, I don't have time currently to work on FreeType, and I won't have time the next few weeks either, I fear, because of some deadlines. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType Consortium?
Is there any sort of consortium, conference, or gathering of any kind for FreeType users or developers? Not really. Has there ever been? Some developers met twice a few years ago (once in Aachen and another time in Amsterdam) -- to have a nice afternoon with talking and a dinner. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] I got error code 7...
I am greenhorn in FreeType implementation to my software aplications. I followed your instruction in Tutorial and wrote a simple program in C++Builder (Client/Server). I included all your libraries and compiled the necessary source files (*.c and *.h) for truetype fonts. My program should simply return bitmap image (monochromatic) of chosen letter, but I got error code 7 (FT_Err_Unimplemented_Feature) when processing function FT_Render_Glyph_Internal. Could you please write me back what can I do with it? Thank you for your help. Sample code, please, and how you've called it. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] W.: Freetype2
The email adress [EMAIL PROTECTED] doesn't exist anymore! Yes, we know :-( Hopefully, this is fixed in the near future. 1.)The structure FT_Resource and the function FT_New_Resource(engine, filename, resource) doesn't exist too or have I overlooked it? There was nothing in the API doc. No, we don't have FT_Resource in the API. What do you want to do? 2.)I want to run Freetype2 under VxWorks (later perhaps QNX). VXWorks uses the UGL Lib. How can I integrate Freetype2 with less effort in Vxworks? Is there already a demo? I have no idea. Maybe someone on the lists can help you. 3.)Vx Works uses in the ROM coded fonts (see below), no binary font files. How can I read the datas from the fonts (C coded) correctly in the face object? These are very simple bitmap fonts. You might write a new driver module, or you convert the font data to the BDF or Winfnt format (in a buffer) which can then be read by FreeType. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Fw: [ft] crash loading font
This seems to be the right forum for this problem. Sorry for double
posting.
Werner
---BeginMessage---
We have 3 fonts that cause an illegal access violation in
t1_builder_close_contour (Adobe Jenson MM Italic Expert, Kepler
MM Expert, and Kepler MM Ornaments 1). [...]
Has anyone seen this problem of have any idea what the issue is here?
This is a *very* deep issue. These Multiple Master fonts also fail
with fontforge, BTW. [David, George, I've just sent you the smallest
of them privately.] They reveal (at least) two serious bugs in
FreeType's Type 1 parser.
Bug 1:
The fonts contain this snippet (disassembled with t1disasm) somewhere
after the private dictionary:
/@DInit {
thisfontdict /Private get /Subrs get exch get
/cs exch def
/ra rcs 256 idiv def
/rb rcs 256 mod def
/_i 0 def
thisfontdict /Private get /lenIV known
{thisfontdict /Private get /lenIV get
dup 0 lt { pop /@decryptproc {} store 0 } if
}
{4} ifelse
{ @Read pop } repeat
} bind def
I have no idea why this code is in the fonts and what it does --
anyway, it tests the `/lenIV' token, and this causes FreeType to
behave incorrectly. As soon as FreeType sees `/lenIV' it tries to get
a value for it. The assumption is that it looks like
/lenIV value def
It finds `known' (and `get') which can't be parsed, so it returns
zero. But this is wrong, since the default value for /lenIV is four,
and /lenIV isn't set in those fonts!
Bug 2:
Due to the incorrect lenIV value the charstring data is crap which
makes FreeType crash. This bug I've fixed right now.
Werner
___
Freetype mailing list
Freetype@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype
---End Message---
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] discussion of truetype glyph loading code
This patch does the changes (avoiding unnecessary array copying) I mentioned in the last post, along with a heavy cleanup of the truetype module. I just skimmed it, and it looks fine. Since the only good thing of the cleanup is to make the code more readible and it risks unstablizing the truetype module, I'll remove it and provide a new patch without the cleanup if someone thinks it's totally stupid to include the cleanup. What is really important is a comparison of FreeType with Windows, especially for critical fonts like Verdana. Ideally, someone writes the equivalent to ftview or ftstring using Windows function calls. Then a direct comparison of the created images can be done, highlighting the differences. Werner PS: Please don't include ChangeLog entries in a diff file directly. Instead, add it to the mail or put them into a separate file. For example, I can't apply your patch to the CVS version without changing it slightly because I've fixed two small problems meanwhile which resulted in new ChangeLog entries. PPS: I can't see a ChangeLog entry that tt_prepare_zone is now compiled conditionally. PPPS: Perhaps it is useful to use uppercase letter for even for macros which look like a function (like tt_loader_set_pp), just as a reminder that calling them might have secondary effects. BTW, this macro isn't mentioned in the ChangeLog either... ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] discussion of truetype glyph loading code
I thought heavily clean up implies some changes are not listed :) This is a lame excuse :-) Seriously, your clean-ups are still comprehendable -- it's more a code shifting than a complete rewrite, isn't it? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ft_validator_run in otvalid
ft_validator_run is defined but it not used in otvmod.c. My patch shrinks otvmod.c 20 bytes:-P Applied, thanks. Sorry for the delay. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] sfnt-housed fonts on MacOS missing hhea table
It seems that FreeType2 cannot load some bitmap-only fonts on MacOS X (possibly on Classic MacOS too), because such fonts have no hhea tables in its sfnt resource. I wrote small patch to bypass the problem [...] Applied, thanks. Sorry for the delay. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] CFF fonts and bbox
Sorry for the late reply. Hi, after having a look at cff source code and primaryly the comment at cffgload.h: /*bbox :: Unused. */ The bbox field in this particular structure is no longer used. CFF fonts of course have a bbox array. it seems that bbox is not used in cff fonts so i'll suggest removing the cff_parse_font_bbox function as having a function that noone calls seems to be a bit useless :-D The function is used, namely in cfftoken.h, line 39: CFF_FIELD_CALLBACK( 5, font_bbox ) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] gxvalid patch for ftvalid.c
P.S. After moving the FreeType2 cvs repository to savannah(subversions?).gnu.org, I may lose my write-access to it. I'm happy if you give mpsuzuki instead of me to write-access for gxvalid merging tasks. Toshiya-san, Masatake-san, 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. 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? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] gxvalid patch for ftvalid.c
I will rewrite with GX. How do you think about? This is fine with me. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Bug in autofit render setup
While playing font rendering, and trying to figure out while scaling some truetype fonts ends up with the bottom horizontal line of E, L, 2 etc is missing. (75dpi, freetype used as an X server renderer, running on Solaris, so using the Sun provided CourierNew.tff.) [...] I think that af_latin_metrics_scale should actually include the line: metrics-root.scaler.render_mode = scaler-render_mode; By adding the line, I now have characters appearing correctly. [...] Applied, thanks. You've looked at Courier New with anti-aliasing off, right? If you switch it on, you won't see that horizontal lines disappear. FreeType's autofitter has been designed for AA mode only, and your fix has almost no visible effects if AA is activated. Maybe this is a bug in your X server renderer which tries to apply the `gasp' table if FreeType's autohinting is active... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Bug in autofit render setup
FreeType's autofitter has been designed for AA mode only, Werner, that's not true. The auto-fitter should be able to handle non-AA modes appropriately. Oh, thanks for the correction. If the lines disappear, there is some bug somewhere. The patch suggested by Chris fixes this problem. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Can't compile under cygwin
For whatever reason, the makefile doesn't realize it's got a 'unixy' environment. Any guesses what's wrong? I think you have to use the Unix shell, not the DOS shell, but this is just an educated guess. Please report again, sending the compressed output of `make -R -r -d', if noone can give you further help. Also, did you guys get my last email to 'freetype@nongnu.org', or am I being ignored? Regarding the CR/LF problem in the doc zip file? I've answered: http://lists.gnu.org/archive/html/freetype/2005-08/msg00018.html Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] freetype2.pc: Missing include directory
The generated freetype2.pc file lists ${includedir}/freetype2 but
not ${includedir} which causes code to fail to find ft2build.h if
freetype is installed in a non-standard directory. freetype-config,
on the other hand, gets this right. Trivial patch attached.
Applied, thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Digital signatures
I seem to remember talk about testing FreeType on randomly corrupted fonts; has any work on this been done? AFAIK, George has started with some work. For my part, I've done nothing, alas. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] randomly corrupting tests
I have a little program which makes a copy of a font file changes a random byte to a random value (optionally more than 1) passes the result to fontforge and makes sure ff can handle it without crashing. BTW, this file is now part of the FontForge CVS. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] TT_MAX_COMPOSITE_RECURSE
#define TT_MAX_COMPOSITE_RECURSE 5 This value is used to specify the maximum depth allowed to which composite glyphs may be nested. But the truetype spec does talk about this, it's a field in maxp maxComponentDepth. So I suggest the following patch: Applied, thanks. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] TT_MAX_COMPOSITE_RECURSE
This patch is causing a regression when trying to use Bitstream Vera Sans 10 = all glyphs with accentuated letters (like à é ù ) are not longer displayed :( Hmm. It works on my system. Did I send the wrong patch? It's my fault I think since I applied it manually. Anyway. Line 1215 of ttgload.c is wrong, there's a = where there should be a . Fixed, thanks. Werner ___ 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
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... Werner ___ 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
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. Great! And thanks in advance for your support. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Inconsistent Function Type
In a header file include/freetype/ftrender.h , typedef void (*FT_Glyph_TransformFunc)( FT_Glyphglyph, FT_Matrix* matrix, FT_Vector* delta ) But in a source file src/base/ftglyph.c , FT_CALLBACK_DEF( void ) ft_outline_glyph_transform( FT_Glyph outline_glyph, const FT_Matrix* matrix, const FT_Vector* delta ) This has been fixed already in the CVS, please try. Thanks for the report. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: Aw: Re: Kerning
[Stefan reports that the macro FT_HAS_KERNING always returns 0.] This is definitely a bug. We have the following in sfobjs.c, function sfnt_load_face: #if 0 /* kerning available ? */ if ( TT_FACE_HAS_KERNING( face ) ) flags |= FT_FACE_FLAG_KERNING; #endif It seems that David has commented this out temporarily while developing the (yet disactivated) FT_OPTIMIZE_MEMORY stuff. Thanks for the report; I've removed the #if 0 ... #endif stuff. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] memory fragmentation
[I've translated and forwarded Stefan's email to this list -- I'm no expert for this topic, so I hope for a competent answer by somebody else.] In embedded systems which aren't booted often it would make sense to use a static memory management, avoiding an increasing fragmentation of the memory. What do you think? What's a recommended maximum size for such a memory block under normal circumstances -- i.e., a TTF not larger than 100KByte, with max. 400 glyphs, probably stored in an array not larger than 500KB, using default modules, max. 3 charmaps, one face, no subglyphs. == The original message in German. bei Embedded Systemen, die nicht oft neu gebootet werden, wäre ein statisches Speichermanagement u.U. sinnvoll, um eine zunehmende Fragmentierung des Speichers zu verhindern. Wie ist Deine Meinung dazu, und wie groß müßte der Speicherbereich im Normalfall max. sein? (bei einem TT-Font-File mit max. 100KB und max. 400 Glyphen, als Array max. 500KB, Defaultmodule, max. 3 Charmaps, 1 Face, ohne Subglyphs) (für fontface,Lib,Stream,etc) ___ 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
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. Since I don't use a Mac, I have no opinion. Hopefully, others can comment. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: Problem with FreeType cache system
max_bytes corresponds to the maximum amount of memory you want to dedicate to the cache nodes, it doesn't need to correspond to the total memory available on your system; it's used to prevent the cache from inflating to vexing levels. note that it does NOT account for managed FT_Face and FT_Size objects though. when you perform a lookup, out-of-memory errors are detected _within_ the lookup, and force incremental flushes of the cache until enough memory is released for the lookup to succeed. If a lookup fails with FT_Err_Out_Of_Memory, this means that your cache has already been completely flushed, and still no memory was available for the operation. I've added this information to the documentation of FTC_Manager_New. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] Autofit and stem snapping
the FreeType API defines several FT_LOAD_TARGET_XXX constants that determine which hinting algorithm to use when loading outlines from a font file: FT_LOAD_TARGET_NORMAL = hint for normal anti-aliased rendering FT_LOAD_TARGET_LIGHT = same as above, but hint less ! FT_LOAD_TARGET_MONO= hint for monochrome rendering FT_LOAD_TARGET_LCD = hint for horizontal LCD rendering FT_LOAD_TARGET_LCD_V = hint for vertical LCD rendering Notice that: - you should only use *one* of these values in your load flags; you cannot OR them, because they're not simple bit flags ! - this means you cannot combine them, i.e. there is no light lcd mode. Light hinting is intended for normal anti-aliased rendering only. However, FreeType makes a distinction between the hinting algorithm being used, and the pixel mode of the target bitmaps. For example, it is possible to use the light hinting algorithm and have the results rendered in horizontal LCD pixel mode, with something like: FT_Load_Glyph( face, glyph_index, load_flags | FT_LOAD_TARGET_LIGHT ); FT_Render_Glyph( face-glyph, FT_RENDER_MODE_LCD ); I've added this to the documentation of the FT_LOAD_XXX enumerations. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] Autofit and stem snapping
- the demo code didn't really select the hinting algorithm correctly, I've corrected it in the CVS to match libXft's behaviour Hmm, no ChangeLog entry. Will you do that? - there was a bug in the auto-fitter, [...] Fixed in CVS this morning before going to work. No, you didn't. Please retry. - I'm still unsure wether the current auto-fitter sources duplicate 100% the old auto-hinter with regards to hinting algorithm. I'll have to check this. I tried hard to identify missing bits in autofit which were in autohint, applying those features again. However, those things were minor details in the `environment', so to say, which don't scratch the algorithm itself. Werner PS: You've disabled compilation of ftgxval.c in the Jamfile. How does it fail for you? ___ 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!
You mean that all registers and operators are based on 8bit entities? yes all registers and operators are 8bit. Hmm, I think there must be at least some 16bit entities for jumps and similar things, right? i don't want to have support for all fonts but if i can compile it for a single font like say BDF that would be great! Well, then I strongly suggest that you take the BDF module and adapt it to your needs directly, avoiding the rest of FreeType altogether! Nevertheless, the fixes should be trivial since we try hard to avoid dependencies on a certain register depth to make FreeType work on 16, 32, and 64bit architectures. can u elaborate more on register dependency of freetype? (i guess it would be for computational purpose) Some operations like `x 8' only make sense if you have at least 16bit wide registers. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Load and Render Flags.
I will appreciate, if someone can give pointers to Load (FT_LOAD_XXX) and Render(FT_RENDER_XXX) flags to be used in ver. 2.1.10. Specifically for following scenarios: -Antialiasing (ON), Hinting(ON) FT_LOAD_TARGET -Antialiasing (ON), Hinting(OFF) FT_LOAD_TARGET_NORMAL FT_LOAD_NO_HINTING -Antialiasing (OFF), Hinting(ON) FT_LOAD_TARGET_MONO -Antialiasing (OFF), Hinting(OFF) FT_LOAD_TARGET_MONO FT_LOAD_NO_HINTING FT_LOAD_NO_HINTING should be ORed with possible other flags while calling FT_Load_Glyph, and FT_LOAD_TARGET_XXX should be used exclusively with FT_Render_Glyph. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Digital signatures
It also means having a non-MS signing tool. Has anyone actually managed to independently verify or sign a font. I've tried and failed at the most fundamental level of trying to get my md5 hash of a font agree with MSs. IIRC, there was something into this direction on the opentype mailing list. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Status of 2.2
- Do you have any idea how far out 2.2 still is ? It's still far away because I currently have limited time to work on. - Will 2.2 be libfreetype.so.7 ? Yes. At least this is my opinion. - Do you still plan to break source compat by doing const correctness changes ? I would like to have that; in most cases it should be trivial to fix in the affected application source code. - 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? I can't answer that. Fact is that the 2.2 release no longer will install the internal header files. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Export services?
There are some functions which are wrappers to services. Then why not simply export the services to clients? Please give an example how you would like to rearrange services. To make finding a service faster, we can use integers as service id, instead of strings. Do you really think that this is of great importance? Strings are more user-friendly IMHO. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Export services?
On Fri, Oct 14, 2005 at 10:11:21PM +0200, David Turner wrote: David, I've added your address to the freetype-devel list (without receiving mails). An exported service is like an exported function call, once get exported, it allows no change. May I suggest that we postpone this discussion and work on fixing the list of exported functions first? This seems to be a more urgent task to me which probably identifies other problems/benefits of services. It basically means the following: . Write a script which collects all EXPORT_DEF declarations and converts it to a list. . Add it to the build process. . Pass it to libtool's `-export-symbols' parameter. Can you afford some time to work on this? Hmm, maybe we can export the byte interpreter as a service, then a client can use this service to show how intructions instruct a glyph vividly. I think this is not worth the time. The only program which uses this is FontForge, and George (who is intentionally using internal headers) will update his interface to FreeType whenever it's necessary. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] non-standard commenting in tttables.h
I did find some discrepancies: ftsysmem.h doesn't put the function name on the the following line for ft_memory_new and ft_memory_destroy, This file, together with ftsysio.h, is obsolete; I've just removed both. cache/ftccmap.h uses a mixed format in FTC_CMapCache_New and FTC_CMapCache_Lookup, I've converted the whole file to the new comment style. ftcache.h uses a mixed format in FTC_CMapCache_New and FTC_CMapCache_Lookup, Fixed. fttrigon.h has a lot of mixed format function comments, Converted the whole file. freetype.h has a mixed format function commen for FT_Stream_OpenGzip. Well, this function isn't in freetype.h, but I've cleaned up all other mix-ups of old with new style. Werner ___ 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?
A haphazard Workaround for such issue (which replace comp by compo) is acceptable? In case this should be really necessary (see my other mail) I ask you to find a variable name which is `more natural', perhaps `Comp' or `component'. werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Question on glyph outline rendering for openType
I would like to load a font , get it's glyph outline and then render it as a path so that I can fill the glyph with custom stuff such as gradients and patterns.I have seen examples of this for free Type and true Type in win32. This has been answered on comp.fonts. I wish to know if this is possible with OpenType? and my targeted platform is win32. Yes, FreeType 2 supports OpenType fonts, but what you want to do is not FreeType's primary target. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Segfault with otf and face_index == -1
If you call FT_New_Face with face_index 0, it should return an empty FT_Face object to indicate that the format is supported (otherwise, an error is returned). Moreover, the face-num_faces field can be used to determine the number of faces within the font file. After that, the caller must destroy the FT_Face normally with FT_Done_Face Ok. You should update the API docs to refelct that. Done. Please check the CVS whether it is understandable. Also the current code allows you to pass face_index 0 and aface == NULL. If that is still legal then the following patch is needed to avoid leaks ...I think :) Applied, thanks. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Fw: [OpenType] kerning in OTF (was: Custom platform (ID 4) cmaps)
This might be interesting for some of you. It means in consequence that the higher-level code which handles GPOS has probably to discard the kern values FreeType returns (which only looks at the `kern' table). Werner ---BeginMessage--- OpenType list address: [EMAIL PROTECTED] Thomas Phinney wrote: My memory kicked in since my last note: I believe that Adobe's current approach for both TT and CFF flavored fonts is that if there is a non-empty GPOS table, we don't look for a kern table. That's right. Specifically, our current approach is to look for a kern table (for either flavour of OT font) iff (a) no GPOS is present, or (b) an empty GPOS is present. An empty GPOS is defined here as one which has FeatureList == 0 or FeatureList.FeatureCount == 0. I believe VOLT generates such stub GPOS and GSUB tables. Note that this means, for example, that if the GPOS contains only a mkmk feature, and a kern table is present, the font will be regarded as having no kerning information in it. Sairus At 11/1/2005 11:09 PM, you wrote: OpenType list address: [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Twardoch Sent: Tuesday, November 01, 2005 10:57 PM To: Multiple recipients of opentype Subject: [OpenType] Re: Custom platform (ID 4) cmaps OpenType list address: [EMAIL PROTECTED] Thomas Phinney wrote: That's a tougher call: this is another case of information that is duplicated for legacy reasons, which mostly don't hold for OpenType CFF (PS). That depends on how you treat OpenType PS fonts. If you treat them with Adobe code, this may be true. But the hardcoded special-purposes behaviors of ATM are not, and should not be, part of the spec, right? We wrote the ATM code to match the spec, not the other way around. It invokes a whole bunch of questions about how to process fonts that have both kinds of kerning. Admittedly, these questions are there for OpenType TT fonts anyway Exactly. Redundancy of information in OpenType fonts is huge and not very practical. But I think it helps if these redundancies are at least consistent among flavors. IMO, anything that is flavor-specific in OpenType is a pest (like name id 4.3.1). This is why the Options dialog in FontLab Studio 5 is 8x as large as that in FontLab 4.6! Yup, the flavor-specific stuff and redundancies are both a pain. - do you simply ignore the 'kern' table if you pay attention to the 'GPOS' 'kern' feature tag? - if you process both, what is their relationship? Are they additive, or does one overrule the other...? The most logical approach would be: if a new structure is there, ignore the old one. If GPOS with a kern feature is defined, the kern table should be fully ignored. My memory kicked in since my last note: I believe that Adobe's current approach for both TT and CFF flavored fonts is that if there is a non-empty GPOS table, we don't look for a kern table. Of course, it would have also helped if FontLab hadn't madeit so easy to violate the spec in this area. :/ Actually, the language OpenType fonts containing CFF outlines are not supported by the 'kern' table and must use the 'GPOS' OpenType Layout table. does not say that the kern table may not be present in the font. If you say so. :) Cheers, T Subscribe: [EMAIL PROTECTED] Unsubscribe: [EMAIL PROTECTED] Set list to inactive: [EMAIL PROTECTED] Set list to active: [EMAIL PROTECTED] Message mode: [EMAIL PROTECTED] Digest mode: [EMAIL PROTECTED] Subscribe: [EMAIL PROTECTED] Unsubscribe: [EMAIL PROTECTED] Set list to inactive: [EMAIL PROTECTED] Set list to active: [EMAIL PROTECTED] Message mode: [EMAIL PROTECTED] Digest mode: [EMAIL PROTECTED] ---End Message--- ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Segfault with otf and face_index == -1
Attached. It includes the change I suggested and copies the same description to FT_New_Face() and FT_New_Memory_Face(). Applied, thanks. Werner ___ 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( )
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. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] serious bug introduced 2005-10-29
David, a comparison between a FreeType checkout with -D 2005-10-28 and -D 2005-10-29 shows that the latter has introduced a serious bug w.r.t. TTF handling. Attached two images from the font Dustismo.ttf. Perhaps your arithmetic performance improvents are buggy... This might also be the cause for the strange Vera rendering issues. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] serious bug introduced 2005-10-29
I just commited a fix to the problem. There was a bug in ft_trigon_prenorm. the optimization introduced recently Also included, a fix to the truetype interpreter FT_UNUSED_EXEC unwanted memcpy Thanks for the quick fix. Will test soon. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] vertical metrics zero for OpenType CFF
I've included a patch for a bug in FreeType related to zero values for vertical metrics for OpenType CFF fonts. Thanks! I've applied a simplified version to the CVS. Sorry for the long delay. My assumption is that the FreeType team didn't have time to implement this yet. Mhmm, I think it is rather an oversight. Currently, the htmx table is completely ignored for OpenType CFF, this is, the advance width and the left side bearing are directly computed from the CFF data. This seems to work without problems -- and is probably more reliable than using the hmtx data. Please test. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] failed to compile ftvalid.c
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, You should use free() in ftvalid.c because FT_FREE() is not a public API. I suppose it is to make FreeType report the consumed memory for validation, by memory leak detection. It's exactly the opposite. Only with FT_FREE() FreeType's internal memory debugger works correctly (by setting the FT2_DEBUG_MEMORY environment variable). If you use free(), you bypass the bookkeeping routines. Hmm, we have a problem. Replacing FT_FREE with free() in ftvalid.c makes the following crash: FT2_DEBUG_MEMORY=1 ftvalid font David, what do you suggest? Maybe it's best to use plain ft_alloc() and friends in FreeType for data which should be deallocated by the user? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] failed to compile ftvalid.c
I attached 4 patches, please check. Thanks a lot! 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? Since most functions of FreeType take FT_Face, I think this is better. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] failed to compile ftvalid.c
I attached 4 patches, please check. And please install! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] module inclusion/exclusion
For systems that dont support dlopen() and only support static linking, the Amiga build can be used as example. The forthcoming libtool version fixes bugs of libltdl on static platforms. I would be glad if you could test whether libltdl (not necessarily the libtool script itself) runs under AmigaOS. Now is the right time to fix any problems so that patches can be included into the libtool CVS since they are going to have a new release soon. It builds a libft2.a with all modules and contains a ftmodule.h file that starts like [...] Yes, something like that will come. I plan to let `make' do most of the work. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Memory leak in bdfdrivr.c
The attached patch fixes a memory leak in bdfdrivr.c. Applied, thanks. Werner ___ 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
--- freetype.h2005-08-15 16:05:44.0 -0400 +++ freetype_1.h 2005-11-21 15:49:16.0 -0500 @@ -1875,7 +1875,9 @@ const FT_Byte* file_base, FT_Long file_size, FT_Long face_index, - FT_Face*aface ); + FT_Face*aface, + FT_Int num_params, + FT_Parameter* params ); This patch isn't possible. We won't change the public API. --- t42objs.c 2005-08-15 16:05:56.0 -0400 +++ t42objs_1.c 2005-11-21 16:01:59.0 -0500 @@ -263,7 +263,9 @@ face-ttf_data, face-ttf_size, 0, -face-ttf_face ); +face-ttf_face, +num_params, +params ); if ( error ) goto Exit; FT_New_Memory_Face is just a small wrapper around FT_Open_Face This should be rewritten to use FT_Open_Face directly. Can you do that? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problem with Verdana font
In attached screenshot you can easily see that at 16 pixel bold, W N characters are too bold compared to other characters. I can see this behaviour in Freetype 2.1.10 and Freetype CVS HEAD. Hmm, I can't see this with ftview from CVS 2005-11-25 (using verdanab.ttf 2.35). Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] distinguish overlapped and unsorted segments in cmap format 4
The problem I mentioned in the last mail is solved by replacing the bool `cmap-unsorted' by `cmap-flags.' So here is the patch. Both patches look good! Please add them to the CVS. I'll then run my suite of bad and problematic fonts... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] A simple script to test
I've commit a patch to make ftdump support -c, show charmap contents. With that, and the simple script `cmaptest' which can be found in the attachment, you can easily test if things still work correctly. I've replaced `-c' with a switch `-v' to indicate verbosity. ftdump now always shows some charmap info. The usage is ./cmaptest fonts-dir and it will show the differences. This should be updated accordingly. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] distinguish overlapped and unsorted segments in cmap format 4
Both patches look good! Please add them to the CVS. I'll then run my suite of bad and problematic fonts... Ok, I've committed. Thanks! There is one difference in format 4, in how charcode 0 is mapped when offset is 0. In my code and the original `tt_cmap4_char_next', `delta' is always added to `charcode' to get `gindex', as the spec says. On the other hand, in original `tt_cmap4_char_index', `delta' is added to `charcode' only when `charcode' != 0. It looks like you've fixed a bug... Folks, since this is rather important code please test whether everything is still fine! Werner ___ 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
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. 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. Where's the problem with binary compatibility? You are going to extend the functionality, not to change, aren't you? 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. 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. I fully agree. Applications can use FT_IS_SCALABLE() to ignore bitmap fonts. Werner ___ 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
NFNT resources are separated for each sizes, just aslike strike of sbit. Could I know more about WINFNT encoding issue in ft-devel archive? As soon as there is an encoding difference you have to use faces. Werner ___ 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
A little bit late but here's the fix without touching FT_New_Meory_Face. Applied, thanks! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] BDF and FT_Set_Pixel_Sizes
How do you come to this conclusion? The original BDF specification (found in the X11 distribution) says that both FONT_ASCENT and FONT_DESCENT are *logical* values. They don't guarantee that all bitmap glyphs are within this range. Still, then we should set y_scale to 8 / (face-ascender + face-descender) in, for example, Set_Pixel_Sizes in ttdriver.c, shouldn't we? I'm not sure -- and too lazy to really think about it :-) Do you encounter problems with bitmap sizes? I found docs/CHANGES mentions this change and it says FT_Set_Pixel_Size is used to select actual font dimensions (the `strike'), not the nominal size. Maybe my question is what actual font dimensions mean? Well, if the font contains an 8x16 bitmap, the parameters are `8' and `16'. This is to get a unified interface to all bitmap formats, including Windows FNT. Note that the ppem values in WinFNT files are normally incorrect. BTW, your latest changes to the SFNT driver broke FNT files with multiple faces (this is, if they contain more than a single bitmap font). Reason is that the check for `face_index' in the SFNT driver is done before validation of the font format -- the driver incorrectly returns SFNT_Err_Bad_Argument instead of the correct SFNT_Err_Unknown_File_Format. I've fixed that now. Werner ___ 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
* 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? As far as I've seen, most system headers exist in one copy only, and use preprocessor macros to detect which the architecture is; usually via sys/isa_defs.h, which defines macros for most of the interesting cases: [...] This is the solution I like most. I don't know how difficult it is to achieve that... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Illegal cff font
I cannot verify that the file was indeed created by PDF-XChange, though that seems likely. Nor can I verify that PDF-XChange produced the incorrect font-subset. Maybe this user can give more details: Perhaps he or she is able to repeat the whole process so that it can be checked what's really going on. This should help all affected parties. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] global font metrics are rounded?
To sum up, I think freetype should not round global font metrics (nor glyph metrics) and let clients decide how to deal with them, despite that clients are able to get the unrounded values by scaling themselves. As the effect is large (all apps using Xft), I need your opinions. If there is no objection, I will commit the attached patch later today. Sorry for not reacting (the same for your other mails regarding bitmap fonts -- I'm swamped with other things currently so that I don't find time to think about it). Please install -- and please add an entry to the CHANGES file, probably by adding a small code snipped to show how to do it properly. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ft-smooth for 2.1.10?
WARNING: INSTALLING THE CURRENT CVS WILL PROBABLY BREAK YOUR SYSTEM What do you mean? The rendering results? Werner ___ 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
Here's revised version of dual-ABI patch which generates unified ftconfig.h for 64/32bit UNIX platforms. This looks very promising! Thanks for your hard work. 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. + /* 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. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] rendering differences between OS X and Win32
Problem solved. I replaced the official binary libraries with mingw compiled libraries I found at http://oss.netfarm.it/mplayer-win32.php which was a lot easier than compiling freetype myself because I'm using VPC and it's slow. I'm guessing that maybe the official binary was compiled with MSVC and some it's behaviour is a little different than gcc. Hmm, inspite of using different compilers the behaviour should be completely identical, since FreeType doesn't use floating point arithmetic. Can you further investigate? Werner ___ 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
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. 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. Just go on. Maybe you can drop a note to the libtool maintainers that you've implemented multilib support in FreeType. Again, thanks for your work. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] How to determine if patented hinting is enabled?
The cvs instructions at http://freetype.org/developer.html#anoncvs are out of date [...] Fixed too, thanks. I'd change the text to remove any mention of ssh and CVS_RSH since that's no longer required. ie remove the '(SSH required!)' in the title, change the CVS+SSH to just CVS and entirely remove the last paragraph. Oops. Fixed, thanks. Werner ___ 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
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. Werner ___ 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
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. I remember, a volunteer was wanted to add PNM output to ftstring, [...] If there's nobody yet, I want to do that, although I cannot give the highest priority to this task. This would be great! No need to hurry... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Improved PS glyph name - Unicode mapping
Folks, I've now fixed Savannah bug #15056: In synthetic Unicode mappings based on the AGL, base glyphs are now preferred over variant glyphs if both are available. At the same time I've replaced the cmap code in psaux/t1cmap.c with the pscmap service, thus reducing the library size slightly. Similarly, I will soon replace the Unicode cmap code in the cff module. Please test. Werner ___ 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?
I want to know when does the next version (ver 2.2.0?) of freetype release? Hopefully within a month or so. Werner ___ 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?
Will it be released with FT_OPTIMIZE_MEMORY defined? Yes, d.e.f.i.n.i.t.e.l.y !! So maybe it's time to switch that on in the CVS... More information at: http://turnerdavid.neuf.fr/freetype/freetype-2.2.0-safe-install.html http://turnerdavid.neuf.fr/freetype/rogue-patches.html I'll grab those files and install them at freetype.org. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] AFM parser optional?
Chia-Yi, can you make the AFM parser optional, to be controlled by a configuration macro in ftconfig.h? Given that Type 1 fonts are vanishing I can imagine that some users in the embedded market only want to have, say, CFF support... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] web page for the forthcoming 2.2.0 release
Have a look at http://freetype.org/freetype2/freetype-2.2.0.html which discusses some important issues with the forthcoming 2.2.0 release. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] web page for the forthcoming 2.2.0 release
[discussion continued on freetype-devel only] A new version which makes such a radical change should bump up the shared object version (.so.N). Where's the `radical change'? That way we'll allow a transition period for applications to update. This has been discussed recently on the FreeType list, and the consensus seems to be that it is better to fix the applications than to increase the DLL version to avoid even more problems. David, what about adding some words to freetype-2.2.0.html? Since you apparently still don't have access to freetype.freedesktop.org please send me a patch which I can apply. Werner ___ 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?
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. This should be added to the freetype-2.2.0.html page, perhaps with even more details. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: [ft-announce] web page for the forthcoming 2.2.0 release
I *think* fontconfig 2.3.93 doesn't use the internals anymore... well, that's what the changelog for the release claims; perhaps this could be noted on the patches page. Added, thanks. Can someone verify this claim, please? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: [ft-announce] web page for the forthcoming 2.2.0 release
OK. I bit the bullet and rebuild freetype and fontconfig... yes, it does look like fontconfig-2.3.93 will compile against freetyle sans internal headers. Thanks a lot for the verification! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FreeType issues
Steve, I've read your very interesting mail at http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html What's your recommendation in the light of http://freetype.org/freetype2/freetype-2.2.0.html ? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] web page for the forthcoming 2.2.0 release
Perhaps we shall *rename* the library to, say, `libft2', instead of `libfreetype', together with a new API prefix `FT2_' instead of `FT_'. This would avoid the whole mess. Or even `libft3' and `FT3_' ... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
