Same problem here. But only when running on a gnulinux laptop. Bottom of window
is outside the desktop at bottom of screen. Only way to access the run button
is to use the modifier key to move the ttfautohintgui window, so that the top
of the window goes outside the desktop at top of screen.
Sorry for a dumb question;
I've built on OSX with GUI and app info gives me.version 95.54-5648
Is that correct version for the latest git build?
-v
On 18 Oct 2013, at 23:42, Werner LEMBERG w...@gnu.org wrote:
Folks,
ttfautohint now supports multiple scripts, following the recent
Now when running ./bootstrap i get the following;
m4/sys_socket_h.m4
m4/sys_types_h.m4
m4/threadlib.m4
m4/unistd_h.m4
m4/warn-on-use.m4
m4/wchar_t.m4
Finished.
You may need to add #include directives for the following .h files.
#include fcntl.h
#include getopt.h
#include
This seems to be OSX specific? So maybe someone else on OSX could confirm?
When pulling the ttfautohint sources from git, the gnulib directory is empty
and running ./bootstrap fails (because gnu lib/gnulib-tool does not exist).
Pulling gnulib manually from git into the ttfautohint source
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
:) 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 'darkness
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
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
Maybe fontforge is doing this but…
3 things;
1. The problematic glyphs were 'special' in that they had been through
ttfautohint and hinted as 'composites'. Unhinted, or hinted but without the
'composites' option, versions of same font had no problematic glyphs.
2. The problematic glyphs were
Same font file goes to all browsers. Just to keep things simple. The font file
would be a single autohinted file that gets served to whichever OS/browser
calls for it, as you say OSX should ignore the truetype instructions.
-v
On 8 Apr 2013, at 22:24, Jungshik Shin (신정식, 申政湜)
Hi
I think the designer of the font actually found a 'work around' when generating
the fonts, so the page is rendering ok now. The 'work around' is not an ideal
solution though. I will test some more and see if the original issue is still
occurring. I will set up a test page too.
Many thanks
,
Jungshik
2013/3/27 Vernon Adams v...@newtypography.co.uk
Hi
I think the designer of the font actually found a 'work around' when
generating the fonts, so the page is rendering ok now. The 'work around' is
not an ideal solution though. I will test some more and see if the original
issue
There appears to be a OSX Chrome render issue with specific glyphs auto
instructed with ttfautohint.
Please see http://www.georgduffner.at/ebgaramond/
On OSX Chrome all characters that are composite substitute glyphs are being
rendered badly (part wiped out, missing stems etc)
The site linked
Isn't the freetype-devel list still used as the ttfautohint-devel list?
Apologies if that's not the case, but i simply replied to the ft-devel post
'[ft] ttfautohint 0.95 has been released' from 8th March to post this issue.
-v
On 26 Mar 2013, at 12:55, Alexei Podtelezhnikov
Werner,
It's an issue when ttfautohint is using dummy glyphs as a workaround for
hinting composite glyphs. Untill know it was assumed that it was a problem free
workaround. My report shows that it seems to be creating problems on OSX
Chrome. Of course it could be a bug caused by something that
Maybe you could please consider developing your ideas within the metrics and
kerning system in fontforge? :) Fontforge's metrics and kerning could do with a
kick in the butt :)
That could provide the learning process and improve / bring new ideas to
already existing software.
Another idea
I know i've asked this before :) but, could this concept also be used to
Decrease the xheight at particular char sizes? Because decreasing the xheight
can also increase legibility at some small sizes on some fonts.
-v
On Sep 18, 2012, at 10:02 PM, Werner LEMBERG w...@gnu.org wrote:
Folks,
Werner,
Would there be any significant differences between the hinting from a
ttfautohint built using Freetype 2.4.7 against one built using say 2.4.10 ?
thanks
-v
On 7 Aug 2012, at 21:24, Werner LEMBERG w...@gnu.org wrote:
ttfautohint 0.92 has been released.
I was hoping this would fix the 'Q-tail' effect, but it hasn't. Please see the
tails on uppercase Q's at 17, 16, 15 px
https://lh5.googleusercontent.com/-kA_3D758Iks/T_GZDZ5yIeI/D4E/9Fl0PH15BIY/s949/ubuntu-XP-firefox-ttfautohint-wgGD.png
ps i notice that file sizes of ttfautohinted fonts
There is an aspect to all this which is maybe most relevant; how do these
settings effect rendering across web browsers?
I've got a bit lost keeping up with what rendering the different browsers on
Windows* use now. The default on Chrome seems to be best, as it sensibly seems
to not use
Those shots were using the win7 system font viewer- which I think makes it
plain old gdi cleartype?? Don't think direct write at system level comes until
win8. I maybe wrong, but I thought dw was found in explorer 9 and Firefox 7+
but not the win system.
-v
Werner LEMBERG w...@gnu.org wrote:
it works! :)
much thanks
-v
On 16 Jun 2012, at 05:00, Infinality wrote:
* Fix Oxygen rendering if usint TT hinting, and other ttfautohinted fonts
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
If no-one is familiar with David Kindersley's experiments with optical spacing
it's well worth looking at.
Info is scarce, except from
http://www.kindersleyworkshop.co.uk/shop/optical-letter-spacing.php
Basically DK built an apparatus for viewing lettering, to gauge spacing before
he cut the
Werner,
Not sure i understand 100%, but isn't it significant that the infinality
patched freetype only renders ttfautohinted fonts in this way? An
infinality patched freetype (bug or not) renders other instructed
truetype fonts perfectly normally afaik.
-vern
On 21/04/12 21:01, Werner
Ok, so i've tested this with a infinality patched freetype 2.4.9 w Kubuntu.
Using ftview or the system font viewer any truetype font instructed with
ttfautohint (i'm using 0.8) renders as Erik has shown. Pretty much the
same screwed up rendering that we saw with old versions of ttfautohint w
On 09/02/12 15:17, Werner LEMBERG wrote:
So, in theory, it could be possible to add a feature to allow the
user to set the threshold ? :)
Not only in theory! We are going right now to implement that. Have a
look at the `autohinter-properties' branch in the FreeType
repository.
Thats
On 09/02/12 20:49, vernon adams wrote:
It's allways been noticeable to me that when i manually hint fonts on
Windows GDI, the font at small pt sizes renders on Freetype sytems with
the x-height and Caps height lower than under Windows GDI. Therefore it
makes sense that the reverse happens when
On 10/02/12 03:07, Infinality wrote:
Hi Erik!
Distortion measurement and outline optimization is what's needed.
Not sure if this is easier, but I've thought that the easiest way
conceptually would be to force at least 1 pixel between any two
horizontal stems when available. Like, if you have
disclaimer - it's an article written by the guy who accused me of
piracy, so my views may be biased :P
For sure though, ttfautohint cannot better well executed manual hinting
for fonts being rendered on windows GDI OS's. Would be more
informational to see GDI grayscale and Directwrite
On 08/02/12 21:53, Behdad Esfahbod wrote:
On Wed, Feb 8, 2012 at 4:10 PM, vernon adams v...@newtypography.co.uk
mailto:v...@newtypography.co.uk wrote:
disclaimer - it's an article written by the guy who accused me of
piracy, so my views may be biased :P
Isn't it a compliment coming
As a kde user, the qt dependency is a non-issue for me :p
but... the build is reliant on qt4.8, which is still pre-release, so
even i have to rebuild my whole qt libs to a non-stable state just for
ttfautohint. Fun but overkill.
Using the qt library for ttfautohint is understandable, but i
On 24/01/12 08:46, Werner LEMBERG wrote:
As a kde user, the qt dependency is a non-issue for me :p but... the
build is reliant on qt4.8, which is still pre-release, so even i
have to rebuild my whole qt libs to a non-stable state just for
ttfautohint. Fun but overkill.
Sorry for that.
On 24/01/12 11:32, Adam Twardoch (List) wrote:
On 12-01-24 10:25, Werner LEMBERG wrote:
AFAIK, Qt uses the native GUI elements of the host OS; it's just a
wrapper to provide a consistent platform-independent interface.
Regarding a special GUI for Cocoa: *I* won't do that :-)
Yes, Qt on Mac or
On 24/01/12 19:05, Werner LEMBERG wrote:
I agree, however, that making a dependancy on Qt version 4.8 is
currently a bit early. Using 4.7 would be recommended at this
point, if possible.
Compilation should work now with 4.7 (or even older versions).
Adam, please try compilation again. I've
Could this be the same reason why 0.6 crashes for me on osx with a
segmentation fault when autohinting any font?
-v
-Original message-
From: Werner LEMBERG w...@gnu.org
To: freetype-devel@nongnu.org
Cc: roberts...@google.com, dcrossl...@google.com
Sent: Tue, 27 Dec 2011, 06:29:50
Werner,
What could be the differences between a font hinted with ttfautohint
rendered with freetype, and a non-hinted font rendered with freetype's
via it's built-in autohinter?
As i understand it there should be no difference, as ttfautohint is
based on freetype libs anyway. But what if a
On 30 Oct 2011, at 07:31, Werner LEMBERG wrote:
Very interesting! Among other things, ttfautohint's `prep' table is
used to set up some elements of the storage area. Maybe Apple's
interpreter resets this area while rendering a new glyph?
Unfortunately, the TTF reference manual of Apple
Hi,
After some quick tests it seems that the same render issues on iOS
printing to postscript printers on OSX remain, or at least partly(?) I
should later test same font autohinted with v0.3 and look for
differences/similarities.
I have put iOS screenshots at
They are not comparable. As far as i know ttfautohint takes a completely
different approach that fontforges autohinter. Ttfautohint is far better at
auto hinting truetype fonts than the fontforge autohinter.
Andrey, if you know how to get comparable results with fontforges autohinter,
please
Great news Werner :)
Re: the gui - with control over something like 'controlling the width of blue
zones', it would be ideal if the user had a preview/visual feedback of what any
blue zone tweaking was doing. Same with other controls; some kind of 'preview'
would be ideal.
vernon
On 17
Hi, sorry i forgot about that.
Patch wouldn't apply
i get -
patching file tafpgm.c
patch: malformed patch at line 14: };
My patch file looks like this (taken from your post) -
diff --git a/src/tafpgm.c b/src/tafpgm.c
index 1268e29..3874844 100644
--- a/src/tafpgm.c
+++ b/src/tafpgm.c
Thanks for that.
Also, how easy might it be to implement an Option that auto-instructs only the
Y-axis ? One thing i'm noticing is that font file sizes almost double as a
result of ttfautohint (10-20% more than manual hinting) and I'm wondering if
much of the x-axis stuff might be
Builds runs for me on OSX 10.6.8 but on Ubuntu 11 i get Error code `0x06'
while autohinting font each time i try and run. Seemed to have built fine tho.
-vern
On 30 Jun 2011, at 08:43, Werner LEMBERG wrote:
ttfautohint 0.1 has been released.
It is available from
The 'final image' is simply the ttfautohint instructions with the addition of
links (double links work best in this instance). I did no extra hinting from
fontlab - what you see afaik is pixel fitting from the ttfautohint
instructions, plus the effect of the additional links. Sadly Fontlab has
Builds runs for me on OSX 10.6.8 but on Ubuntu 11 i get Error code `0x06'
while autohinting font each time i try and run. Seemed to have built fine tho.
-vern
On 30 Jun 2011, at 08:43, Werner LEMBERG wrote:
ttfautohint 0.1 has been released.
It is available from
ahh thanks - default for libfreetype.so install is /usr/local/lib. Ubuntu had
installed old freetype libs to /usr/lib. :)
now fixed working. many thanks -v
On 30 Jun 2011, at 13:40, Werner LEMBERG wrote:
Builds runs for me on OSX 10.6.8 but on Ubuntu 11 i get Error
code `0x06' while
On 25 Jun 2011, at 06:56, Werner LEMBERG wrote:
Please try the current git snapshot and play with the options
--hinting-range-min and --hinting-range-max.
Currently, the default value for hinting-range-max is 1000; this means
that the autohinter tests all ppem values up to 1000 to find
Thanks again for your invaluable help in testing ttfautohint!
My pleasure. Very keen to see a working autohinter available to font
designers :)
The feedback i'm getting from my screenshots is that the ttfautohint
output is overall superior under DirectWrite to the original hinted
Hi Werner,
Do you think it's possible that the autohinter can be tweaked to lessen the
effects of the aggressive vertical filtering of GDI?
or is it already at the limits of what's possible for GDI?
The feedback i'm getting from my screenshots is that the ttfautohint output is
overall superior
http://code.newtypography.co.uk/
Just posted screenshots of ttfautohint output under DirectWrite (Cleartype
Grayscaling).
Interesting. imo, generally the ttfautohint output is superior to the original
fonts' output, though there are some glitches, e.g. dot accents are malformed.
I have posted new screenshots from my testing with Werner's ttfautohint
library. Goto http://code.newtypography.co.uk/
Have tested - UbuntuFont, Vera Sans, Vera Sans Bold, Playfair, Copse.
Looking good. The shots so far are from the biggest headache, Windows GDI
Cleartype, but i will also
However, I don't understand where the differences come from.
Nothing in the hinting instructions added by ttfautohint is
specific to ClearType. It uses a large number of twilight points
which is probably unusual a bit, but this doesn't explain how the
asymmetry can come into existence.
On 19 Jun 2011, at 16:37, Werner LEMBERG wrote:
I'm guessing the render differences are caused by my tests being run
on WinXP Win7.
Interesting. Is Win7 OK? Does WinXP only fail?
On Chrome the Win7 XP were near identical, as the browser uses GDI on both
OS's.
I will do some tests
Hi
updated ttfautohint from the repository made a better waterfall test page.
The ttfauto hinting looks much better imo, though still not 100% perfect yet :)
i have now also included a test of a version of Ubuntu Font with TTF
instructions tables replace by instructions from Fontforge's
I have added detailed shots to http://code.newtypography.co.uk/?p=898
At 400% magnification the difference does not look so great, but at 100% the
difference in rendering is noticeable. I'll leave hinting interpreation to the
experts, but to my eyes the vertical extremes of curves are not being
I've carried out some simple tests using ttfautohint with the Ubuntu Font on
Win XP Win7, Chrome12 Firefox4.
The screenshots are at http://code.newtypography.co.uk/
Looks good so far, but i shall test more fonts, particularly a serif and a bold
display face. I chose Ubuntu Font as i know it's
great. but i am embarrassed to admit that i have built the library but
have not found how to use the 'autohint' function :)
a quick howto, please!
vern
On 16 Jun 2011, at 21:20, Werner LEMBERG wrote:
One major problem still remains which I have to resolve in the next
days: Composite
Werner,
Sounds good.
I think i remember you saying that ttfautohint will not have a GUI. Is that
still the case?
vernon
On 15 Jun 2011, at 11:28, Werner LEMBERG wrote:
[Vern, I take the liberty to answer on the list also.]
That's very interesting and gives some pretty good results.
Werner,
judging by the gnome switcher it is possible to switch between hintslight,
hintfull, no hint etc, also sub pixel rendering etc without x server restart,
so I guess most of what I need is there. but would also need the ability to
fine tune those into switchable pre sets for the purpose
59 matches
Mail list logo
