[gs-code-review] Patch(es) for bug #688971 "hugeperformaceproblem (with large TT font?)" |

[Leonardo]

Dear SaGS,

> is FAPI expected to work with FreeType 2.1.4 AND Type42 fonts?

It is so by design, but we haven't got practical applications yet.

The FreeType plugin still doesn't work properly.
UFST plugin does, but it is not public.

A FAPI plugin can work with fonts in 2 modes :
1. Handling a PS font - either embedded into a document,
or a disk font installed to Ghostscript.
In this mode FAPI accesses Type 42 font data via ttfReader,
which simply wraps pfont->data.string_proc - see gx_ttfReader__Read.
Thus a proper optimization of string_proc should optimize
ttfReader and FAPI with no additional effort.

2. A PS font emulation with plugin's font technology.
In this case the plugin reads disk or ROM font by own methods.
In this case the plugin (a 3d party software) is responsible for all
access problems, and you must not care about its optimization.

Leo.

----- Original Message ----- 
From: "SaGS" <sags5495 at hotmail.com>
To: "Ray Johnston" <ray.johnston at artifex.com>
Cc: "gs-code-review" <gs-code-review at ghostscript.com>
Sent: Sunday, November 19, 2006 11:24 AM
Subject: Re: [gs-code-review] Patch(es) for bug #688971 
"hugeperformaceproblem (with large TT font?)" |


> ----- Original Message -----
> From: "Ray Johnston" <ray.johnston at artifex.com>
> To: "SaGS" <sags5495 at hotmail.com>
> Cc: "gs-code-review" <gs-code-review at ghostscript.com>
> Sent: Saturday, 18 November 2006 20:51
> Subject: Re: [gs-code-review] Patch(es) for bug #688971 "huge 
> performaceproblem (with large TT font?)" |
>
>
>> Dear SaGS,
>>
>> I am unable to unpack the attachment. Possibly the upload didn't preserve
>> the binary or some other problem.
>>
>> Please send the attachment via email.
>
> Here is it, if still necessary.
>
>
> I also have a question: is FAPI expected to work with FreeType 2.1.4 AND 
> Type42 fonts? I coudn't get FAPI working, so I
> cannot test part (C) (the one for FAPI) at all; I don't even know if there 
> really is a performance problem there (if
> "seek" operations are rare, then optimizing these won't make a 
> difference).
>
> Sincerely yours,
> SaGS
>


--------------------------------------------------------------------------------


> _______________________________________________
> gs-code-review mailing list
> gs-code-review at ghostscript.com
> http://www.ghostscript.com/mailman/listinfo/gs-code-review
>