Dear Paul,
I could reproduce the crash by http://aquawicket.com/FreetypeBug.zip ,
but I could not reproduce it with smaller program like attached one.
Does this bug occur when a program uses both of SDL and FreeType2?
Regards,
mpsuzuki
suzuki toshiya wrote:
I will check.
Regards,
mpsuzuki
In addition, if I build freetype-2.4.9 with bundled MSVC 2008 project file
and link FreeTypeBug.exe with freetype249MT.lib or freetype249ST.lib (release
multithreaded or singlethreaded), the crash does not appear.
Regards,
mpsuzuki
suzuki toshiya wrote:
Dear Paul,
I could reproduce the crash
Building with gcc-4.4.5 and -Os give this warning
/usr/src/freetype-2.4.10/src/base/ftglyph.c: In function 'FT_Glyph_To_Bitmap':
/usr/src/freetype-2.4.10/src/base/ftglyph.c:296: warning: dereferencing pointer
'bitmap.17' does break strict-aliasing rules
From the documentation:
### Stem Width and Stem Positioning
`--strong-stem-width=`*string*, `-w`\ *string*
: ttfautohint offers two different routines to handle stem widths
and stem positions: 'smooth' and 'strong'. The former uses
discrete values which slightly increase the stem
Did a little testing using OpenSans Reg Bold under Win7 (cleartype
greyscale) and WinXP (cleartype greyscale) but, to be honest, i didn't see
any difference :) except under Win7 there the `--strong-stem-width=g gave a
tiny (i think) better rendering.
In theory, what difference should there
Hi
it is the 'G' option that gave the only 'different' rendering
i saw, and it's not overall better anyway
Hmm. Looks to me like Capture-G-win7GDI.PNG is the best of those 3,
though the c and e and some numbers have some issues, there are less
overall than the other 2.
Alas I think there is a
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
I feel fine today!
A.
Sent from my mobile phone.
On 01.07.2012, at 21:13, Karsten Luecke karsten.lue...@kltf.de wrote:
When you say something like
strong-stem-width=g gave a tiny (i think) better rendering
could you please explain what your definition of better is, plus a link to
:)
On 01.07.12 21:34, Adam Twardoch wrote:
I feel fine today!
A.
Sent from my mobile phone.
On 01.07.2012, at 21:13, Karsten Lueckekarsten.lue...@kltf.de wrote:
When you say something like
strong-stem-width=g gave a tiny (i think) better rendering
could you please explain what your
Dave,
workin' on it :)
A.
Sent from my mobile phone.
On 01.07.2012, at 22:03, Dave Crossland d...@lab6.com wrote:
Hi
it is the 'G' option that gave the only 'different' rendering
i saw, and it's not overall better anyway
Hmm. Looks to me like Capture-G-win7GDI.PNG is the best of those
In theory, what difference should there be under which render
settings?
First of all, I'm not sure whether the selection of the three
rendering modes really works as expected. My only test was with
current git version of FreeType, and there everything's fine...
To be sure to really see the
Ok Thanks for that Werner,
I will test mainly using those 2 args, plus the original instructed truetype.
Also, i would like to test this with fonts that are 'industry standard' of
good manual TT instructing. I have the Droids and Ubuntu, but am thinking to
seek permission to test on some
On Wed, Jun 27, 2012 at 1:22 PM, Werner LEMBERG w...@gnu.org wrote:
[...] the drawing functions ultimately inherit the error codes from
FT_Glyph_To_Bitmap currently. Therefore it has to be something
different from those defined in fterrdef.h to distinguish. It would
be good if freetype
I will try and do some extensive tests tomorrow; sans, serifs, win7,
winXP, diff browsers, etc. I will prob add in Android too, as
ttfautohint can effect fonts under Freetype too.
Thanks in advance for that! I think it's best to directly compare the
algorithms (this is `-w gGD' vs. `-w ')
On closer inspection it is the 'G' option that gave the only
'different' rendering i saw, and it's not overall better anyway.
If you say `-w G', this means that you get the smooth algorithm for
gray and DW ClearType, and strong for GDI ClearType, at least in
theory.
Shots attached.
Thanks!
I've got a bit lost keeping up with what rendering the different
browsers on Windows* use now.
Here is a nice table:
http://www.smashingmagazine.com/2012/04/24/a-closer-look-at-font-rendering/
No idea whether this is correct, though...
Werner
PS: I faintly remember that there
Here is a nice table:
http://www.smashingmagazine.com/2012/04/24/a-closer-look-at-font-rendering/
No idea whether this is correct, though...
Reading the comments on that page, it seems that it is *really*
complicated. Another facet is that according to
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:
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.
Aah. Then the rasterizer logic in
BTW, what font exactly is `Open Sans' used in your test images? I
want to have a more detailed look at the stem alignment.
It is OpenSans Regular from the Google webfonts server.
I've got a bit lost keeping up with what rendering the different
browsers on Windows* use now.
Here is a
20 matches
Mail list logo
