freetype-devel
[Top][All Lists]
Advanced

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

Re: [ft-devel] [GSoC] Extending the CF2 interpreter


From: Dave Arnold
Subject: Re: [ft-devel] [GSoC] Extending the CF2 interpreter
Date: Wed, 21 Jun 2017 10:01:34 -0700
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0

Hi Ewald,

I'm not familiar with the FreeType Type 1 code, but Adobe has a combined CFF+Type 1 interpreter where the "PostScript stack" is implemented by a simple array of 3 Fixed elements. I see a comment about a change to "skip the unique id check", if that helps.

The large number operator (255) expects small Type 1 values to be integers, converted to Fixed by << 16 (thus zero fraction). Large values are converted to Fixed by a subsequent div operator, and there is no shift when the numerator is pushed on the stack. CFF values are expected to already be Fixed, so there is no shift.

-Dave


On 6/20/2017 4:26 AM, Ewald Hew wrote:
Hi,

I have now started merging Type 1 processing into the CF2
interpreter `cf2_interpT2CharString'. After considering the structure
of the interpreter I decided to put the control logic for shared
commands outside, i.e. inside the glyphpath functions, etc. instead.

Now, the differences in control flow and operand stack management
between the Type 1 and CF2 interpreter make this a non-trivial merge.

First off, the `callothersubr' operator is Type 1 only. So, in the old
interpreter, it simply leaves the results on top, 'pushing' them by
incrementing the pointer, or in the case of an unknown subr, waits for
the `pop' operator to do the same, that is, nothing is done and the
operands for `callothersubr' are left for subsequent `pop's. This is
not possible with `CF2_Stack', so we need some extra memory to hold
these ignored operands if they should be needed later.

What I understand from the spec is that there are two stacks, the
interpreter one and the PostScript one, but the latter has been
abbreviated in the old interpreter and not present in the new one. So
I could simply introduce another stack in which to store
`callothersubr' results in, implementing `pop' in the correct manner,
i.e. pop from one and push to the other. Is the cost of maintaining
another stack significant?

Also, is the different treatment of large numbers (charstring byte
255) between Type 1 and CFF a problem, control flow aside? Please tell
me if you know of any potential issues.

Regards,
Ewald

P.S.  Is it OK if I rebase my clean git branch onto master every so
often and do forced updates? Not exactly best practices but seems
easiest. Also, I'll delete the old `ewaldhew-refactor-cf2' branch as
it's no longer needed.

_______________________________________________
Freetype-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/freetype-devel
.



reply via email to

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