Bug 689103

Created attachment 2784 [details]
testfile from older fixed bug

Neither the baseline raster nor the output from HEAD is correct.

Revision 7764 shows some changes, but the middle character above the lion's head
is still wrong.  Some strokes are too long, some too short; compared with Adobe
Acrobat 8 Pro.

I put myself on the CC earlier because I can tell it is wrong without 
comparing with acrobat :-). FWIW, the middle character of the 3 above the 
lion is wrong on 8.54 (the one I tried) so some sort of bug seems to be 
around for some time.

Since this was wrong in 8.54, it is not a regression.

Passing to Asian font specialist.

The embedded font is notorious (for OSS people) MingLiU,
a font which cannot be rendered correctly without patented
hinting. I guess it's the reason why the glyph is not
rendered correctly.

I ask for help by the residents in countries where Apple's
hinting patent is not registered or software patent itself
is not accepted: anybody can compare how the rasterization
result changes when "THROW_PATENDED" macro in ttinterp.c
is changed to empty macro?

The original
--------------------------------------------------------
/* The following macro is used to disable algorithms,
   which could cause Apple's patent infringement. */
#define THROW_PATENTED longjmp(find_jmp_buf(CUR.trap), TT_Err_Invalid_Engine)
--------------------------------------------------------

The modified version that can patent infringement
--------------------------------------------------------
/* The following macro is used to disable algorithms,
   which could cause Apple's patent infringement. */
#define THROW_PATENTED
--------------------------------------------------------

If the modified version generates correct rasterization result,
I have no idea to fix this issue, because the "right" solution
requires the patented hinting.

*** Bug 689525 has been marked as a duplicate of this bug. ***

I believe the algorithm won't work if THROW_PATENTED is empty. Also please use 
C debugger to know whether it is executed with the test case, and eliminate "I 
guess".

Created attachment 3650 [details]
gdb trace log: THROW_PATENDED is reached.

I set breakpoint on src/ttinterp.c:223 (defines THROW_PATENDED)
and execute the sample PS file. As I attached log, the execution
is interrupted - gs reached to THROW_PATENDED (it seems that
THROW_PATENDED executed only once). However, I cannot check
the rasterization result if THROW_PATENDED is skipped, because
Apple hinting patent might be registered.

(gdb) where
#0  Norm (X=-200704, Y=-2703360) at ./src/ttinterp.c:541
#1  0x0808bcf6 in Normalize (exc=0x8e028c8, Vx=-200704, Vy=-2703360,
R=0x8e02b6c) at ./src/ttinterp.c:1514
#2  0x0808d389 in Ins_SxVTL (exc=0x8e028c8, aIdx1=153, aIdx2=147, aOpc=6,
Vec=0x8e02b6c) at ./src/ttinterp.c:2695
#3  0x0808d3f7 in Ins_SPVTL (exc=0x8e028c8, args=0x9180ee8) at
./src/ttinterp.c:2714
#4  0x08091238 in RunIns (exc=0x8e028c8) at ./src/ttinterp.c:5213
#5  0x08092cf3 in Context_Run (exec=0x8e028c8, debug=0) at ./src/ttobjs.c:466
#6  0x08088ba8 in ttfOutliner__BuildGlyphOutlineAux (this=0xbf996160,
glyphIndex=18016, m_orig=0xbf996060, gOutline=0xbf996188)
    at ./src/ttfmain.c:694
#7  0x08089477 in ttfOutliner__BuildGlyphOutline (this=0xbf996160,
glyphIndex=18016, orig_x=0, orig_y=0, gOutline=0xbf996188)
    at ./src/ttfmain.c:842

...[snip]

Well, this case uses a patented feature, which Artifex has not obtained a 
license for. I'll assign the bug to Ralph who I believe works on patents. 
Thanks to Toshiya for the good analyzis.

There is no code in ttinterp.c to actually implement the TrueType opcode in
question. If you eliminate the THROW_PATENTED macro then the code simply returns
0, and does nothing. Pretty much the same as with the macro in place.

The font does exercise that opcode, and in general you can't simply miss out
operations without deleterious effects, so I'd say its a pretty good bet that
this is the problem. Especially since the comment describes this as 'computes
the projection of Vx, Vy along the projection vector'. 

Note that I see 4 contour problems in this text, and the opcode is only used
once, so I suspect there may be some other problem (but its hard to be certain
with TrueType). Breaking down the problem to the two glyphs, and making two
different test files, one for each glyph would allow you to check if the opcode
is called once for each glyph, or if one of the glyphs does not use it.

Assuming the unimplemented opcode is the problem, I can't see any solution other
than to implement it. Which we can't do because its patented, apparently.

I think that patent expires in the not too distant future though. Hmm, two were
filed in May 1989, the third in May 1992. So at least another 18 months.

Thanks Ken, I agree with your pointing out:
the sample is too huge to guarantee the breakpoint set to
THROW_PATENT was reached during the rendering of problematic glyph.

I will revise the sample or make another sample for atomic test.

Created attachment 3653 [details]
PDF including the problematic MingLiU character U+9C02

An atomic PDF including the problematic glyph:
Adobe Reader displays correctly but
Ghostscript displays incorrectly.
It uses a patented operator SPVTL, thus gdb hits
the breakpoint which is set to THROW_PATENDED.

Created attachment 3654 [details]
Modified PDF including the problematic MingLiU character U+9C02

a patented SPVTL operator is replaced by unpatended (maybe) SFVTPV operator.

The original PDF (previous attachment)
--------------------------------------

SPVTL is used in fpgm table of MingLiU. In the PDF...

005320 60 12 2d 2c 43 60 39 2d 2c b0 27 43 60 20 10 20
005330 8a b0 27 43 60 20 8a 06 0e 23 49 b0 28 23 42 2d

5336 8a = ROLL
5337 06 = SPVTL
5338 0e = SFVTPV
5339 23 = SWAP
533a 49 = MD
533b b0 = PUSHB1
533c 28 = 40
533d 23 = SWAP
533e 42 = WS
533f 2d = ENDF			     

The gdb traces executed operators as:

Ins_RS
Ins_ADD
Ins_DUP
Ins_ROLL
Ins_SPVTL <-- reaches THROW_PATENDED
Ins_SFVTPV
Ins_SWAP
Ins_MD

The modified PDF (current attachment)
-------------------------------------
In attached PDF, I replaced 0x06 (SPVTL) at 0x5337 by
0x0e (SFVTPV). If there's an operator that just
discards 2 objects from stack, I want to use it (to
emulate the behaviour of ghostscript), but there's no,
so I used similar operator SFVTPV, like this:

005330 8a b0 27 43 60 20 8a 0e 0e 23 49 b0 28 23 42 2d

5336 8a = ROLL
5337 0e = SFVTPV
5338 0e = SFVTPV
5339 23 = SWAP
533a 49 = MD
533b b0 = PUSHB1
533c 28 = 40
533d 23 = SWAP
533e 42 = WS
533f 2d = ENDF			     

The gdb traces executed operators as:

Ins_RS
Ins_ADD
Ins_DUP
Ins_ROLL
Ins_SFVTPV <-- replaced operator, does not reaches THROW_PATENDED
Ins_SFVTPV
Ins_SWAP
Ins_MD

gdb does not reach THROW_PATENDED at all (during whole
interpretation of the PDF).

Both of Adobe Reader and Ghostscript displays incorrectly.
The broken form is similar to the rasterization result of
original PDF by ghostscript.

In summary, I think the implementation of SPVTL is required
to close this issue.

Passing to Ralph who handles licensing issues.

We can't implement the patented instruction at this time. The patent expires in
a few years. Until then we must find some other workaround, or just say we
cannot  handle this file.

Checking current code this file now renders correctly. We now use FreeType 2, which implements the patented instructions.