Re: resizable ft2demos

[Dmitry Timoshkov]

Alexei Podtelezhnikov  wrote:

> 
> > On May 23, 2020, at 23:43, Anuj Verma  wrote:
> > 
> > Also, the application crashes when the width/height becomes zero.
> > So it should check the values of width/height before 
> > `gr_win32_surface_resize'
> > in the `WM_SIZE' message.
> 
> Thank you and Dmitry for your suggestions and testing. Clearly, the smooth
> resizing is probably not meant to be in Windows by design.

Well, the applications are supposed to render window contents on WM_PAINT,
and on WM_SIZE change the canvas size. In other words, the demo should take
into account that window size could change but a being painted bitmap stay
the same.

> So I will just
> use WM_EXITSIZEMOVE instead of WM_SIZE to remove artists and be done with it.

That would leave the cases of external window resizing and maximizing not
handled.

-- 
Dmitry.

Re: resizable ft2demos

[Dmitry Timoshkov]

Alexei Podtelezhnikov  wrote:

> On Sat, May 23, 2020 at 6:01 AM Dmitry Timoshkov  wrote:
> > In addition to CS_HREDRAW | CS_VREDRAW the WM_SIZE handler should call
> > DefWindowProc() so that default message processing forces a window update.
> > After that the window gets repainted while being resized.
> 
> I've achieved the same effect with CS_HREDRAW | CS_VREDRAW | CS_OWNDC.
> It looks funky as if everything is working without the bitmap data
> being updated.
> Check it out if you have time.

I'd suggest to avoid using CS_OWNDC.

> > I'd suggest to change the demo design, so that it provides a callback
> > to the graphics subsystem for a forced bitmap resize.
> 
> Indeed we need a callback or... Would a longjmp to break the loop work?

That would leave user32 in broken internal state.

-- 
Dmitry.

Re: resizable ft2demos

[Dmitry Timoshkov]

Alexei Podtelezhnikov  wrote:

> Dmitry,
> > It probably needs adding CS_HREDRAW | CS_VREDRAW to ourClass.style.
> 
> That was not enough.

Alexei,

In addition to CS_HREDRAW | CS_VREDRAW the WM_SIZE handler should call
DefWindowProc() so that default message processing forces a window update.
After that the window gets repainted while being resized.

However that leads to the limitation of the demo that can't update its
bitmap contents until the mouse button is released and modal message loop
passes control back to the application code. As the result WM_SIZE calls
gr_win32_surface_resize() however the source bitmap the demo paints to
still has old size and contents, and WM_PAINT gets broken.

While Anuj's approach works I'd personally refrain from using it since
it basically replaces low level user32 code with custom window resizer.
I'd suggest to change the demo design, so that it provides a callback
to the graphics subsystem for a forced bitmap resize.

-- 
Dmitry.

Re: resizable ft2demos

[Dmitry Timoshkov]

Alexei Podtelezhnikov  wrote:

> Dmitry,
> > It probably needs adding CS_HREDRAW | CS_VREDRAW to ourClass.style.
> 
> That was not enough.

I'll try to find time and have a look at it.

-- 
Dmitry.

Re: resizable ft2demos

[Dmitry Timoshkov]

Anuj Verma  wrote:

> The window enters a modal loop whenever you start resizing the window, the
> loop terminates when the mouse is released.
> more on this here:
> https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-entersizemove
> So I think the solution would be to handle the "WM_SYSCOMMAND" message and
> manually resize the window. You can
> also integrate this code. (
> https://sourceforge.net/p/win32loopl/code/ci/default/tree/)

That's clearly an overkill. Probably that code is nice to have for
education purposes, but it should not be needed to get window repainted
when being resized.

-- 
Dmitry.

Re: resizable ft2demos

[Dmitry Timoshkov]

Alexei Podtelezhnikov  wrote:

> I've just made ft2demos resizable under Xlib and GDI. It works quite
> well under X with dynamic repainting during resizing. I was not able
> to achieve this under GDI: the window only repaints once the resizing
> is finished. I would appreciate if somebody more fluent in GDI took a
> look.
> 
> https://git.savannah.gnu.org/cgit/freetype/freetype2-demos.git/commit/?id=95117bcfd06b44331296ff74ea9bae0e3bb3a2ac

It probably needs adding CS_HREDRAW | CS_VREDRAW to ourClass.style.

Thanks for working on this!

-- 
Dmitry.

Re: [ft-devel] Logging library proposal

[Dmitry Timoshkov]

 wrote:

> > Also, obviously there is no point in inventing new dependencies for such a
> > simple thing as logging.
> 
> This is probably where I disagree the most.  Logging/tracing in itself is
> far more than "a simply thing";  it is a tremendous debugging tool (when
> done right).  Instructions that are (1) dead easy to insert and (2) generate
> output that is spot-on for whatever you're looking for in any specific
> situation can make the difference between firing up `gdb' or finding an
> issue within a few seconds.  The current logger is great, but there are far
> better solutions out there.

It would be helpful to list the things that the developers would like
to see changed in the current logger, especially since it's already
great.

-- 
Dmitry.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Logging library proposal

[Dmitry Timoshkov]

 wrote:

> >> Well, as far as I can see, it's exactly as Armin described the
> >> situation: people insert `printf' statements for debugging.  And the 
> >> final code usually missed important debugging calls...
> >
> > How does that justify adding new logging library or changing the current
> > logger code? That sounds more like current tracing statements should be
> > improved.
> 
> May I ask you, Dmitry, what are your concerns with introducing an external
> logger?  Obviously, the goal is to improve the overall situation for
> everyone or (at least) keep things equally fine as they are at the moment.
> Following our discussion here, it seems to me as if changes would affect you
> negatively which should (obviously) be avoided.  Necessity aside (who cares
> if it's necessary if someone else does it (properly) and it has no negative
> effect on anyone), what are negative consequences for you personally or for
> FreeType in general and how can they be avoided/tackled/justified/eased?

There's a simple rule: don't try to fix something that is not broken.
Another consideration would be to leave the decision to people who
actually works with Freetype code, and who is used to work with existing
code base. Also, obviously there is no point in inventing new dependencies
for such a simple thing as logging. IMHO if something is going to be changed
or improved this shouldn't be an external library, and new things should be
left compatible with existing ways of usage.

-- 
Dmitry.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Logging library proposal

[Dmitry Timoshkov]

Werner LEMBERG  wrote:

> >> > For instance has anyone heard anything about the logger during
> >> > last years GSoC?
> >>
> >> The idea to add a logger library is just a few months old.
> > 
> > I mean that even if a GSoC student working on adding some
> > functionality to Freetype (and who apparently was new to Freetype)
> > never complained about the logging functionality then the logging
> > code is not a problem at all.
> 
> Well, as far as I can see, it's exactly as Armin described the
> situation: people insert `printf' statements for debugging.  And the
> final code usually missed important debugging calls...

How does that justify adding new logging library or changing the current
logger code? That sounds more like current tracing statements should be
improved.

-- 
Dmitry.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Logging library proposal

[Dmitry Timoshkov]

Werner LEMBERG  wrote:

> > If a developer believes that she/he needs to change the logger of a
> > project she/he starts to work with - that's good sign that this
> > developer has slightly distorted priorities.
> 
> Well, it is a nice GSoC project IMHO.  Not that I would implement it
> by myself...

Current logging code is perfectly fine IMO, it would be nice to hear
from the long time Freetype contributors whether they would like to
see it changed. Frankly an opinion from an external developer doesn't
qualify and shouldn't be accounted for at all.

> > For instance has anyone heard anything about the logger during last
> > years GSoC?
> 
> The idea to add a logger library is just a few months old.

I mean that even if a GSoC student working on adding some functionality
to Freetype (and who apparently was new to Freetype) never complained
about the logging functionality then the logging code is not a problem
at all. That doesn't mean that the logger shouldn't be improved, but
throwing away current implementation is not a very wise decision.

> > And next (but not last) thing is that it's possible to redirect
> > stderr to a file even in Windows GUI mode.
> 
> Really?  How?  AFAIK, you need some explicit code in the program to do
> the redirection.  If this code is missing, nothing will happen.

Of course the developer needs to write 5-10 lines of code to make it
possible. That doesn't sound like a huge amount of efforts.

-- 
Dmitry.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Logging library proposal

[Dmitry Timoshkov]

Werner LEMBERG  wrote:

> >> I want to work on your project titled "Replace FreeType's tracing
> >> and debugging facilities with an external logging library".  You
> >> have mentioned that there are platforms where stderr is not
> >> accessible.  Can you give me an example of such a platform?
> 
> Windows in GUI mode.

Since I was working on adding support for Windows fonts to Freetype,
and I had to use the Freetype built-in logging facilities probably
I could share a bit my own experience of using it. First of all
the Freetype logger is perfectly sufficient for productive work.
If a developer believes that she/he needs to change the logger of
a project she/he starts to work with - that's good sign that this
developer has slightly distorted priorities. For instance has anyone
heard anything about the logger during last years GSoC? And next
(but not last) thing is that it's possible to redirect stderr to
a file even in Windows GUI mode. So, this platform doesn't need
anything changed from Freetype's logger side of things.

-- 
Dmitry.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [freetype2] master 3ec6465: Explain how to build a PIC-enabled version of FreeType.

[Dmitry Timoshkov]

Werner LEMBERG  wrote:

> >> > What does mean?  Shared libraries are definitely PIC code.  Me not
> >> > understand.
> >> 
> >> As written:
> >> 
> >>   Setting this macro is needed for systems that prohibit address
> >>   fixups, such as BREW.
> >> 
> >> gcc or clang is capable of automatically doing address fixups, BREW is
> >> not.
> >> 
> >> I've just add this piece of information.
> > 
> > This is confusing.  PIC support is a toolchain feature and has
> > nothing to do with support from the source code.  In fact, marking
> > the source directory or module as not PIC capable is confusing even
> > more.
> 
> Yeah, but I don't know how to call this BREW stuff correctly.  It
> seems to be related to the SDK available from
> 
>   https://developer.brewmp.com
> 
> I guess that older versions (or even the current one?) have this
> restriction.
> 
> So maybe
> 
>   s/FT_CONFIG_OPTION_PIC/FT_CONFIG_OPTION_BREWMP/
> 
> is helpful?  Or are there other compilers with that need this
> functionality?

Probably explaining first why such an option is considered at all would be
helpful. For instance compilers/linkers for Windows platform don't support
PIC mode at all and that has never been a problem.

-- 
Dmitry.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [freetype2] master 3ec6465: Explain how to build a PIC-enabled version of FreeType.

[Dmitry Timoshkov]

Werner LEMBERG  wrote:

> > What does mean?  Shared libraries are definitely PIC code.  Me not
> > understand.
> 
> As written:
> 
>   Setting this macro is needed for systems that prohibit address
>   fixups, such as BREW.
> 
> gcc or clang is capable of automatically doing address fixups, BREW is
> not.
> 
> I've just add this piece of information.

This is confusing. PIC support is a toolchain feature and has nothing to do
with support from the source code. In fact, marking the source directory or
module as not PIC capable is confusing even more.

-- 
Dmitry.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] strict aliasing

[Dmitry Timoshkov]

Werner LEMBERG  wrote:

> My preferred solution would be to use something similar to the fix in
> issue #27441, given that unions is not the right way to go for C++,
> according to advice I've seen in the internet – and I want to preserve
> the ability that a C++ compiler can compile FreeType.

Probably a most easy and effective "fix" for this kind of bugs is to add
-fno-strict-aliasing flag, just like other system level libraries do.

-- 
Dmitry.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Latin, Cyrillic, and Greek fonts questions

[Dmitry Timoshkov]

Hi Werner,

Werner LEMBERG w...@gnu.org wrote:

 I have two questions:
 
   1.  Do Cyrillic or Greek outline fonts exist which don't contain the
   ASCII characters a-z, A-Z, and 0-9?

I can speek only about Cyrillic here, but I haven't seen any cyrillic font
without latin letters and 0-9 digits. It simply doesn't make sence since
often texts have mixed cyrillic/latin-based context.

   2.  Do you know of any Cyrillic or Greek fonts where the lowercase
   and uppercase glyph heights differ from the heights of the Latin
   glyphs?  Given that all three alphabets share e.g. characters
   `A' and `o', this rather sounds implausible, but who knows...

Again regarding Cyrillic that's not the case, and very often for instance
truetype fonts (Arial is one of them) have cyrillic glyphs as a composite
of the existing latin ones with a transform/composition applied: an example
is: Я - R with a mirroring transform attached.

-- 
Dmitry.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Latin, Cyrillic, and Greek fonts questions

[Dmitry Timoshkov]

Denis Jacquerye denis.jacque...@daltonmaag.com wrote:

 Some designers have Cyrillic with slightly taller x-height (sometimes by a
 minute amount) to adjust the squareness of the script relative to the
 roundness of Latin, even glyphs that are usually components have adjusted
 outlines. Other designers recommend components but different spacing
 (slightly larger side bearings) instead of x-height to address the issue.

Could you please name a couple of fonts that behave like that?

-- 
Dmitry.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Question about charset.

[Dmitry Timoshkov]

Johnson Y. Yan yinsen_...@foxitsoftware.com wrote:

 I mean that it likes 
 
 #define FT_WinFNT_ID_CP12520
 #define FT_WinFNT_ID_DEFAULT   1
 #define FT_WinFNT_ID_SYMBOL2
 #define FT_WinFNT_ID_MAC  77
 #define FT_WinFNT_ID_CP932   128
 #define FT_WinFNT_ID_CP949   129
 #define FT_WinFNT_ID_CP1361  130
 #define FT_WinFNT_ID_CP936   134
 #define FT_WinFNT_ID_CP950   136
 #define FT_WinFNT_ID_CP1253  161
 #define FT_WinFNT_ID_CP1254  162
 #define FT_WinFNT_ID_CP1258  163
 #define FT_WinFNT_ID_CP1255  177
 #define FT_WinFNT_ID_CP1256  178
 #define FT_WinFNT_ID_CP1257  186
 #define FT_WinFNT_ID_CP1251  204
 #define FT_WinFNT_ID_CP874   222
 #define FT_WinFNT_ID_CP1250  238
 #define FT_WinFNT_ID_OEM 255
 
 defined in ftwinfnt.h, can these work for other type fonts, type1, CFF and so 
 on.

These values are win32 internal code page identifiers, and have nothing
to do with other OS's or font formats in general.

-- 
Dmitry.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Fast bisecting BBox_Cubic_Check

[Dmitry Timoshkov]

Alexei Podtelezhnikov apodt...@gmail.com wrote:

  Looks good, thanks!  How do you check that the new code produces
  identical bboxes?
 
 I used src/tools/test_bbox.c. I had to add some hexadecimal output,
 because the original output was just identical. As you'll see below
 the results are not bit-identical. I wish I knew the true answer. One
 possibility is to add a third outline to test_bbox with known
 theoretical bbox.
 
 OLD CODE:
 [apodtele@prosha ft-test]$ ./bbox
 outline #1
 time =  0.13 cbox = [-37.88 535.32 455.89 786.22]
 cbox_hex =  [FFDA1F9E 021750FF 01C7E381 0312387F]
 time =  3.14 bbox = [115.62 535.32 412.08 672.25]
 bbox_hex =  [00739FDF 021750FF 019C14EE 02A04028]
...
 NEW CODE:
 [apodtele@prosha ft-test]$ ./bbox
 outline #1
 time =  0.13 cbox = [-37.88 535.32 455.89 786.22]
 cbox_hex =  [FFDA1F9E 021750FF 01C7E381 0312387F]
 time =  7.34 bbox = [115.62 535.32 412.08 672.25]
 bbox_hex =  [00739F5D 021750FF 019C143F 02A03FD5]

You may try to change precision from .2f to print more digits
after the point (probably just completely remove the limit).

-- 
Dmitry.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Patch to fix the ttsubpix implementation

[Dmitry Timoshkov]

Behdad Esfahbod beh...@behdad.org wrote:

  Guys, I'm not a hardcore C coder, and don't know about private RAM
  allocation per-process, and how that's impacted by putting structs
  inside of .c files instead of .h files.  Of course, I'm willing to
  understand why that's the case, I just don't necessarily know some
  of that stuff.  So, likely all code that I write is going to have
  the potential of being implemented more efficiently by people with
  more experience in coding.  I don't really want to burden you guys
  with babying me through the best way to implement code, but if you
  can nudge me in the right direction sometimes that would be helpful.
 
  If you have some time to read, this is a good place to start:
 
http://www.akkadia.org/drepper/dsohowto.pdf
  
  Reading that paper made my head hurt :) It's full of descriptions of
  various tricks and jumps through the hoops how to avoid limitations of
  dynamic libraries implementation under Linux which is based on old,
  questionable and inefficient design. This really has nothing to do
  with the problem David has fixed.
 
 There's an expression that programmers use: think low-level, write
 high-level.  The point being that to write good code one has to understand
 how the compiler and the machine work, but then write high-level code that
 translates to good machine code.  What David found was indeed different:
 defining variables in a header file is a basic mistake of C / C++ programming,
 but when you get past that, making sure that your variable don't end up
 consuming private per-process memory (specially when dealing with strings) has
 a lot to do with understanding how the linker works, and what is dealt with in
 the mentioned paper.

I'd argue that this document is hightly gcc/ELF/Linux specific, and may not
apply to other platforms, so it can't be considered or even recommended as
a general set of rules for a programmer, especially since Freetype is a
library that's used on many different platforms.

A programmer doesn't need to know about flawed dynamic linker design when
his mistake is just in placing a relatively large data structure in a shared
.h file instead of the .c file it's actually being used.

-- 
Dmitry.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Patch to fix the ttsubpix implementation

[Dmitry Timoshkov]

Behdad Esfahbod beh...@behdad.org wrote:

  Guys, I'm not a hardcore C coder, and don't know about private RAM
  allocation per-process, and how that's impacted by putting structs
  inside of .c files instead of .h files.  Of course, I'm willing to
  understand why that's the case, I just don't necessarily know some
  of that stuff.  So, likely all code that I write is going to have
  the potential of being implemented more efficiently by people with
  more experience in coding.  I don't really want to burden you guys
  with babying me through the best way to implement code, but if you
  can nudge me in the right direction sometimes that would be helpful.
 
 If you have some time to read, this is a good place to start:
 
   http://www.akkadia.org/drepper/dsohowto.pdf

Reading that paper made my head hurt :) It's full of descriptions of
various tricks and jumps through the hoops how to avoid limitations of
dynamic libraries implementation under Linux which is based on old,
questionable and inefficient design. This really has nothing to do
with the problem David has fixed.

-- 
Dmitry.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] FreeType patches to support amalgamation

[Dmitry Timoshkov]

Vinnie thev...@yahoo.com wrote:

 With an amalgamated version of FreeType I can add support for hinted
 fonts to my open source offerings, while including the entire FreeType
 distribution as a single source file instead of a large tree.

How about providing a single precompiled library file for these people?

-- 
Dmitry.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] FreeType patches to support amalgamation

[Dmitry Timoshkov]

Vinnie thev...@yahoo.com wrote:

  How about providing a single precompiled library file for these people?
 
 That would only work for one particular build environment, and within that
 environment, only one target. For example, debug, or release. Or 32 bit versus
 64 bit. If the resulting FreeType library were misused, the absence of sources
 would complicate debugging.

That's true that compiling something slightly more complex than Hello World!
requires some efforts.

-- 
Dmitry.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Free tyep font - query

[Dmitry Timoshkov]

jeyasathya jeyasathy...@jasmin-infotech.com wrote:


It will be helpful if you support us as early as possible. Kindly let me
know if queries is not clear.


This is not really a place for this kind of queries. Freetype project
already provides you with sample code and documentation. If you can't
understand what that code does or how to change it for your own needs
that's a different problem which doesn't belong here.

--
Dmitry.


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Re: [ft] Re: Few typefaces are not loading

[Dmitry Timoshkov]

Noorul Sahabudeen noorulsahabudeen...@gmail.com wrote:

   For few fonts like Cambria face is Null and for few fonts line 
webdings i am not getting any characters.


You need to select an appropriate charmap:

FT_Select_Charmap(face, FT_ENCODING_UNICODE); // or FT_ENCODING_MS_SYMBOL

--
Dmitry.


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Re: [ft] Re: Few typefaces are not loading

[Dmitry Timoshkov]

Noorul Sahabudeen noorulsahabudeen...@gmail.com wrote:

   I am using Windows. Freetype2 is not loading few fonts like 
Windings, Webdings, Cambria and some .TTC files also.


I have no Cambria here under XP, but Freetype works just fine with
other fonts I tested with.


Can anyone check and give me some solution.


Please attach a maximally simplified source you are using.

--
Dmitry.


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Regarding Position-Independent-Code, modules, etc..

[Dmitry Timoshkov]

Oran Agra o...@monfort.co.il wrote:


Waiting to see your suggested solution.


I'd once again suggest to stop making FreeType code ugly and force
broken platforms to upgrade their compiler toolchain instead.

Especially since it's been stated that not all code was/will be
converted. There is no need to do the compiler/linker job in
the source code.

--
Dmitry.


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] TrueType font that is not loaded by freetype

[Dmitry Timoshkov]

Albert Astals Cid [EMAIL PROTECTED] wrote:

Hi, the attached font is not loaded by freetype but it is loaded by FontForge 
so it seems the font is either correct or not that broken to not be able to 
be read.


I have not tried debugging the problem but if i'm given a pointer i could try 
it and see what i can do, but i can't promise anything as i've done 0 work 
with fonts stuff.


JFYI, Windows XP SP3 reports that the font is broken, and refuses to load it.

--
Dmitry.


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] TrueType font that is not loaded by freetype

[Dmitry Timoshkov]

Dmitry Timoshkov [EMAIL PROTECTED] wrote:


Albert Astals Cid [EMAIL PROTECTED] wrote:

Hi, the attached font is not loaded by freetype but it is loaded by FontForge 
so it seems the font is either correct or not that broken to not be able to 
be read.


I have not tried debugging the problem but if i'm given a pointer i could try 
it and see what i can do, but i can't promise anything as i've done 0 work 
with fonts stuff.


JFYI, Windows XP SP3 reports that the font is broken, and refuses to load it.


Looks like there are 2 reasons of that:
1. Missing OS/2 table (this is the real reason why Windows doesn't load it)
2. Font header reports 9 tables, and the 9th table seems to be broken:
offset 0x3EC6A78B, length 0x5F0F3CF5
Once I patch the font to report 8 tables, FreeType loads it without a problem.

--
Dmitry.


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Understanding Type1 fonts

[Dmitry Timoshkov]

[EMAIL PROTECTED] wrote:


However, it is theoretically possible for AFM  PFM
to have the metrics which is different from PFA  PFB.
I don't know recent utilization is popular.


AFM and PFM files also may contain kerning data which is not
available in .pfa/.pfb files.

--
Dmitry.


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Understanding Type1 fonts

[Dmitry Timoshkov]

Donn [EMAIL PROTECTED] wrote:


On Wednesday, 09 January 2008 11:11:00 Dmitry Timoshkov wrote:

AFM and PFM files also may contain kerning data which is not
available in .pfa/.pfb files.

Okay so potentially, -1 on the vote. Making AFM and PFM important again.

How important do you thing that extra data is on a modern Gnu/Linux system. 
Without going into C code, to what extent does Freetype work around when it 
does not find a metric file for a given font file?


FreeType doesn't care about additional data in afm/pfm files, it's applications
and users who care. For instance a decent typesetting application must require
reasonable metrics and kerning data to be available for professional fonts.

--
Dmitry.


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Understanding Type1 fonts

[Dmitry Timoshkov]

Donn [EMAIL PROTECTED] wrote:

So, I take it you would advise that the corresponding metric files should be 
in the same folder as the glyph files?


It depends on how applications handle that.

--
Dmitry.


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] Incomplete cmap table for platform 0 (Apple Unicode)

[Dmitry Timoshkov]

Hello,

http://bugs.winehq.org/show_bug.cgi?id=9840 has a ttf font attached
to it which can be perfectly displayed in Windows, but Wine is not able
to actually show any character using this font, only 'c' is displayed.
That's because Freetype selects first unicode cmap table which happens
to be with platform id 0 (Apple Unicode), and that cmap table is incomplete
(or truncated). cmap tables for other platforms (1 and 3) are good, and
making Freetype ignore cmap with platform id 0 makes the font display
properly in Wine's notepad.

Attached is the hack that makes Freetype ignore cmaps with platform id 0.

What Freetype developers think about this problem?

--
Dmitry.
diff -uprN freetype2/src/sfnt/ttcmap.c freetype2/src/sfnt/ttcmap.c
--- freetype2/src/sfnt/ttcmap.c 2007-06-13 17:05:55.0 +0900
+++ freetype2/src/sfnt/ttcmap.c 2007-09-30 20:45:39.0 +0900
@@ -2284,6 +2284,20 @@
  charmap.encoding= FT_ENCODING_NONE;  /* will be filled later */
  offset  = TT_NEXT_ULONG( p );

+  FT_TRACE2(( found cmap platform_id %u, encoding_id %u\n,
+  charmap.platform_id, charmap.encoding_id ));
+
+  /* cmap tables with platform_id == Apple Unicode sometimes are
+   * incomplete in comparison to other tables.
+   * FIXME: perhaps fallback to this table if no other table exists.
+   */
+  if ( charmap.platform_id == 0 ) /* Apple Unicode */
+  {
+FT_TRACE2(( ignoring Apple Unicode encoding\n ));
+continue;
+  }
+  
+

  if ( offset  offset = face-cmap_size - 2 )
  {
FT_Byte* volatile  cmap   = table + offset;
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Incomplete cmap table for platform 0 (Apple Unicode)

[Dmitry Timoshkov]

[EMAIL PROTECTED] wrote:


Your patch assumes that Apple Unicode cmap is often
broken but others are more reliable, but I'm afraid
that this is not generic assumption.


That was really a hack to show that other cmap tables actually
work better for that font. Of course other fonts can have cmap
tables for other platfoms rather than 0 broken.


Excuse me, do you think the selection of best cmap is
the role of FreeType? I think, FreeType2 provides an
API for users to select cmap subtable by the pair of
platformID  platform-specificID.
http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html

I think, it's better for Wine to have internal priorities
of prefered cmap and try to load from the best to
the worst. For example, thinking about UCS-4 capable fonts
(like SURSONG.TTF or SIMSUN-EXTB.TTF). Such fonts have
cmap subtables for Microsoft UCS2, and Microsoft UCS4.
Usually Microsoft UCS4 cmap subtable appears after MS
UCS2 cmap subtable. So, if we let FreeType to choose the
cmap subtable automatically, we cannot reach Microsoft
UCS4 cmap subtable, even if we ignore Apple Unicode.
From the viewpoint of compatibility with Microsoft products,
it's not good idea.

So, I think, it's better for Wine to have internal priorities
of prefered cmap subatble and choose the best cmap subatble
by himself. How do you think of?


Wine uses FT_Select_Charmap API to select either FT_ENCODING_UNICODE,
FT_ENCODING_MS_SYMBOL or FT_ENCODING_APPLE_ROMAN when appropriate.
So that's actually Freetype's responsibility to choose the best/correct/
working charmap table in that case.

Yes, Wine can arrange some kind of cmap priorites, what if some of preferred
cmap tables is broken? How an application can decide which cmap table is better
without digging into internal cmap data? Shouldn't that be a responsibility of
Freetype to ignore incomplete/broken cmaps, especially since it already parses
cmap tables and can easily decide which one is better?

--
Dmitry.


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] PATCH: Do not do further load font attempts if a previous attempt has failed but returned error FNT_Err_Invalid_File_Format

[Dmitry Timoshkov]

Hello,

this patch speeds up a lot programs that scan a directory of files and load
every font they find using the code like below:

face_index = 0;
while (1)
{
if ((ft_err = FT_New_Face(ft_library, fnt_name, face_index, ft_face)))
break;
...
FT_Done_Face(ft_face);
face_index++;
}

The patch avoids trying to load a file as a font if a previous attempt has
failed but returned error FNT_Err_Invalid_File_Format, i.e. file format has
been recognized but no fonts found in the file. That's a different error to
FNT_Err_Unknown_File_Format.

Changelog:
* src/winfonts/winfnt.c (fnt_face_get_dll_font): Return error
FNT_Err_Invalid_File_Format if file format was recognized but
file doesn't contain any FNT(NE) or RT_FONT(PE) resources.
Add verbose debug logs to make it easier to debug failing load
attempts.
* src/winfonts/winfnt.c (FNT_Face_Init): A single FNT font can't
contain more than 1 face, so return an error if requested face
index is more than 0.
Do not do further load font attempts if a previous attempt has
failed but returned error FNT_Err_Invalid_File_Format, i.e. file
format has been recognized but no fonts found in the file.

diff -up freetype2/src/winfonts/winfnt.c freetype2/src/winfonts/winfnt.c
--- freetype2/src/winfonts/winfnt.c Sun Jun 17 12:46:50 2007
+++ freetype2/src/winfonts/winfnt.c Tue Jun 19 03:53:03 2007
@@ -343,7 +343,7 @@
 if ( !font_count || !font_offset )
 {
   FT_TRACE2(( this file doesn't contain any FNT resources!\n ));
-  error = FNT_Err_Unknown_File_Format;
+  error = FNT_Err_Invalid_File_Format;
   goto Exit;
 }
 
@@ -413,6 +413,7 @@
  pe32_header.size_of_optional_header != 0xe0 /* FIXME */ ||
  pe32_header.magic32 != 0x10b)
 {
+  FT_TRACE2(( this file has invalid PE header\n ));
   error = FNT_Err_Invalid_File_Format;
   goto Exit;
 }
@@ -435,6 +436,7 @@
 goto Found_rsrc_section;
 }
 
+FT_TRACE2(( this file doesn't contain any resources\n ));
 error = FNT_Err_Invalid_File_Format;
 goto Exit;
 
@@ -553,6 +555,13 @@
 }
   }
 
+  if ( !face-root.num_faces )
+  {
+FT_TRACE2(( this file doesn't contain any RT_FONT resources\n ));
+error = FNT_Err_Invalid_File_Format;
+goto Exit;
+  }
+
   if ( face_index = face-root.num_faces )
   {
 error = FNT_Err_Bad_Argument;
@@ -681,12 +690,18 @@
 
 /* try to load font from a DLL */
 error = fnt_face_get_dll_font( face, face_index );
-if ( error )
+if ( error == FNT_Err_Unknown_File_Format )
 {
   /* this didn't work; try to load a single FNT font */
   FNT_Font  font;
 
 
+  if ( face_index  0 )
+  {
+error = FNT_Err_Bad_Argument;
+goto Exit;
+  }
+
   if ( FT_NEW( face-font ) )
 goto Exit;
 
@@ -697,9 +712,10 @@
   font-fnt_size = stream-size;
 
   error = fnt_font_load( font, stream );
-  if ( error )
-goto Fail;
 }
+
+if ( error )
+  goto Fail;
 
 /* we now need to fill the root FT_Face fields */
 /* with relevant information   */




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] PATCH: builds/win32/ftdebug.c: Unify debug level handling with other platforms

[Dmitry Timoshkov]

Hello,

all other platforms allow the debug level to be between 0 and 7.

Changelog:
* builds/win32/ftdebug.c: Unify debug level handling with other platforms.

--- freetype2/builds/win32/ftdebug.cThu Jun 14 09:13:26 2007
+++ freetype2/builds/win32/ftdebug.cFri Jun 15 07:08:40 2007
@@ -175,7 +175,7 @@
   if ( *p )
   {
 level = *p++ - '0';
-if ( level  0 || level  6 )
+if ( level  0 || level  7 )
   level = -1;
   }
 




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] PATCH: Add support for loading bitmap .fon files in PE format

[Dmitry Timoshkov]

Werner LEMBERG [EMAIL PROTECTED] wrote:


please find the attached patch, any comments are welcome.


This looks good!  Some issues:

 . Please send me a PE font for testing.

 . If possible, stay within the 80-characters-per-line limit.

 . A more detailed ChangeLog entry would simplify my life
   enormously...


Thanks for reviewing the patch! I'm attaching an updated version that should
address your concerns. Also I'm attaching font_dll.tar.bz2 which includes
wine_fnt.fon in PE format with the sources taken from the Wine project and
build.bat in case you need to rebuild the dll. Another font in PE format
I'm aware of is included with Adobe Photoshop.

Changelog:
* src/winfonts/winfnt.h: Add necessary structures for PE resource
parsing.
(WinPE32_HeaderRec): New structure.
(WinPE32_SectionRec): New structure.
(WinPE_RsrcDirRec): New structure.
(WinPE_RsrcDirEntryRec): New structure.
(WinPE_RsrcDataEntryRec): New structure.
* src/winfonts/winfnt.c (fnt_face_get_dll_font): Add support for
loading bitmap .fon files in PE format.

--
Dmitry.

font_dll.tar.bz2
Description: Binary data

diff -up freetype2/ChangeLog.21 freetype2/ChangeLog.21
--- freetype2/ChangeLog.21  Mon Mar 12 01:23:08 2007
+++ freetype2/ChangeLog.21  Thu Jun 14 11:46:25 2007
@@ -6391,7 +6391,7 @@
* include/freetype/internal/fnttypes.h (WinFNT_HeaderRec): Increase
size of `reserved2' to avoid memory overwrites.

-2003-01-08  Huw Dawies  [EMAIL PROTECTED]
+2003-01-08  Huw Davies  [EMAIL PROTECTED]

* src/winfonts/winfnt.c (winfnt_header_fields): Read 16 bytes into
`reserved2', not `reserved'.
Only in freetype2/objs: debug_st
diff -up freetype2/src/winfonts/winfnt.c freetype2/src/winfonts/winfnt.c
--- freetype2/src/winfonts/winfnt.c Mon Jun 11 10:18:34 2007
+++ freetype2/src/winfonts/winfnt.c Thu Jun 14 11:50:57 2007
@@ -6,6 +6,8 @@
/* */
/*  Copyright 1996-2001, 2002, 2003, 2004, 2006, 2007 by   */
/*  David Turner, Robert Wilhelm, and Werner Lemberg.  */
+/*  Copyright 2003 Huw D M Davies for Codeweavers  */
+/*  Copyright 2007 Dmitry Timoshkov for Codeweavers*/
/* */
/*  This file is part of the FreeType project, and may only be used,   */
/*  modified, and distributed under the terms of the FreeType project  */
@@ -62,6 +64,81 @@
FT_FRAME_END
  };

+  static const FT_Frame_Field  winpe32_header_fields[] =
+  {
+#undef  FT_STRUCTURE
+#define FT_STRUCTURE  WinPE32_HeaderRec
+
+FT_FRAME_START( 248 ),
+  FT_FRAME_ULONG_LE ( magic ), /* PE00 */
+  FT_FRAME_USHORT_LE ( machine ), /* 0x014c - i386 */
+  FT_FRAME_USHORT_LE ( number_of_sections ),
+  FT_FRAME_SKIP_BYTES( 12 ),
+  FT_FRAME_USHORT_LE ( size_of_optional_header ),
+  FT_FRAME_SKIP_BYTES( 2 ),
+  FT_FRAME_USHORT_LE ( magic32 ), /* 0x10b */
+  FT_FRAME_SKIP_BYTES( 110 ),
+  FT_FRAME_ULONG_LE ( rsrc_virtual_address ),
+  FT_FRAME_ULONG_LE ( rsrc_size ),
+  FT_FRAME_SKIP_BYTES( 104 ),
+FT_FRAME_END
+  };
+
+  static const FT_Frame_Field  winpe32_section_fields[] =
+  {
+#undef  FT_STRUCTURE
+#define FT_STRUCTURE  WinPE32_SectionRec
+
+FT_FRAME_START( 40 ),
+  FT_FRAME_BYTES ( name, 8 ),
+  FT_FRAME_SKIP_BYTES( 4 ),
+  FT_FRAME_ULONG_LE ( virtual_address ),
+  FT_FRAME_ULONG_LE ( size_of_raw_data ),
+  FT_FRAME_ULONG_LE ( pointer_to_raw_data ),
+  FT_FRAME_SKIP_BYTES( 16 ),
+FT_FRAME_END
+  };
+
+  static const FT_Frame_Field  winpe_rsrc_dir_fields[] =
+  {
+#undef  FT_STRUCTURE
+#define FT_STRUCTURE  WinPE_RsrcDirRec
+
+FT_FRAME_START( 16 ),
+  FT_FRAME_ULONG_LE ( characteristics ),
+  FT_FRAME_ULONG_LE ( time_date_stamp ),
+  FT_FRAME_USHORT_LE ( major_version ),
+  FT_FRAME_USHORT_LE ( minor_version ),
+  FT_FRAME_USHORT_LE ( number_of_named_entries ),
+  FT_FRAME_USHORT_LE ( number_of_id_entries ),
+FT_FRAME_END
+  };
+
+  static const FT_Frame_Field  winpe_rsrc_dir_entry_fields[] =
+  {
+#undef  FT_STRUCTURE
+#define FT_STRUCTURE  WinPE_RsrcDirEntryRec
+
+FT_FRAME_START( 8 ),
+  FT_FRAME_ULONG_LE ( name ),
+  FT_FRAME_ULONG_LE ( offset ),
+FT_FRAME_END
+  };
+
+  static const FT_Frame_Field  winpe_rsrc_data_entry_fields[] =
+  {
+#undef  FT_STRUCTURE
+#define FT_STRUCTURE  WinPE_RsrcDataEntryRec
+
+FT_FRAME_START( 16 ),
+  FT_FRAME_ULONG_LE ( offset_to_data ),
+  FT_FRAME_ULONG_LE ( size ),
+  FT_FRAME_ULONG_LE ( code_page ),
+  FT_FRAME_ULONG_LE ( reserved ),
+FT_FRAME_END
+
+  };
+
  static const FT_Frame_Field  winfnt_header_fields[] =
  {
#undef  FT_STRUCTURE
@@ -213,6 +290,7 @@
  /* yes, now look for an NE header in the file */
  WinNE_HeaderRec  ne_header;

+  FT_TRACE2(( MZ signature found\n ));

  if ( FT_STREAM_SEEK

[ft-devel] PATCH: Add support for loading bitmap .fon files in PE format

[Dmitry Timoshkov]

Hello,

please find the attached patch, any comments are welcome.

Changelog:
   Add support for loading bitmap .fon files in PE format.

Thanks.

--
Dmitry.
diff -upr freetype2/ChangeLog.21 freetype2/ChangeLog.21
--- freetype2/ChangeLog.21  2007-03-12 15:24:39.0 +0800
+++ freetype2/ChangeLog.21  2007-06-13 17:09:16.0 +0900
@@ -6391,7 +6391,7 @@
* include/freetype/internal/fnttypes.h (WinFNT_HeaderRec): Increase
size of `reserved2' to avoid memory overwrites.

-2003-01-08  Huw Dawies  [EMAIL PROTECTED]
+2003-01-08  Huw Davies  [EMAIL PROTECTED]

* src/winfonts/winfnt.c (winfnt_header_fields): Read 16 bytes into
`reserved2', not `reserved'.
diff -upr freetype2/src/winfonts/winfnt.c freetype2/src/winfonts/winfnt.c
--- freetype2/src/winfonts/winfnt.c 2007-06-13 17:05:55.0 +0900
+++ freetype2/src/winfonts/winfnt.c 2007-06-13 17:49:33.0 +0900
@@ -6,6 +6,8 @@
/* */
/*  Copyright 1996-2001, 2002, 2003, 2004, 2006, 2007 by   */
/*  David Turner, Robert Wilhelm, and Werner Lemberg.  */
+/*  Copyright 2003 Huw D M Davies for Codeweavers  */
+/*  Copyright 2007 Dmitry Timoshkov for Codeweavers*/
/* */
/*  This file is part of the FreeType project, and may only be used,   */
/*  modified, and distributed under the terms of the FreeType project  */
@@ -62,6 +64,81 @@
FT_FRAME_END
  };

+  static const FT_Frame_Field  winpe32_header_fields[] =
+  {
+#undef  FT_STRUCTURE
+#define FT_STRUCTURE  WinPE32_HeaderRec
+
+FT_FRAME_START( 248 ),
+  FT_FRAME_ULONG_LE ( magic ), /* PE00 */
+  FT_FRAME_USHORT_LE ( machine ), /* 0x014c - i386 */
+  FT_FRAME_USHORT_LE ( number_of_sections ),
+  FT_FRAME_SKIP_BYTES( 12 ),
+  FT_FRAME_USHORT_LE ( size_of_optional_header ),
+  FT_FRAME_SKIP_BYTES( 2 ),
+  FT_FRAME_USHORT_LE ( magic32 ), /* 0x10b */
+  FT_FRAME_SKIP_BYTES( 110 ),
+  FT_FRAME_ULONG_LE ( rsrc_virtual_address ),
+  FT_FRAME_ULONG_LE ( rsrc_size ),
+  FT_FRAME_SKIP_BYTES( 104 ),
+FT_FRAME_END
+  };
+
+  static const FT_Frame_Field  winpe32_section_fields[] =
+  {
+#undef  FT_STRUCTURE
+#define FT_STRUCTURE  WinPE32_SectionRec
+
+FT_FRAME_START( 40 ),
+  FT_FRAME_BYTES ( name, 8 ),
+  FT_FRAME_SKIP_BYTES( 4 ),
+  FT_FRAME_ULONG_LE ( virtual_address ),
+  FT_FRAME_ULONG_LE ( size_of_raw_data ),
+  FT_FRAME_ULONG_LE ( pointer_to_raw_data ),
+  FT_FRAME_SKIP_BYTES( 16 ),
+FT_FRAME_END
+  };
+
+  static const FT_Frame_Field  winpe_rsrc_dir_fields[] =
+  {
+#undef  FT_STRUCTURE
+#define FT_STRUCTURE  WinPE_RsrcDirRec
+
+FT_FRAME_START( 16 ),
+  FT_FRAME_ULONG_LE ( characteristics ),
+  FT_FRAME_ULONG_LE ( time_date_stamp ),
+  FT_FRAME_USHORT_LE ( major_version ),
+  FT_FRAME_USHORT_LE ( minor_version ),
+  FT_FRAME_USHORT_LE ( number_of_named_entries ),
+  FT_FRAME_USHORT_LE ( number_of_id_entries ),
+FT_FRAME_END
+  };
+
+  static const FT_Frame_Field  winpe_rsrc_dir_entry_fields[] =
+  {
+#undef  FT_STRUCTURE
+#define FT_STRUCTURE  WinPE_RsrcDirEntryRec
+
+FT_FRAME_START( 8 ),
+  FT_FRAME_ULONG_LE ( name ),
+  FT_FRAME_ULONG_LE ( offset ),
+FT_FRAME_END
+  };
+
+  static const FT_Frame_Field  winpe_rsrc_data_entry_fields[] =
+  {
+#undef  FT_STRUCTURE
+#define FT_STRUCTURE  WinPE_RsrcDataEntryRec
+
+FT_FRAME_START( 16 ),
+  FT_FRAME_ULONG_LE ( offset_to_data ),
+  FT_FRAME_ULONG_LE ( size ),
+  FT_FRAME_ULONG_LE ( code_page ),
+  FT_FRAME_ULONG_LE ( reserved ),
+FT_FRAME_END
+
+  };
+
  static const FT_Frame_Field  winfnt_header_fields[] =
  {
#undef  FT_STRUCTURE
@@ -213,6 +290,7 @@
  /* yes, now look for an NE header in the file */
  WinNE_HeaderRec  ne_header;

+  FT_TRACE2(( MZ signature found\n ));

  if ( FT_STREAM_SEEK( mz_header.lfanew )   ||
   FT_STREAM_READ_FIELDS( winne_header_fields, ne_header ) )
@@ -228,6 +306,7 @@
FT_UShort  font_count  = 0;
FT_ULong   font_offset = 0;

+FT_TRACE2(( NE signature found\n ));

if ( FT_STREAM_SEEK( res_offset )||
 FT_FRAME_ENTER( ne_header.rname_tab_offset -
@@ -293,7 +372,6 @@

face-font-offset = (FT_ULong)FT_GET_USHORT_LE()  size_shift;
face-font-fnt_size   = (FT_ULong)FT_GET_USHORT_LE()  size_shift;
-face-font-size_shift = size_shift;

stream-cursor += 8;

@@ -301,6 +379,149 @@

error = fnt_font_load( face-font, stream );
  }
+  else if ( ne_header.magic == WINFNT_PE_MAGIC )
+  {
+WinPE32_HeaderRec  pe32_header;
+WinPE32_SectionRec  pe32_section;
+WinPE_RsrcDirRec  root_dir, name_dir, lang_dir;
+WinPE_RsrcDirEntryRec

Re: [ft-devel] Kerning support in freetype

[Dmitry Timoshkov]

David Turner [EMAIL PROTECTED] wrote:


Windows reports 96 dpi screen resolution (I'm using a device context
of the screen), and I'm creating a font with 1200 pixels height.


this formulation doesn't make much sense to us. Could you elaborate what
you're doing in both cases. Precisely:

- how do you choose the font size under Windows (and/or resolution ?)
- how do you do the same with FreeType ?


I tried to avoid using logical units and use pixels instead, but apparently
made an error. I've resolved the problem by passing a negative height to
win32 API CreateFont and using FT_Set_Pixel_Sizes instead of FT_Set_Char_Size.
Now I get almost the same values from freetype and windows for all font sizes
I tried. What remains is a rounding error of +1/-1 (would be nice to avoid
that error as well), and find a way to get all amount of available kerning
pairs from freetype.

Thanks.

--
Dmitry.


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Kerning support in freetype

[Dmitry Timoshkov]

Russell Shaw [EMAIL PROTECTED] wrote:


I need it to implement behaviour of a win32 API GetKerningPairs, which
is able to return total amount of kerning pairs available. I don't see
why that info shouldn't be available for an application which wants to
cache it for any reason.


If freetype has already loaded all the pairs from the file, then cacheing
wouldn't be needed (unless you really need them all to emulate some api).


Yes, that's needed for a GetKerningPairs implementation via freetype APIs.


face Arial Regular has kerning
kerning between 32 and 65 is -2:0
kerning between 32 and 84 is -1:0
kerning between 70 and 44 is -3:0

which is a bit small for a 1200 pixels font face.


Note that your printfs are dividing by 64 (6).


Which is correct to convert from a 26.6 format to an integer. And
now I see my mistake thanks to James, FT_Set_Char_Size takes a 26.6
value as well, not an integer.


Using Win32 API GetKerningPairsW I get:

wFirst 32, wSecond 65, iKernAmount -59
wFirst 32, wSecond 84, iKernAmount -19
wFirst 70, wSecond 44, iKernAmount -119

which looks reasonable for a 1200 pixel sized font face.


After taking out the 6 in the printfs, i get:

face Arial Regular has kerning
kerning between 32 and 65 is -66:0
kerning between 32 and 84 is -22:0
kerning between 70 and 44 is -133:0

using: /usr/share/fonts/truetype/msttcorefonts/arial.ttf

The differences might be due to the screen resolution not
being set in FT_Set_Char_Size().


Many thanks for the hint. In my sample if I replace

if (FT_Set_Char_Size(ft_face, 0, 1200, 0, 0))

by

if (FT_Set_Char_Size(ft_face, 0, 1200  6, 64, 64))

I get the closest match to what Windows returns:

face Arial Regular has kerning
kerning between 32 and 65 is -59:0
kerning between 32 and 84 is -20:0
kerning between 70 and 44 is -119:0

But using 64 as a magic resolution confuses. Any idea what
might cause that behaviour?

Thanks.

--
Dmitry.


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Kerning support in freetype

[Dmitry Timoshkov]

Russell Shaw [EMAIL PROTECTED] wrote:


But using 64 as a magic resolution confuses. Any idea what
might cause that behaviour?


What point-size and screen resolution are you using on Windows?

1200  6 is a size of 18.75pt.


Windows reports 96 dpi screen resolution (I'm using a device context
of the screen), and I'm creating a font with 1200 pixels height.

Thanks.

--
Dmitry.


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel