[cairo] PDF text doesn't render
Baz
brian.ewins at gmail.com
Tue Sep 25 12:35:49 PDT 2007
On 25/09/2007, Kristian Høgsberg <krh at bitplanet.net> wrote:
> On 9/22/07, Baz <brian.ewins at gmail.com> wrote:
> > Ok -pushed. You're right, fixing this properly would be better; it
> > seems that everything we need we already have except a replacement for
> > FT_Get_Glyph_Name. I'll play around.
>
> Oh, heh, that's one of my old TODO-items. I started out using
> freetype for most of the type1 subsetting, but when I was done, most
> of the code just accessed the type1 file directly. I always intended
> to get rid of the remaining FT calls... Anyways, it shouldn't be too
> difficult to extend the code to parse the glyph names and avoid the FT
> dependency here.
It's a little awkward on the atsui side of things, as usual the api is
a bit high-level and the glyph names aren't exposed. I'd assumed that
I'd be grubbing around in the 'post' table, or (yuk) just ignoring the
original glyph names - use the 'standard' names for the western glyphs
plus aXXXX style for the rest (something like post format 4)
I hadn't mentioned this as a possibility because (a) I'd like to avoid
it if at all possible (b) I'm not 100% certain it would work and (c) I
don't think anyone would thank me for adding yet another large static
table of strings.
> > btw there's another call to FT_Load_Glyph in the type1-subset code
> > that can return CAIRO_STATUS_NO_MEMORY. I'm not sure if this would
> > actually happen ie if we had an error loading a glyph to show it, will
> > we still try to use it in the subset? And if we don't find any glyph
> > info, and tried to ignore that error, what would end up in the subset?
>
> Calling FT_Load_Glyph here is overkill, since we just need the width
> and the name of the glyph. Getting rid of the freetype dependency
> here will probably eliminate a couple of error paths too. Are you
> working on a patch now?
That's how I read it too. I havent written a patch yet, I'm back
diffing font embeddings to figure out the mac bug. But my game plan
here was to begin by moving the ft calls into the ft backend, so
instead of testing for 'if (is ft font)' I'd be doing 'if (font
backend fn is not null)', etc. It didn't look too difficult and would
let me add an atsui implementation as an independent patch.
If you've got an alternate plan that doesn't need more work in the
font backend I'd be very interested!
> cheers,
> Kristiani
>
More information about the cairo
mailing list