[Top][All Lists]

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

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

From: Ewald Hew
Subject: [ft-devel] [GSoC] Extending the CF2 interpreter
Date: Tue, 20 Jun 2017 19:26:56 +0800


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.


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.

reply via email to

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