This sounds like a good candidate for a property of the truetype
module...
I think I have a workaround for now, but it would certainly be
easier if it were supported in the library.
OK. I'm still exploring how to introduce global properties in modules
(and, most of all, where to add
On Fri, Sep 7, 2012 at 11:53 PM, suzuki toshiya
mpsuz...@hiroshima-u.ac.jp wrote:
Tagoh-san, could you describe more about the advantage to put full CFR
support into FreeType?
I think, the significant advantage is the minimized cost of the migration
from concrete TrueType/OpenType with 64k
On Fri, Sep 7, 2012 at 1:40 PM, Werner LEMBERG w...@gnu.org wrote:
Not necessarily. It shouldn't be too difficult to provide the
necessary hooks so that a small library for handling composite font
objects on top of FreeType can reuse FreeType's code.
Sure. that sounds reasonable and I didn't
Chris Liddell wrote:
On 07/09/12 03:34, Akira TAGOH wrote:
On Thu, Sep 6, 2012 at 11:32 PM, Chris Liddell
chris.lidd...@artifex.com wrote:
I just think that Freetype should remain an engine which takes a font
from
some source, and uses it to to create outline or bitmap glyphs. I
would not
Another example that I recently stumbled across (and haven't yet
investigated fully) is the rendering of notdef glyphs. For Truetype,
Freetype is (correctly) using the TTF notdef glyph (the empty
rectangle), but for Postscript/PDF/PCL/PXL, the notdef is a
non-marking glyph. So, in the event
On 06/09/12 07:05, Werner LEMBERG wrote:
Another example that I recently stumbled across (and haven't yet
investigated fully) is the rendering of notdef glyphs. For Truetype,
Freetype is (correctly) using the TTF notdef glyph (the empty
rectangle), but for Postscript/PDF/PCL/PXL, the notdef is a
On Thu, Sep 6, 2012 at 11:32 PM, Chris Liddell
chris.lidd...@artifex.com wrote:
I just think that Freetype should remain an engine which takes a font from
some source, and uses it to to create outline or bitmap glyphs. I would not
like to see Freetype getting sucked into loading fonts by name
Loading a font face by its name is too platform dependent problem
(some platform may have multiple font management systems and their
registries are often left with no synchronization), putting everything
for CFR into FreeType2 would be slightly difficult. My concern is
that the system maintainer
I just think that Freetype should remain an engine which takes a
font from some source, and uses it to to create outline or bitmap
glyphs. I would not like to see Freetype getting sucked into
loading fonts by name (even if that was done by punting off the
fontconfig), or gaining any kind of
On Wed, Aug 29, 2012 at 11:45 AM, Werner LEMBERG w...@gnu.org wrote:
Any plans for Freetype3? It's been 12 years. Is it time yet for a
spring cleaning?
Since I'm very bad at API design, I won't start such a project, but
you are very welcome to discuss potential improvements, and it's very
At 10:26 30/08/2012 -0400, Alexei Podtelezhnikov wrote:
Can we ask FreeType users what do they want to have and have simplified in
API?
What do they not need too?
By users I mostly mean:
- Cairo and Pango (Behdad ?)
- Qt
- fontconfig
- ghostscript (Ken Sharp ?)
Should be Chris Liddell for
On Thu, Aug 30, 2012 at 11:26 PM, Alexei Podtelezhnikov
apodt...@gmail.com wrote:
By users I mostly mean:
- Cairo and Pango (Behdad ?)
- Qt
- fontconfig
Since there are a discussion to support the Composite Font
Representation in fontconfig, I'd like to see some APIs that
fontconfig let
Indeed, I think FreeType3 should have some distinction of APIs
between the APIs bound to real single font file, and APIs not
bound to. Maybe I should investigate the existing software and
make a list of referred APIs and their popularity.
Regards,
mpsuzuki
Akira TAGOH wrote:
On Thu, Aug 30,
I think FreeType3 should have some distinction of APIs between the
APIs bound to real single font file, and APIs not bound to. Maybe I
should investigate the existing software and make a list of referred
APIs and their popularity.
Please do so!
Werner
Is this because we ran out of FT_LOAD_XXX space? We used to control
Freetype with flags, now it is this API.
Potentially this is more flexible Freetype3 material.
Any plans for Freetype3? It's been 12 years. Is it time yet for a
spring cleaning?
___
On 08/29/2012 09:58 AM, Alexei Podtelezhnikov wrote:
Any plans for Freetype3?
I'm been thinking about that...
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Is this because we ran out of FT_LOAD_XXX space?
This is one of the reasons, yes. Another one is that controlling
modules with FT_LOAD_XXX simply doesn't feel right, since modules
belong to FT_Library objects and not to FT_Face.
Any plans for Freetype3? It's been 12 years. Is it time yet
The intended API looks like this now
FT_Error
FT_Property_Set( FT_Librarylibrary,
const FT_String* module_name,
const FT_String* property_name,
void* value );
FT_Error
FT_Property_Get( FT_Library
Werner,
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. As a user of the library, I don't care about
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,
well... This is definitely not my fault :-)
and the proposed property service is a big step in that
direction.
As
What are the void* pointers typically expected to point to...?
Property data structures.
As I suppose these void* values are often pointers to some malloced
memory in many cases, how is it expected that resource management of
that memory is done...? I.e., when the a list gets destroyed
Werner LEMBERG w...@gnu.org writes:
What are the void* pointers typically expected to point to...?
Property data structures.
As I suppose these void* values are often pointers to some malloced
memory in many cases, how is it expected that resource management of
that memory is done...?
FreeType. If there is ever a need to pass a new string to the
library (for which I currently don't have a use case), the data
will be copied.
Wait how does that work?
That suggests that freetype will copy any structure passed in into
malloced memory or something; otherwise, one
2012/8/22 Werner LEMBERG w...@gnu.org:
But since (AFAICT) the property mechanism is generic, the type of
the data structure wouldn't be known except to the eventual caller
of FT_Property_Get. Given this, how can FT_Property_Set know the
size of the data structure passed in, to malloc/copy it?
What are the void* pointers typically expected to point to...?
As I suppose these void* values are often pointers to some malloced
memory in many cases, how is it expected that resource management of
that memory is done...? I.e., when the a list gets destroyed because
a FT library is destroyed,
Folks,
it's embarassing, but I've screwed up my property proposal. The
reason is quite simple: While designing and discussing the interface,
I haven't looked closely enough at the source code, and only now I
have discovered the discrepancy between my faulty memory and the
reality...
However,
Hello Toshiya-san!
Sorry for the late response.
At present, FTC_Manager instance is allocated with FT_Library's
allocator, FT_Library object itself does not have a (list of)
FTC_Manager, so, it could be slightly difficult for set- property
functions to invoke the cache flusher. There might
Toshiya-san and I have met in Osaka, and we have enjoyed a great time
visiting the private museums of Motoya and Morizawa, two big font
companies in Japan.
While having a nice lunch, we've discussed how to control modules in
FreeType. In FreeType's `autohinter-properties' branch, I've posted a
28 matches
Mail list logo
