Re: [ft-devel] Force PMingLiU like font do HINTING
> . Add `FT_FACE_FLAG_TRICKY'. If set, the font is tricky. To > access it, add a macro `FT_IS_TRICKY'. [This is a read-only > flag.] > > . Change the meaning of `FT_LOAD_NO_HINTING' so that fonts which > always need TrueType instructions (these are fonts which have > FT_FACE_FLAG_TRICKY set) ignore it. > > . Instead of adding a new `FT_LOAD_RAW' flag which would do what > `FT_LOAD_NO_HINTING' currently does, I propose that we get the > behaviour of `raw' loading if both `FT_LOAD_NO_HINTING' and > FT_LOAD_NO_AUTOHINT are set. This is now implemented in the CVS. Please test! Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Force PMingLiU like font do HINTING
> What happens (with or w/o the proposed change) for tricky fonts when > ft is compiled with -DTT_CONFIG_OPTION_BYTECODE_INTERPRETER? The patented hinting is forced then. > What about the cases where autofitting or light autofitting is > requested and the font is tricky? Do the instructions get run? Yes, always, except if you use both `FT_LOAD_NO_HINTING' and FT_LOAD_NO_AUTOHINT. Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Force PMingLiU like font do HINTING
One last (perhaps stupid) question: What happens (with or w/o the proposed change) for tricky fonts when ft is compiled with -DTT_CONFIG_OPTION_BYTECODE_INTERPRETER? OK. Two questions. What about the cases where autofitting or light autofitting is requested and the font is tricky? Do the instructions get run? -JimC (thinking up corner cases) (For the curious: it turned out to be 6 dm of snow in need of shoveling the other day; but at least it was mostly nice, soft powder.) -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Force PMingLiU like font do HINTING
> > . Add `FT_FACE_FLAG_TRICKY'. If set, the font is tricky. To > > access it, add a macro `FT_IS_TRICKY'. [This is a read-only > > flag.] > > > > . Change the meaning of `FT_LOAD_NO_HINTING' so that fonts which > > always need TrueType instructions (these are fonts which have > > FT_FACE_FLAG_TRICKY set) ignore it. > > > > . Instead of adding a new `FT_LOAD_RAW' flag which would do what > > `FT_LOAD_NO_HINTING' currently does, I propose that we get the > > behaviour of `raw' loading if both `FT_LOAD_NO_HINTING' and > > FT_LOAD_NO_AUTOHINT are set. > > For the patented hinter, the FT_LOAD_NO_HINTING turns off the > hinting. Do you want to change that behavior for the applications > that use the patented hinter? Yes, such a change makes only sense IMHO if done in a uniform way. The tricky fonts look bad with both patented and unpatented hinting switched off. Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] Force PMingLiU like font do HINTING
> After some thinking I can imagine that the following works. > > . Add `FT_FACE_FLAG_TRICKY'. If set, the font is tricky. To access > it, add a macro `FT_IS_TRICKY'. [This is a read-only flag.] > > . Change the meaning of `FT_LOAD_NO_HINTING' so that fonts which > always need TrueType instructions (these are fonts which have > FT_FACE_FLAG_TRICKY set) ignore it. > > . Instead of adding a new `FT_LOAD_RAW' flag which would do what > `FT_LOAD_NO_HINTING' currently does, I propose that we get the > behaviour of `raw' loading if both `FT_LOAD_NO_HINTING' and > FT_LOAD_NO_AUTOHINT are set. Werner, For the patented hinter, the FT_LOAD_NO_HINTING turns off the hinting. Do you want to change that behavior for the applications that use the patented hinter? Thanks, Sergey ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Force PMingLiU like font do HINTING
> FT_LOAD_NO_HINTING now has a implication: I will do some auto fixing > with the hinting when neccessary unless your also prevent me with > NO_AUTOHINT. ? I fear I don't understand. Please explain what you mean. Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Force PMingLiU like font do HINTING
On 2008-12-05, Werner LEMBERG <[EMAIL PROTECTED]> wrote: > > After some thinking I can imagine that the following works. > > . Add `FT_FACE_FLAG_TRICKY'. If set, the font is tricky. To access > it, add a macro `FT_IS_TRICKY'. [This is a read-only flag.] > > . Change the meaning of `FT_LOAD_NO_HINTING' so that fonts which > always need TrueType instructions (these are fonts which have > FT_FACE_FLAG_TRICKY set) ignore it. > > . Instead of adding a new `FT_LOAD_RAW' flag which would do what > `FT_LOAD_NO_HINTING' currently does, I propose that we get the > behaviour of `raw' loading if both `FT_LOAD_NO_HINTING' and > FT_LOAD_NO_AUTOHINT are set. > This sounds good. FT_LOAD_NO_HINTING now has a implication: I will do some auto fixing with the hinting when neccessary unless your also prevent me with NO_AUTOHINT. ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Force PMingLiU like font do HINTING
That proposal looks right. It, of course, has the advantage of backwards compatability in that current apps and libs will just work once ft is upgraded. Now to deal with the quarter or two metres of snow which fell since I last posted here. [SIGH] If you don't hear from me again I'm probably buried in a snow drift. ;^) -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Force PMingLiU like font do HINTING
> >> So anyone who use freetype or libraries that use freetype (like > >> cairo) will have to be make awared of this problem. I'm not sure > >> how practical this will be. > > > > Graham's suggestion of introducing a flag in FT_Face sounds good. > > If I understand his sugguestion correctly, the user always has to > check the FT_FACE flag for the tricky fonts when he turns on > NO_HINTING. Therefore, the user has to know that there are some > Chinese fonts which are tricky with hinting. OK, you and James have convinced me to change my mind. After some thinking I can imagine that the following works. . Add `FT_FACE_FLAG_TRICKY'. If set, the font is tricky. To access it, add a macro `FT_IS_TRICKY'. [This is a read-only flag.] . Change the meaning of `FT_LOAD_NO_HINTING' so that fonts which always need TrueType instructions (these are fonts which have FT_FACE_FLAG_TRICKY set) ignore it. . Instead of adding a new `FT_LOAD_RAW' flag which would do what `FT_LOAD_NO_HINTING' currently does, I propose that we get the behaviour of `raw' loading if both `FT_LOAD_NO_HINTING' and FT_LOAD_NO_AUTOHINT are set. Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Force PMingLiU like font do HINTING
On 2008-12-04, Werner LEMBERG <[EMAIL PROTECTED]> wrote: > >> So anyone who use freetype or libraries that use freetype (like >> cairo) will have to be make awared of this problem. I'm not sure how >> practical this will be. > > Graham's suggestion of introducing a flag in FT_Face sounds good. > If I understand his sugguestion correctly, the user always has to check the FT_FACE flag for the tricky fonts when he turns on NO_HINTING. Therefore, the user has to know that there are some Chinese fonts which are tricky with hinting. In practics, most of the time, when a user turns on NO_HINTING, he's not intend to make the tricky fonts illegible. Therefore in most situation, the user expectation are broken because they don't expect that there exist such kind of fonts. No hinting on tricky fonts only serve a specific purpose: shows that the fonts are broken without hinting. Only program like ftview need to force real no hinting to display raw rendering result of the fonts. This is why I suggest default to force HINTING on tricky fonts but allow expert users to get complete NO_HINTING. ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Force PMingLiU like font do HINTING
> "Werner" == Werner LEMBERG <[EMAIL PROTECTED]> writes: >> And I'm still seeing PDF files using those fonts often. >> Without hinting. Werner> Why is there no hinting? Poppler (and probably xpdf before it) forces no hinting because it is rendering paper documents and is likely trying to maintain metrics et al exactly as they would print, irregardless of the current scaling, etc. I've tested poppler with a small patch to use FT_LOAD_TARGET_LIGHT instead of FT_LOAD_NO_HINTING and the results are not on par. Try it by either doing a: find -name \*.cc -print0 | xargs -0 \ perl -pi.bak -e 's/FT_LOAD_NO_HINTING/FT_LOAD_TARGET_LIGHT/' in the poppler src before compiling, or perhaps adding like: -DFT_LOAD_NO_HINTING=FT_LOAD_TARGET_LIGHT to CXXFLAGS might work? Then read some pdf documents in evince, linked against that version of libpoppler. The quality is noticeably degraded. I'm only speculating as to their motives, of course, but I'm confident that my hypothesis is correct. Forcing on unpatented for the trickies would be a beneficial addition to freetype. Disabling that force—eg for testing—would best, I expect, be done via an environmental. People do embed these fonts into documents; document rendering does not look correct when the autofitter is used, even the light variation. So we definately need some way to allow the apps to select no hints except for the trickies, with a central location for the list of them. -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Force PMingLiU like font do HINTING
> I feel it is not right to allow such a low-level API as freetype to > override programmer request for the hinting type unless we have > FT_LOAD_NO_HINTING FT_LOAD_NO_HINTING_AND_I_REALLY_MEAN_THAT Hmm. This would be a change in the API which I won't implement. But see Graham's suggestion. > The publicly available list of "tricky" fonts with recommended > hinting setting (may be even per glyph index for some) would be nice > to have. So that a higher level API could benefit. The list isn't `publicly available'. However, I invite you to contribute parsing routines and API functions which can make it configurable. Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Force PMingLiU like font do HINTING
> So anyone who use freetype or libraries that use freetype (like > cairo) will have to be make awared of this problem. I'm not sure how > practical this will be. Graham's suggestion of introducing a flag in FT_Face sounds good. > And I'm still seeing PDF files using those fonts often. Without > hinting. Why is there no hinting? Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] Force PMingLiU like font do HINTING
> > Do those tricky fonts' gasp tables suggest not to use hinting even > > though they look bad without it? > > Good question. One old font which I have, mingli.ttf, doesn't have a > gasp table at all. > > > Or they look bad when a programmer asks to turn the hinting off > > ignoring the gasp table suggestion? > > Such fonts must have hinting activated all the time. I feel it is not right to allow such a low-level API as freetype to override programmer request for the hinting type unless we have FT_LOAD_NO_HINTING FT_LOAD_NO_HINTING_AND_I_REALLY_MEAN_THAT The publicly available list of "tricky" fonts with recommended hinting setting (may be even per glyph index for some) would be nice to have. So that a higher level API could benefit. Thanks, Sergey ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Force PMingLiU like font do HINTING
> Do those tricky fonts' gasp tables suggest not to use hinting even > though they look bad without it? Good question. One old font which I have, mingli.ttf, doesn't have a gasp table at all. > Or they look bad when a programmer asks to turn the hinting off > ignoring the gasp table suggestion? Such fonts must have hinting activated all the time. Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] Force PMingLiU like font do HINTING
I see now. Thank you. Do those tricky fonts' gasp tables suggest not to use hinting even though they look bad without it? Or they look bad when a programmer asks to turn the hinting off ignoring the gasp table suggestion? Thanks, Sergey Tolstov > -Original Message- > From: Werner LEMBERG [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 04, 2008 8:01 AM > To: Sergey Tolstov > Cc: [EMAIL PROTECTED]; [email protected] > Subject: Re: [ft-devel] Force PMingLiU like font do HINTING > > > > How is it possible to decide from the font it is unusable with > > FT_LOAD_NO_HINTING? > > Unfortunately, it isn't. We have a hard-coded list of `tricky' fonts > for this purpose. > > > Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Force PMingLiU like font do HINTING
On 2008-12-04, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I think MingLiU is a commercial font bundled to Microsoft > Windows, and Mozilla can use Microsoft's TrueType rasterizer > supporting patented hinting technology. If there is a case that > the tricky application of unpatented hinting of FreeType2 to > MingLiU, please let me know. > I don't parse this lines. But I was trying to solve a problem that lib poppler cannot display MingLiU font properly with Cairo backend. https://bugs.freedesktop.org/show_bug.cgi?id=15301 poppler forced NO HINTING when open a font face there. In this case, it either has to hardcode a list of 'tricky fonts' inside poppler itself or somehow freetype has to solve the problem for it (or tells poppler hinting is required for some fonts.) So anyone who use freetype or libraries that use freetype (like cairo) will have to be make awared of this problem. I'm not sure how practical this will be. The problem is that most casual freetype user do not aware of these requires hinting fonts, *and they shouldn't*. Then rendering without hinting are useless other than showing how tricky the fonts are. And I'm still seeing PDF files using those fonts often. Without hinting. Moving references are hinting in principle but for these fonts, forced hinting are more practical to me. Since people who know these fonts are in the minority, maybe for the tricky fonts, the default should be forced hinting, unless the user knows what he's doing and switch on a flag to signal a force unhinting_on_tricky_font to show the tricks. ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Force PMingLiU like font do HINTING
> How is it possible to decide from the font it is unusable with > FT_LOAD_NO_HINTING? Unfortunately, it isn't. We have a hard-coded list of `tricky' fonts for this purpose. Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] Force PMingLiU like font do HINTING
Hello, How is it possible to decide from the font it is unusable with FT_LOAD_NO_HINTING? Thank you, Sergey Tolstov > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Werner LEMBERG > Sent: Thursday, December 04, 2008 12:06 AM > To: [EMAIL PROTECTED] > Cc: [email protected] > Subject: Re: [ft-devel] Force PMingLiU like font do HINTING > > > > The "tricky" fonts like PMingLiU need unpatented hinting. Those > > fonts are unusable at all when programmers accidently turns on > > FT_LOAD_NO_HINTING. So I think freetype should force fonts like > > those to ignore FT_LOAD_NO_HINTING. > > This is a fundamental question. My opinion is that shifting of glyph > elements using TrueType instructions clearly is (a kind of) hinting. > In other words, I don't like to change the current behaviour of > FreeType without good reasons. > > However, it might be helpful if FreeType emits a warning message that > the font is probably unusable. Hmm. > > Opinions, please. Maybe most of you disagree, so please chime in. > > > > And detecting of tricky font should be outside of this defines: > > > > #if defined( TT_CONFIG_OPTION_UNPATENTED_HINTING) && \ > > !defined( TT_CONFIG_OPTION_BYTECODE_INTERPRETER ) > > > > otherwise, the fonts are not detected on my debian box. > > This is probably fixed already in the CVS: > > 2008-11-05 Werner Lemberg <[EMAIL PROTECTED]> > > * devel/ftoption.h, include/freetype/config/ftoption.h > [TT_CONFIG_OPTION_BYTECODE_INTERPRETER]: Undefine > TT_CONFIG_OPTION_UNPATENTED_HINTING. This fixes the return > value of `FT_Get_TrueType_Engine_Type' (and makes it work as > documented). Reported in bug #441638 of bugzilla.novell.com. > > Please test. Otherwise, please report the vales of those two macros > on your box. > > > Werner > > > ___ > Freetype-devel mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Force PMingLiU like font do HINTING
On Thu, 04 Dec 2008 11:40:22 +0100 (CET) Werner LEMBERG <[EMAIL PROTECTED]> wrote: >> I'm not sure if unpatented hinting solves the broken shape of >> MingLiU completely. I guess it's better than nothing but not fully, >> and the introduction of the trick of conditional hinting cannot >> close MingLiU issue. > >Mhmm, *theoretically* it should be sufficient. Why do you think it >isn't? I'm sorry, I misunderstood the current situation. When I worked for MingLiU issue in Ghostscript ever (including old FreeType rasterizer), MingLiU had several glyphs (e.g. U+9C02) that their shapes were still broken, although most glyphs are well rasterized (in comparison with no-hinted results). Current FreeType2 rasterizes U+9C02 well. Regards, mpsuzuki ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Force PMingLiU like font do HINTING
> I'm not sure if unpatented hinting solves the broken shape of > MingLiU completely. I guess it's better than nothing but not fully, > and the introduction of the trick of conditional hinting cannot > close MingLiU issue. Mhmm, *theoretically* it should be sufficient. Why do you think it isn't? Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] Force PMingLiU like font do HINTING
Actually here is a better design: at the point of discovery, set a flag in the FT_Face structure. That way, there is no interference between a non-zero error code and the opportunity for the caller to ignore the problem. Graham -Original Message- From: Werner LEMBERG [mailto:[EMAIL PROTECTED] Sent: 04 December 2008 10:21 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [email protected] Subject: Re: [ft-devel] Force PMingLiU like font do HINTING > FreeType can't normally 'emit warning messages' because it is a > library, not an app - it's up to the caller how to deal with > errors. A new, well documented, error code that the caller can > choose to ignore is the way to go, in my opinion. Sounds good. However, which function should return it? Or shall we add a new API function? Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Force PMingLiU like font do HINTING
> FreeType can't normally 'emit warning messages' because it is a > library, not an app - it's up to the caller how to deal with > errors. A new, well documented, error code that the caller can > choose to ignore is the way to go, in my opinion. Sounds good. However, which function should return it? Or shall we add a new API function? Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Force PMingLiU like font do HINTING
Hi, I'm not sure if unpatented hinting solves the broken shape of MingLiU completely. I guess it's better than nothing but not fully, and the introduction of the trick of conditional hinting cannot close MingLiU issue. I think MingLiU is a commercial font bundled to Microsoft Windows, and Mozilla can use Microsoft's TrueType rasterizer supporting patented hinting technology. If there is a case that the tricky application of unpatented hinting of FreeType2 to MingLiU, please let me know. Regards, mpsuzuki On Thu, 4 Dec 2008 09:04:18 - "Graham Asher" <[EMAIL PROTECTED]> wrote: >FreeType can't normally 'emit warning messages' because it is a library, not >an app - it's up to the caller how to deal with errors. A new, well >documented, error code that the caller can choose to ignore is the way to >go, in my opinion. > >Graham > >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On >Behalf Of Werner LEMBERG >Sent: 04 December 2008 08:06 >To: [EMAIL PROTECTED] >Cc: [email protected] >Subject: Re: [ft-devel] Force PMingLiU like font do HINTING > > >> The "tricky" fonts like PMingLiU need unpatented hinting. Those >> fonts are unusable at all when programmers accidently turns on >> FT_LOAD_NO_HINTING. So I think freetype should force fonts like >> those to ignore FT_LOAD_NO_HINTING. > >This is a fundamental question. My opinion is that shifting of glyph >elements using TrueType instructions clearly is (a kind of) hinting. >In other words, I don't like to change the current behaviour of >FreeType without good reasons. > >However, it might be helpful if FreeType emits a warning message that >the font is probably unusable. Hmm. > >Opinions, please. Maybe most of you disagree, so please chime in. > > >> And detecting of tricky font should be outside of this defines: >> >> #if defined( TT_CONFIG_OPTION_UNPATENTED_HINTING) && \ >> !defined( TT_CONFIG_OPTION_BYTECODE_INTERPRETER ) >> >> otherwise, the fonts are not detected on my debian box. > >This is probably fixed already in the CVS: > > 2008-11-05 Werner Lemberg <[EMAIL PROTECTED]> > >* devel/ftoption.h, include/freetype/config/ftoption.h > [TT_CONFIG_OPTION_BYTECODE_INTERPRETER]: Undefine > TT_CONFIG_OPTION_UNPATENTED_HINTING. This fixes the return > value of `FT_Get_TrueType_Engine_Type' (and makes it work as > documented). Reported in bug #441638 of bugzilla.novell.com. > >Please test. Otherwise, please report the vales of those two macros >on your box. > > >Werner > > >___ >Freetype-devel mailing list >[email protected] >http://lists.nongnu.org/mailman/listinfo/freetype-devel > > > >___ >Freetype-devel mailing list >[email protected] >http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] Force PMingLiU like font do HINTING
FreeType can't normally 'emit warning messages' because it is a library, not an app - it's up to the caller how to deal with errors. A new, well documented, error code that the caller can choose to ignore is the way to go, in my opinion. Graham -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Werner LEMBERG Sent: 04 December 2008 08:06 To: [EMAIL PROTECTED] Cc: [email protected] Subject: Re: [ft-devel] Force PMingLiU like font do HINTING > The "tricky" fonts like PMingLiU need unpatented hinting. Those > fonts are unusable at all when programmers accidently turns on > FT_LOAD_NO_HINTING. So I think freetype should force fonts like > those to ignore FT_LOAD_NO_HINTING. This is a fundamental question. My opinion is that shifting of glyph elements using TrueType instructions clearly is (a kind of) hinting. In other words, I don't like to change the current behaviour of FreeType without good reasons. However, it might be helpful if FreeType emits a warning message that the font is probably unusable. Hmm. Opinions, please. Maybe most of you disagree, so please chime in. > And detecting of tricky font should be outside of this defines: > > #if defined( TT_CONFIG_OPTION_UNPATENTED_HINTING) && \ > !defined( TT_CONFIG_OPTION_BYTECODE_INTERPRETER ) > > otherwise, the fonts are not detected on my debian box. This is probably fixed already in the CVS: 2008-11-05 Werner Lemberg <[EMAIL PROTECTED]> * devel/ftoption.h, include/freetype/config/ftoption.h [TT_CONFIG_OPTION_BYTECODE_INTERPRETER]: Undefine TT_CONFIG_OPTION_UNPATENTED_HINTING. This fixes the return value of `FT_Get_TrueType_Engine_Type' (and makes it work as documented). Reported in bug #441638 of bugzilla.novell.com. Please test. Otherwise, please report the vales of those two macros on your box. Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Force PMingLiU like font do HINTING
> The "tricky" fonts like PMingLiU need unpatented hinting. Those > fonts are unusable at all when programmers accidently turns on > FT_LOAD_NO_HINTING. So I think freetype should force fonts like > those to ignore FT_LOAD_NO_HINTING. This is a fundamental question. My opinion is that shifting of glyph elements using TrueType instructions clearly is (a kind of) hinting. In other words, I don't like to change the current behaviour of FreeType without good reasons. However, it might be helpful if FreeType emits a warning message that the font is probably unusable. Hmm. Opinions, please. Maybe most of you disagree, so please chime in. > And detecting of tricky font should be outside of this defines: > > #if defined( TT_CONFIG_OPTION_UNPATENTED_HINTING) && \ > !defined( TT_CONFIG_OPTION_BYTECODE_INTERPRETER ) > > otherwise, the fonts are not detected on my debian box. This is probably fixed already in the CVS: 2008-11-05 Werner Lemberg <[EMAIL PROTECTED]> * devel/ftoption.h, include/freetype/config/ftoption.h [TT_CONFIG_OPTION_BYTECODE_INTERPRETER]: Undefine TT_CONFIG_OPTION_UNPATENTED_HINTING. This fixes the return value of `FT_Get_TrueType_Engine_Type' (and makes it work as documented). Reported in bug #441638 of bugzilla.novell.com. Please test. Otherwise, please report the vales of those two macros on your box. Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
