>From the CHANGES file:
- The new CFF engine now handles the `random' operator. All CFF
opcodes are now supported.
- The CFF module has a new property `random-seed' to control the
pseudo-random number generation for the `random' operator.
Please test!
Werner
The most important dependency is on linear blending (or gamma
correction) in the compositing of glyph images onto the screen. The stem
darkening function assumes blending with a gamma close to 1.8. If linear
blending is not used (e.g., gamma 1.0) then black text will appear too
dark. This might
I have been testing the new adobe-Freetype CFF engine, and was wondering if the
default 'darkness' of stem darkening is a little too high?
How does the width of stems in a font effect the amount of darkness rendered? I
think someone mentioned that thinner stems will render with relatively more
12.05.2013, 15:52, Vernon Adams v...@newtypography.co.uk:
I have been testing the new adobe-Freetype CFF engine, and was wondering if
the default 'darkness' of stem darkening is a little too high?
How does the width of stems in a font effect the amount of darkness rendered?
I think someone
:) ah thanks. it was under my nose all the time.
very interesting.
On 12 May 2013, at 07:34, octoploid octopl...@yandex.com wrote:
12.05.2013, 15:52, Vernon Adams v...@newtypography.co.uk:
I have been testing the new adobe-Freetype CFF engine, and was wondering if
the default
Hello Werner,
while testing the fantastic new engine, I found that much prefer to turn
off stem darkening, because it really makes CFF fonts stand out compared
to (autohinted) Truetype fonts... It's jarring to switch between
websites and alternate between fat and thin looking text. I'm
I'm thinking that maybe it should either be turned off by default or
stem darkening should also be turned on for other font types by
default.
While this is not possible for native TrueType, stem darkening for
smaller sizes is already part of the Infinality patch for the
auto-hinter, and this
While this is not possible for native TrueType, [...]
I mean `native TrueType hinting'.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
And maybe made configurable from fontconfig like what the Cleartype
tuner on Windows 7/8 does.
Yes, maybe. However, stem darkening is a font driver property and not
to be changed font-wise.
Werner
Within the new CFF hinter, stem darkening automatically accounts for font
weight. At a
I've build freetype2 and freetype2-demos with clang's
-fsanitize=undefined. Here's what I get when run ftview on an otf
font: [...]
All those issues should be fixed in the git repository. Please rerun
your test and report whether you still get errors.
Werner
PS: The just committed
04.05.2013, 14:07, Werner LEMBERG w...@gnu.org:
I've build freetype2 and freetype2-demos with clang's
-fsanitize=undefined. Here's what I get when run ftview on an otf
font: [...]
All those issues should be fixed in the git repository. Please rerun
your test and report whether you
Two (minor) issues remain for otf fonts: [...]
For tty fonts I get these warnings: [...]
Thanks again. Should be fixed now in git.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
04.05.2013, 16:44, Werner LEMBERG w...@gnu.org:
Two (minor) issues remain for otf fonts: [...]
For tty fonts I get these warnings: [...]
Thanks again. Should be fixed now in git.
Unfortunately your last commit breaks true-type hinting
in certain cases (see attached picture).
It also
Unfortunately your last commit breaks true-type hinting
in certain cases (see attached picture).
Should be fixed in git, please test.
It also introduces two new issues:
/var/tmp/freetype2/src/cff/cffgload.c:999:37: runtime error: left shift of
255 by 24 places cannot be represented in
Everything runs error free now. And the 64-bit problem is also
fixed.
Thanks for testing. Theoretically, I've also fixed clang issues with
other font formats, but it's easy to miss them...
Werner
___
Freetype-devel mailing list
04.05.2013, 18:58, Werner LEMBERG w...@gnu.org:
Unfortunately your last commit breaks true-type hinting
in certain cases (see attached picture).
Should be fixed in git, please test.
It also introduces two new issues:
/var/tmp/freetype2/src/cff/cffgload.c:999:37: runtime error: left
04.05.2013, 19:13, Werner LEMBERG w...@gnu.org:
Everything runs error free now. And the 64-bit problem is also
fixed.
Thanks for testing. Theoretically, I've also fixed clang issues with
other font formats, but it's easy to miss them...
One last issue:
On Thu, May 02, 2013 at 11:50:41PM +0200, Werner LEMBERG wrote:
Basically, I took the following steps:
$ git status
# On branch master
nothing to commit, working directory clean
$ git rev-parse HEAD
9bf75e08199794c4a5fcefcbfe71b5d39f42e46d
$ make devel make
$ cd
Hello Werner,
do I understand this correctly:
1. The new engine only works for .otf fonts with included hints and does
nothing for .ttfs
2. Setting the new engine as the default like in your mail sets it up
automatically for all .otf fonts regardless of hinting settings in
fontconfig, meaning
Please send me the output of
echo '#include limits.h' | cpp -dM -E
From your 64bit box, I mean.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
1. The new engine only works for .otf fonts with included hints and
does nothing for .ttfs
Correct. Similar to TTFs, however, an eternal rule applies: A badly
hinted font appears better if displayed without hints (or with
auto-hinting). But this is beyond the control of FreeType, entering
03.05.2013, 11:48, Werner LEMBERG w...@gnu.org:
After trying on Fedora 19 64bit, Ubuntu 13.04 64bit with gcc 4.7 and
gcc 4.6 with the same result, I eventually tried Ubuntu 13.04 32 bit
and it seemed normal. Maybe it is a 64-bit issue?
Yes, I think so. BTW, does `make devel' really
On Fri, May 03, 2013 at 11:47:51AM +0200, Werner LEMBERG wrote:
After trying on Fedora 19 64bit, Ubuntu 13.04 64bit with gcc 4.7 and
gcc 4.6 with the same result, I eventually tried Ubuntu 13.04 32 bit
and it seemed normal. Maybe it is a 64-bit issue?
Yes, I think so. BTW, does `make
On 13-05-03 05:47 AM, Werner LEMBERG wrote:
Yes, I think so. BTW, does `make devel' really works out of the box
on your 64bit platform? I suppose that you have
UINT_MAX = ULONG_MAX = 2^64 - 1
On most 64 bit platforms int is still 32 bit.
--
behdad
http://behdad.org/
I am also seeing the 'wavy text in ftview', with the Adobe engine + hinting:
on. By 'wavy text' i assume we are meaning that some stems are not snapping to
the xheight, baseline or capheight, but +1 or -1 pixel from those lines.
Kubuntu 13.04 64bit.
I would like to test this further, so i have
I am also seeing the 'wavy text in ftview', with the Adobe engine +
hinting: on. By 'wavy text' i assume we are meaning that some stems
are not snapping to the xheight, baseline or capheight, but +1 or -1
pixel from those lines. Kubuntu 13.04 64bit.
Yep. This is a 64bit issue; I'm already
I've build freetype2 and freetype2-demos with clang's
-fsanitize=undefined. Here's what I get when run ftview on an otf
font:
ttcmap.c:908:18: runtime error: left shift of negative value -1
[...]
Thanks. clang is *very* picky :-) Virtually all compilers do the
right thing for left
Yes, make devel appears to work except for the wavy text.
Attached is the output of that command.
Thanks. So `int' is 32bit.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
03.05.2013, 16:23, Werner LEMBERG w...@gnu.org:
I've build freetype2 and freetype2-demos with clang's
-fsanitize=undefined. Here's what I get when run ftview on an otf
font:
ttcmap.c:908:18: runtime error: left shift of negative value -1
[...]
Thanks. clang is *very* picky :-)
Thanks for the clarification :) Say, are there parts or tricks in the
new engine that could be carried over to .ttf rendering or the
auto-hinter? I would love to see improvements to typeface fidelity with
hintslight :)
Regards,
Nikolaus
___
Thanks for the clarification :) Say, are there parts or tricks in
the new engine that could be carried over to .ttf rendering or the
auto-hinter? I would love to see improvements to typeface fidelity
with hintslight :)
Well, stem thickening at small sizes is already available in the
o == octoploid octopl...@yandex.com writes:
o One issue that I've noticed is that turning hinting on
o and using the new engine results in bad rendering (wave-
o like) with many fonts.
o See the attached screenshot (Minion font) as an example.
That screenshot duplicates what I saw.
-JimC
--
o == octoploid octopl...@yandex.com writes:
o Compiler is gcc-4.8.
I also used 4.8.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
WL == Werner LEMBERG w...@gnu.org writes:
WL Thanks. So `int' is 32bit.
The only system I'm aware of where int was 64 bits was alpha. (Cray's
first alpha systems went so far as to have sizeof(char)==sizeof(int)==
sizeof(long)==sizeof(int64_t)==1.)
Everyone else, as far as I remember, kept
Hi Werner,
Looks like a very exciting development!
I'm just getting ready to do some testing in Ghostscript, and I noticed
a missing header inclusion. Trivial patch attached.
Cheers,
Chris
On Wed, 01 May 2013 20:11:31 +0200 (CEST)
Werner LEMBERG w...@gnu.org wrote:
Folks,
Adobe, in
I'm just getting ready to do some testing in Ghostscript, and I
noticed a missing header inclusion. Trivial patch attached.
Applied, thanks!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Please forgive my naive question, but how would one enable the new
engine by default for testing? Is the following enough?
diff --git a/src/cff/cffobjs.c b/src/cff/cffobjs.c
index ebcf189..1b8643d 100644
--- a/src/cff/cffobjs.c
+++ b/src/cff/cffobjs.c
@@ -1056,8 +1056,8 @@
I noticed in ftview that, as 24 ppem, the baselines and the xheight of
any glyph with a round baseline are one pixel lower than the other
glyphs when using the Adobe engine.
Toggling forced autohint after switching to the Adobe engine makes the
issue very obvious.
I'm at commit
I noticed in ftview that, as 24 ppem, the baselines and the xheight
of any glyph with a round baseline are one pixel lower than the
other glyphs when using the Adobe engine.
Toggling forced autohint after switching to the Adobe engine makes
the issue very obvious.
I'm at commit
One issue that I've noticed is that turning hinting on and using the
new engine results in bad rendering (wave- like) with many fonts.
See the attached screenshot (Minion font) as an example.
This seems to be the same effect which James has reported. Attached
is what I get with exactly the
02.05.2013, 22:32, Werner LEMBERG w...@gnu.org:
One issue that I've noticed is that turning hinting on and using the
new engine results in bad rendering (wave- like) with many fonts.
See the attached screenshot (Minion font) as an example.
This seems to be the same effect which James has
Folks,
Adobe, in collaboration with Google, has contributed a new CFF parsing
and hinting engine. The last few months it was my job to fully
integrate the code into FreeType, and I'm very pleased with the
results. Here are links to the relevant blogs:
http://adobe.ly/12mJWGv
On 1 May 2013 20:16, vernon adams v...@newtypography.co.uk wrote:
That's look like good stuff.
Will this new code also be integrated into ttfautohint library? :)
Its CFF so no
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Will this new code also be integrated into ttfautohint library? :)
Not directly, since ttfautohint can't handle CFFs. However, maybe the
algorithm influences the auto-hinter also which in turn could
influence ttfautohint.
Werner
___
On 1 May 2013, at 11:18, Dave Crossland d...@lab6.com wrote:
On 1 May 2013 20:16, vernon adams v...@newtypography.co.uk wrote:
That's look like good stuff.
Will this new code also be integrated into ttfautohint library? :)
Its CFF so no
That's just plain lazy :)
surely there's some
Its CFF so no
That's just plain lazy :)
surely there's some crossover with ttf?
Not really, since TrueType doesn't have the concept of `hints' at all.
ttfautohint emulates Type 1 hints to a certain extent, but those hints
are created by algorithm (i.e. by FreeType's auto-hinter), while
46 matches
Mail list logo
