Re: mmap and Windows

2020-07-24 Thread Nikolay Sivov
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

2018-03-18 Thread Nikolay Sivov
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

2018-03-18 Thread Nikolay Sivov
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

2018-03-18 Thread Nikolay Sivov
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

2018-03-18 Thread Nikolay Sivov
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?

2017-05-17 Thread Nikolay Sivov
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)

2016-07-07 Thread Nikolay Sivov
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?

2016-06-06 Thread Nikolay Sivov
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?

2015-12-03 Thread Nikolay Sivov

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

2015-11-05 Thread Nikolay Sivov

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