Re: mmap and Windows
On Fri, Jul 24, 2020 at 4:25 PM Vincent Torri wrote: > hello > > On Windows, there is no mmap, but there is shared memory support, with > CreateFileMapping and MapViewOfFile. > > If shared mem really improved loading of files on Unix, would you > consider adding shared mem support on Windows too ? > You can already do that on Windows by mapping it yourself and using FT_New_Memory_Face(). > > Vincent Torri > >
Re: [ft-devel] Contribution to freetype
On 3/18/2018 12:05 PM, Werner LEMBERG wrote: > >> Higher level would make use of ranges/language mapping for fallback. >> DirectWrite fallback is modeled very close if not identical to how >> this data is defined in .compositefont xml format. When using >> DirectWrite layout API, application can rely on implicit fonts being >> selected for different script ranges, and you can set specific >> language per range to get more accurate results. Newer versions >> allow user-defined fallback data, and API-wise it's very close to >> what those files provide. > > If I understand you correctly, an application that uses DirectWrite > doesn't need `.compositeFont' files at all, right? What happens with > applications that don't use DirectWrite? No, I don't think they have any value for DirectWrite. If application is not using DirectWrite the only option left is GDI paired with Uniscribe, or .NET (WPF is also working through DirectWrite in modern versions). > AFAIK, Windows offers > composite fonts in its font selection menu like normal fonts... Where do you see this, and under what names are they listed? Standard Win32 font selection dialog is GDI-based, Wordpad does not list anything called "Global User Interface" or "Global Sans Serif", DirectWrite system font enumeration does not include anything obscure like that either. It's possible those files are for WPF/.NET stuff that I'm not familiar with. > >> You can certainly parse and discard information irrelevant to >> freetype, but that will create ambiguity because same script ranges >> could be mapped to different fonts, and only differ in language. > > We are miscommunicating, I think. I talk about taking a > `.compositeFont' file and use it as a font. You are talking about > configurability of `.compositeFont' files, effectively overriding its > contents. I'm talking about data such files provide. Assuming the idea was for freetype to read them directly, and interpret one way or another. > > > Werner > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Contribution to freetype
On 3/18/2018 11:17 AM, Werner LEMBERG wrote: > > Adding support to FreeType would immediately enable *all* applications > to handle them without changes. What should a higher level do in your > opinion? Higher level would make use of ranges/language mapping for fallback. DirectWrite fallback is modeled very close if not identical to how this data is defined in .compositefont xml format. When using DirectWrite layout API, application can rely on implicit fonts being selected for different script ranges, and you can set specific language per range to get more accurate results. Newer versions allow user-defined fallback data, and API-wise it's very close to what those files provide. You can certainly parse and discard information irrelevant to freetype, but that will create ambiguity because same script ranges could be mapped to different fonts, and only differ in language. > > > Werner > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Contribution to freetype
On 3/18/2018 10:25 AM, Werner LEMBERG wrote: > >>> The difficulty is not adding support for the VF format itself but >>> to find a good API that is generic enough for other purposes, too. >>> I'm thinking of handling files like Microsoft's >>> `GlobalSerif.CompositeFont'. Apple and Android provide similar >>> concepts. It's probably not the job of FreeType to digest such >>> composite fonts by itself (you'll need an external XML >>> interpreter); however, it would be very helpful if we have a >>> foundation to provide easy support for such composite fonts. >> >> Could you elaborate? I don't see how .CompositeFont files are >> related to FreeType mission. They are not fonts, and have no font >> data, but only define {range, locale} -> {family} mapping. > > Technically, they are not fonts, but practically they are. It's not > much different to, say, a CFF that consists of a bunch of subfonts. Okay, I guess I'll have to wait and see when this is implemented. My understanding is that it's a way to define mapping for existing fonts, so you still need all referenced font data (which is referenced by NAME names by the way). If e.g. you filter all duplicate entries out, and use resulting font array, it will have no additional information comparing to individual font files. If freetype decided to do a "smarter" mapping, or a fallback rather, using language/codepoint pairs, that's a different thing that sounds higher level, and not fitting to existing API. But again, I'm just curious that's all. > > > Werner > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Contribution to freetype
On 3/18/2018 6:19 AM, Werner LEMBERG wrote: > > The difficulty is not adding support for the VF format itself but to > find a good API that is generic enough for other purposes, too. I'm > thinking of handling files like Microsoft's > `GlobalSerif.CompositeFont'. Apple and Android provide similar > concepts. It's probably not the job of FreeType to digest such > composite fonts by itself (you'll need an external XML interpreter); > however, it would be very helpful if we have a foundation to > provide easy support for such composite fonts. Could you elaborate? I don't see how .CompositeFont files are related to FreeType mission. They are not fonts, and have no font data, but only define {range, locale} -> {family} mapping. > > > 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
Re: [ft-devel] Does FreeType have internal cache mechanism?
On 18.05.2017 5:59, Chester Hsieh wrote: > Hi, I'm Chester. > > I just start to use FreeType engine, and I'm interested in how it works > with cache. > > Since it would be awesome if the FreeType has a internal cache mechanism so > that once we query a character which had already been queried and cached > before, > the performance would be increased. > > But so far as I saw, a FT face would only have one slot for user to > store the latest > query result. If we start to load new character, it would erase the > previous one. > It doesn't seem like it has a internal cache to handle several recent > query results. > > I guess FreeType should have had a internal cache, but I just miss it. > Can you > enlighten me a direction? In my imagination, there should be somewhere even > allowing user to set a cache/heap size to store the recent query results. It does have caching system, it's documented [1]. Cache is not used internally, so you have to manage it yourself, using freetype cache API. [1] https://www.freetype.org/freetype2/docs/reference/ft2-cache_subsystem.html > > > Thank you very much. > > -Chester > > > ___ > 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
Re: [ft-devel] Something in 2.6.4 broke my windows (Re: Freetype-devel Digest, Vol 138, Issue 9)
On 07.07.2016 19:56, Hin-Tak Leung wrote: > I don't seem to have the very beginning of this thread so it is a bit > difficult to see what's going on, anyway, there are > a few things I like to respond to... > > > On Thu, 7/7/16, freetype-devel-requ...@nongnu.org >wrote: > > > From: Nikolaus Waxweiler > >> I think everyone with Wine installed has Microsoft's fonts > :) > > That's not true - BTW, I keep my wine installation quite up to date to wine's > bi-weekly release schedule. My wine install has a couple of > permanently-non-streamed patches, so I upgrade about once a month. Wine has > had its own version of the MS fonts for many years now. They work okay, and > are metric-identical to their genuine counter parts, I think. I do have the > genuine Microsoft fonts in my hard disk, but they are not hooked up to my > display system, at all. > My display system uses the wine version of those fonts. That's misleading. Wine only provides Tahoma, Tahoma Bold, and a couple of symbol fonts - Symbol, Marlett, Wingdings. None of them are hinted, for Tahoma we have embedded bitmaps for certain commonly used sizes. Common scenarios of using MS fonts with Wine are: - installed corefonts package because application explicitly wants certain specific font (original WPF framework for example); - Microsoft Office, that installs a lot of fonts on its own. So no, not everyone with Wine uses MS fonts, but it happens quite often. If previous behaviour for engine v38 will be kept, it's easy to switch over to it, if new code produces disturbing results with some of MS fonts. And if it's unexpected results, it should be fixed imho. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Builtin way to trace freetype API calls?
On 06.06.2016 21:08, Qian Hong wrote: > Hi folks, > > I am working on Wine support for a closed source Win32 application. > This Win32 application bundle a freetype library to process fonts: > > https://www.reasoncoresecurity.com/freetype.dll-0aa9e1bd9e67aa9852df16152a83fcb1e7886d48.aspx > > In order to understand how the application use freetype, I am hoping > to tracing the freetype API calls. Is there something like `export > FREETYPE_DEBUG=1` available so I can read freetype API logs? > > The freetype version is 2.4.3 according to resource dump from > freetype.dll ( $ winedump -j resource freetype.dll ) > > Thank you very much! There's FT2_DEBUG envvar for that, documented in docs/DEBUG. This will only work if library was compiled with enabled tracing support. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] State of TrueType interpreter v38 and up?
On 03.12.2015 21:38, Werner LEMBERG wrote: There is a misunderstanding, see above. `Native' ClearType doesn't do y-only hinting! It's simply that advance width modifications are ignored in Windows at a later stage, namely in the rasterizer. I'm confused. Is this "native ClearType" actually called "Natural ClearType" or "natural advance widths"? MS created too many buzzwords :-( `Native ClearType ' means `no ClearType backwards-compatibility mode' `natural ClearType mode' is DWrite talk for subpixel positioning `natural ClearType widths' is GDI talk for integer pixel positioning with subpixel rendering. Mostly as note to my future self, to summarize those rendering modes in DWrite terms, please correct me if I got anything wrong: DWRITE_RENDERING_MODE_ALIASED No antialiasing (still hinted I think) DWRITE_RENDERING_MODE_GDI_CLASSIC Horizontal direction AA, advances are adjusted. DWRITE_RENDERING_MODE_GDI_NATURAL Horizontal direction AA, advances are not adjusted, but still rounded. DWRITE_RENDERING_MODE_NATURAL Horizontal axis AA, with subpixel positioning, i.e. no snapping to pixel boundaries. DWRITE_RENDERING_MODE_NATURAL_SYMMETRIC Both axis AA, with subpixel positioning DWRITE_RENDERING_MODE_OUTLINE Raw design outlines, irrelevant in this context. In all cases that offer AA, it could be either cleartype or grayscale, it's specified separately from rendering mode. Could it mean that in grayscale mode DWrite NATURAL mode is the same as GDI_NATURAL? I remember that symmetric mode is not supported in freetype yet, so we can forget about it. So the question is what does freetype support from this list, and how can I switch between different modes? I know that one option is a per-library engine version setting, but what does it change in terms of those listed modes (also is there any reason to never switch it back and forth between render operations, performance penalty for example?). ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] rendering mode of Firefox on Windows 10
On 05.11.2015 23:40, Nikolaus Waxweiler wrote: gfx.font_rendering.cleartype_params.force_gdi_classic_for_families indeed contained something by default, I tried to reset to empty string, no change. Also if it really applies to specific family my guess would be that RasterInfo font won't be affected, as it's never on the list by default. Did you restart the browser? :) Sure I did. On every change. And yes, RasterInfo isn't affected by default on my installation, so it's probably Khaled's explanation. ___ 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