Here are some screenshots, were the bad.jpg is a good approximation
of the original situation.
Please try ftview and/or ftdiff on this particular font.
Am i again asking the wrong mailinglist?
Yes, your question really belongs to freetype list.
Not necessarily.
I don't know why
I do have one small question, why is the autohinter so ugly? (Is
this on purpose?)
You are joking, aren't you? You should read, for example, this
article
http://www.tug.org/TUGboat/Articles/tb24-3/lemberg.pdf
to see how the autohinter is (more or less) working. On the other
hand, native
Attached patch makes second argument of ps_mask_table_set_bits const
and adjusts rest of the source accordingly.
Applied, thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
I've identified the point of the regression as the change from
ttinterp 1.96 to 1.97.
I shall revert to rev 1.96 pending a proper fix.
David, please handle this!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
I`ve downloaded freetype-1.3.1 from sourceforge
Uh, oh, do you really need *that*? FreeType 1 is dead.
I saw on forums that others had problems with this so you might fix
this in the next release.
Thanks for the report; however, there won't be a new release.
Werner
I want to display the font “PMingLiU”, so I have to use the macro
“TT_CONFIG_OPTION_BYTECODE_INTERPRETER” to avoid the font broken.
And some font was uglily, so I open the auto hint.
When I use the macro “FT_LOAD_FORCE_AUTOHINT” or
“FT_LOAD_NO_HINTING”, the macro
I am getting very bad results autohinting Times New Roman (times.ttf
from Microsoft): see the attached image. I have turned off the
TrueType bytecode interpreter, and verified by single-stepping that
the autohinter is being used.
Any ideas about what I might be doing wrong are very
Here's another compiler warning we can get rid of: the stub version
of tt_size_ready_bytecode in ttobjs.c cshould be deleted because the
function is called only if TT_USE_BYTECODE_INTERPRETER is defined.
[...]
Applied, thanks.
Werner
___
I'm having some weird results when I vary the point size of some
fonts, for example if I desire a character with vertical point size
20 and horizontal point size 10 @ 203 DPI with unpatented hinting
enabled the output is really bad.
If I set the point size to 10x10 or 20x20 the result is
I get the following warnings building 2.3.4 on Solaris 7 with the Sun
C compiler:
This has been fixed in the CVS, I think, based on patches from Graham.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Attached font doesn't work with freetype CVS but works fine with
Freetype 2.2.1 . The font was embedded in a pdf file and works fine
with Fontforge.
Hmm, this font doesn't have a `cmap' table, which is invalid according
to the OpenType standard, and the behaviour is defined as
`implementation
Hmm, this font doesn't have a `cmap' table, which is invalid
according to the OpenType standard, and the behaviour is defined
as `implementation specific' in PDF standard (see section
5.5. in the PDF 1.6 specification).
I see but lots of real world PDF files have this kind of
I have a question about freetype and harfbuzz. FreeType1 includes
an extension to support OpenType text layout processing. But this
support hasn't become part of FreeType2. Why? Why does FreeType2
not use the codes of harfbuzz to support OpenType text layout
processing?
We have decided
I want to display the font “PMingLiU”, so I have to use the
macro “TT_CONFIG_OPTION_BYTECODE_INTERPRETER” to avoid the font
broken.
And some font was uglily, so I open the auto hint.
When I use the macro “FT_LOAD_FORCE_AUTOHINT” or
“FT_LOAD_NO_HINTING”, the macro
David,
just load an arbitrary font with ftview from the CVS and press the
space key repeatedly -- after some time, nothing gets displayed.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
# Personally, I'm one of the people who want FT2 to have support for
# text layout feature. I guess I feel sympathy with you. But we
# are minority among FT2 developers :-).
Perhaps a misunderstanding: I don't object to make FreeType handle
OpenType tables (see the validating stuff which we
In this particular case I think FreeType should do a default
action; this is, a missing `cmap' table should completely disable
functions like FT_Get_Char_Index (by returning either an
appropriate error and/or -1 for the glyph index) but still make
FT_Load_Glyph and friends work as expected.
Another old email which seems to be gone completely unnoticed. David,
please look at it.
Werner
---BeginMessage---
I've been trying to fetch information about PFR-fonts using freetype2 and came
up with few possible bugs (ft219)
1. External leading (pfr/pfrload.c)
And here's the patch to the accompanying email.
Werner
---BeginMessage---
Hello,
Found few possible minor bugs in PFR loading and fontmetrics calculations. Not
sure if my previous post about this got to mailing list, but here's patch I've
come up with.
Index: ./src/pfr/pfrobjs.c
1) fttypes.h contain a tab char (line 387) could it be changed to
spaces? VTK will not allow commits of files with tabs, and freetype
seems to prefer spaces also.
Fixed.
2) A compiler warning (ftsystem.c:278):
The reason why the drop-out mode is fixed to 2, is simply because
it's the only way to get decent rendering with most TrueType fonts.
OK. *Please* add some doc lines to ttraster.c so that innocent
viewers can recognize how to associate FreeType raster modes 1, 2, 4,
and 5 with the mode numbers
OK. *Please* add some doc lines to ttraster.c so that innocent
viewers can recognize how to associate FreeType raster modes 1, 2,
4, and 5 with the mode numbers in the specification (which are not
identical).
BTW, they have different enumerations in the Apple and MS
specification too...
I recently got a crash when running out of memory in open_face in
ftobjs.c. It was caused by the failure of destroy_charmaps to check
whether 'face' is null. [...]
It may be better to put the checks inside destroy_charmaps and
clazz-done_face. I leave that for David or Werner to decide.
To concentrate more on other features, IMO it would be good to have
a separate module for Indic. If that is possible, please let me know
when and where to submit the module and corresponding patches for
the same.
Please send patches to this list. If you think that you can reuse
code from
Can FreeType return glyph paths from mingliu and other fonts which
need the bytecode interpreter for positioning?
This should be possible. It would be illogical otherwise.
In my experiments, I've failed to get correct results, but that may
be my error — I may not have supplied the
Well, saying
ftgrid -f 1915 20 EPPGLH+DFHSMincho-W3-WIN-RKSJ-H.ttf
I get image A.
Pressing the `h' key I get image B.
BTW, I've compiled FreeType with `make devel', so the images use the
native TT bytecode interpreter.
Werner
___
Folks,
the current CVS code of FreeType contains the following #if
clause as the central part of handling unpatented hinting:
in ttobjs.c:
#if defined( TT_CONFIG_OPTION_UNPATENTED_HINTING) \
!defined( TT_CONFIG_OPTION_BYTECODE_INTERPRETER )
...
However, the
Well, saying
ftgrid -f 1915 20 EPPGLH+DFHSMincho-W3-WIN-RKSJ-H.ttf
I get image A.
Pressing the `h' key I get image B.
BTW, I've compiled FreeType with `make devel', so the images use
the native TT bytecode interpreter.
That's why it works for Werner - I run into
This seems to be a regression in freetype CVS (patented hinting is
enabled):
(gdb) run ppem /usr/share/fonts/windows/tahomabd.ttf
Starting program: /packages/ft2demos/bin/.libs/ftview
ppem /usr/share/fonts/windows/tahomabd.ttf
Program received signal SIGSEGV, Segmentation fault.
Interesting thing: only Cyrillic symbols are affected, while Latin
symbols, ciphers and punctuation marks are rendered exactly the same
way!
This is probably caused by the new default for the fallback hinter:
It's no longer `latin' but `cjk'. It seems that this needs some more
fine tuning.
This is probably caused by the new default for the fallback hinter:
It's no longer `latin' but `cjk'. It seems that this needs some
more fine tuning. Please try to set
#define AF_SCRIPT_LIST_DEFAULT 1
instead of value 2 in afglobal.c and report the results.
Here's something better,
When I use FT_New_Memory_Face, the phenomenon is more obvious than
FT_New_Face. I have enabled the built-in debugger, and traced those
message, I don't know how to determine where the leak:
What you've enabled is the normal debugger, not the memory debugger!
You should enable
#define
This is probably caused by the new default for the fallback
hinter: It's no longer `latin' but `cjk'. It seems that this
needs some more fine tuning. Please try to set
#define AF_SCRIPT_LIST_DEFAULT 1
instead of value 2 in afglobal.c and report the results.
Here's
please find the attached patch, any comments are welcome.
This looks good! Some issues:
. Please send me a PE font for testing.
. If possible, stay within the 80-characters-per-line limit.
. A more detailed ChangeLog entry would simplify my life
enormously...
Werner
all other platforms allow the debug level to be between 0 and 7.
Applied, thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
---BeginMessage---
As list administrator, your authorization is requested for the
following mailing list posting:
List:Freetype-devel@nongnu.org
From:[EMAIL PROTECTED]
Subject: Rotating auto-hinted glyphs in v. 2.3.4
Reason: Post by non-member to a members-only list
At
Just to follow up a bit, it appears that part of my problem was my
choice of flags to FT_Load_Glyph — since I wanted the glyph path
in font units, I passed in FT_LOAD_NO_SCALE |
FT_LOAD_IGNORE_TRANSFORM. It appears, however, that this ended up
by-passing the hinter, and so my glyph paths
Here is what I get after installing CVS version (01.png
attached). it's not a Cyrillic problem, interface is in English
(Tahoma).
This is wrong!
David's last patch to fix various crashes was incomplete (making
FreeType reject many valid glyphs); I think he'll soon correct it.
Werner
this patch speeds up a lot programs that scan a directory of files
and load every font they find using the code like below: [...]
Applied, thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
So, to sum up: the first definition refers to the centre of the
stroke; the second to the top edge.
Thanks for your analysis.
Thus (depending on whether there are other discrepancies that I have
not had time to search for) we ought to either change the definition
of
In order to have a separate module for Indic autohinting, here I am
giving two files and few patches to be added in the cvs.
Thanks, applied! Please test.
Have I missed anything?
I've added a ChangeLog entry which I ask you to provide the next time.
Werner
FreeType 2.3.5 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
or
http://sourceforge.net/project/showfiles.php?group_id=3157
The latter site also holds older versions of the FreeType library.
See below for the relevant snippet from the CHANGES
I am new to freetype develpment
I have faced a problem
I have a GeneralFont in which i have GlyphArray
OnKeyDown I use to create new Bitmap
But after creating 3-4 bitmaps
Out of memorr error came!!!
fnt-glypharray=new CGlyphInfo();
fnt-glypharray-bitmap=new FT_Bitmap();
Urgh.
I am using freetype 2.3.1,
You should switch to the just-released version 2.3.5 and try again.
I have craeted a general font class, with the help of which, i can
create any type of font In general font class, i have an instance of
glypharray, glypharray contains FT_Bitmap,
I am unable to get the glyph advance.x,it remains zero, advance.y
value keep on changing I am using the folowing functions after
creating face...
Again: Please provide a *complete* example which we can compile, and
which exhibits your problem.
Werner
I'd like to get access to some of the CID-specific info (for
example, the Registry/Ordering/Supplement triple) from an FT_Face.
I understand how to do this using internal headers/structs, but that
seems fragile and not the best way. What would be the correct way
to do this? I'd be happy to
I'm just updating VTK to use 2.3.5, and have 2 issues:
1) in ftglyph.c in FT_Glyph_Copy(), the 'target' param is
dereferenced before it is checked for being null, this was not so in
2.3.4 and seems wrong.
Fixed in CVS. Thanks for the report.
Werner
Folks,
I've released 2.3.5 without testing whether it compiles with a C++
compiler. And of course, it doesn't. In case you need to do this,
please use the CVS instead.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
I've gone the path you suggested and added a CID service. At
present, it provides access only the Registry/ Ordering/Supplement
for CFF CID fonts.
Maybe some day we need more, so please design something extensible...
What's the best way to integrate in the FreeType sources (assuming
you're
I hope this is extensible — I'll probably need to add more myself
soon.
It looks good. However...
Here's the patch:
please resend the patch as an attachment: almost all files have been
incorrectly folded.
Werner
___
Freetype-devel mailing
please resend the patch as an attachment: almost all files have been
^
incorrectly folded.
I mean `lines'.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
please resend the patch as an attachment: almost all files have
been incorrectly folded.
Sorry about that; here you go.
Applied, thanks!
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Perhaps not everything was checked into CVS? It looks like a few
files are missing:
src/base/ftcid.c
include/freetype/ftcid.h
include/freetype/internal/services/svcid.h
Oops! Fixed, thanks.
Werner
___
Freetype-devel mailing
I have an idea that baseline can be computed through glyph-metrics
but can anybody guide me. how can i exactly get baseline position
value
What do you mean with `baseline position'? The vertical distance
between lines? Please give more details and probably an example of
what you need.
I want to give user a facility to specify chacter set or unicode
for a face how can i do this
This is described in the FreeType API reference. Have a look at
FT_Select_Charmap and friends.
Werner
___
Freetype-devel mailing list
Can any body give me a snippet od code that can help me in
determining baseline
I think you have the wrong concept. Normally, you *define* the
baseline and put characters on it.
I have studied samples like ftstring... can't get it yet
You put glyph after glyph onto a common baseline. This
I am using FT_Glyphslot_Embolden and so far it seems to work quite
well. However, the default extra boldness (1/24 em) is too great
for my purposes, and ought to be settable via an argument, because
different values are needed at different times. For example, 1/32 em
is adequate for making
I have updated VTK to freetype 2.3.5 and there are only 2 compiler
warnings this time (much better than 2.3.4). They are here:
http://www.vtk.org/Testing/Sites/krondor.kitware/Darwin-c++-carbon/
20070727-0300-Nightly/BuildWarning.html
I have searched the archive of this list, so I hope I don't ask neither
a trivial question nor an already answered question. [...]
Sorry for my late replay which isn't very helpful...
David is still on vacation, AFAIK. Please resend your question from
time to time until he finds time to
ftoption.h documents and defines FT_CONFIG_OPTION_POSTSCRIPT_NAMES,
but the compilation of psmodule.c is controlled by
FT_CONFIG_OPTION_NO_POSTSCRIPT_NAMES.
Fixed, thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
And - one other thing - we need to enclose the whole of pstables.h
in
#ifdef FT_CONFIG_OPTION_ADOBE_GLYPH_LIST ... #endif
This is not correct. For example, ft_standard_glyph_names is used in
ps_get_macintosh_name which is not within the scope of the
abovementioned macro.
Werner
Sorry about this stupid question, but I certainly remember me using
ftview on my old machine with OpenSUSE. But now, using Ubuntu 7.04 I
can't find it anywhere.
In case you can't find it, check out the `ft2demos' CVS module.
Werner
___
I'll prepare a patch if I have time,
You make a backup up of the original file and change it to your
needs...
and indeed install GNU diff if I can find it and understand yet
another utility...
then simply say
diff -u old-file new-file file.diff
on the command line. This is all. No
Okay - but I suggest that we need (or is there already?) a macro to
prevent compilation of these large tables, which are about 60K in
size, when they are not needed.
Hmm, shouldn't a compiler simply ignore it in case it isn't needed? I
can't imagine that such an optimization is left out...
When i write some text using freetype, How can i come to know that i
reach end of line i.e
xsaEnd
after 'd' i should come to know that i reach end of line, so that i
can move to next line
This depends
Please apply the otvmathconstant patch
Applied.
The patch coverageCount passes an extra argument to
otv_Coverage_validate (the expected number of glyphs, or -1 if this
is not known -- it isn't always) and then checks that these counts
match.
Applied.
I may be wrong, and perhaps the
I would like to update VFlib [1] from Freetype 1 to Freetype 2.
Aah, Hirotsugu's project is still alive? I met him a few years ago in
Tsukuba, but even then he told me that he didn't have much time to
work on it...
So I would like to know if Freetype 2 would be sufficient for using
Type 1
Applied. However, I think there is a mistake for the
SingleSubstFormat1 case:
idx = otv_Coverage_get_first( Coverage ) + DeltaGlyphID;
if ( idx 0 ||
idx + DeltaGlyphID 0||
That entire patch chunk was wrong (and unneeded in the first
place). This should back it out.
Applied, thanks.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
If we can't change the existing function then I agree that a new
one is a good idea, but I would prefer
FT_GlyphSlot_Embolden_By_Weight or something like that to give
an idea of the meaning of the new parameter.
FT_GlyphSlot_Embolden exists only for historial reasons, and is a
There seems to be a bug due to 2.2 to 2.3 changes in TrueType
hinting. See the example aring U+00E5 in DejaVu Sans Book [1] where
the ring above isn't properly rendered at some size with freetype
2.3.5. The problem seem to occur wiht some MDRP instructions.
Thanks for the report; please add
I've downloaded the xpdf source package from sourceforge.net along
with the freetype package
in building the freetype project first, I've done:
./configure
make
make install
the latter fails with error:
make: *** [/tmp/freetype-2.3.5/objs/libfreetype.la] Error 1
Hmm. I doubt that
Yes, I'm running 'make install' as the superuser
Then please post a log of the complete compilation process from a
freshly unpacked tarball (compressed). I assume problems with
libtool; maybe upgrading to another version helps.
Werner
___
I needed to create links in /usr/bin for ar, ld, ranlib, strip
to link to the gxx commands in /usr/sfw/bin
Hmm. FreeType should build with standard Sun compilers too.
I couldn't find an easy way of addressing this in your instructions.
What instructions do you expect? Normally, the
I found that FreeType can not get the correct glyph index from the
font “Simsun-extb” corroding the Unicode of the character.
Where can I find this font?
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
I found it in Windows Vista system. It's size is about 15Mb.
I don't have Vista.
Please check whether the problem exists with the simsunb.ttf file
which can be found with google on some Taiwanese hosts. I'll then
download it from there. Otherwise, I ask you for making it available
privately
are there any plans afoot to support 'cmap' format 14 (the variant
selector table)?
I've skimmed the specs but didn't look more closely. Do you
volunteer? It seems that we need a special interface for that, right?
Werner
___
Freetype-devel
Another point is that the arrays returned are 0-terminated. this
assumes that 0 is not a valid selector variant, but I don't see code
to check for this in the cmap 14_validate function. will add these
George, what do you think of undefining TT_CONFIG_CMAP_FORMAT_14 until
the specs are
ok, I have several issues with this patch
I've expected this, but you have been silent :-)
(and I'm writing a fix right now):
Great.
-naming: I prefer all new APIs to use the FT_Object_ActionName
template,
OK.
- documentation: the API documentation doesn't make the purpose of these
- documentation: the API documentation doesn't make the purpose of
these functions very clear. An explanation of what a variant
selector charmap is would be welcomed
Unicode decided that some characters had variant forms. [...]
I've moved the cmap 14 API into a new section (in
http://blogs.msdn.com/text/archive/2007/04/23/wpf-font-selection-model.aspx
I wonder whether step 1 in this algorithm should be incorporated
directly into FreeType...
I did this. FreeType now recognizes bit 9 of the `fsSelection' field
in the `OS/2' table and sets FT_STYLE_FLAG_ITALIC
1. I want to use pure python.
Hmm. If I remember correctly, a longer time ago there was a message
about someone having written a python wrapper for FreeType. Whether
this still exists or whether it is up to date, I don't know.
Werner
___
I'd like to be able to know when Freetype will use a strike size for
an FT_Face after the size has been specified. This will let me
select monochrome rendering for any glyphs which don't happen to
have bitmaps in the strike. [...]
I'd much rather just get the strike_index somehow and check
When I compile a program that use freetype it search the header in
/usr/include/freetype/config/ but the headers are
in/usr/include/freetype2/freetype/config/ so in file ftheader.h in
/usr/include/freetype2/freetype/config/ u must add a prefix
freetype2/ in the #include freetype/.
I
This worked for me a while ago when compiling FreeType into a
Windows DLL:
#define FT_EXPORT(return_type) __declspec(dllexport) return_type
#define FT_EXPORT_DEF(return_type) __declspec(dllexport) return_type
Thanks. Is this already handled if you use the Visual Studio project
files?
I tried to compile the solution bundled with 2.3.5. The solution built
without error, but with dozens of warnings such as the following:
1c:\development\build\gnuwin32\src\freetype\2.3.5\freetype-2.3.5\src\tr
uetype\ttinterp.c(772) : warning C4273: 'TT_New_Context' : inconsistent
dll
I need to make freetype render into a flow_down bitmap, but with the
byte order of each row reversed.
Example: For a bitmap that is 24 pixles wide (3 bytes), byte 2 is
the top left, byte 1 is top middle, and byte 0 is top right. The
start of the next row will be byte 4, etc.
I think you
In the distribution that I downloaded,
Aah! Which one, downloaded from where?
I see the following two lines commented out (along with a
description along the lines of what you are suggesting):
/* #define FT_EXPORT(x) extern x */
/* #define FT_EXPORT_DEF(x) x */
Later in the
Errrm...
No reaction? :(
I'm abroad, sorry. Will take care next week, I hope.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
I use compiler is Metaware hcarc4.5a, FT2 version is 2.3.5. I get the
following compiler warnings: [...]
So, I decide that disable the display of 572 warning message with
pragam Offwarn:
CFLAGS += -Hpragma=Offwarn(572)
[...]
CFLAGS += -Hoff=Behaved
Would you like to contribute
I am curious to know, if this issue has been resolved in post 2.2.1
releases.
I think yes. It was a fundamental flaw in our rasterizer due to a
misinterpretation of the TT specs.
Werner
___
Freetype-devel mailing list
I was just trying to use the FreeType library in a C# application,
with Visual Studio 2005. I have downloaded the freetype6.dll file
from the indicated website and thought that by reading the header
files (*.h) I could create an API class to use FreeType from C#
(.NET) applications. But
Pass options from one configure script to another AS IS (not
expanded). That needed for options like
--includedir='${prefix}/include'. Patch follows: [...]
Applied to the CVS, thanks.
Werner
___
Freetype-devel mailing list
The first glyph in the font F4.1.ttf (index:3058, maybe the Chinese
character 版) can not be parsed.
Uh, oh, another Type 1 operator (callothersubr)! This font is simply
not a valid CFF! It's pure luck that other parsers support it.
Hopefully, it's not your company which produces such weird
When I use the codes: [...]
it displayed wrong.
And these codes are displayed correctly. [...]
I just can repeat: Please provide a compilable, stand-alone code
snippet which demonstrates your problem. Additionally, have a look
into ftbench.c (from the ft2demos bundle) which also uses
Referenced to ftgray.c's comments, I have compile `ftgrays' with the
_STANDALONE_ macro defined. [...] My question is how to us this
lib after compile it? Anybody would give a usage demo?
I believe that such a demo usage has never been given on the list. In
case someone can provide this I
I've been working on a new rasterizer to replace the Freetype
rasterizer for aliased painting in the raster paint engine,
But you haven't mentioned that this won't work for fonts...
Werner
___
Freetype-devel mailing list
so if I understand correctly, this is a monochrome-only (not
anti-aliased) rasterizer
No. According to the links given in the mail (and following the links
further) it's anti-aliased but...
that probably doesn't handle the subtle drop-out control rules we
need for fonts.
it supports only
FreeType is designed to read and rasterize fonts. It doesn't
have conversion in mind, and while conversion could be done with
FreeType it would be a lot of coding on your part.
Can Freetype2 read ttc files and access all the sub fonts?
Of course it can. Internally, a non-TTC font is
Can Freetype2 read ttc files and access all the sub fonts?
Of course it can. Internally, a non-TTC font is handled as a TTC
with exactly one subfont. However, as George has already mentioned,
it's not the right tool to convert fonts.
In case you really need a TTF (or TTC) converter to
301 - 400 of 3661 matches
Mail list logo
