freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Devel] mailing list archive; patch submission


From: Dirck Blaskey
Subject: Re: [Devel] mailing list archive; patch submission
Date: Thu, 28 Jun 2001 13:37:33 -0700

Tom,

Here are some more details;

for CID/CFF, in cffload.c:

in CFF_Load_Font,  CFF_Load_FD_Select uses charstrings_index.count,
not dict->cid_count (from Adobe's 5167.CFF.pdf spec), so 
the charstrings index has to be loaded first, and then I set 
dict->cid_count = font->charstrings_index.count before 
calling CFF_Load_FD_Select.  Setting cid_count probably isn't cool, 
because the value may be needed later,  but for now it fixed this call 
and the num_glyphs thing in cffobjs.c.  

The next problem has to do with encodings.  
The font encoding is a literal array of DBCS character values, 
so CFF_Load_Encoding is pretty much irrelevent, and the functionality 
has to be replaced with something I haven't come up with yet.
Basically, given a DBCS character, it has to search the array 
and return the index.  I don't think I want to preallocate the whole 
DBCS mapping of 16000 or so characters, though it's certainly doable, 
if somewhat extravagant.

I'm not sure what's going to come up next after that. -
I also have some problems up in the PDF application to deal with.

I suppose I may be out on a limb here - if I get these issues sorted
out, is this likely to work, or is this beyond the bounds of what it
will do?

...

for Type42 (TrueType) in ttload.c

TT_Load_SFNT_Header, around:
    /* now, check the values of `num_tables', `seach_range', etc. */

    my type42 font has a bogus entry_selector specwise,
    it is equal to num_tables before it is shifted.  I check for
    this and skip the error.

TT_Load_Names, around
    /* The name table is required so indicate failure. */

    there is no name table in the font, returned no error

TT_Load_CMap, around
    error = TT_Err_CMap_Table_Missing;

    also ignored this error.  

Postscript has an encoding external to the font, so the internal
names table and cmap aren't needed, and are literally missing.

I would be happy to provide the postscript and pdf or the
extracted fonts if you would like to take a look, or anything
else, just let me know.

d
    
----- Original Message ----- 
From: "Tom Kacvinsky" <address@hidden>
To: "FreeType Development" <address@hidden>
Sent: Thursday, June 28, 2001 1:06 PM
Subject: Re: [Devel] mailing list archive; patch submission


> Hi,
> 
> >
> > *) I have patches to sfnt/ttload.c to handle some
> > 'incomplete' type42 fonts in postscript, and i'm working on
> > patches to cff/cffload.c (and probably other) to get
> > Type0/CID/CFF Japanese fonts to work in a pdf application.
> >
> 
> This is the list where you send patches.
> 
> I am interested in your patches to the cffload.c.  What exactly are you
> adding to make this "work" with CID fonts in CFF format?
> 
> > Is there a standard person to send patches to?
> > Any known fixes/work I might be replication?
> 
> I don't know of anyone working on a Type 42 driver.  I wouldn't know if
> there is replication in the CFF stuff until you tell me what you plan on
> doing (if it involes Unicode stuff, yes, there is duplication)
> 
> Tom
> 
> 
> _______________________________________________
> Devel mailing list
> address@hidden
> http://www.freetype.org/mailman/listinfo/devel
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]