headers
Ian Britten | 3 Jun 2008 14:30
Favicon

Re: [ft] Adding custom font driver?

Werner LEMBERG wrote:
>>What's the proper way to add a custom font driver to FT, as a FT
>>user, not as a FT developer/maintainer? (ie: I can't just modify a
>>FT build and add my code to the library)
>>
>>Currently (v2.1.7), we do something similar to this: [ NB - C++ ]
>>     static const FT_Driver_ClassRec custom_driver = {
>>              //  Blah blah blah.  Details omitted
>>     };
>>     FT_Add_Module(library, &custom_driver);
>>
>>Upon trying to upgrade to v2.3.5, I'm finding that the
>>FT_Driver_ClassRec structure is in freetype/internal/ftdriver.h,
>>which is no longer publicly accessable.  As such, I'm kindof stumped
>>about how best to proceed.
> 
> This looks indeed like a problem.  David?

Since David doesn't seem to be around (Busy?  Probably...), anyone
have any suggestions?  (Or should I maybe repost on -devel?)

Thanks for any info!
Ian
Permalink | Reply | 3 comments |
headers
Kian T. Gould - AOE media GmbH | 2 Jun 2008 17:34
Picon
Favicon

[ft] Sponsoring Freetype

Hi guys

We are a small OpenSource company in Germany specialised in TYPO3 and due to our close connection to the
OpenSource world we sponsor dozens of successful OpenSource projects that help us in our daily work
and/or are great contributions to the OS world as such. Therefore we have also picked your project as a
possible recipient of sponsorship.

We currently sponsor e.g. PHP, TYPO3, ImageMagick, Horde, DotProject, DokuWiki, Mantis, KDE, RSSOwl,
Serendipity and many more. In general we offer three kinds of sponsorship.

1.         Monthly sponsoring of around 50 to 100 USD
2.         Sponsoring of Rootservers for Mirrors or as webservers.
3.         Redesign of the projects website and delivery as PSD file (e.g. we are currently re-designing PHP.net).

If one of these offers sounds interesting to you, I would be glad to hear from you soon so we can work something
out. All we ask for in return for our sponsorships is a short mentioning somewhere on the page.

Hear from you soon

Kian T. Gould
Geschäftsführer / CEO

AOE media GmbH
Borsigstr. 18
65205 Wiesbaden
Germany  Tel. +49 (0) 6122 58 70 24
Fax. +49 (0) 6122 58 70 99
Mobil: +49 (0) 177 38 191 09

e-Mail: gould <at> aoemedia.de
(Continue reading)

Permalink | Reply | 0 comments |
headers
Werner LEMBERG | 3 Jun 2008 14:57
Picon

Re: [ft] Adding custom font driver?

> >>Currently (v2.1.7), we do something similar to this: [ NB - C++ ]
> >>     static const FT_Driver_ClassRec custom_driver = {
> >>              //  Blah blah blah.  Details omitted
> >>     };
> >>     FT_Add_Module(library, &custom_driver);
> >>
> >>Upon trying to upgrade to v2.3.5, I'm finding that the
> >>FT_Driver_ClassRec structure is in freetype/internal/ftdriver.h,
> >>which is no longer publicly accessable.  As such, I'm kindof stumped
> >>about how best to proceed.
> > This looks indeed like a problem.  David?
> 
> Since David doesn't seem to be around (Busy?  Probably...),

Yes, it seems so.

> anyone have any suggestions?

To solve this temporarily I suggest to add an FT_Driver_ClassRec
structure definition to your project so that you can proceed.  We
don't plan to change its interface, and unless there are objections,
I'll lift this definition from `internal' to `public'.

    Werner
Permalink | Reply | 2 comments |
headers
Ian Britten | 3 Jun 2008 17:25
Favicon

Re: [ft] Adding custom font driver?

Werner LEMBERG wrote:
>>>>Currently (v2.1.7), we do something similar to this: [ NB - C++ ]
>>>>    static const FT_Driver_ClassRec custom_driver = {
>>>>             //  Blah blah blah.  Details omitted
>>>>    };
>>>>    FT_Add_Module(library, &custom_driver);
>>>>
>>>>Upon trying to upgrade to v2.3.5, I'm finding that the
>>>>FT_Driver_ClassRec structure is in freetype/internal/ftdriver.h,
>>>>which is no longer publicly accessable.  As such, I'm kindof stumped
>>>>about how best to proceed.
> 
> To solve this temporarily I suggest to add an FT_Driver_ClassRec
> structure definition to your project so that you can proceed.  We
> don't plan to change its interface, and unless there are objections,
> I'll lift this definition from `internal' to `public'.

Ok, many thanks!  I'll proceed accordingly...

- I assume you would be exposing all the other necessary structures
   and stuff too, eh?  (FT_CMap_InitFunc, FT_DriverRec, etc).
- Do you need/want me to put in a bug somewhere?
- What release would I expect to see this change in?  2.3.6?  2.4?

Thanks!
Ian
Permalink | Reply | 1 comment |
headers
Werner LEMBERG | 4 Jun 2008 08:51
Picon

Re: [ft] Adding custom font driver?


> - I assume you would be exposing all the other necessary structures
>    and stuff too, eh?  (FT_CMap_InitFunc, FT_DriverRec, etc).

Yes.

> - Do you need/want me to put in a bug somewhere?

Not necessary, thanks.

> - What release would I expect to see this change in?  2.3.6?  2.4?

2.3.6, which will appear soon, I think.

    Werner
Permalink | Reply | 0 comments |
headers
Mickey Gabel | 4 Jun 2008 10:38
Picon
Favicon

[ft] Clipping Of Empty Glyphs (space)

Hi all,

I am writing a text rendering library based on FreeType 2.3.5. and 
encountered some problems.

One of the problems I encountered was translation of "empty" glyphs like 
the space character ' '.

	// assume chacater is loaded and copied to glyph[i]
	FT_Glyph_Transform( glyph[i], NULL, &pen_pos[i] );	
	FT_Glyph_Get_CBox( glyph[i], FT_GLYPH_BBOX_PIXELS, &bbox );
	FT_Glyph_To_Bitmap( glyph[i], FT_RENDER_MODE_NORMAL, NULL, 1 );
	DrawBitmap( (FT_BitmapGlyph)glyph[i], clip_region, ... );

I also do some clipping in DrawBitmap(). Everything works just fine so 
far, including clipping, mostly.

My goal is to determine if a glyph is inside the clip region, or 
outside, or partially clipped. It works fine for most glyphs.
However for empty glyphs like ' ' it seems that the CBox (bbox) is all 
zeros, and the bitmap->left and bitmap->top are also some unrelated 
value that ignores the transform I set. For ' ' I was sort of expecting 
a bbox with height 0 but with a real width and position.

Even if these characters don't need to be drawn anyway, I need to 
determine if they are inside the clip_region.
How do I do that?

Thanks,
	Mickey
(Continue reading)

Permalink | Reply | 4 comments |
headers
Werner LEMBERG | 4 Jun 2008 14:21
Picon

Re: [ft] Clipping Of Empty Glyphs (space)

> However for empty glyphs like ' ' it seems that the CBox (bbox) is
> all zeros, and the bitmap->left and bitmap->top are also some
> unrelated value that ignores the transform I set. For ' ' I was sort
> of expecting a bbox with height 0 but with a real width and
> position.
> 
> Even if these characters don't need to be drawn anyway, I need to
> determine if they are inside the clip_region.  How do I do that?

Empty spacing glyphs have non-zero horizontal metrics, so you have to
check those values.

    Werner
Permalink | Reply | 3 comments |
headers
Mickey Gabel | 4 Jun 2008 14:29
Picon
Favicon

Re: [ft] Clipping Of Empty Glyphs (space)

Werner LEMBERG wrote:
>> However for empty glyphs like ' ' it seems that the CBox (bbox) is
>> all zeros, and the bitmap->left and bitmap->top are also some
>> unrelated value that ignores the transform I set. For ' ' I was sort
>> of expecting a bbox with height 0 but with a real width and
>> position.
>>
>> Even if these characters don't need to be drawn anyway, I need to
>> determine if they are inside the clip_region.  How do I do that?
> 
> Empty spacing glyphs have non-zero horizontal metrics, so you have to
> check those values.
> 
> 
>     Werner

Thank you for your help.

Is there a real reason for me to use Get_CBox, then?
I'd like (if it's possible) to treat "real" glyphs and "empty" glyphs in 
a uniform manner.
Should I not simply switch my "engine" to never use CBox, and instead go 
with glyph metris (bearing, advance, width, height) and pen position?
Do empty characters still have an actual width and bearing? Or do I have 
to rely on glyph advance in such special cases?

	Mickey
Permalink | Reply | 2 comments |
headers
Werner LEMBERG | 4 Jun 2008 14:59
Picon

Re: [ft] Clipping Of Empty Glyphs (space)


> Is there a real reason for me to use Get_CBox, then?

Yes.

> I'd like (if it's possible) to treat "real" glyphs and "empty"
> glyphs in a uniform manner.

You can't.  An empty glyph never has something to draw, but it still
has dimensions.  It's a natural non-uniformity.

> Should I not simply switch my "engine" to never use CBox, and
> instead go with glyph metris (bearing, advance, width, height) and
> pen position?

Metrics don't reliably reflect the real dimensions of a glyph.  Just
think of a `O' character -- there's some overshoot below and above the
glyph which is not part of the bounding box given by the metrics.

> Do empty characters still have an actual width and bearing? Or do I
> have to rely on glyph advance in such special cases?

Empty glyphs in general don't have a width or a bearing.  You should
use the advance width for that.

Note that, for example, TeX fonts don't have a space glyph at all
because it is something redundant in general -- in most cases it's the
job of the text formatting engine to adjust the spaces between words
while breaking text into paragraphs.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mickey Gabel | 4 Jun 2008 15:54
Picon
Favicon

Re: [ft] Clipping Of Empty Glyphs (space)

Werner LEMBERG wrote:
> 
> You can't.  An empty glyph never has something to draw, but it still
> has dimensions.  It's a natural non-uniformity.
> 
>> Should I not simply switch my "engine" to never use CBox, and
>> instead go with glyph metris (bearing, advance, width, height) and
>> pen position?
> 
> Metrics don't reliably reflect the real dimensions of a glyph.  Just
> think of a `O' character -- there's some overshoot below and above the
> glyph which is not part of the bounding box given by the metrics.
> 
>> Do empty characters still have an actual width and bearing? Or do I
>> have to rely on glyph advance in such special cases?
> 
> Empty glyphs in general don't have a width or a bearing.  You should
> use the advance width for that.
> 
> Note that, for example, TeX fonts don't have a space glyph at all
> because it is something redundant in general -- in most cases it's the
> job of the text formatting engine to adjust the spaces between words
> while breaking text into paragraphs.
> 
> 
>     Werner

OK, now I also understand the reasoning. Thank you for the excellent 
explanation.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane