Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(684)

Issue 5846051: Modify SkFontHost_FreeType to allow for a client to control the FT_Face object (Closed)

Can't Edit
Can't Publish+Mail
Start Review
Created:
12 years ago by gw280
Modified:
11 years, 8 months ago
Reviewers:
bungeman, reed1
Base URL:
http://skia.googlecode.com/svn/trunk/
Visibility:
Public.

Description

Modify SkFontHost_FreeType to allow for a client to control the FT_Face object

Patch Set 1 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+174 lines, -12 lines) Patch
A include/ports/SkTypeface_FreeType.h View 1 chunk +19 lines, -0 lines 0 comments Download
M src/ports/SkFontHost_FreeType.cpp View 11 chunks +155 lines, -12 lines 0 comments Download

Messages

Total messages: 8
gw280
12 years ago (2012-03-16 20:55:04 UTC) #1
gw280
So my understanding is that FreeType is not thread safe, so to overcome this we ...
12 years ago (2012-03-16 20:56:49 UTC) #2
reed1
Ben, could you also take a look at this. Things that come to mind: 1. ...
12 years ago (2012-03-19 21:19:38 UTC) #3
bungeman
The first issue which stands out to me is the cross library FT_Face. The GDI ...
11 years, 11 months ago (2012-04-10 19:32:00 UTC) #4
bungeman
For an example of how the above can be done with fontconfig, see Chrome souce ...
11 years, 11 months ago (2012-04-10 19:48:39 UTC) #5
gw280
On 2012/04/10 19:32:00, bungeman wrote: > The first issue which stands out to me is ...
11 years, 10 months ago (2012-05-08 20:29:33 UTC) #6
bungeman
On 2012/05/08 20:29:33, gwright wrote: > On 2012/04/10 19:32:00, bungeman wrote: > > The first ...
11 years, 10 months ago (2012-05-14 21:37:49 UTC) #7
gw280
11 years, 10 months ago (2012-05-14 21:45:21 UTC) #8
On 2012/05/14 21:37:49, bungeman wrote:
> > We can do this, however it doesn't map too well to our internal gfx APIs,
> which
> > wrap an underlying font object for the platform we're dealing with with no
> > obvious way to get the memory data backing the font object. We do all our
own
> > font selection so SkFontHost_FreeType not knowing how to find any fonts is
> ideal
> > for us (we do all our own selection via FontConfig before it gets to Skia).
> 
> What I described seems to map rather well to the existing internal gfx APIs.
> What I am proposing is simply treating Skia as the platform and passing around
> SkTypeface as the platform font (because that's how it was written to be
used).
> Whether Skia happens to use FreeType under the hood or not should be
immaterial.

Well the issue we have is that then we'd have an internal implementation of
gfxFont (this is in Gecko) that would be Skia specific, whereas ideally we'd
like to be able to share our font code between backends on the same platform.
i.e. - on Linux we use gfxFontFreeType, on Windows we use gfxFontWindows, etc. I
guess what I'm really after is to be able to have an API in Skia that's
analogous to Cairo's cairo_ft_font_face_create_for_ft_face().

Whilst we could conceivably create a new set of gfxFont classes which speak
Skia/SkTypeface internally, it seems to make more sense for us to implement it
in terms of the lowest common denominator between our backends, which is
Freetype.
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b