The characters just above the lion are missing some strokes, compared with Adobe. file BUG687698.ps 687698 was a different bug and was fixed. The same test file now shows a different defect.
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.