I've released a new amalgamation that corresponds to the FreeType
2.4.12 release. It is located here:
https://github.com/vinniefalco/FreeTypeAmalgam
What's an amalgamation?
An amalgamation is simply a collection of header and source files that
have been concatenated together to form one or more
Hey guys, I'm a little late to the party. It looks like a lot of exciting
things have been happening! I need to bring the amalgamation up to date. So
is the CFF stuff finalized? I would just have to add the items in src/cff
(and md5.c)?
Thanks!
--
Follow me on Github:
Well...I updated the amalgamation to the tip of the master branch from the
FreeType repository, to include the recent CFF changes. The files in
src/cff seemed to be included, after I added the necessary macro
substitution for FT_CFF_DRIVER_H. So, if anyone would like to try it and
let me know if
FreeType 2.4.11 has been released.
I'm having the dickens of a time putting together a new amalgamation.
It seems afmodule.c uses the type 'FT_Properties_SetFunc', which is
only declared if FT_CONFIG_OPTION_PIC is set? But FT_CONFIG_OPTION_PIC
is not set in my configuration so I am getting a
...
All of this is outside of an FT_CONFIG_OPTION_PIC block.
Maybe you are missing the file `svprop.h'?
I tracked it down. afpic.h includes svprop.h conditionally. Since
afpic.h is seen before an unconditional include of svprop.h (in my
amalgamation templates), the first time it is included
I've updated the FreeType amalgamation to the recently released
version of FreeType, 2.4.11. It is available in the develop branch
of the official amalgamation repository:
https://github.com/vinniefalco/FreeTypeAmalgam
If there are no bug reports or requests I will publish this to the
master
My question relates to a more direct way to compute the signed distance and
to know if
anyone has already coded it by any chance ? Said differently, is there a quick
way to
compute the shortest signed distance from any point (x,y) to the glyph
contours ?
You can do this in the pixel-domain,
On Wed, Oct 31, 2012 at 11:46 AM, Nicolas Rougier
nicolas.roug...@inria.fr wrote:
Thanks for the reference and the code. I've been using code from
http://contourtextures.wikidot.com since it can handle antialiased images and
then I use grayscale rendering of the glyph to increase precision.
I wrote some code to use FreeType to render hinted glyphs in the JUCE
cross platform library. The problem is that I have to do an operation
on the order of O(N^2) where N = number of glyphs, to extract the
kerning pairs. It would be a lot easier if FreeType offered some sort
of iterator that lets
From: Behdad Esfahbod beh...@behdad.org
I know I'm fairly opinionated when it comes to library design, but thought
share my thoughts anyway. Personally I think FreeType's public API is largely
over-engineered, and the proposed property service is a big step in that
direction.
I agree 100%.
FreeType Amalgamation 2.4.10rc1 is now available, based on VER-2-4-10
of the official FreeType repository. It is available in the 'develop'
branch of the FreeTypeAmalgam repository:
https://github.com/vinniefalco/FreeTypeAmalgam
The tag is VER-2-4-10-rc1
Please open issues as needed if there
From: Miles Bader mi...@gnu.org
I'm sure all the relevant arguments were well-covered in the _previous_
flamewar on this topic...
You call that a flamewar? freetype-devel is the model of how I wish
participants in other open source projects that I have amalgamated
would behave. Sure, there
, if I'm not mistaken, the amalgamation tool itself is not
cross-platform. I
haven't tried running it to produce the amalgamation myself. I've only tried
using
versions of freetype.c and freetype.h that Vinnie has made available. I would
love
to see the amalgamation tool become cross-platform and part
From: Alan Coopersmith alan.coopersm...@oracle.com
Do you know where most of the FreeType security issues in the past few years
has been found? By people trying to hack smartphones via downloads of
malicious PDF's or opening webpages with bad webfonts.
That's
only a vulnerability of the
I've updated the amalgamated version of FreeType, these are the changes:
- The amalgamated repo is at https://github.com/vinniefalco/FreeTypeAmalgam
- The repo no longer includes the templates
- The directory structure has been flattened to make it easier to view
- A file called COMMITLOG
From: http://rawmaterialsoftware.com/viewtopic.php?f=6t=8654
those amalgamations are pretty convenient imo, i don't get why you got so much
hostility on the freetype dev list
I'd like to thank everyone for putting up with my odd request and helping to
make this FreeType amalgamation happen,
Perhaps your amalgamation tool should add
#ifdef __FOO_C__
... contents of file `foo.c'
#endif
to all files, and a special header file (based on `modules.cfg' and
ftmodule.h) can then control the parts which are really compiled.
Oh! That's easily done. The amalgamation for FreeType
I want to provide a simple header that users of the amalgamated version of
FreeType can edit to turn modules on and off. For example, my own application
doesn't require anything other than TrueType font loading, outline extraction,
and hinting (no renderers or other formats needed).
I'm
FreeType 2.4.9 has been released.
Is there a reference or explanation for what the branches in the git repository
mean? I get that some of them are experimental but what's the convention for
tagging releases? Also, it seems there are some branches that haven't been
touched in quite a long
I don't see the tag for VER-2-4-9...or am I misunderstanding? This is the URL
I am looking at:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/refs/tags
Thanks
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
I've moved the FreeType amalgamation over to github. You can access it here:
https://github.com/vinniefalco/FreeTypeAmalgam
The amalgamation tool has also been moved to github, at:
https://github.com/vinniefalco/Amalgamate
Comments welcome,
Date: Wed, 22 Feb 2012 16:54:00 -0800
From: Tom Bishop, Wenlin Institute wen...@wenlin.com
It works! Awesome! Thank you Vinnie!
Glad to hear it!
One question: my application normally includes ftoutln.h, for directly calling
FT_Outline_Render(), etc. With FreeTypeAmalgam.h
Date: Tue, 21 Feb 2012 08:02:43 -0500
From: Alexei Podtelezhnikov apodt...@gmail.com
You planing this for Stone Age people who do not know how to use
make. I rest my case.
Actually, that is true.
My target audience includes musicians or artists who are beginning
to dabble in C / C++
From: Alexei Podtelezhnikov apodt...@gmail.com
Sent: Tuesday, February 21, 2012 8:28 AM
It is hard to believe that there are people who'll dive into font rendering
without first learning how to use multiple files and libraries in a project.
I agree, it is hard to believe but that's just
pain trying to merge
c++ code into sqlite due to the amalgamated approach.
What exactly was the issue with sqlite?
Thanks
Vinnie
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
I'm afraid that MacOS specific ugly hacks (detecting Mac OS,
excluding CodeWarrior, detecting Mac OS X, excluding PPC, excluding
64bit, etc etc) made Vinnie feel sick.
I don't think so :-) If I understand him correctly, he would like to
configure everything with platform-dependent
The real issue with external dependencies is about upgrading. [...]
For my use-case vulnerabilities are a non-issue.
Okay; but my point was rather the reverse: that the only real reason
you'd want an external dependency is for the fixes; if you do not care
(and provided the redistribution
is to rename one. PRaster will also have to be renamed since its an
alias.
This is what I mean by cosmetic changes. It looks like ftgrays.c was born as
a copy of the file
ftraster.c and modified appropriately, thus the duplicate symbol names.
Thanks,
Vinnie
More cosmetic changes I had to make:
1) ttdriver.c
Rename Load_Glyph() static function as it conflicts with another static
function.
2) t1driver.c
Rename t1_get_glyph_name() as it conflicts with another static function.
3) cidload.c
Rename parse_font_matrix(), t1_init_loader(),
I'm interested in building an amalgamated version of FreeType. Specifically,
I would like to use an in-house tool to combine all the FreeType headers and
source files into a set consisting of a single .h and .c (or a couple of .c
files if they are too large). This amalgamation would be much
I'm ashamed to admit it but you are talking about things that are going WAY
over my head. I tried to use those programs fontforge and ttx but I failed to
get them to run. Something about needing Cygwin, which also generated errors
when I tried to install that, and I don't understand TTX.
So my
The function FT_Get_Gasp tells you,
for a given ppem, whether you should
render a glyph as monochrome
(i.e., black-white) or with anti-aliasing.
ppem? is that what I understand to be the font height? Pixels per EM unit? By
monochrome I assume you mean, two intensity levels (on or off). As
You haven't told us which FreeType version you are
using... For bug
reports, please always try the recent one, this is, 2.4.4.
Sorry about that and yes of course I'm using the most recent version.
BTW, I'm not sure that `professional' fonts are intended
for screen display, working at small
The trickyness is that you are trying to separate hinting
from rasterizing. As explained already, the TrueType
bytecode interpreter and the rasterizer do interact. It's
not intended to be handled separately.
I went through the trouble of tweaking my 3rd party library to support
rendering
I know that you can use FT_Get_Kerning() if you want to retrieve the kerning
for a specific pair of glyphs but what if I just want to loop over all of the
available kerning pairs and get the information? I'm trying to transfer all the
data in a FreeType FT_Face into another object in a 3rd
Several months ago I noticed that the output of Freetype was worse for my
application. I've returned to working on that part of my application and now I
have something concrete. It seems the bytecode hinter is defective, and the
autohinter is working. Check out this image:
Wojtek Mamrak wrote
I observed some differences in how fonts are rendered. Here is the screen
showing same text rendered with the same font family and font size:
I have noticed this myself. In fact the entire display in my application is
broken now. The problem happens when hinting is enabled.
37 matches
Mail list logo
