Re: Something wrong with this PDF to PS conversion

On 29 September 2016 at 22:11, Ken Sharp <[email protected]> wrote:
> Youy could also try using Ghostscript's ps2write device to produce the
> PostScript. I note that Ghostscript interprets and renders the original PDF
> file without problems.
>
> If I create PostScript using the ps2write device then that also can be
> interpreted and rendered correctly. Looks like the problem lies in the Apple
> PostScript production.  As Chris says, there is no likely prospect of us
> fixing this, perhaps you should report it to Apple.
>

Ah, I missed the fact that the original PDF was attached......

So the TTF embedded in the original PDF *does* have the required cmap
table, so it very much looks like the conversion Postscript broke the
TTF data.

Therefore, in a revision to my previous comment, the only solution
would be use a PDF->PS conversion that doesn't break the font.

Chris

>
> On 29 September 2016 at 22:04, Chris Liddell <[email protected]>
> wrote:
>>
>> On 29 September 2016 at 16:14, Alex Korobkin <[email protected]>
>> wrote:
>> > You guys are pro at deciphering PostScript, I was hoping you can help me
>> > with this problem below. I don't know where else to ask.
>> >
>> > Here is a seemingly valid roboto.pdf with a single line of text and one
>> > special character, å. When this PDF is passed through cgpdftops (Apple's
>> > PS
>> > filter), it comes out invalid.
>> >
>> > GhostScript would say:
>> > GPL Ghostscript 9.05: Error: Font Renderer Plugin ( FreeType ) return
>> > code =
>> > -10
>> > Can't render Font RGEZEM+Roboto-Regular with FAPI, will do with native
>> > GS
>> > renderer.
>> > Can't render Font F1.1 ( aliased from RGEZEM+Roboto-Regular ) with FAPI,
>> > will do with native GS renderer.
>> >
>> > ERROR: rangecheck
>> > Offending command: show
>> >
>> > Stack: (!)
>> >
>> > What's wrong with the way this PS conversion was done?
>> > Could the original PDF be encoded in a different way to avoid this?
>>
>> There's a broken Truetype font in the Postscript - it lacks a cmap
>> table which is a mandatory table in Truetype. It also looks like some
>> offsets or table lengths are wrong.
>>
>> The way to avoid this problem would be to use a non-broken TTF......
>>
>> I doubt whether it is feasible to make the Postscript interpreter any
>> more tolerant of such problems.
>>
>> Chris
>
>