This is how to intercept GETINFO and why it should be in FreeType

2020-08-25 Thread piotrunio-2004 

ÿþThe way to do it is to first go to 
ttinterp.c , then at the start of the 
file declare two variables:



   char FT_injectedGETINFOhack = 0;

   FT_Long 
FT_injectedGETINFOhackvalue;



Now here's the tricky part. Go near 
line 7660 and find the ending of the 
GETINFO function. It would look 
something like this:



#endif /* 
TT_SUPPORT_SUBPIXEL_HINTING_INFINALITY 
*/



    args[0] = K;

  }



So the way to add the intercept is to 
then proceed to add code to overwrite 
the value:



#endif /* 
TT_SUPPORT_SUBPIXEL_HINTING_INFINALITY 
*/



    if(FT_injectedGETINFOhack){

   K = FT_injectedGETINFOhackvalue;

    }

    args[0] = K;

  }







What will provide in it better render 
result? Of course, this makes the 
GETINFO customizable for users of 
FreeType (that include the FreeType 
files in their programs). The benefits 
of interception can be seen for 
instance in the v38 renderer.



Disclaimer: The sample images are made 
with v38 FreeType bytecode, but the 
outlines are not rasterized with 
FreeType rasterizer. The correct gasp 
setting for symmetric smoothing is used 
in the renders, with 6×1 or 6×5 
oversampling and the subpixel box 
filter to simulate ClearType.



First of all, a commercial font is 
rendered like this when GETINFO is not 
intercepted: 
https://i.imgur.com/W9FSEzd.png



Size 18ppem and up is where it gets 
very controversial in rendering. In 
this case what default v38 FreeType 
does is end up with fractional 
horizontal stems. Using Visual TrueType 
reveals that the font only does that 
when fractional widths are used in 
ClearType. However it is very worrying 
that this is default FreeType behavior, 
and no FT_RENDER_MODE_XXX is documented 
to use an integer width version of 
subpixel hinting.



What happens with the intercepted 
GETINFO? In the following image I use 
the following settings: 

      FT_injectedGETINFOhack = 1;

      FT_injectedGETINFOhackvalue = 
0x00006C00;

https://i.imgur.com/PuhGJ13.png . 
Suddenly the problems with fractional 
horizontal stems disappear. This will 
in fact allow the FreeType user to use 
a custom GETINFO value, and GETINFO 
(what fonts see how the renderer is 
like) becomes detached from the 
FreeType render mode (what the renderer 
is actually like), allowing for 
personalized renderer settings. 
However, even when the GETINFO is 
changed the v38 or v40 renderer is 
still miles from being finished, 
especially considering that FreeType 
does not even directly have a proper 
rasterizer for the base

Re: Logging Library-GSOC

2020-08-25 Thread Werner LEMBERG 


>>Create a new branch that presents your code in an ordered
>>fashion, this is, using not-too-large, concise, well documented
>>commits that makes it easy to understand how your project works.
>>Have a look how Anuj is doing this to get an idea.  While doing
>>so, please check the code and documentation formatting.
>>- Two spaces after a full stop.
>>- Source code files should always have a newline character at
>>  the very end (again an editor setting).
>>- Avoid trailing whitespace (this should be an editor setting)
>>- Don't precede tab characters with spaces (again an editor
>>  setting).
> 
> Is there a git way to do it or do I have to manually order changes
> and do commits?

This is a manual job.  You take the final code, split it into smaller,
logical chunks that get committed separately (taking care that each
commit is compilable).  In other words, you replace your 40+ commits
with, say, less than 10.

>> I wonder whether it is necessary to have a separate `dlg.vcxproj`
>> file (and friends).  What about folding its contents into
>> `freetype.vcxproj`?  The `dlg` stuff gets completely integrated
>> into FreeType and will be always linked statically...
>
> I have made a separate project for dlg, as for the release
> builds(Release Static and Release) it would be easy to not compile
> the dlg's code just by simply skipping the dlg project and building
> only the FreeType project.

My knowledge is too limited to have a qualified opinion.  Alexei?

> Ok, I will use the dlgwrap.c method, for this we also have to
> include file `freetype.h' right?

Please include whatever is necessary :-)


Werner

Re: Logging Library-GSOC

2020-08-25 Thread Priyesh kumar 
Hi,











*> Create a new branch that presents your code in an ordered fashion,>
this is, using not-too-large, concise, well documented commits>that
makes it easy to understand how your project works.  Have a>look how
Anuj is doing this to get an idea.>While doing so, please check the
code and documentation>formatting.>- Two spaces after a full
stop.>- Source code files should always have a newline character at
the>  very end (again an editor setting).>- Avoid trailing
whitespace (this should be an editor setting)>- Don't precede tab
characters with spaces (again an editor>  setting).*

Is there a git way to do it or do I have to manually order changes and do
commits?






*> I wonder whether it is necessary to have a separate `dlg.vcxproj`>  file
(and friends).  What about folding its contents into>  `freetype.vcxproj`?
The `dlg` stuff gets completely integrated into>  FreeType and will be
always linked statically...>  Am I missing something?*
I have made a separate project for dlg, as for the release builds(Release
Static and Release)
it would be easy to not compile the dlg's code just by simply skipping the
dlg project and
building only the FreeType project.




*> * I expect that>FT_LOGGING_FILE=/dev/stderr>  works to emit data to
stderr.  It should probably be documented.*
Yes, it works, will update this in documentation...




*> Please keep `devel/ftoption.h` in sync with>
 `include/freetype/config/ftoption.h`.  Right now, the former lacks>
 `FT_LOGGING`.  Note that the devel version should have FT_LOGGING>
 activated by default, while the standard one should not*
Ok.



*> Have you checked that `make refdoc` builds ok, and that your>
`debugging_apis` stuff is properly displayed as HTML in the API>
documentation?*
Yes, it is working properly.








*> For function definitions (and especially API functions), always use>
 one argument per line.  This is, don't write>int foo( char  bar, void
*baz )>   but>int>foo( char   bar,> void  *baz )*
Ok.



*> Have you ensured that the `dlg` files are compiled into the library>
only if `FT_LOGGING` is defined?  As far as I can see, this is not>  the
case yet[...]*
Ok, I will use the dlgwrap.c method, for this we also have to include
file `freetype.h' right?




*> In `toplevel.mk `, change># For builds that
don't use `./configure' script ...>  to># For builds directly from the
git repository .*
Updated, thanks.

On Tue, Aug 25, 2020 at 11:45 AM Werner LEMBERG  wrote:

>
> Hello Priyesh,
>
>
> > I have updated the FreeType's code in accordance with the recent
> > changes in the dlg library and again tested the code on
> > Linux(Autotools), Windows(Visual Studios), and on OS X(Autotools).
>
> thanks!
>
> > I wanted to ask that is there something else which I have to take
> > care of?  or should I proceed towards writing the final report?
>
> In addition to the final report you should do two things.
>
> (1) Rebase your code to current 'master'.
>
> (2) Create a new branch that presents your code in an ordered fashion,
> this is, using not-too-large, concise, well documented commits
> that makes it easy to understand how your project works.  Have a
> look how Anuj is doing this to get an idea.
>
> While doing so, please check the code and documentation
> formatting.
>
> - Two spaces after a full stop.
> - Source code files should always have a newline character at the
>   very end (again an editor setting).
> - Avoid trailing whitespace (this should be an editor setting)
> - Don't precede tab characters with spaces (again an editor
>   setting).
>
> If you do, for example,
>
>   git diff master
>
> on the command line then trailing whitespace is marked in red, and
> right now you will see *a lot* of red boxes :-)
>
>
> Some comments regarding the code.
>
> * I wonder whether it is necessary to have a separate `dlg.vcxproj`
>   file (and friends).  What about folding its contents into
>   `freetype.vcxproj`?  The `dlg` stuff gets completely integrated into
>   FreeType and will be always linked statically...
>
>   Am I missing something?
>
> * I expect that
>
> FT_LOGGING_FILE=/dev/stderr
>
>   works to emit data to stderr.  It should probably be documented.
>
> * Please keep `devel/ftoption.h` in sync with
>   `include/freetype/config/ftoption.h`.  Right now, the former lacks
>   `FT_LOGGING`.  Note that the devel version should have FT_LOGGING
>   activated by default, while the standard one should not.
>
> * Have you checked that `make refdoc` builds ok, and that your
>   `debugging_apis` stuff is properly displayed as HTML in the API
>   documentation?
>
> * For function definitions (and especially API functions), always use
>   one argument per line.  This is, don't write
>
> int foo( char  bar, void  *baz )
>
>   but
>
> int
> foo( char   bar,
>  void  *baz )
>
> * Have you

Re: about the meson build systel

2020-08-25 Thread Keith Packard 
Werner LEMBERG  writes:

>>> BTW, how well does meson support cross compilation?
>> 
>> it does support cross-compilation a lot better than cmake
>> on Windows (though compilation fails because of mmap) :
>
> Thanks for checking.

I've done some experimentation with 'picolibc', which uses meson for
doing cross compilation of an embedded C library. It took about an hour
to get things building under Windows using the armgcc packages for
windows and generating equivalent results to Linux.

I did have to install mingw though; meson requires a native C
compiler. I also ended up installing msys as my meson scripts used a few
POSIX utilities to extend the functionality of meson. I'm currently
using 'sed' to do some string editing that meson should probably support
internally, and 'ls' to check whether files exist ('test' isn't
available in msys); again, meson should probably have some internal
support for that.

Meson is a huge relief from using autotools in a multi-platform
environment as you can easily identify these kinds of platform-specific
usages -- they're all in explicit calls to functions for running
external commands...

-- 
-keith


signature.asc
Description: PGP signature

Re: about the meson build systel

2020-08-25 Thread Werner LEMBERG 


>> BTW, how well does meson support cross compilation?
> 
> it does support cross-compilation a lot better than cmake
> on Windows (though compilation fails because of mmap) :

Thanks for checking.


Werner

Re: mmap and Windows

2020-08-25 Thread Vincent Torri 
Werner

On Sat, Jul 25, 2020 at 12:37 PM Werner LEMBERG  wrote:
>
>
> Hello Vincent,
>
>
> > 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 ?
>
> If this really makes a difference on Windows, and if you want to
> contribute such code, you are welcome to do so!

I guess that mmap is useful with a font with a large size, right ? if
so, do you have a font to test with ?

thank you

Vincent Torri

Re: Logging Library-GSOC

2020-08-25 Thread Werner LEMBERG 


Hello Priyesh,


> I have updated the FreeType's code in accordance with the recent
> changes in the dlg library and again tested the code on
> Linux(Autotools), Windows(Visual Studios), and on OS X(Autotools).

thanks!

> I wanted to ask that is there something else which I have to take
> care of?  or should I proceed towards writing the final report?

In addition to the final report you should do two things.

(1) Rebase your code to current 'master'.

(2) Create a new branch that presents your code in an ordered fashion,
this is, using not-too-large, concise, well documented commits
that makes it easy to understand how your project works.  Have a
look how Anuj is doing this to get an idea.

While doing so, please check the code and documentation
formatting.

- Two spaces after a full stop.
- Source code files should always have a newline character at the
  very end (again an editor setting).
- Avoid trailing whitespace (this should be an editor setting)
- Don't precede tab characters with spaces (again an editor
  setting).

If you do, for example,

  git diff master

on the command line then trailing whitespace is marked in red, and
right now you will see *a lot* of red boxes :-)


Some comments regarding the code.

* I wonder whether it is necessary to have a separate `dlg.vcxproj`
  file (and friends).  What about folding its contents into
  `freetype.vcxproj`?  The `dlg` stuff gets completely integrated into
  FreeType and will be always linked statically...

  Am I missing something?

* I expect that

FT_LOGGING_FILE=/dev/stderr

  works to emit data to stderr.  It should probably be documented.

* Please keep `devel/ftoption.h` in sync with
  `include/freetype/config/ftoption.h`.  Right now, the former lacks
  `FT_LOGGING`.  Note that the devel version should have FT_LOGGING
  activated by default, while the standard one should not.

* Have you checked that `make refdoc` builds ok, and that your
  `debugging_apis` stuff is properly displayed as HTML in the API
  documentation?

* For function definitions (and especially API functions), always use
  one argument per line.  This is, don't write

int foo( char  bar, void  *baz )

  but

int
foo( char   bar,
 void  *baz )

* Have you ensured that the `dlg` files are compiled into the library
  only if `FT_LOGGING` is defined?  As far as I can see, this is not
  the case yet.

  Two possible solutions

  - Adjust the copying process from the 'dlg' sub-repository to
`src/dlg`, for example do

  echo "#ifdef FT_LOGGING" > dlg.c
  echo>> dlg.c
  cat submodules/dlg/src/dlg/dlg.c>> dlg.c
  echo>> dlg.c
  echo "#else /* !FT_LOGGING */"  >> dlg.c
  echo "/* ANSI C doesn't like empty source files */" >> dlg.c
  echo "  typedef int  _dlg_dummy;"   >> dlg.c
  echo>> dlg.c
  echo "#endif /* !FT_LOGGING */" >> dlg.c

You might use the `sed` program instead of `echo` and `cat`.

  - Create a wrapper file (say, `dlgwrap.c`) that contains

  #ifdef FT_LOGGING
  #  include "dlg.c"
  #else
/* ANSI C doesn't like empty source files */
typedef int  _dlg_dummy;
  #endif

and compile this instead.

* In `toplevel.mk`, change

# For builds that don't use `./configure' script ...

  to

# For builds directly from the git repository ...


   Werner

Re: Gitlab Migration Progress

2020-08-25 Thread Keith Packard 
Werner LEMBERG  writes:

> and I couldn't find a commercial feature that would be necessary for
> us.  Am I missing something?

People at the Gnome foundation worked with gitlab to add enough features
to the free version to make Gnome developers happy. Seems to be working
fine for freedesktop developers too; we haven't had anyone asking for
something available only in the non-free version.

-- 
-keith


signature.asc
Description: PGP signature