Re: Question about FT_Var_Axis
Hi Werner, On Wed, Feb 16, 2022 at 10:41 PM Werner LEMBERG wrote: > > > > The fields minimum, def, and maximum are 16.16 fractional values for > > TrueType GX and OpenType variation fonts. For Adobe MM fonts, the > > values are integers. > > > > Does this mean those variables are represented as 16.16 fractional > > numbers or integers in some cases? > > Correct. > > > If so, how can I recognize if it is GX/OpenType fonts or Adobe MM > > fonts? > > Basically, it doesn't make a difference. Either all three variables > `minimum`, `def, and `maximum` are in 16.16 format, or all of them are > integers. It's just a matter how to report them to the user. > > If macro `FT_IS_SFNT` returns false, you have an Adobe MM font. Thanks. Hopefully that would help. > > So I'm wondering if they may have opsz in integers. > > AFAIK, no. Aha. but he said that removing those lines fixes his issue. I can't think of any other reasons so far. but I may be missing something else. > > > Werner -- Akira TAGOH
Question about FT_Var_Axis
Hi,
Well, this may be a dumb question.
I'm reading the API doc for FT_Var_Axis[1]. they say:
The fields minimum, def, and maximum are 16.16 fractional values for
TrueType GX and OpenType variation fonts. For Adobe MM fonts, the
values are integers.
Does this mean those variables are represented as 16.16 fractional
numbers or integers in some cases? If so, how can I recognize if it is
GX/OpenType fonts or Adobe MM fonts?
Someone reported Apple's SF Pro font has wider kerning after the
following code added to fontconfig:
switch (master->axis[i].tag)
{
case FT_MAKE_TAG ('o','p','s','z'):
if (!FcPatternObjectAddDouble (pat, FC_SIZE_OBJECT,
master->axis[i].def / (double) (1U << 16)))
goto bail1;
So I'm wondering if they may have opsz in integers.
Any suggestions would be appreciated.
[1]...https://freetype.org/freetype2/docs/reference/ft2-multiple_masters.html#ft_var_axis
Thanks,
--
Akira TAGOH
Re: [ft-devel] Where is FT_Library reference for FT_MM_Var?
Aha. Thanks! On Thu, Jul 25, 2019 at 9:40 PM Behdad Esfahbod wrote: > > You're not missing anything... > > Face->GlyphSlot->Library... > > On Thu, Jul 25, 2019, 4:47 AM Akira TAGOH wrote: >> >> Hi, >> >> FT_MM_Var instance can be created without FT_Library instance in its >> scope. but FT_Library is required to free it with FT_Done_MM_Var. How >> can it be freed to avoid the memory leak? >> Apparently there are no reference in even FT_Face nor FT_MM_Var though. >> >> If I'm missing something, please let me know. >> >> TIA, >> -- >> Akira TAGOH >> >> ___ >> Freetype-devel mailing list >> Freetype-devel@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/freetype-devel -- Akira TAGOH ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Where is FT_Library reference for FT_MM_Var?
Hi, FT_MM_Var instance can be created without FT_Library instance in its scope. but FT_Library is required to free it with FT_Done_MM_Var. How can it be freed to avoid the memory leak? Apparently there are no reference in even FT_Face nor FT_MM_Var though. If I'm missing something, please let me know. TIA, -- Akira TAGOH ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Something in 2.6.4 broke my windows
On Fri, Jul 8, 2016 at 9:51 AM, Behdad Esfahbod <behdad.esfah...@gmail.com> wrote: > If I may chime in: fontconfig does indeed specify rendering options. Werner > is right that fontconfig itself does not prepare the FT_Face or rendering, > and that is a problem, because our means adding any new config options to > fontconfig requires updating all clients. But fundamentally I think it > makes sense adding "ft-parameters" to fontconfig, the same way that lcd > filter is set for example. I'm not sure if it is/was a good way to have, because it sometimes confuses it could applies per fonts/FT_Face, despite it is applicable per FT_Library. maybe fontconfig should improve something to have a global parameter rather than providing them as in FcPattern. That said, there are still a problem how those are used is up to applications. we may need an upper-layered fundamental and lightweight library to wrap them up and provide proper functionality to applications. > > On Jul 7, 2016 4:34 PM, "Werner LEMBERG" <w...@gnu.org> wrote: >> >> >> >> Just grep'ed through /etc/fonts/conf.d/* , fontconfig allows one to >> >> switching hinting on/off per font, as well as disabling the use of >> >> embedded bitmaps, again, per font. >> > >> > I think you have a fundamental misunderstanding of how fontconfig >> > works. This library is only used to find a best matching font for a >> > given set of constraints. Essentially, it returns a string that holds >> > a font's file name, together with auxiliary information the >> > application might find useful. However, it is the application's job >> > then to process this font name with a call to `FT_Open_Face'! In >> > other words, fontconfig has *zero* control how the application loads >> > the font. It just provides a suggestion, nothing more. >> > >> > The `switch hinting on/off' configuration and similar parameters in >> > fontconfig influence the auxiliary information returned together with >> > the matching font, nothing more. Again, it's the application's job to >> > adhere to this data while calling `FT_Open_Face'. >> >> And even more important: It's also the application's job to call >> `FT_Init_FreeType' to get a proper `FT_Library' object, and fontconfig >> doesn't provide any hints how to control FreeType modules. >> >> >> Werner >> >> ___ >> Freetype-devel mailing list >> Freetype-devel@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/freetype-devel > > > ___ > Freetype-devel mailing list > Freetype-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/freetype-devel > -- Akira TAGOH ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Infinality
On Wed, Mar 4, 2015 at 5:46 AM, Werner LEMBERG w...@gnu.org wrote: I ask because after upgrading to Fedora 21 I can't seem to install it and even with freetype-freeworld the font rendering is, quite honestly, horrible. Blurry and gives me a headache within 10 minutes. Hmm. Then you shouldn't use auto-hinting. The auto-hinting should be disabled by default on Fedora 21. I guess he doesn't use that unless he changes it. what I heard is, the issue was improved by changing the sub-pixel order and the hinting style to the slight... the sub-pixel order and the lcd filter depends on the monitor, if it can be configured by the lower layer or give some information for that, that would be great though. -- Akira TAGOH ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Fontconfig] fontconfig crash for special bdf font
[Cc'ing freetype-devel and Werner] That prop.u.atom is the result of calling FT_BDF_Get_Property though, we are expecting to see the proper atom when prop.type is set to BDF_PROPERTY_TYPE_ATOM. in this case IMHO prop.type should be set to BDF_PROPERTY_TYPE_NONE and returns an error. Werner, any comments for that? On Tue, Jan 28, 2014 at 5:48 PM, Petr Gajdos pgaj...@suse.cz wrote: Hello, a crash in libfontconfig was reported to me. Run $ fc-query startchar.bdf (startchar.bdf is reproducer for buffer overflow in libXfont, see [1]) The problem is following: Breakpoint 3, IA__FcFreeTypeQueryFace (face=0x608dd0, file=0x7fffebb9 startchar.bdf, id=0, blanks=0x0) at fcfreetype.c:1591 1591width = FcIsWidth ((FcChar8 *) prop.u.atom); (gdb) p prop.u.atom $6 = 0x0 Following patch fixes problem for me, but maybe this is not correct place for this check. Index: src/fcstr.c === --- src/fcstr.c.orig2013-10-11 05:10:18.0 +0200 +++ src/fcstr.c 2014-01-28 09:34:05.409800632 +0100 @@ -26,6 +26,7 @@ #include stdlib.h #include ctype.h #include string.h +#include limits.h #ifdef HAVE_REGEX_H #include regex.h #endif @@ -211,6 +212,7 @@ FcChar8c1, c2; if (s1 == s2) return 0; +if (!s1 || !s2) return INT_MAX; FcStrCaseWalkerInit (s1, w1); FcStrCaseWalkerInit (s2, w2); Petr [1] http://cgit.freedesktop.org/xorg/lib/libXfont/commit/?id=4d024ac10f964f6bd372ae0dd14f02772a6e5f63 ___ Fontconfig mailing list fontcon...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/fontconfig -- Akira TAGOH ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
On Fri, Sep 7, 2012 at 11:53 PM, suzuki toshiya mpsuz...@hiroshima-u.ac.jp wrote: Tagoh-san, could you describe more about the advantage to put full CFR support into FreeType? I think, the significant advantage is the minimized cost of the migration from concrete TrueType/OpenType with 64k glyph limitation to the CFR without such limitation. If FreeType supports CFR fully, with builtin fontconfig client etc, just upgrading the older FreeType library to new one would be sufficient. It's very happy scenario. That's true and what I'm mainly concerned. I'm not that familiar with FreeType API though, I guess it's not feasible to apply the modified fonts metrics etc so far, right? this is why I'm requesting some changes according to FreeType3 discussion too. And the point that I think it would be better support CFR in FreeType is, CFR itself could be a font file. even though it's a virtual font that doesn't contain any outline nor bitmap data for glyphs. So it shouldn't break the usage of the existing APIs. In fact, it is not rare to see the posts to freetype (or freetype-devel) mailing list asking a question like why Microsoft Windows can show every Unicode characters by Arial font, but FreeType2 cannot do such?. Often I reply as what you specify on Microsoft Windows is not arial.ttf, it is ..., but I don' think the people asking the question can get any pragmatic solution from my reply (and I guess they may feel as if they are forced to give it up what they wanted to do originally). If FreeType supports CFR directly and fully, I can post the solution for them. It's very happy scenario. Sure. if FreeType has any solution for that, that would be nice and hope it may helps in case we may see in pure Xft-based applications too. but I'm not expecting on this discussion to change the behavior on the existing APIs too. rather I don't think it's needed. However, as I've investigated the the number of applications/libraries assuming as they access concrete font files is not negligible. To support CFR fully without asking some change in these applications/libraries, some fake concrete fonts should be synthesized. I'm afraid that debugging such layer would not be so easy, and it is difficult for FreeType developers to guarantee the faked fonts are safe/stable for current FT2 clients. That's why I proposed to support CFR with another layer, at the beginning. Aha. interesting. well, I'm not at the position to recommend using CFR strongly. so if CFR support can be implemented outside FreeType without missing compatibility to FreeType APIs, I don't have any objections. but just trying to find out if there are any easier way to do it from the POV of application developers. -- Akira TAGOH ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
On Fri, Sep 7, 2012 at 1:40 PM, Werner LEMBERG w...@gnu.org wrote: Not necessarily. It shouldn't be too difficult to provide the necessary hooks so that a small library for handling composite font objects on top of FreeType can reuse FreeType's code. Sure. that sounds reasonable and I didn't mean to have all-in-one. having said, if FreeType allows us to do FT_New_Face(foo.cfr...) instead of having another library with FreeType's hooks, that would be easier to support in applications though. I was presuming to have the sort of callback APIs in FreeType and set it in other library or applications, but anyway. -- Akira TAGOH ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
On Thu, Sep 6, 2012 at 11:32 PM, Chris Liddell chris.lidd...@artifex.com wrote: I just think that Freetype should remain an engine which takes a font from some source, and uses it to to create outline or bitmap glyphs. I would not like to see Freetype getting sucked into loading fonts by name (even if that was done by punting off the fontconfig), or gaining any kind of layout capabilities. But it's what one has to be done for CFR. otherwise someone needs to write another library to support CFR, which may has a lot of duplicate code to FreeType. -- Akira TAGOH ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
On Thu, Aug 30, 2012 at 11:26 PM, Alexei Podtelezhnikov apodt...@gmail.com wrote: By users I mostly mean: - Cairo and Pango (Behdad ?) - Qt - fontconfig Since there are a discussion to support the Composite Font Representation in fontconfig, I'd like to see some APIs that fontconfig let FreeType know what real fonts they may requires or what's the better font if missing because CFR doesn't alllow to have the file path for an real font but PostScript font naming. This would gives us an opportunity to open CFR with FreeType directly and less changes in applications to support it. TIA, -- Akira TAGOH ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
