[lucida] Bug in lucida ligature handling

[Jaap-Henk Hoepman]

And yet another data point: when running
	ps2pdf -dCompatibilityLevel=1.1
the ffl is displayed correctly in Bluebeam pdf revu, but then Acrobat
complains it cannot extract the embedded font (and as a result only
shows dots...)

Jaap-Henk

On 02/08/2012 20:39, Jaap-Henk Hoepman wrote:
> Hi,
> 
> Some more (weird) datapoints. I managed to find an old .pdf with
> corresponding .ps that was used to create the .pdf with (back then) AFPL
> Ghostscript 7.0. If I view that .pdf in Bluebeam PDF revu the ffl
> ligature is displayed correctly.
> 
> If I then use the _same_ .ps file to create a .pdf file today, the
> resulting .pdf will _not_ show the ffl ligature in Bluebeam PDF revu
> (but will in Acrobat). It doesn't matter whether I generate the .pdf
> using GPL Ghostscript 9.04, Acrobat, or Distiller...
> 
> As the .ps is self contained (full .pfb for each font, with all encoding
> information), it seems as if the meaning of 'standard encoding' against
> which fonts are apparently reencoded when creating a .pdf file has
> somehow changed over the years. The original .ps (and .pdf) file are
> from 1999...
> 
> Any ideas would be very much appreciated... I only started to see these
> issues a year or so ago, when I started to use Bluebeam PDF revu to
> annotate pdf's on my tablet.
> 
> Jaap-Henk
> 
> On 02/08/2012 13:55, Jaap-Henk Hoepman wrote:
>> Hi,
>>
>> There appears to be a problem in the way ligatures are handled for the
>> lucida fonts. In particular, the \ffl ligature is displayed as a white
>> box, but _only_ when viewed with Bluebeam Pdf Revu and _only_ when the
>> .pdf is produced from the .ps that was produced using dvips. In the
>> latter case it doesn't matter whether ps2pdf was used or "Convert to
>> Adobe PDF" under windows.
>>
>> In other words
>> - the .pdf displays fine in Acrobat (and PdfAnnotator)
>> - the .pdf also displays fine in Bluebeam Pdf Revu if it is generated
>> directly from the latex source using pdflatex (but not when generated
>> from the .ps file).
>>
>> Note that the .ps file views fine in ghostview.
>>
>> The problem seems to be related to the following snippet of .pdf
>>
>> 8 0 obj
>> <</BaseFont/TVCKVO+LucidaBright/FontDescriptor 9 0 R/Type/Font
>> /FirstChar 8/LastChar 121/Widths[ 663 0 0 0 657 0 994 1000
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 608 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 543 0 509 642 530 0 0 0 307 0 0 313 0 633 602
>> 642 0 0 504 0 0 0 795 0 551]
>> /Encoding 13 0 R/Subtype/Type1>>
>> endobj
>> 13 0 obj
>> <</Type/Encoding/BaseEncoding/WinAnsiEncoding/Differences[
>> 8/fl
>> 12/fi
>> 14/ffi/ffl]>>
>> endobj
>>
>> If I remove the encoding object (obj 13) or if I remove /Encoding 13
>> from the font object (obj 8) the file displays fine in Bluebeam PDF Revu.
>>
>> I have not been able to determine which parts of the .ps file lead to
>> the above snippet of .pdf.
>>
>> What gives?
>>
>> Best,
>> Jaap-Henk
>>
> 

-- 
Jaap-Henk Hoepman            |  Sure! We've eaten off the silver
TNO, Groningen &             |  (when even food was against us)
Radboud University Nijmegen  |    - The Birthday Party "Just You and Me"
(e) jhh at cs.ru.nl /           |
    jaap-henk.hoepman at tno.nl | (m) +31 6 20619554
(w) www.cs.ru.nl/~jhh        | (t) @xotoxot